Joel Spolsky has often blogged his opinions on Software Architects. Those people who design whole software environments and their tendency to become astronauts (that is divorced from the realities on the ground). I have a great deal of empathy with his view. Grounded architects may have some use in large companies to set a general technical direction and aid communication among independently working teams. In smaller groups there is no need for them, yet they often appear. Recently I have worked on small teams of 5-10 developers with 10-20 tasks that need to be done immediately. At these workplaces there has been a focus on getting things done and we have all handled our own design, relying on professionalism to keep us all moving in the same direction. So luckily I have avoided Software Architects for many years, but my luck is running out – I have just encountered people ready for take-off.
I have some empathy for the architect – just a little. I used to have designs on being an architect. I wanted to do things the “right way” (in quotes because it is always a matter of opinion, with many caveats). For a technical person it seems like the place where you can have the most influence. It is also part of the informal software development career path, on which I was once travelling. However, as I enjoy programming I would help code my solutions. Thus I encountered the problems that occur when abstract perfection meets messy reality. Solving the problem has to come first – to paraphrase Jeff Atwood the architecture should be framed in the context of the problem.
Now I think the first priority should be solving the clients’ problem. For the last 6 years or so I have chosen workplaces that emphasise “getting things done”, especially since timescales are always tight. One can make the argument that it takes time to do things right and we should take that time. That is true, and if that is hugely important you should probably work someplace else. Where I currently work, our original project was to create a complete European government bond trading platform in around 3 months. The market opportunity was fading fast and costs were increasing. If an extra year was taken to produce a technically beautiful solution the result would be useless as the investment wouldn’t be recouped in a reasonable timeperiod. Corners had to be cut and they were, but we delivered on time. Now when time allows we can refactor the system into a better state.
The current architect wannabees I have encountered are ranting that the reason they can’t get their job done is that our environment is crap (despite being part of the team that created that environment). It needs to be ripped up and started again the “right way”. They produce eloquent arguments for beautiful service-oriented architectures. While I agree that their vision is better than our reality, it in no way reflects our reality. Worse, they are not very good coders, and they use our “wrong” but working environment as their excuse for their messy, buggy code. When given the chance to rework something from scratch without dependencies on other components they still produce buggy, messy, unreliable code that no one wants to use and took 4 times as long as the original working version. This has happened not once, but twice! As a result, we are further from the right way as we have to cover the other person’s unfinished work and fight their new code, leaving us less time for refactoring. Yet still they continue, it will all be better if we just do everything their way. Personally, I’d rather just solve the problem at hand – which at the moment includes them!
Just had to get that off my chest.