OTUG's latest distinguished lecturer presentation was Joe Yoder and Brian Foote's Big Ball of Mud.
First, let me say that Foote and Yoder were the most entertaining speakers I've seen at an OTUG presentation. Their presentation style was to tag team the presentation. Each speaker would talk to a point or two and then the other would take over. Their approach really worked well. Foote and Yoder's energy levels seemed to stay at a higher level than it would have been with a single continuous speaker.
If there's one criticism that's resonated about the distinguished lecturer series recently it's that the presenters tend to be academics who do not speak to the same world that working software professionals live in. There's nothing wrong with speaking to the abstract, if not disconnected, world of academia. Sometimes I think that people come into these lectures with the expectation that they will receive a practical lecture that can be directly applied to their situations.
With that said, Yoder and Foote's presentation is clearly rooted in real world practical experience. If anything, Big Ball of Mud is the antithesis of the ivory tower lecture. It's all about the disconnect between what we say we are doing and what we are doing.
The premise of Big Ball of Mud is that software professionals aspire to produce software that is architecturally elegant, yet the product that we so often create is very different than those aspirations. As Yoder and Foote put it, "if [most] software were architecture, it would look like a shanty town." They liken software architecture to 'The Emperor's New Clothes' and that everyone is in denial that we are creating shanty towns.
Yoder and Foote call this ugly software mud. The dirty and chaotic messes of spaghetti. We all see mud in other people's code, and in that I've seen the monster and it is us way, we see it in our own code too. It's really a wonder that anything ever worked until we the noble craftsmen arrived, or is it.
They point out a few of the types of mud and the ways that it happens. Copy and paste, which they call metastasis. Big Bucket of Glue, or taking open source libraries from the wild and haphazardly gluing them into an ugly chimera of an application.
Yoder and Foote raised the question, "Why does stuff that sucks hang around so long?" It's easy to characterize the obvious negative traits of mud, but Yoder and Foote pointed out some of the things that aren't so obvious. The mud that we encounter works. If it didn't work, we'd ditch it. The mud that we see is sufficiently complex, otherwise we'd find the time to replace it with something beautiful.
Yoder and Foote showed examples of how a good enough solution now can be more valuable than a beautiful solution later. It kind of makes sense that for software to add value, it must be available.
Yoder and Foote addressed software craftsmanship. Brian Foote, talked about Amish furniture craftsmanship. He even wore an Amish hat for that portion of the presentation. If we think about Amish made furniture, it's beautiful and of excellent quality. We all would like furniture that is of that quality and is beautiful. We also buy stuff that's made of particle board from Ikea in droves. Sometimes the Ikea furniture is good enough.
The takeaway from the talk I got is that mud is the byproduct of a trade off from writing software in a way that costs less upfront. The mud is a technical debt that may, or may not, need to be paid down the road, but it is a debt that certainly does not get paid at the onset of its introduction. We can clean up mud through refactoring and replacing muddy software.
Foote and Yoder brought up a great point that automated tests will have your back when it comes time to clean up the mud.
We can strive to create mudless software, but it comes at a cost that becomes impractical. I'm reminded of a project that I was on. We set the goal to get our automated test code coverage at 85%, and we did. It was a worthwhile effort. Someone then thought we should strive to get the code coverage to 95% and we did at the cost of adding about 30% more time to our work. Was that 10% worth the effort? Is it worth 1/3 of a feature? In that case we let our idealism take precedence over the practical need to deliver something of value to our customers.
It seems that the image of the muddy boot architect may be an appropriate metaphor for software creators. Some mud is needed on the job site. We may have the opportunity to clean it up, but it isn't something that we need to avoid at the cost of delivering value.
As an observation, I don't think that the software that we are creating today, with the tools that we have available, is nearly as muddy as some of the code that was created in the past. We're getting better. As a community, I think that we are moving towards producing less muddy software. Just as I was thinking, nay fantasizing, about how we may reach a time where the mud we see is more like a fine layer of dust. Then Deion Steward had to bring up a question about concurrency and multicore development and I think that may be a whole other swamp.
EDIT: Please read Foote and Yoder's paper Big Ball of Mud.
Wednesday, May 26, 2010
Del.icio.us Add to del.icio.us Digg DiggIt! Reddit Reddit Stumbleupon Stumble This Google Bookmarks Add to Google Bookmarks Yahoo My Web Add to Yahoo MyWeb Technorati Add to Technorati Faves Slashdot Slashdot it
Posted by Paul Wiedel at 7:52 AM