Simon Brown — The lost art of software design

Summary

Simon Brown advocates for a balanced approach to software design in his talk, criticizing the extremes of 'big design up front' and no design at all. He emphasizes the importance of upfront design to set a direction while acknowledging the need for evolutionary architecture to adapt to changes. Brown introduces the C4 model for visualizing software architecture at different levels of abstraction, promoting better communication and decision-making within teams. His presentation encourages technical leadership and the use of various techniques to address risks and ensure the design's effectiveness.

Takeaways

• 📚 The speaker emphasizes the importance of not completely abandoning upfront design in software development, as it can be a valuable tool when done correctly.
• 🔄 The Agile Manifesto does not discourage upfront design; it encourages doing what adds value, and sometimes that includes some degree of design before development begins.
• 💡 The talk highlights the need for a balanced approach to design, advocating for 'evolutionary architecture' that allows for both planned and unplanned evolution over time.
• 🚫 The speaker criticizes the extreme approaches of either doing 'big design up front' or no design at all, suggesting that both extremes can be detrimental to effective software development.
• 🛠 The speaker introduces the C4 model for visualizing software architecture, which provides a hierarchical set of diagrams at different levels of abstraction to communicate design decisions effectively.
• 🤔 The importance of being able to answer two key questions in design is stressed: whether the diagrams reflect what we think we're going to build, and whether it's going to work.
• 📉 The script discusses the S-curve of learning, indicating that many people get stuck at the early stages of learning about upfront design and fail to progress to a more sophisticated understanding.
• 🤝 The speaker encourages the use of diagrams as a communication tool, stating that better diagrams lead to better design discussions and improved team alignment.
• 📈 The talk underlines the significance of making architectural decisions related to technology and modularity upfront, as these are the decisions that are hard to change later.
• 🧩 The speaker suggests using various techniques and practices, such as risk storming and architecture evaluations, to ensure that the design is robust and addresses key risks and requirements.
• 🔍 The importance of having a common set of abstractions and a ubiquitous language for discussing architecture is highlighted, as it aids in scaling teams and maintaining a shared understanding of the system.

Q & A

What is the main argument Simon Brown makes about software design in his talk?

Simon Brown argues that while big upfront design has been largely abandoned in favor of agile practices, it's a mistake to throw out all upfront design work. Instead, he advocates for a balanced approach that incorporates some upfront design to set a direction, while also embracing evolutionary architecture to adapt to changes.

What does Brown mean by 'The Agile Manifesto does not say, don't do any of that stuff'?

Brown is referring to the common misconception that agile development excludes any form of upfront design. He clarifies that the Agile Manifesto does not explicitly forbid upfront design activities; rather, it encourages flexibility and adaptation, which does not preclude doing design work that adds value.

What is the quote from Dave Thomas that Brown frequently uses in his talks?

The quote from Dave Thomas that Brown frequently uses is 'Big design up front is dumb. Doing no design up front is even dumber.' This quote encapsulates Brown's stance on the importance of a balanced approach to design in software development.

Why does Brown emphasize the importance of technical leadership in software design?

Brown emphasizes the importance of technical leadership because it provides direction and ensures that all team members, regardless of team size or distribution, are aligned in their approach to design and development. It helps in making significant design decisions and maintaining a good architectural structure.

What is the C4 model that Simon Brown created and what does it represent?

The C4 model is a tool created by Simon Brown for visualizing software architecture. It consists of a hierarchical set of diagrams at different levels of abstraction, including system context, container, component, and code. It is designed to help teams communicate their design effectively and is notation-independent, allowing the use of various diagramming styles.

What does Brown suggest is the minimum level of upfront design needed before starting development?

Brown suggests that the minimum level of upfront design should include understanding the key requirements, important quality attributes, and constraints that drive the architecture. Specifically, one should be able to confidently draw a system context diagram and a container diagram that illustrate the design direction.

Why does Brown criticize the lack of technical decisions on architecture diagrams?

Brown criticizes the lack of technical decisions on diagrams because it leads to ambiguity and a lack of clarity about the system's design. Without specifying technologies and significant design decisions, it's difficult for teams to understand, evaluate, and communicate the architecture effectively.

What is the 'S-curve of learning' that Brown refers to and how does it relate to upfront design?

The 'S-curve of learning' is a concept that describes the rate of skill acquisition over time. Brown uses it to illustrate the initial slow progress in learning upfront design, followed by a phase of accelerated learning, and eventually a plateau. He encourages designers to push through the initial slow phase to gain a deeper understanding of design principles before they plateau.

What is Brown's view on the use of UML in modern software design?

Brown notes that UML is not widely used in modern software design due to various reasons, such as it being seen as too detailed, old-fashioned, or a tool for imposing solutions on developers. However, he suggests that the issue is not with UML itself but with how it is applied and that a common set of abstractions could be more useful than the standard notation.

What are some of the techniques Brown suggests for determining how much upfront design is sufficient?

Brown suggests techniques such as risk storming, architecture spike, threat modeling, and the use of architecture decision records to determine when enough upfront design has been done. The key is to stop when the team understands the significant design decisions and is comfortable with the risks of proceeding.