There’s an old article on the web about balls of mud, defined by the article as:
“A big ball of mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. 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.”
It’s almost as if the balls of mud are genetically predisposed to existing. It probably is the most common phenotype of software out there. The article also includes a pretty thought-provoking analysis of why they appear. Now, this article is quite old, and the problem it’s describes is even older. It begs the question as to why these mud balls are so prominent in spite of decades of well-meaning development methodologies.
It seems that none of these processes have worked, because people still produce mud balls all the time.
- Software engineering was supposed to make us programmers into engineers. At least that was the original purpose of the term, though it has now evolved into an umbrella term that encompasses all other methodologies. The gist of the idea was that by eliminating the rock’n roll hacker mentality of developers and tuning all developers onto the idea that engineering software should be done like you would engineer a bridge. With requirements and analysis and calculations. It didn’t work, because programming isn’t engineering.
- The waterfall model, nowadays usually more ridiculed than followed seems to try to solve the mud problem by eliminating change once development has started. This is a great idea, except for the nasty thing called reality where requirements change all the time. So it didn’t work.
Code craftmanship is perhaps the latest and most prominent way of addressing mudballs, except that it really doesn’t. It only says that you’d like to be a craftsman and that you want to create quality stuff and that we should celebrate the programmers as craftsmen. To be fair, it doesn’t even call itself a methodology, it is more of a movement.
But agile will solve it right? Agile solves everything!
The interesting thing is that the article is written before Agile became the latest and greatest thing out there. So, has things turned out for the better?
Of course they haven’t! The mud balls are as ubiquitous as ever.
Agile embraces the change and allows fast iterations and a deliver-focused attitude. So, there will be constant changes and patches to whatever you do, and you have quick iterations with fast releases – which is exactly what causes balls of mud – changing things around fast without thinking in the long term. It won’t work. It might even make it worse.
The only way it can possibly solve the mud problem is that it will make developers so happy that they won’t create bad code any more. Possibly by shielding the team so much behind a scrum master so that they can take the time to make the necessary architectural changes to keep an application clean.
I’m not saying that agile is a bad thing, but it feels like acceptance. Are we by our latest ideology accepting that the development world is a muddy one and constructing our ideological base around handling this as best as we can?
Because scrum handles balls of mud fairly well, but it doesn’t fix them or even prevents them from appearing. Perhaps it polishes them a bit.
Are we resigning to our glorious muddy overlords?