The "Big Ball of Mud" Pattern
laputan.org
laputan.org
Here's a personal account of ball of mud code:
(from my comment on http://blogs.smugmug.com/don/2007/04/07/how-to-wreck-your-brand/ )
I worked with them [Sony] on the development of their http://musicstore.connect.com/ site that was their attempted 'iTunes Store killer' (just saying that makes me chuckle). Wow, what a mess. Talk about spaghetti code that had mushroomed into a giant ball of mud. It was way over budget and took much longer than anyone anticipated. And a year later, it still only supports Internet Explorer and Windows.
My take on what went wrong in this instance: they did not manage complexity.
They let it grow and grow and did not believe that 'code debt' was a reality. It soon took 10 times longer to make even the simplest changes because of the very poor state of the code.
I have seen this happen at several companies and it's usually the same story. There are B and C level coders that don't understand the dangers or code complexity or code debt and thus create loads of both. The A level coders that do understand this try to explain the growing problem to management. The management doesn't know any better, so they see code cleanup as a needless expense that will only slow down rolling out new features and so they side with the B and C level coders. Of course, the irony is that development will eventually crawl to a near halt because the code is undecipherable. Along the way the A level coders get so frustrated with the state of the code base that they leave the company for greener pastures. This is the critical turning point since the B and C level coders will only hire other B and C level coders - and the project will die a slow death as the cycle continues.