The following is a true story. I haven't even bothered to change any of the details.
1. The developers were really enthusiastic about .NET technology but they couldn't persuade management to re-write any of the existing products using it. 2. The developers went off and put together a general, all-purpose platform with data management capabilities. It was so general that it could have housed almost any kind of products, including ones far outside of the range offered by the company. It used every .NET feature, including remote databases. (The developers may have thought that they were working for Microsoft.) 3. They showed it to management. Management wanted to know what it was good for. The developers said, it's a product development platform with data management capabilities. It uses all of the latest .NET features. 4. Management asked, could it help customers manage their data? Sure, said the developers. It manages any kind of data. 5. The new product got a catalog number and product manager to manage it and promote it. 6. After five years in development and three years in the market, the product was canceled. No problem with existing customers being upset about the cancellation; there weren't any! Moral of the story: the kind of programmer directed development that Frank Wales references only works if the developers are developing something whose usage the developers understand well, for example, software the developers will be using every day themselves. The usage knowledge requirement also extends to the adoption mechanism, e.g., who will distribute/promote/sell it? For the remaining 99% of the time, a good set of requirements, not specifications, really helps. The requirements needn't be detailed but they must give the developers a really accurate idea of the problem they are solving. Tomorrow, I'll tell a story about agile development in which they didn't bother with documentation, because the code is what is really important, and they didn't bother with test cases until the very end. I'll also tell the true cost of the project, including the cost of "agile recovery." Ruven Brooks
