The Travelling Programmer |
||
|
Location: Perth, Australia
Next: ?
Jobs: Programmer Teacher
|
15 May 2008Joel Spolsky wrote an interesting and informative article on architecture astronauts. Go and have a read. This is a topic near and dear to my own heart. Through my time at a previous employer I gained more experience with architecture astronauts that I ever wanted. Joel wrote about this phenomena from the perspective of a Microsoft customer and competitor. For those whove never been through it Id like to explain what goes on in a company thats being invaded by architecture astronauts. The Holy WarsThe company had divided itself into three camps. Camp one, the astronauts, was championed by the business development manager. The group included a smattering of managers and programmers. How the hell does a bdm get involved in architecture decisions? Well, because he fancied himself quite the technical savant despite his negligible experience. He was backed by a cadre of managers and programmers he'd managed to convince that sufficient abstraction and framework development would cure all of their problems. The astronauts had developed one of the companies big products. Camp two was championed by the most experienced programmer in the company. He had attained the lofty heights of managing the companies other big product. He was backed by the officially acknowledged best programmer in the company, the resident boy genius and a number of other programmers including myself. We just wanted to ship code that could be installed and maintained by mere human beings. The third group was made up of about half the company and they were the spectators necessary for any gladiatorial contest. Discussions between the two camps consisted of us presenting well thought out logical arguments for why excessive architecting was hurting us while the other camp would clamp their hands over their ears and chant "needs more abstraction. needs more abstraction." It was a contest between quietly spoken experience and knowledge Vs repeated loudly asserted dogma. And lo there was much strife in the land. Integration of the two products was fiercely advocated by the astronauts and resisted with equal ferocity by the non-astronauts. Arguments were plentiful. How We Got ThereThe root issue was nontechnical people feeling they were qualified to dictate technical decisions to technical people far more experienced than themselves. Thats ok if were talking a user experience issue but not for the internal aspects of the software. Once were talking anything but offered functionality and the UI the sales people shouldnt even be in the room. Let them dictate architecture to the quietly spoken programmers using their big strong personalities at your peril. I suspect this is why software companies run by sales guys often ultimately go broke. Theyre entirely dominated by sales guys from day one. Theyre operating out side their area of expertise and its only a matter of time until they make what looks like an innocuous decision that brings down the company. Im not saying sales people are bad but you generally wouldnt take a programmer out on a sales call would you? Theres a good reason for that. They say inappropriate things. They dont really know how to handle the sales process. The Holy Wars Are EndedSo how did it end at that company? Eventually the technical manager who championed the non-astronaut group quit to go work in a role at another company where he'd be able to work quietly by himself without having to wage any political wars. The victors were benevolent. There were no purges. Those of us remaining from the defeated camp were accepted into the fold. We were even given more responsibility. Henceforth we were to maintain not only our own product but also the product developed by the architecture astronauts. It turns out they were dying to get rid of its buggy unmaintainable carcass. |
|
|
©2008 Andrew Add to Technorati Favorites
|
||