Beautiful Architecture Chapter 2: A Tale of Two Systems

This chapter grabbed me out of the gate by not comparing building software to building a house like the majority of similes. I loved the comparison of the design and evolution of a software system to a city. Flows of data like streets that need to be neatly laid out at first and widened or rerouted over time. The different types of buildings. Some construction projects can be done by individuals, whereas more massive projects need the involvement of an architect and construction crew to plan and implement.

Ah, the Messy Metropolis. How I wish I was unfamiliar with thee. I liked the idea that the author presented here of drawing out the modules, dependencies, and data flows to easily see at a visual level what the system had become over time. Metrics about afferent and efferent coupling don't give you the same sense of flow and grouping. I liked that with the whole mess of a system drawn out, the author was more easily able to see when a "destination" was "geographically" nearby but a roundabout path had to be taken instead.

The personality aspect of the team is also an important factor that doesn't get as much press as it deserves. As the author points out in the next section, though, the hoarding of interesting features and development of modules lacking cohesion can often be avoided by pair programming and YAGNI.

On the other hand, coupling is something that does get a lot of press, but I feel like several projects that I've worked on lately have missed the boat. As the author states in one of his notes, "Good design takes into account connection mechanisms and the number (and nature) of inter-component connections." I feel that on many teams that I've worked on, the idea of a component is at too high of a level. The code will often be organized into just a few .NET assemblies/Java packages such as UI, business logic, and data access layer. We'll often do a good job of managing coupling between those entities, but I feel that coupling should be closely analyzed as low as the class level in areas that are business-critical, complex, or very fluid. I've seen too many people thinking the were in Design Town when in fact they were barreling towards the Messy Metropolis at 100 mph.

Then we arrive at Design Town. I like how the author emphasized that upfront planning is necessary in Agile methodologies. Consider this famously misinterpreted Einstein quote: "Make everything as simple as possible, but not simpler." While most people tend to focus on the first portion as justification for doing away with any and all planning and design, it is the second portion that is key. Throwing out all up-front planning in Agile to determine some basic modules, patterns, etc., you're stacking the deck against yourself.

I also liked the author's note that "An architecture helps you to locate functionality: to add it, to modify it, or to fix it." I find that the key part of architecture that helps developers with day-to-day tasks is knowing where to insert and find methods in the system, UML sequence diagrams required.