Thoughts

I struggle with the term Software Architecture. We use it as if it's something that can be studied in a classroom, or a role someone takes on in an organization. And although, both of these items do happen today, I think it is a poor representation of the industry. The term is loaded and should be abandoned as a term of rank, and instead be used as it is truly defined, "the innate structure of a software system."

The Industry Software Architect

Who is a software architect? He is the guy that comes up with the design, structure, and contracts of a software system before it is built. It's the guy (or girl) that determines the bones of software product based on any number of potential trade-offs. For instance, an architect will take the following into consideration:

  • Budget and Costs
  • Current State of the Software (if any)
  • Maintenance Considers
  • Performance Requirements
  • Lifespan of the Software
  • Scalability
  • Reliability and Resiliency
  • and much more

This is the job. However, in large organizations, they tend to be more divorced from software and instead focus on theory. They run from meeting to meeting, providing guidance / advice and direction for a product. And this ritual continues week to week.

The best architects teach other developers and engineers the trade-offs and how to make these decisions. Eventually, the baton is passed to the next generation of architects.

And so the cycle goes.

What is a Software Architect Really?

I get that it's a role, but the reality is this: Software Architect's are just really experienced software developers, people that have tried and failed enough times, learned from their mistakes, and built up a repertoire of techniques that enable them to make better decisions than less experienced developers.

So, they are just professional, disciplined, software developers that have proven (hopefully) their ability to write maintainable, reliable, scalable software.

That's it.

They are those 10x developers that you want on your most critical pieces of software. And maybe that happens. However, when they leave those products, you start to notice that the software doesn't seem to maintain that level of quality. Why? Because less experienced developers take over and start making "less disciplined" decisions on the pull requests.

They don't do this purposefully. It's an issue of assuming that all developers are created equal. But they're not. And if you're in an organization without "ownership" then it's worse.

Software Ownership

I believe that all software products should be owned by one, and only one, person. This is the Team Lead and they should be in the code directly, watching all PR(s), and are held accountable for all bugs found in the software, even if it's a team of people working on the software.

Why? Because if forces learning. It makes it hurt. If someone on your team starts getting you in trouble, for the code they write, you'll start watching the PR(s) more closely. You'll put more rules in place. You'll create more automation and testing. You'll take responsibility and train the developers to be better. You will naturally become a "software architect."

See, for me, let's get rid of software architects and instead give Team Lead's more ownership of the products. The results will be the same, assuming you pick the right person, and hold them accountable. Then, you create multiple "architects" through this process for each person leading a team. If they don't cut it, then you find the right person. It may seem harsh, but it's the best way to create better quality software.

Conclusion

I'm advocating for more software ownership; a world where a single person takes accountability for a software product end-to-end. And if that software gets too big for one person, you break the software up into separate, manageable pieces, that can be owned by different people. And as it gets too big past several teams, then you hire that VP visionary that works at the system level. And so it evolves over time as scale is required.

Anyways, that's my rant for the day. Let's get rid of the software architect role, today.