💾 Archived View for gemini.abiscuola.com › gemlog › 2022 › 08 › 03 › architecture-here-architecture-… captured on 2023-09-08 at 16:06:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
An architect shouldn't do architecture anymore. Like, WTF???
Everybody knows that I'm not the biggest fan of mainstream agile approaches to software development. However, I love to work on small, sharp and focused teams, where everybody knows what needs to be done, and somebody is in charge to set a direction, or take decisions. Apparently, this shouldn't be the case anymore. I think this is a recipe for disaster, even in the best of the agile teams.
For the writer, the architect should shift from using their experience to push the work forward, to "helping" the other team members take good decisions. How do you define such a figure? A professor? A baby-sitter? A coach (that's a term the agile whack-a-mole vendors love)? No. It's just a manager.
So, for the sake of agility, you take a figure that was agile by definition (an architect using their good brain to design a system) shovel it down the toilet, and use that good brain to teach worse brains how not to decide to do stupid things. This is the contraddiction that I see in mainstream agile. Instead of removing communication lines from the team's graph, you add more, because, as the agile manifesto puts it:
Individuals and interactions over processes and tools
The main problem is that this was taken way too much to it's extreme. But Patrick has a solution:
A developer, with a narrower focus, might make a decision that seems suitable for their context, but may make less sense in the broader organisation. If only they had more context! Fortunately, architects can provide this. Better yet, architects can create channels for developers to discover and pull for more relevant context. A common mechanism for this is to work with teams to write down and publish Architecture Decisions Records. These might be as simple as on a wiki, or as a MarkDown file in source code repository for a service. Once decisions are written down, they are more discoverable and with a little encouragement from an architect, developers build a broader context that influences their decision.
"Architecture Decision Records", isn't this fantastic? Isn't this the Agile way of doing architecture? No, it's not, considering Patrick just renamed what is called a "non-functional specification". This is the agile mainstream movement. An endless pile of buzzwords used to circle-back to practices discovered 50 or 60 years ago. Initially lean, the processes takes over to become even worse compared to what was there before, because something "agile" cannot be formally specified.
An architect, should work as an architect, not as a coach, not as a baby-sitter. If an architect wants to be a teacher, that's the kind of architect I, personally, would never want in my team. Because they are useless. Like CTOs not doing any CTO work, but being focused on the "vision" (whatever that means).
Mentoring, perhaps, is something that should be encouraged. But mentoring means to take a junior programmer and pair it with a senior one, and they will work together for a long period of time, until the junior becomes proficient in it's role.
Fred P. Brooks discovered 50 years ago, that too many brains designing a system leads to a lack of elegance and consistency. One, maximum two people should take decisions about a system design, and in this era, an architect will take a decision with the input from all of the members of the team. But the architect must be the one with the final word because, as the article puts it:
An architect typically has more context than a developer on a team. The architect interacts with more teams. They have a broader but less deep awareness of how systems evolve.
The architect has the experience, and the context, to take the final decision and it is it's JOB to do so. I don't know why everybody try, this days, to put more and more responsibilities on everybody's shoulders. Of course you, as a grunt programmer, will never be paid like an architect to make architectural decisions, but you will carry the responsibility for it, and will be thrown under the bus by the same architect that "helped" you in the first place.
Because that's how the real world works.