That certainly doesn’t sound very appealing, does it? But it might depend on the context, and it actually might be a pretty good idea in software development.
During WW II, when the British were under attack by German bombers, they desperately needed a way to detect incoming hostile aircraft as early as possible. They knew that it was possible to bounce radio waves off of objects like airplanes and measure the distance somehow, but there were a lot of details to be worked out to make this work well. The British scientist who directed the R&D work on this project, Robert Watson-Watt, became frustrated with the slow pace of development work because he knew that time was of the essence – if they didn’t get something working fast, even if it wasn’t perfect, it soon wouldn’t matter at all. So he told his team to aim for “second best, tomorrow.” The goal was not to create something second-rate, but to build something that worked even if not perfectly, and have it done tomorrow, and not take months or years to come up with the perfect solution. Once a basic system was working, it could be used right away (time to market), and could be enhanced over time if necessary.
The product was radar, and I think Watson-Watt’s thinking is relevant to what we do here today. While we are not building software in response to an emergency wartime threat, we are working in a highly competitive world where speed to market is of the utmost importance to increasing our revenues and overcoming our competitors.
In my opinion, the best way to create software rapidly and economically is to use agile development. Agile is a topic that other writers have already mentioned many times in this forum, including Jeff’s recent post. There are many aspects and methods of agile development, but the overall methodology that I like the best is simply iterative development with cross-functional teams.
The key concept of iterative development (sometimes called “iterative and incremental development”) is the use of a series of fixed time-boxes, each one of which results in something that works and is incrementally better than its predecessor. Once you get something working, you can demonstrate it, get feedback, refine it … and even ship it, if good enough. We don’t have to worry about the approach of enemy airplanes, but I’m pretty sure our competitors are hard at work right now on their own good ideas, so the sooner we can get our products to market, the better.
Watson-Watt actually used time boxes for his radar development team. He gave them fixed amounts of time to reach incrementally better versions of a working product, and then put each version into production. This might sound like a reckless disregard for quality, but it’s not. It just has to be good enough to work and do its intended job, without any frills or extras. Watson-Watt’s crude term for that was “second best” – we might chose different terminology – but the concept is the same.
