Simon Brown - Software Architecture for Developers
Fleeting- External reference:
Simon Brown, software architecture, C4 model for visualising software architecture
He says that we first had waterfall models and its big upfront design and when agile methods came, people confusingly understood that it told that we should not make any upfront design at all.
He uses the citation big design up front is dumb, but doing no design up front is even dumber.
He says that the amount of upfront design to do is «just enough». You should have just enough to get you started. Some goal, a vision to get to.
In the guitar analogy to explain the evolutionary architecture, emergent design, I believe it gives a wrong idea of what it would look like. I believe that at first, you don’t even have a clear idea that you need strings or even something to make sound. This also comes clearer when the project moves forward. This is part of thinking in the problem space, you realize along the way that you got it all wrong and it is better to fail early rather than keeping pushing in the wrong direction.
For him, we need to engage in the problem space to create a software architecture. The two question you should ask are “is that what we are going to build” and “is that going to work”
It cites important decisions, as measured by the cost of change, indicating that there is no string threshold between significant and not significant.
Enough up front design to create a good starting point and direction.
It is said that we need a common view of the architecture or else we get a big ball of mud. This document is not necessarily dealt with by a single person, but it is dealt with by a role. The fact that some people occasionally lead this document is likely a symptom of the super hero antipattern.
Everyone needs to think about software architecture.
He describes the solution architect antipattern that just give people a document to implement without being involved in the process of implementing it, like a relay sport. When he asks how the guy know that the solution is implementable, the guy does not know how to answer and fall back invoking an “implementation detail”. often the system is perfectly designed to generate the result it did.
The software architect is a technical lead whose most difficult task is dealing with other people (soft skills). It is about coding, collaboration and coaching.
It as also a master builder, someone with a lot of experience that will be recognised for per knowledge by per peers, rather than simply be put their by a management that wants to justify a pay raise (principe de Peter).
A software architect is a guy that works like the other developers, only that per has been recognised to have experience.
For him, the software architecture should not use complex notation, like uml, but it should not be totally free (like using a whiteboard). It should provide some constraints but still leave room for creative thinking.
Better focus of abstraction rather than notation, this is why he created the C4 model for visualising software architecture.
To him, we should keep our freedom to make mistakes and continuous improvement.