The subtle difference between a terrible and amazing software architect is…
The subtle difference between a terrible and amazing software architect is…Clairvoyance!
Even a junior software engineer can architect a service or app. Quickly, they learn they’ve made a mess on how they created the boundaries of presentation, logic, and storage. Then they learn they componentized it the wrong way. Then they learn they made bad assumptions on how certain SDKs, APIs, or third-party libraries work that makes them perform terribly slow or maintain/not maintain certain states between calls. After just a couple of years of beating their head against bad architecture, they learn how to do this “right”.
Well, it’s complicated.
Software Architect Level I (Novice)
If you are not working for one of the large tech companies (Google, Apple, Amazon, Facebook, Microsoft, etc.) you’ll be able to architect software well after 2–4 years of experience. Given a problem/spec/product definition, you’ll come up and be able to implement the solution. You’ll pat yourself in the back and your PM/sales team/CEO will praise you for a job well done.
You solved a problem for a specific use case. Then…
Software Architect Level II (Beginner)
After a few months, you realize that you’ve made a few mistakes in how you originally architected your software. Because your CEO/PM/sales team forgot to mention a few use cases and you didn’t consider them. After suffering through your not so great architecture decisions (or someone else’s decision) and working on it for another couple of years, a lightbulb comes up on your head and you finally “get it”.
The next project you are put on, you know what to do. You need better specs/requirements/PRD/docs!
You go back to your PM/sales team/CEO and work with them to better define the scope of the project. You provide them a checklist about localization, data governance, use cases, scale & latency, data model requirements, flow charts, etc. There are spec reviews, meetings with customers, (software) design discussions. You feel comfortable what you’ll do will solve the problem. You do it, it solves the problem. You feel confident you covered your bases on everything. The software works, you get the pat in the back.
The sales team is rocking and then they ask you for an extra (small) feature. Oops. It’s a small thing from a UI point of view. Not so small from logic and repository POV. As a matter of fact, that scenario was never accounted for and the data required to make it happen has never been properly collected. So, even after the software is re-architected, even after all the code has been implemented and deployed, there won’t be any data to show and it’ll take months before that new feature delivers what the customers were asking the sales team.
Software Architect Level III (Competent)
After going through this painful cycle year after year of your execs/PMs/sales team asking you why such a small change requires so long to make you realize it’s a moot point to keep repeating yourself. A couple of years later a lightbulb clicks on your head. You realize you’ll have to think ahead of what you’ve been asked.
This time you know what to do!
Forget about building a hammer factory, forget about building a tool factory, you need to build a factory that builds tool factories!
Let’s abstract the crap out of everything. You are not going to build a specific solution anymore, you’ll make sure that you abstract as many concepts as possible and use rules engines, configuration, and dependency injection everywhere so if someone wants to redefine what an active user is or what an item in the products table is, you can do it. As a matter of fact, you fall in love with NoSQL, document storages, microservices, orchestration, docker, MVVM, etc. These are the tools and patterns you need to make sure your abstracted architecture works well.
You know, you just know, that when a PM/sales person/exec comes to you to ask if you can add the “small” feature, your answer will be yes. And, it’s true! You achieved nirvana.
What you did is to actually build a house where the walls, the doors, the pipes, the electrical outlets, and where it’s located in the world can be easily moved. It wasn’t easy to do it this way, it took you a couple of years to get there, and new engineers take a while to reach productivity because of so much abstraction, but you can’t envision a scenario within reasonable bounds that your abstracted-architecture would not serve the company.
Well, you couldn’t, until…
Software Architect Level IV (Proficient)
Well, your CEO decides to pivot the product. The app/service/solution the company was providing plateaued or the industry has moved in a completely different direction and the expectations have shifted. The good news is that your hyper-abstracted solution still could be used to serve the new solution. Well, the new solution is quite simpler actually and it could be done with significant simpler architecture.
But you and the team are committed to the architecture in place. After a long and hard debate, you realize the efforts of the last 3+ years should be thrown out of the window and starting from zero is the right thing to do.
The next project you are put on, you know, you just know, that building architectures that you imagine would survive the next decade is just futile. You realize that you need a balanced approach between how much abstraction and how much specificity you’ll have in the code. You know you have to take engineering onboarding cost into account. You know what maintainability actually means.
After a few rounds of product pivot, full re-architecture execution, managing (not removing) technical debt, knowing that big rewrites take too long, you achieve…
Software Architect Level 5 (Master)
After being a great software architect for a few years, you start to realize there are a few constants every time you start a new project: a) No one knows what they want and what they should do, b) Things change more often than expected.
You develop clairvoyance!
You know that you have to look beyond the requirements/scope and assume a few scenarios that haven’t been covered, but likely will show up in the future. You also know that trying to plan for all of it is futile and you are constantly making compromises in which scenarios you’ll prepare for (but not implement) and which you’ll sacrifice (either knowing they are unlikely to happen or taking a measured risk if they do happen). Finally, you know the right balance between hacking pieces together (deliberately creating a technical debt) and abstracting modular solutions. In other words, you know how to dynamically act between a Level I and a Level IV software architect.
You just know. You don’t monkey around. Your intuition has been fine-tuned by the lessons of life. Congrats!
You might also like:
Follow me on Twitter:
