Friday, December 29, 2006

Smart Suits

After a little hunting around, I became “world wide chief scientist” for a pretty large software development organization, with offices around the world. Officially, I was responsible for all software products. In practice, I was only responsible for the exciting “next generation” ones. This gave me another great technical refuge, where instead of speaking to real clients I spent most of my time surrounded by senior technical people from our various offices forming a mutual admiration society.

To be honest, this was a quite different kind of company from my previous employers, since the chief executive himself was deeply involved in ensuring developers had “clear focus” throughout their work. He made sure we had a unambiguous and unwavering requirements up front, then gave us four years to deliver a system matching them. During that four years we only had one business meeting involving anybody outside the development team, and that was to discuss salary reviews. As far as we were concerned, requirements were fixed, and now we could remain focused on real software development without any outside interference or moving goalposts (as we called unwanted requirements changes).

We had no uncertainties. We “got on with it” and delivered on exactly what he wanted. The chief executive was delighted. Here, we felt, was a “smart suit”. He knew what he wanted, expressed it clearly, and provided an isolated environment where we could deliver on our promise. He boasted at conferences about how great our development process was, and what a great job my team had done. We were heroes.

The downfall came a couple of years later, when it slowly dawned on that that although we had faithfully delivered precisely the product the chief executive has asked for, hardly any customers actually bought it. We produced something without mess or uncertainty, and nobody wanted it.

We had assumed that development was about pinning down requirements up front, and delivering whatever those requirements dictated would lead to success. We hadn't worried about whether or not those requirements were relevant to the target market. We has assumed that “if you build it, they will come”. Well, they stayed away.

My painful lesson from this experience was that a “pinned down” requirements specification doesn't make your worries go away.

No comments: