What defines a software architect? It usually means someone has achieved a high level of technical skill. Most of the architects I’ve worked with have been quite good. They may spend a good portion of their day around whiteboards with various teams, but they also spend a decent amount of time writing code.
Occasionally, I meet someone who has let the title go to their head. They view writing code as beneath them. While I totally understand the desire to solely work on architecture, anyone who doesn’t actively write code is completely ineffective as a software architect.
To understand why this is, we need to understand what it is that a software architect actually does and what they shouldn’t do. Top on the list of “should never ever do” is create a technical spec and hand it off to some lowly developer to implement. I’ve had this done to me a few times. I’ve seen it done to others many more times. I’ve even done it once.
This is a great tactic if you hate efficiency and well written code. It is incredibly hard for any developer to effectively write code for something they don’t fully understand. Inevitably they will come upon an issue that was not noted in the spec. Software is hard and complex and not every edge case is going to be written up.
If a developer does not have a role in making any decisions in creating the software architecture, they won’t have the foundation for resolving that issue themselves. The result will be either:
- Fumbling ineffectively for a few hours before asking for help
- Never asking for help and building something that won’t really work (and maybe having it all redone after code review)
- Asking for help so frequently that the “architect” starts to feel they should have done it themselves
No amount of lecturing will help a developer understand more than if they were actually involved in the process for creating that software architecture. What never goes into any spec are the dozens or hundreds of roads not taken. This may be because the architect thought about them and ruled them out for some reason. Or it more likely will be because the thoughts never occurred to the architect because of their experience. Either way, involving developers in the creation of software architecture brings those paths to light. Discussions are had. Time is spent, but understanding is also achieved.
This makes software architects teachers first.
Teaching requires empathy. Occasionally developers may struggle with certain implementation paths. Telling them to “go do their jobs” is not super effective. Understanding their problems goes a long way to a more productive discussion. Software development advances fast enough that having written code 10 years ago is not sufficient for this kind of empathy. Kubernetes wasn’t around 10 years ago. Blockchain was just getting it’s start 10 years ago. Cloud deployments were still pretty fringe 10 years ago. Some of the languages and frameworks we use today weren’t around 10 years ago. An architect who doesn't write code is not going to be able to work through a developer's code with them and figure out a solution.
Teaching also requires being able to use real examples. Software development is filled with abstraction, but abstraction can only really be understood when some concrete examples are encountered first. Talking about concurrency in an abstract sense can make anyone’s eyes glaze over. Walking through a developer’s code with them and showing how they can turn a 5 hour operation into a 20 minute operation makes a lot more sense.
An architect who hasn’t written code in 10 years will only be able to use examples that are 10 years old. Those examples are going to feel less relevant and more abstract to developers who started writing code more recently.
Writing code can be grueling. Some people enjoy it. Some people pretend to enjoy it. I’m definitely one of those that finds it tedious. It’s definitely more fun to think and talk about systems at a high level. But writing code is the price that must be paid in order to do that effectively.
Top comments (0)