It might be said that any software codebase and architecture initially resembles spaghetti code by being incomprehensible at first to any but an acolyte deeply familiar with its design.
The Big Ball of Mud architecture pattern was proposed by Foote and Yoder (Foote et al. 2000) as an 'anti-pattern' in software design and an inevitable consequence of the forces experienced by development. Development takes place within an environment of contrary forces and time pressure that imposes restrictions, constraints etc. on 'proper' design. For example, foundational design concepts such as coupling and cohesion of code modules are gradually broken and so architectural integrity degrades over time due to the ad hoc nature of evolving needs, requirements, and bug fixing. Boehm claimed that both ends of the lifecycle spectrum, ‘Code and Fix’ and Stagewise models end up producing unmanagable code or programs that fail to address the customer's goals (Boehm 1988). Foote and Yoder take an alternate view, that life cyle isn't the problem, the problem is intrinsic to code that succeeds and therefore needs to be maintained over a long time. They suggest that the BBM pattern is present as entropy, an attractor to disorder that imposes a constant tension on code but one that can be resisted through the practice of Refactoring.
"A certain amount of controlled chaos is natural during construction, and can be tolerated, as long as you clean up after yourself eventually. Even beyond this though, a complex system may be an accurate reflection of our immature understanding of a complex problem." (Foote & Yodder, 2000)
On the mysterious mound builders of Mountain View.
Brian Foote observes that in the years since he and Yoder wrote the article, "that no one has ever challenged our premise. No one has ever said 'no it isn't the most frequently deployed architecture out there', 'it isn't what we're all doing'" (Foote, 2007: 17'29")
One of the dynamics that produces BBM is turnover. "All too many people get onto projects, beat the heck out of the code, and move onto the next project. The code 'dies', the code is unmaintainable, nothing else can grow there, the enterprise founders, the end of the story." (Foote, 2007: 30'35")
The messiness of the relationship between code, architecture, and design may again be an intrinsic facet of software. Richard P. Gabriel (link) is credited with the counter-intuitive adage that 'worse is better' to characterise the dynamics of software acceptance. Subtly it can be understood from two perspectives, the developer and the user. From the developer's perspective worse code may produce better results for the user. From the user's perspective less features (worse) may be better because simplicity is what the need rather than what they want.
REFERENCES
Big Ball of Mud: Foote, B. & Yoder, J. (2000) Big Ball of Mud. IN HARRISON, N., FOOTE, B. & ROHNERT, H. (Eds.) Pattern languages of program design 4. Addison Wesley. (version online)
A wiki discussion on one of BBM's topics at Ward Cunningham's c2.com (link) - photo credit JohnLennon shovels on the spaghetti in cover art from the Magical Mystery Tour.
Foote, B. (2007) Big ball of Mud. Google Tech Talks.
