To talk about Design Patterns is to talk about software architecture; and software architecture is one of those things that everybody knows is right to do but very its actually done in very few projects . Extensive information has been written about the subject of why is it so difficult to produce clean code, and one of my favourites is the BIG BALL OF MUD paper. I find it really funny to read such denigrating description of software architecture so many times in a serious paper.
A BIG BALL OF MUD is one of the most common anti-patterns in software projects: spaghetti code that evolved (and possibly started) without any identifiable structure, where information is promiscuously shared by everybody, where the names of the so many variables and functions lack any meaning at best and could be misleading at worst, where there are patches fixing patches that try to hide nasty bugs, big piles of code that is unused but somehow removing it breaks the whole system, code where any change required needs to be done in at least three different places that seem full copies of each other but have unnoticeable differences. And code that induces fear any developer’s soul that dares to touch it in order to apply another patch. Like trying to put a banana skin on top of a pile of garbage at the edge of collapsing.
BIG BALLS OF MUD become a burden to a business because of the maintenance costs they represent. Every change to the code takes a considerable amount of time, and often breaks something in totally unexpected ways, leading to constant full regression tests of the system at best, or to constant complaints and consumer confidence degradation, up to the point at which they switch to another system as soon as they can. Contracts are not renewed, projects are canceled. To add to the problem, BIG BALLS OF MUD have been there for some time, so perhaps the original developers are no longer working on the system or even on the company, making it more costly to make changes introduced by inexperienced developers, as they have a hard time trying to understand the original philosophy behind the technical decisions taken by the original developers.
If these kind of systems are so bad, why are they so common? It turns out there are powerful forces behind them:
Cost and Time. Introducing an architecture strategy to the system is costly. Time needs to be invested in thinking about good ways to solve the problem, diagrams are drawn, discussions need to happen, decisions need to be taken. On some projects there’s a small window to market, so that if the product is not released within that window it will not succeed. Think about systems aimed at a specific event like Christmas or a scheduled concert. There are also projects run by startups, where there’s a finite amount of money. If the product is not released soon and starts bringing in money before the seed capital runs out, the little company goes bankrupt.
The system already works. This problem is difficult to solve because a system is like a building that you can only see from the outside, unless you are a developer. The only things that people see are the outside doors, windows, paintings, the shape of the building, how it illuminates at night, and if it looks ok then everything is right. But the outer building and the inner building are two totally separate entities. While people only see the exterior, the interior may be as disparate as an inconceivable maze where there are leaks everywhere, plumbery falling from the ceiling, wires crossing the floor next to the bathroom, inner windows leading to a wall, “Don’t Touch” signs everywhere, even a hidden basement that doubles the size of the building but nobody enters because the key is missing and the legend says some kind of creature lives there. Or perhaps the interior may be a beautiful cathedral with famous paintings and a fountain, while the exterior is a standard, boring, gray and dirty building with some windows crashed. People taking the decisions about the future of the system only see the outer building.
Frequent changes. People is getting used to more complex systems, and adding to the problem is the fact that people doesn’t know exactly what they want from the beginning, but generally the idea evolves as time passes. One can imagine a beautiful green user interface, but when it becomes real it doesn’t look so good, so it needs to be changed. Or perhaps the world changed and the system needs to cope with that, like a payroll system where every year there are tax changes dictated by the capricious feelings of the government in turn.
Skills. Even if the team is committed to give some kind of structure and architecture to a system, specific knowledge is needed to succeed. You cannot ask a fast food cooker to cook a gourmet dinner.
Essential complexity. Software development is a wicked problem. Often you don’t know how to solve it until you solve it first, and that has a direct relationship with the fact that you cannot tell exactly how much time it takes to be solved. A well designed system depends on knowledge of the specific problem domain that it tries to solve. Often the problem domain is not well understood, so people make their best guesses given the available information. This is where an iterative approach excels because you are solving the same problem again and again, but each time you get to know better the problem domain. Sometimes systems are ugly because the problem they address is ugly.