Comment by hcarvalhoalves

> 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.