Software Architects

The question of what defines a good software architect came up in a recent conversation.  Well, several recent conversations, actually.

In the software world the title "{software,system} architect" is perhaps one of the more suspect titles there is.  It is one of those vague titles that doesn't really nail down what this person is supposed to be or do in a meaningful way.

Sure, if you work for a large consulting company there will no doubt be reams of paperwork defining the role of "architect" within some huge framework that your company markets as The Really Clever Way We Do Things[tm] -- but let's be honest: most reasonable people would rather stab themselves in the leg with a pencil than spend even two minutes reading what is mostly going to be the verbose and inane drivel of inarticulate morons.

I have yet to come up with a good answer to what positively identifies good candidates.   But there is at least one heuristic that can be applied to divide candidates into those more and less likely to be good architects.

My take, and it is important to note that I am expressing a subjective view here, is that at the very least a software architect needs to be a competent programmer.

If you can't program or you are a below average programmer, then the chances of you being great at thinking about architecture are going to be really slim.  It is like thinking that you have a future in theoretical physics without understanding one iota of mathematics.  It just isn't going to happen for you because you won't have adequate command of the fundamental language used to express and understand physics.

The only software architects I know whom I have found worth paying attention to are above average programmers as well as being good at thinking of architecture and system design.  Not only that, but they spend a significant amount of time maintaining these skills by participating in software development and keeping abreast of what goes on in their field.

The main danger of becoming too far removed from where the rubber meets the road is that it gradually changes your perception.  You start to think about complexity and sources of complexity in a more abstracted manner.  You tend to forget how hard the details can be,  which details are important and which are not.  You gradually lose language and intuition.  You become prone to base decisions on politics and vague, or unfounded, assumptions rather than deep understanding.  And when assumptions suddenly change you may not understand the implications in time, or at all.

It should also be noted that just because someone is a brilliant programmer does not automatically mean they will make great architects.  This is roughly equivalent to thinking that a good practitioner in some field will always make a good leader, or even capable of even vaguely normative works in that field.
Some do, most don't.

In fact, the software engineering industry is full of quacks and charlatans who have had some success as programmers, but who then shamelessly go on to peddle pseudoscience and feelgood easy fixes.  (I'll leave it up to the reader as an exercise to identify the more egregious offenders).

My main point is that being an architect takes deep, detailed and up to date working knowledge of technology to the point where you wouldn't be completely lost if you had to get your hands dirty.  If you are too far removed from the action you most likely won't be any good.


  1. After some exposure to them, I've come to believe that a large number of them are rectruited from the ranks of undevelopers - i.e. dead developeres that have been re-animated by evil coorporations.

    The insight can be very beneficial for developers. Architects usually have a higher paygrade - and they can easily be impersonated...