Comment by henrik_w
12 years ago
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.
The above is a comment I wrote in August 2007 (how time flies!) on Scott Rosenberg's blog (author of Dreaming in Code), http://www.wordyard.com/2007/08/07/next-up-in-code-reads-big...
> 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.
Software engineering and architecture analogies often turn up, because both are design problems ("design" in the broader sense of using creativity to propose solutions given the requirements). The fact the final output of architecture is a concrete artifact doesn't change the challenge all that much, you still need to provide a solution that fits a set of requirements, often hard to quantify objectively.
1. You can tell whether your algorithm will run in O(N) or O(log n), this is computer science. You can't tell whether it's producing the output your client expects in all cases though, because it's hard to quantify this requirement.
2. You can tell whether a house will stand up after built, this is physics. You can't tell whether this house will provide adequate quality of life for a middle-class family with two kids though, because it's hard to quantify this requirement.
> 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).
Christopher Alexander, who is an architect (fun fact: he coined the term "design pattern"), also identified this "pattern", in which solutions that emerge naturally - as opposed to upfront planning - are more often that not a more adequate solution because the solution is shaped by the constraints - as opposed to being shaped by a person who doesn't fully comprehend the problem, or introduces it's own biases and motivations. E.g.: shantytowns solve the habitation problem of many people more adequately than if the same people had to wait under the bridge for the market to provide beautifully architected villas at affordable prices. [1]
The same might be said about software. The reason we have so many big balls of mud in production might be because it was the best solution given the constraints at hand (time, money and labor skill), and it solves the problem reasonably well (in the grand scheme of things, bugs and downtimes are tolerated and circumvented).
[1] The author discusses different approaches from which solutions emerge ("unselfconscious vs. self-concious") by contrasting ancient cultures and modern architecture, how solutions fit to constraints (or rather how constraints shape solutions) and other interesting topics on his book "Notes on the Synthesis of Form" (http://en.wikipedia.org/wiki/Notes_on_the_Synthesis_of_Form). I highly recommend this reading.
"shantytowns solve the habitation problem of many people more adequately than if the same people had to wait under the bridge for the market to provide beautifully architected villas at affordable prices."
This must be one of the most braindead sentences I have read in a long time. I dare you to count all the fallacies involved.
I suggest you try to understand inside the context of the comment, or give up trolling HN.
I agree with most of your points, but software is constrained by physics. Bandwidth (disk/network), calculation speed, which processors to allocate resources, ram. In fact, many software architectural decisions are made because of these inevitable physical barriers.
Sometimes the barriers are themselves architectural. How do you network together two computers when there's no simple route for a network cable and the Wifi is saturated? Where do you put this monster rack?
In real buildings, there are tons of dynamics - it just depends on the building. You can have commercial shipments, foot traffic, elevators, go karts, water pipes, and more. The reason we don't think of these is because buildings are well designed so that these things are managed well. Imagine if all commercial shipments were made during peak foot traffic and weren't given access in the back?
In any case, food for thought. :)
Imagine if all commercial shipments were made during peak foot traffic and weren't given access in the back
This exact scenario happens at my local Starbucks. The little strip mall it's in is set so far back on the property that there is no room for a delivery vehicle behind the building. So they get all their deliveries through the front door, and it usually seems to happen just at the end of lunch hour (the worst time, as people are getting their after-lunch coffee).
Point taken ;-)
I was thinking more along the lines that you can not have a building with 100 rooms, where each room has a door to every other room. In software on the other hand, nothing (except your own sanity) stops you from having 100 classes, where each class accesses every other class.
The text is readable, but the 1999 HTML is awful. The PDF is better (http://laputan.org/pub/foote/mud.pdf) or use Readability or something similar.