Perspectives on how to be an effective software architect

Comment Not Found

Software architects usually interact with the clients and stakeholders of a project. They - ideally - will need to be involved in figuring out exactly what kinds of requirements the client is looking for, being able to make sure the requirements are business requirements and not just "make this page have a floating top menu bar."

Total aside: Yes, I've been on a project where we literally spent hours of meetings with CEOs of two large insurance companies just to decide whether to use a floating top menu on the web site 😜. It happens...

Anyways, the architect needs to make sure that the technical direction of the project is viable/feasible give the business needs.

So there are two primary parts:

• You need to know tech really well (system design and knowing what problems specific tech solves)
• You need to be able to communicate well with non-technical people and convert business needs into software systems/designs that will allow the business to achieve those goals and yet allow flexibility of the system to change over time.

Knowing multiple programming languages, paradigms, etc. as mentioned in the "question" of this post are helpful because every language and paradigm solve specific and different kinds of problems.

If you have a business, for example, who needs a system that will be developed and maintained by hundreds of developers, then you need to know that there are specific patterns for building these kinds of systems (DDD, Microservices, etc.)

Imagine the need for an e-commerce site which needs to keep the data of all user interaction with the site (via products ordered, products added to cart, products removed for cart, etc.) so they can do analytics in the future (I.e. predictive analysis, etc.). Knowing that Event Sourcing can solve that problem would be applicable here.

So, a big part of being a good architect means your knowledge is broad enough that you at the very least know what technologies are available to solve which problems. And you can figure out what business problems map to which technological problems and solutions.

It's good to first know what you're asking for. A "software architect" position usually refers to the job in an enterprise setting. This clarification may be useful.

What you're describing as examples is more about people who are actively engaged with the programming community, present and past, with a very specific set of questions:

1. Will this change in how I think improve some aspect of how I write software?
2. Will it break some other aspect?
3. What led the people who did this to do so?

So once you have been through this many times you look at a new library, framework, or language, and can quickly categorize most of it. Usually you can categorize all of it, in which case it's interesting only insofar as you may have to use it to get paying work done. Sometimes it remains interesting because of interactions that you haven't seen tried before (e.g., Scala trying to wed the Java type system with Hindley-Milner type systems, and experiment that I feel was a failure). Occasionally there's an interesting piece of something and you spend a few hours or a few days beating on it, trying to find what's there.

When you're just starting out, you can flail at the usual suspects and get a lot of mileage. A short list of things that I guarantee will not be a waste of your time:

• Ullman's Elements of Standard ML. Then go look at the ML language family and read the papers of people who designed the various members and what drove them.
• Leo Brodie's Starting Forth and Thinking Forth, then go mess with Pygmy Forth and read about what Charles Moore has done with colorForth.
• Spend some time working with Pharo or Self, and learn what it's like not to have a separation of a system into programs, shell, etc. Then go read the literature of people who worked on these systems and find out about the problems with them.
• Learn to write Prolog.
• Read a bunch of Dijkstra's EWDs, especially the late ones, and get into his ideas on calculational mathematics. And read a bunch of Alan Kay's work. These two couldn't stand each other's work, and being able to switch back and forth between their perspectives is a diabolically valuable ability.

SICP is a wonderful book. If you enjoy it, go to it. Branch prediction is worth understanding. If you know probability, it should take you about half an hour to understand how it's supposed to work. There's no reason to understand it at a silicon level unless you're designing chips or fighting with truly bizarre performance problems. Likewise, Types and Programming Languages is more machinery than you probably need right now. If you find yourself building type systems or programming languages, then you will read it cover to cover and it will seem like the most wonderful, applied advice ever. If you aren't in that game, you're better off getting the basics down so you can understand how various type systems differ and what the experts mean when they argue about them, and then moving on to something else. Remember, your time is finite.