Big Ball of Mud: On Software Architecture
There has been a paper that was kept out of my radar for a surprisingly amount of time: “Big Ball of Mud”, by Brian Foote and Joseph Yoder. Just reading the introduction makes any software architect fight the urge to get out screaming to their bosses and colleagues: “See?? This is exactly what I’ve been saying!!”
The paper is an excellent summary of the dynamics of software development and evolution. I can’t resist to quote some passages from the introductory chapters to see if I can persuade someone to read it:
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.
Now… Who doesn’t recognize these symptoms? The authors go on:
Why does a system become a BIG BALL OF MUD? Sometimes, big, ugly systems emerge from THROWAWAY CODE. THROWAWAY CODE is quick-and-dirty code that was intended to be used only once and then discarded. However, such code often takes on a life of its own, despite casual structure and poor or non-existent documentation. It works, so why fix it? When a related problem arises, the quickest way to address it might be to expediently modify this working code, rather than design a proper, general program from the ground up. Over time, a simple throwaway program begets a BIG BALL OF MUD.
The time and money to chase perfection are seldom available, nor should they be. To survive, we must do what it takes to get our software working and out the door on time. Indeed, if a team completes a project with time to spare, today’s managers are likely to take that as a sign to provide less time and money or fewer people the next time around.
Programmers with the ability to discern and design quality architectures are reputed to command a premium. These expenses must be weighed against those of allowing an expensive system to slip into premature decline and obsolescence. If you think good architecture is expensive, try bad architecture.
And I could continue to quote the article for dozens of pages… This was written in 2000. Eight years later, where are we? I believe we are roughly at the same. People still come out from University clueless about architecture and design, despite they have courses intended for that. But, somehow, it’s still relegated as a second-class knowledge. Why?
Not wanting to start on a largely (perhaps irrelevant) rumination about the “why’s” and “how’s” (read the article for that), I would like to close this simple post with another quote:
Another is the Extreme Programming practice of pair programming [Beck 2000]. A pure pair programming approach requires that every line of code written be added to the system with two programmers present. One types, or “drives”, while the other “rides shotgun” and looks on. In contrast to traditional solitary software production practices, pair programming subjects code to immediate scrutiny, and provides a means by which knowledge about the system is rapidly disseminated. Indeed, reviews and pair programming provide programmers with something their work would not otherwise have: an audience. Sunlight, it is said is a powerful disinfectant. Pair-practices add an element of performance to programming. An immediate audience of one’s peers provides immediate incentives to programmers to keep their code clear and comprehensible, as well as functional.
In other words: if you have to write your code alone, do it so you can be proud of it. Do it as if you’re going to show the world what you’ve done…
June 28th, 2008 at 9:04 am
I think things are changing, though. At least their having those kinds of courses now, and I see some people coming out of the university actually aware and interested for software engineering.
June 29th, 2008 at 11:49 pm
What about job security?
July 1st, 2008 at 12:30 am
great post. thanks.
my 2c: would it be that the current education system cannot even teach “it” beacause simply most current teachers never practiced “it”
where “it” stands for the specific practices, principles and values of xp, agile, scrum, and many many others
July 1st, 2008 at 12:59 am
@andre: it is a good point. I agree with you when I consider the fact that a whole change of attitude (not just a course) would be needed for the XP practices to be assimilated by the students as “natural”. Still, I’m worried with the fact that XP pushes people to “do it right”, while most of them is interested in “just doing it”.
July 8th, 2008 at 11:15 pm
don’t worry: those that are interested in “just doing it” will move along the next trendy buzz-word and leave xp alone
anyways I couldn’t care less about XP or anyother acrinym for that matter. I follow my Zen-ish aproach to it, thus names are meaningless.
It’s the principles and values that matter… as in “wanting to do it right”… that’s the atitude that must change