Technology, politics, culture
Thanks to the suggestion from Sam Penrose I’m going to go read “Big Ball of Mud,” which I hadn’t encountered before, for the next installment of Code Reads. Looks fascinating.
The paper can be found here (or here in PDF). There was a good previous discussion of the paper over on Dan Lyke’s Flutterby.
There are no revisions for this post.
report an error
I'm a writer, editor and website builder. These days I'm working as executiive editor at Grist. In 2009 I founded MediaBugs.org. I wrote Say Everything and Dreaming in Code. I was co-founder and managing editor of Salon. I maintain a mirror version of this blog at Open Salon.
Say Everything: How Blogging Began, What It's Becoming, and Why It Matters
Dreaming in Code: Two Dozen Programmers, Three Years, 4732 Bugs, and One Quest for Transcendent Software
I think this is one of the more accessible papers yet. Any programmer can relate to this. The funniest quote I think was when it says bad code has a survival advantage over good code because it resists changes and is prone to be left alone (or something like that). haha I never looked at it that way before. I’ll definitely write something soon when I get to it.
Props for finding this one!
This is a good, readable paper, with clever pictures to illustrate the points. Many of the ideas in it are well known (especially if you are already familiar with XP).
I like the fact that the authors recognize that the BIG BALL OF MUD architecture is successful (in the sense that many working systems have this architecture – or rather lack of architecture). In the paper, they describe the BIG BALL OF MUD architecture, and several related patterns on how you end up there, but also ways to deal with it and how to work towards a better architecture.
Some of the main reasons for ending up with a BIG BALL OF MUD are simply time and money constraints. But the authors also do a good job of discussing other reasons, for example that in the beginning you simply don’t know enough about the problem domain to be able to come up with a good architecture. This ties in with the notion of programming as learning and discovering, more than simply constructing.
Of the seven patterns discussed in the paper, the only one I hadn’t heard about before was the SHEARING LAYERS (I also had not seen the term BIG BALL OF MUD before, but the concept of “lack of architecture” is of course familiar to everybody). I think it’s a good concept, and something I’ll look more consciously for in the future.
It is also interesting to note that PIECEMEAL GROWTH can be both a cause of a BIG BALL OF MUD and a solution to it (when coupled with refactoring). KEEP IT WORKING also an important strategy, in my mind.
When it comes to RECONSTRUCTION – it may be necessary for several reasons, but there are also many good reasons not to do a re-write from scratch (Joel on Software has written a good article about that, see http://www.joelonsoftware.com/articles/fog0000000069.html )
In the paper, there are many comparisons to physical buildings and architecure in the traditional sense (even many of the pictures emphasize this). These analogies are good to a point, but it is important to remember that in many ways developing software is NOT like a constructing a building. In particular, in software there are no physical laws that constrain the structure, so it is possible to make things a lot more complex, and with a lot more coupling than in a physical building.
Also, when the program is running there is the whole dynamic behavior (objects created and destroyed, threads interacting with each other etc), that is not present in buildings.
There are also several pages of useful references at the end (and it is particularly cool to be able to have a reference to Vitruvius 20 B.C.!)
All in all I think it is a good paper, with many important ideas presented in an easy to read way.