“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.”
—Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
In a development team, people are focused day to day to complete enhancements and/or new tickets. Generally the initial work of setting up the architecture is long over. The understanding of the structures set up and shortcuts thereafter due to exception requirements and a need to deliver ‘yesterday’ usually end up as residue and new dependencies in the code. After a while it is easy to identify codebases that are deemed unfit for consumption.
How do you know if the codebase you’re dealing with is Spaghetti ?
If you’re reviewing new code – well that is simple: as you’re reading the code it makes you proud of the team or person that contributed to it.
There are a lot of other measures: Cyclomatic Complexity, N-Path metrics, dependency mapping, Unused code etc. It is mathematically impossible to determine all unused code via static analysis, however it can provide useful results. A runtime comprehensive usage metrics determination is difficult, depending on the complexity and data needs – it can be nearly impossible to detect unused code. At work, I am working on a strategy that is going to take a million plus lines of code and begin a “cleanup” project. Lining up spaghetti in a big bowl of mud will be challenging. I will post strategies I employ, tactics I use, the tools that prove useful, and the technologies that help in the coming month.
—Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
In a development team, people are focused day to day to complete enhancements and/or new tickets. Generally the initial work of setting up the architecture is long over. The understanding of the structures set up and shortcuts thereafter due to exception requirements and a need to deliver ‘yesterday’ usually end up as residue and new dependencies in the code. After a while it is easy to identify codebases that are deemed unfit for consumption.
How do you know if the codebase you’re dealing with is Spaghetti ?
If you’re reviewing new code – well that is simple: as you’re reading the code it makes you proud of the team or person that contributed to it.
There are a lot of other measures: Cyclomatic Complexity, N-Path metrics, dependency mapping, Unused code etc. It is mathematically impossible to determine all unused code via static analysis, however it can provide useful results. A runtime comprehensive usage metrics determination is difficult, depending on the complexity and data needs – it can be nearly impossible to detect unused code. At work, I am working on a strategy that is going to take a million plus lines of code and begin a “cleanup” project. Lining up spaghetti in a big bowl of mud will be challenging. I will post strategies I employ, tactics I use, the tools that prove useful, and the technologies that help in the coming month.
