How to become a software architect

Transcript

Cal: What is software architecture, and what is the role of a software architect?

Keith: I always compare it to building traits. So, if you look at somebody who’s building a house, they’re the person that comes on the site slinging two by fours, pouring concrete, and driving nails. You can’t have a house [built] without that step, but there’s actually a step before that– architecture.

The architect is responsible for coming up with the plan, describing how things are going to fit together, and articulating the overarching vision for the house.

Cal: Do you actually draw out blueprints or is software architecture more cerebral?

Keith: No, if it’s just floating in your head, it doesn’t count. I tell everyone I work with until it’s written down, it doesn’t count, it doesn’t exist.

Whether we’re talking about pitching companies or designing systems, when it’s in your head, you can have these contradictions that don’t always fit together. So I always tell people, write them down, draw them out, make sure you can express them to other people.

Cal: How do you express a software architecture, in drawing?

Keith: The drawing really depends on who you’re expressing it to. If you’re expressing it to an outsider of your system who just needs to know that this thing is thought through, then simply block diagrams are probably sufficient. Just real simple blocks of “here’s what it is”.

When you get into the deeper components, you need to start thinking about what a database diagram might look like. You might think in terms of sequence diagrams and UML. Especially when you start talking about the interactions or what users are going to do within your system. You probably want to start sketching out the sequence diagrams to show how information flows back and forth.

Cal: So, does expressing a software architecture visually look different the more you drill down?

Keith: Yeah. It’s like Google maps. When you pull up the United States on Google maps, you see national borders and state borders. When you start zooming deeper and deeper into, say Texas, you start seeing rivers and streams.

Realistically, [expressing software architecture visually], it’s the exact same information, it’s just a more fine-grained analysis of the information. For somebody who’s designing streets, that worldview isn’t very useful. You need to get down to that level of detail.

Cal: How is a software architect different from a senior developer?

Keith: I’ll go back to my earlier construction analogy. The architect is the one that’s drawing plans for the house. The senior developer is the one that completely owns the bathroom, the plumbing, or the electricity.

[Senior developers] have a critical part of the whole thing and it doesn’t work without them, but they own one part. They know how their system fits into the overall picture, but the overall picture is not their show to run.

Cal: Is a software architect a role that a developer can play, or is it a rank on an org chart?

Keith: It’s a role and a set of responsibilities. I guess you can get promoted into systems or software architecture, but I think it’s really dangerous to just treat it as the next level of software development.

I don’t think it’s just a quick and easy promotion, it’s really expanding your skillset out quite a bit.

Cal: If it’s a role and not a rank, as a manager, how do you know if someone is right for a software architect role?

Keith: Developing a software architect takes years. I think it really takes a deep understanding of the field, the tools you’re working in, and the systems you’re creating. Realistically, it takes such a wide diverse skillset, it’s really hard to do.

It’s not something you want to give over easily because just like in building a house, if the foundation is wrong, if the initial first steps are wrong, the project is going to turn out catastrophically. There’s no way to go back and replace a lot of that stuff without having to go back to the beginning of the project.

Cal: I’ve experienced putting the wrong person in a software architect role. What makes a bad software architect?

Keith: If you have an architect who can’t stand up for themselves, who can’t draw that line, and know this is a bad idea and here’s why, you have a major problem on your hands because the downstream that the project, the team, the customers are dependent on the decisions and the things that that architect does.

If you have somebody who’s weak or somebody who’s not prepared for the role, you’re taking serious risks that everyone’s going to pay for sooner, rather than later.

Cal: Is communication a requirement to be a good software architect?

Keith: If you can’t express your ideas well, and that is in pictures and diagrams and written word, it doesn’t matter how good your idea is, it will never be implemented. It’ll never have that coherent vision that is required.

Plus, your career will be significantly better if you can communicate effectively.

Cal: What would you say is the most important skill for software architects?

Keith: You don’t have to be perfect. Software architects get wrapped around the axle trying to say this architecture needs to be perfect. Most of the time, there are no perfect architectures, there are only trade-offs. There is understanding, look, if we do it this way, this is what it’s going to take, this is what’s going to cost, these are what the consequences are going to be, but if we do it this way, here are the other consequences.

If you can’t understand what the trade-offs are, it doesn’t matter, even communicating it well doesn’t help. You really need to be able to at least lay out those options.

Cal: How do you cultivate the technical skills required to be a software architect?

Keith: You need to have the technical chops. From shipping code, building things, screwing things up, breaking things.

What’s the old saying? You don’t get wisdom without making mistakes and you don’t make mistakes if you have the wisdom? You need to screw it up. You need to have bruises. You need to have those scars from those previous things.

Earlier this week, I told someone point-blank, “look, I’ve made all these mistakes before, I’ve got scars to prove it, let me help you make different mistakes”. Leverage my experience, leverage my understanding to make this work better, so you can make your own creative, foolish mistakes.

Cal: How do you know if you’re a good fit for software architecture?

Keith: It’s not based on experience, strictly. It’s not based on years on the job or anything like that. It’s really based on a hunger to know more.

If you’re always looking to take what you have and learn what the adjacent topics are, and expand that out, that’s a pretty good sign that you might be a candidate for being a software architect.

Cal: What resources do you recommend for those interested in becoming software architects?

Keith: I really try to encourage people to build their toolbox, and I mean that on the technical side and on the communication side.

So on the technical side, I’m a big fan of McConnell’s Code Complete. That’s a little dated right now, but he also has a rapid prototyping book. Also, Pragmatic Programmers to get a wider perspective of the world.

[I’m a] big fan of Martin Fowler’s design pattern series. The first time you read the design patterns book, most people go, oh, I can use all of these. No, It’s a toolbox. You’re building a toolbox and just because you have a hammer, doesn’t mean everything in the world is a nail. One of the things that those will start teaching you to do is, one, be able to recognize a nail, so you know you need to pull out the right tool for it. Two, it’ll start giving you a framework on how to communicate things.

Lastly, I always recommend, improve your speaking and writing skills as much as possible. So, writing? Do more of it and focus on it.

My 11th grade English teacher always had a phrase, concise, but precise. Use as few words as possible to express the complete idea. It’s exceptionally hard to do, but when you get better at it and the better you express your ideas, the better off you’re going to be.

Cal: Lastly, how can software professionals, in general, be better?

Keith: We have been very much in the mindset of, leave me alone, let me just write code.

I think we’re selling ourselves short there. I think we’re really getting into this position where we don’t have an understanding of the business. We don’t have any understanding of how our systems are going to be used and we’re going to suffer as a result because if you’re the software developer in the back room, that doesn’t talk to anyone, doesn’t interact with anyone, doesn’t understand the customer, you’re a super easy to outsource. You’re super easy to get rid of. You’re not valuable.

We need to understand, who finds it useful? Why? What are they going to do better or faster, easier as a result of this? How is my customer, my end-user, going to be able to go home on time because I did my job well?

When we have a better understanding of that as an industry. I think we’re going to build better systems. I think our systems are going to be more resilient and oh, by the way, we’ll probably make more money in the process.