Spaghetti code

AntiPattern Name: Spaghetti Code
Most Applicable Scale: Application
Refactored Solution Name: Software Refactoring, Code Cleanup
Refactored Solution Type: Software
Root Causes: Ignorance, Sloth
Unbalanced Forces: Management of Complexity, Change
Anecdotal Evidence:

“Ugh! What a mess!”
“You do realize that the language supports more than one function, right?”
“It’s easier to rewrite this code than to attempt to modify it.”
“Software engineers don’t write spaghetti code.”
“The quality of your software structure is an investment for future modification and extension.”

Background

The Spaghetti Code AntiPattern is the classic and most famous AntiPattern; it has existed in one form or another since the invention of programming languages. Nonobject-oriented languages appear to be more susceptible to this AntiPattern, but it is fairly common among developers who have yet to fully master the advanced concepts underlying object orientation.

General Form

Spaghetti Code appears as a program or system that contains very little software structure. Coding and progressive extensions compromise the software structure to such an extent that the structure lacks clarity, even to the original developer, if he or she is away from the software for any length of time.

If developed using an object-oriented language, the software may include a small number of objects that contain methods with very large implementations that invoke a single, multistage process flow.

Furthermore, the object methods are invoked in a very predictable manner, and there is a negligible degree of dynamic interaction between the objects in the system. The system is very difficult to maintain and extend, and there is no opportunity to reuse the objects and modules in other similar systems.
Symptoms And Consequences
After code

mining, only parts of object and methods seem suitable for reuse. Mining Spaghetti Code can often be a poor return on investment; this should be taken into account before a decision to mine is made.
Methods are very process-oriented; frequently, in fact, objects are named as processes.
The flow of execution is dictated by object implementation, not by the clients of the objects.
Minimal relationships exist between objects.
Many object methods have no parameters, and utilize class or global variables for processing.
The pattern of use of objects is very predictable.
Code is difficult to reuse, and when it is, it is often through cloning. In many cases, however, code is never considered for reuse.
Object-oriented talent from industry is difficult to retain.
Benefits of object orientation are lost; inheritance is not used to extend the system; polymorphism is not used.
Follow-on maintenance efforts contribute to the problem.
Software quickly reaches a point of diminishing returns; the effort involved in maintaining an existing code base is greater than the cost of developing a new solution from the ground up.
Typical Causes
Inexperience with object-oriented design technologies.
No mentoring in place; ineffective code reviews.
No design prior to implementation.
Frequently the result of developers working in isolation.
Known Exceptions

The Spaghetti Code AntiPattern is reasonably acceptable when the interfaces are coherent and only the implementation is spaghetti. This is somewhat like wrapping a nonobject-oriented piece of code. If the lifetime of the component is short and cleanly isolated from the rest of the system, then some amount of poor code may be tolerable.