Hi, friends!
In times where I think about career a lot, when my brain is idling while I’m waiting for the subway, folding laundry or something, it starts to play future job interviews in my head. One voice is coming up with interview questions, the other tries to find good answers. (It’s not required to be schizophrenic to play this game, but it certainly helps…)
Today I had to deal with the question “What do you think about software architects?”.
This was a tough one. Though I do have a strong opinion on software architects, you don’t always want to answer straight away in a job interview. Of course you should answer honestly, but you can still put a spin on it in one way or the other. You want to sound smart and give a well founded own opinion based on your experience, but you do not want to take the risk of insulting the interviewer by discrediting something he may identify with. In this case, how would I know if the interviewer is an evangelist of lean product development or a proud senior architect?
So this is what I answered (After quicksaving and reloading a couple of times. Yes, that’s possible. We are not playing in Iron Man mode here!):
Given that you have the role of a software architect in your organisation, and it’s more prestigous and better paid than the software developers, every developer wants to become an architect, and your best developers are promoted to be architects pretty soon. That means, you architects are probably very good engineers, and they do a great job making all the big decisions, defining interfaces between components and coming to the rescue if a dev team is in trouble.
Nevertheless, I think it’s not a good idea to have the architect’s role at all, because it’s constantly draining the best developers out of the teams, leaving each team in a state of everlasting inexperience.
If those people stay part of the teams instead and keep coding, they contribute a lot individually and teach the less experienced developers by example, making the whole team way more productive. At the same time, when they make that big decisions, they know more how the system currently works (in code, not on paper and diagrams), so the outcome will be better. Even more, they see if the developers understand and embrace the architectural concepts; that way you avoid that the code becomes very different from the ideas over time.
Now, if the team’s product is quite small, there is not enough big-picture-work for a full architect’s position anyway, so he can easily be a senior developer and take care of architectural decisions when necessary. On the other hand, if your system is that large so that you feel you need a team of architects to maintain the big picture, you’re probably better off to split that system into team-sized microservices that can be developed independently and let the teams figure out interfaces for the nnecessary calls from one system to the other.
I admit that I have this view based on a limited experience: I have seen big teams with big systems fail to coordinate, although there were architects in charge; and I have seen small teams succeed with small, communicating services, leaving architectural decisions to experienced developers in the teams. If you show me a software system which is impossible to build as microservices and it works well to have it designed by architects and built by developers, I’m happy to adapt my opinion.
Me, in my head
There is one more thing though that I have to say about architects, but I left out in my answer: A service company (which is renting out their manpower to build a software project) usually can bill a higher rate for someone called “architect” than for someone called “developer”. For their business, it makes sense to staff a project with as many high-ranked employees as the customer is willing to pay. If the customer is convinced that there should be architects, of course the service company gives the title to someone who else would be a senior developer, or even adds an architect who draws diagrams no developer needs, just to increase the bill.
I strongly dislike it, but from a business perspective it makes sense.