Architects and Developers

So one of my colleagues reading yesterdays blog shouted out to me across the office “You only like architecture because you are a c**p developer”. I took this as British humour (I hope!) however it is reasonably accurate; I am a poor programmer. The last time I had to do any serious programming was 5 years ago when I had just started at the Office Strategy Group in Microsoft at Redmond. The group was working on the digital dashboard and they needed some sample web parts to ship with the kit. As I was the new boy and everyone else was busy I got detailed off to write them. Given that it had been many years since I had done any programming, I didn’t know anything about web parts or the digital dashboard and I only had a week to do it (all excuses!) the very buggy code I produced wasn’t a great surprise but even so a decent programmer would have done a lot better.

So whilst I am a poor developer I am actually a pretty good architect. Indeed most architects I know are not great programmers and most great developers I have come across are not very good architects. This is of course a generalisation but I think its a reasonably valid one (and please lets not have the “My Aunty Gertrude is a red hot C# programmer working on the Longhorn Kernel and she architected the whole of the Megabank customer processing systems in a day on a napkin” comment, there are always exceptions!)

I think this is because the skills required to be a good architect are subtly different from that of a good developer; typically an architect is working with complex, multidimensional and in many cases conflicting requirements and solutions whilst a developer is working a complicated set of programming constructs and techniques. Typically developer problems are solved by the well known divide and conquer (D&C) approach; however D&C does not work for architectural problems because of their multidimensional nature. Typically good architects work with a simulated annealing approach to problem solving where you expand the problem domain and then use D&C. This means that architects are much more comfortable with multidimensional complexity; it also means they are a lot slower in getting a solution, especially if the problem is simple!

I have done a ton of interviewing of architects and typically look for this simulated annealing in their problem solving approach using a number of architectural problems that I have come across that cannot be solved by D&C (in fact make the problem worse). One of my favourite non technical interview questions is very simple and designed to see how people analyse problems. Their response allows you to categorise them roughly into mathematical, logical or analytical thinkers. Developers tend to be logical, architects tend to be analytical, I not sure what the mathematicians are! Again, these are generalisations so please don’t tell me about your Auntie Gertrude. Here’s the question if you want to see what you are:

I have a cup of coffee and a cup of tea. I take a teaspoon full of coffee and put it in the tea. I then take a teaspoon of the tea and put it in the coffee. Which is the purest, the coffee or the tea? Explain your thinking.

I will put the answer to this in the feedback. Have fun!