How it is done is as important as having it done. —Eduardo Namur
It is still a sad reality that many software development projects are in bad conditions, and some might even be in a serious crisis.
The reasons for this are manifold. Some projects, for example, are afflicted because of lousy project management.
In other projects, the conditions and requirements are constantly changed, but the process does not support this high-dynamic environment.
In some projects there are pure technical reasons: their code is of poor quality. That does not necessarily mean that the code is not working correctly.
Its external quality, measured by the quality assurance department using black box, user, or acceptance tests, can be pretty high. It can pass the QA without complaints, and the test report says that they find nothing wrong.
Also users of the software may be satisfied and happy, and its development has been completed on time and budget (... which is rare, I know).
Everything seems to be fine ... really everything?
Nevertheless, the internal quality of this code, which might work correctly, can be very poor. Often the code is difficult to understand and horrible to maintain and extend. Countless software units, like classes, or functions, are very large, some of them with thousands of lines of code.
Too many dependencies between software units lead to unwanted side effects if something is changed. The software has no perceivable architecture.
Its structure seems to be randomly originated and some developers speak about “historically grown software” or “architecture by accident.”
Classes, functions, variables, and constants have bad and mysterious names, and the code is littered with lots of comments: some of them are outdated, just describe obvious things, or are plain wrong.
Developers are afraid to change something or to extend the software because they know that it is rotten and fragile, and they know that unit test coverage is poor, if there are any unit tests at all.
“Never touch a running system” is a statement that is frequently heard in such kinds of projects. The implementation of a new feature doesn’t need a few days until it is ready for deployment; it takes several weeks or even months.
Such a kind of bad software is often referred to as a Big Ball Of Mud. This term was first used in 1997 by Brian Foote and Joseph W. Yoder in a paper for the Fourth Conference on Patterns Languages of Programs (PLoP ’97/EuroPLoP ’97).
Foote and Yoder describe the Big Ball Of Mud as “... a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle.”
Such software systems are costly and time-wasting maintenance nightmares, and they can bring a development organization to its knees!
The pathological phenomena just described can be found in software projects in all industrial sectors and domains. The programming language used doesn’t matter.
You’ll find Big Ball Of Muds written in Java, PHP, C, C#, C++, or any other more or less popular language. But why is that so?
