5 things every developer should know about software architecture
Abstract
- When to stop design?
- Instead of the extremes “Big design up front” or “No design up front”, we should ask ourselves “When to stop design?”
- Up front design is an iterative and incremental process.
- It’s used for a good starting point and direction.
- We should use some design up front + evolutionary design.
- Every team need technical leadership.
- architecture driver: understanding goals, requirements, …
- designing software: technical strategy, vision, …
- technical risk
- technical leadership
- quality assurance: standards, guidelines, …
- Software architect.
- Should code, coach, mentor.
- != AaaS (Architecture As A Service), i.e. the “Seagull effect” where the “architect” comes and goes, then we need to clean up after his shit.
- Continuous technical leadership.
- Every team is different and needs different kinds of leadership: some need command and control type, some need freedom.
- We should target “Elastic leadership”.
- In the same aspect of pair programming, we should also do pair architecture to reduce bus factor, transfer knowledge, …
- People designing software involves trade-offs.
- You don’t use UML.
- Most are saying a whiteboard is enough, but it’s quite difficult to understand the schema afterwards without much structure.
- Use c4 model to have some basic structure.
- No need to use all 4 levels of c4 model, the first 2 is enough for most of people. The 2 others are used for more detailed information.
- A good software architecture enables agility.
Reviews
Really good points. The speaker, Simon Brown who I seem to see him in a lots of talks, highlights some “trivial” points. The idea is to be flexible, adaptable, …, and act depending on the context. There is no silver bullet / one size fits all, we need to adapt to the organization to make good software architecture.