”Big design up front is dumb. Doing no design up front is even dumber.” This quote epitomises what I’ve seen during our journey from ”big design up front” in the 20th century, to ”emergent design” and ”evolutionary architecture” in the 21st. In their desire to become ”agile”, many teams seem to have abandoned architectural thinking, up front design, documentation, diagramming, and modelling. In many cases this is a knee-jerk reaction to the heavy bloated processes of times past, and in others it’s a misinterpretation and misapplication of the agile manifesto.
As a result, many of the software design activities I witness these days are very high-level and superficial in nature. The resulting output, typically an ad hoc sketch on a whiteboard, is usually ambiguous and open to interpretation, leading to a situation where the underlying solution can’t be communicated, assessed, or reviewed. The same is true of long-lived documentation, which is typically a collection of disconnected diagrams that are out of sync, and out of date. Modelling can help resolve many of these problems, but that’s a tough thing to sell to mainstream developer audiences these days – teams are either not aware of modelling, or they associate it with bad experiences using complicated CASE tools from the past. Join me for a discussion about the lost art of software architecture modelling, and my experiences of how it can be reintroduced to the agile generation.