During a panel discussion on November 12 at the iSAQB Software Architecture Gathering in Berlin, the topic of complexity in software led to a few eponymous “laws” to be proclaimed. The moderated discussion featured many small bits of advice for the audience of software architects and engineers, some of which were framed as “my law” to provide additional emphasis.
Gregor Hohpe, author of The Architect Elevator, declared Gregor’s Law as “Excess complexity is nature’s punishment for organizations that can’t make decisions.”
In response, Chris Richardson, author of Microservices Patterns, coined Chris’ Law, stating, “An architectural element should only exist if it solves a tangible problem.”
Rounding out the playful activity, Diana Montalion, author of Learning Systems Thinking, revised the words of Mel Conway, providing Diana’s Law as “People who design systems will produce copies of their thinking and communication patterns.”
Software Architecture Gathering speaker panel. From left: Alexander Heusingfeld, Gregor Hohpe, Lars Roewekamp, Diana Montalion, Chris Richardson, Rebecca Parsons, and Rainald Menge-Sonnentag.
Richardson warned of introducing “accidental complexity,” which is “the complexity of the system we built to solve the original complexity.” Montalion pointed out the counterintuitive concept that the hardest thing to do is to know the one simple action we should take.
Montalion took issue with Hohpe’s statement that complexity is the enemy. Montalion said there is a difference between complexity and complication. The goal should not be to eliminate complexity in software systems, but to reduce (and certainly not introduce unnecessary) complications when architecting and designing software.
Lars Roewekamp, founder and CIO New Technologies at Open Knowledge GmbH, echoed that sentiment, saying software architects should only introduce additional complexity when the resulting additional costs can be measured.
The panelists discussed how complexity varies over time, and the importance of considering volatility in systems design. Montalion said, “Certainty is an illusion–it doesn’t exist. If change isn’t your thing, this might not be your industry.” She believes one of the benefits software architects provide is being able to have impact in uncertain situations.
Earlier at the conference, Richardson presented “Architectural Patterns for Fast Flow,” covering how to design an architecture that enables organizations to thrive in an uncertain world. During the panel discussion, he said he could have renamed the talk “Architecting for High Volatility,” because architects need to identify the most volatile parts of a system, and put extra effort into designing those areas. While general guidance says we should aim for loose coupling, some coupling will always be necessary. The more volatile a component, the greater the need for it to be loosely coupled and not require widespread changes.
When the discussion turned to the value provided by good architecture, Rebecca Parsons, CTO Emerita of Thoughtworks and co-author of Building Evolutionary Architectures, said it’s hard to measure the value in advance. However, early on, decide how to measure the value, and practice hypothesis-driven development with tight feedback loops so you can measure the value and adapt as needed.
The panel was asked about human factors that drive complexity, and if complexity is related to a fear of change. Hohpe said architects need to understand where people are coming from, and what drives behaviors that increase complexity. For example, if people learned from past projects that adding late changes is expensive or impossible, then they are more likely to put every requirement into the first round, rather than spreading them out over time. They may even ask for twice as much as they need because they expect to only get half of those requirements delivered.
Architects can help to make problems like this visible, thereby identifying bottlenecks, and allowing the process to be improved. In a similar vein, he also said, “Complexity is not a line item in the budget. People think it costs zero.” Architects need to translate the complexity within a system into terms the business can understand, then they will be more likely to work to decrease the complexity. However, sometimes people benefit from the complexity, so there can also be fear of change if that added complexity is eliminated.
The panel was moderated by Rainald Menge-Sonnentag and Alexander Heusingfeld. The Software Architecture Gathering, presented by the International Software Architecture Qualification Board (iSAQB®), took place in Berlin, Germany between November 11-14, 2024. The next SAG will take place November 24–27 2025 in Berlin.
