Five Things Every Developer Should Know about Software Architecture • Simon Brown • GOTO 2020

Summary

The speaker addresses common myths about software architecture, emphasizing the importance of a balanced approach between 'big design up front' and agility. They discuss the evolution from waterfall models to agile and iterative development, highlighting the Agile Manifesto's preference for responding to change over sticking to a plan. The talk explores the concept of 'just enough' design, which involves making significant decisions that are hard to change later, such as technology choices, while remaining flexible and open to feedback. The speaker also stresses the role of software architects in coding, coaching, and collaboration, advocating for a continuous involvement throughout the project lifecycle. They debunk the necessity of UML for architecture and introduce the C4 model as a tool for creating hierarchical diagrams to communicate architecture effectively. Finally, they argue that a good architecture enables agility, allowing for rapid, incremental development and continuous improvement, and advise against adopting trends like microservices without careful consideration of the specific needs and structure of the project.

Takeaways

• 🚫 **Myth Dispelling**: The speaker emphasizes that 'big design up front' and software architecture are not the same, and that the former has been largely debunked in favor of agile and iterative approaches.
• 🔄 **Agile Manifesto**: The manifesto prioritizes responding to change over following a plan, which challenges traditional waterfall methodologies and encourages a more flexible approach to software development.
• ⚖️ **Balanced Design**: Both extremes of 'no design' and 'big design up front' are not ideal. The speaker advocates for a balanced approach, suggesting that 'just enough' upfront design is necessary.
• 🛠️ **Technical Leadership**: Every team needs some degree of technical leadership to guide architecture decisions and avoid chaos, such as big balls of mud or inconsistent code bases.
• 🤝 **Collaborative Architecture**: The old-fashioned, dictatorial approach to architecture is outdated. Instead, architects should code, coach, and collaborate with development teams throughout the project lifecycle.
• 👥 **Team Maturity**: Different levels of team maturity require different leadership styles. Inexperienced teams might need more direct guidance, while experienced teams benefit from autonomy and the removal of blockers.
• 💻 **Architects Should Code**: Good software architects are also skilled developers, which allows them to stay connected with the code base and ensure that architectural decisions are practical and followed.
• 📈 **Risk Management**: Identifying and mitigating the highest priority risks should be a part of the architecture process. Techniques like 'risk storming' can help teams collaboratively identify these risks.
• 📝 **Documentation and Experimentation**: Documentation should be light but sufficient to guide development. Concrete experiments, such as prototypes or spikes, are crucial to validate architectural decisions.
• 📐 **C4 Model**: The C4 model provides a hierarchical set of diagrams to describe software systems at different levels of abstraction, which can be used to communicate effectively without prescribing specific notation.
• 🔧 **Architecture for Agility**: A good architecture enables agility by being well-structured and modular, allowing for faster and more isolated changes, which is crucial for responding to volatile business requirements.

Q & A

What is the first myth the speaker wants to dispel about software architecture?

The first myth the speaker wants to dispel is the notion that software architecture is synonymous with 'big design up front.' Historically, there was a tendency towards this approach, but the speaker emphasizes that this is not the same as software architecture, which can be more iterative and flexible.

What does the speaker say about the concept of 'big design up front'?

The speaker points out that 'big design up front' was a predominant approach in the past, particularly in the 80s, 90s, and early 2000s. However, Winston Royce, who described the waterfall model in the 1970s, actually warned against this approach, stating that it was risky and could invite failure.

What is the Agile Manifesto's stance on responding to change versus following a plan?

The Agile Manifesto, created in 2001, values responding to change over following a plan. This principle challenges the traditional approach of 'big design up front' and encourages a more flexible and adaptive methodology in software development.

What does Dave Thomas say about the extremes of 'big design up front' and doing no design at all?

Dave Thomas is quoted as saying that 'big design up front' is done for various reasons, and that doing no design up front is even more foolish. This underscores the need for a balanced approach to software architecture that avoids both extremes.

What is the concept of 'just enough' design?

'Just enough' design refers to doing the minimum amount of upfront design necessary to establish a good starting point and set an initial direction for the project. It emphasizes the need for a foundation that can evolve and adapt as more is learned through feedback and experimentation.

What is the significance of the term 'architecture' as defined by Grady Booch?

Grady Booch defines 'architecture' as representing significant decisions, where significance is measured by the cost of change. This definition highlights that some design decisions are more important than others due to their long-term impact and the difficulty of changing them later on.

Why is it important for software development teams to have technical leadership?

Technical leadership is important because it guides the team in making significant decisions about the architecture and technology choices that will affect the system's maintainability, scalability, and overall quality. It also helps to prevent chaos and ensure that the team's efforts are directed towards a coherent vision.

What is the role of an architect in the context of coding and coaching?

The role of an architect is not just to design the system but also to engage in coding, coaching, and collaboration with the development team. This approach moves away from a dictatorship model to a more collaborative one, where architects work closely with developers to ensure that the design is practical and adhered to.

Why should architects write production code?

Architects should write production code to maintain a pulse on the code base, ensure that guidelines are followed, and to keep the design and code base moving in the right direction. It also helps architects to understand the trade-offs involved in design decisions and to assess the impact of those decisions on the system.

What is the C4 model and how does it help in describing software architecture?

The C4 model is a set of hierarchical diagrams that can be used to describe different levels of abstraction in software systems. It stands for Context, Containers, Components, and Code. The model provides a structured way to visualize and communicate the architecture at various levels, from a high-level context diagram to detailed code structure.

How does a good architecture enable agility in software development?

A good architecture enables agility by being well-structured and highly modular. This allows changes to be isolated to specific parts of the code base, reducing the complexity and risk associated with making changes. It supports the ability to move fast and adapt quickly to changing requirements, which is a key aspect of agile software development.