In Steve McConnell’s excellent book, Rapid Development, he talks about wasting time during the fuzzy front end. This is the time of a project when you’re waiting for the new specifications to come from product design or marketing or whoever does the up-front design work for your product (or web site, etc.). After a release, especially an intense one, it’s natural to need some slow time. Keeping up a high-intensity pace on a permanent basis leads to rapid burnout, which isn’t very productive in the long term.
So, what can you do and what should you do? Here are some ideas for you next time you run into this time period.
- Clean up time. Go through your code and find all of the crappy stuff you wrote because you didn’t have time to think it through clearly. Rewrite it the way you really should have.
- Fix up the buggy back end. How many bugs didn’t you fix at the end of the previous release? Now’s a good time to fix the low hanging fruit or the ones that seemed too risky to attempt just before release.
- Design time. What would you like to see your system structured like in the future? Can you design it differently to accommodate the expected feature set? Will some new designs make it easier to add new functionality?
- Toolkit time. Do you have a lot of semi-repetitive or duplicated code in your system? Is it time to take these routines or classes and create a toolkit from them that can be called by the rest of the system?
- Prototype time. As long as you don’t get too possessive of your new code, can you develop a small prototype for some expected new functionality? If you do, show it to the designers and see if it affects their thoughts on how something might look. I have long thought that the developers of a product can make excellent designers if consulted early and often during the design process. Are your developers actually the designers of your product? Great, but having someone be the overall supervisor of design work can make your product more consistent from a look and feel standpoint and can coordinate possibly redundant development work.
The fuzzy front end doesn’t have to be a waste of time. Your developers can be more productive if they have a clue of what might be coming and what’s expected of them. Making sure that they know that possible functionality isn’t cut in stone will help ensure that time and effort isn’t wasted on completed functionality before the details come out. Setting some clear goals for the fuzzy time can help keep them focused on using the time to their advantage and keep them from going crazy while waiting for the action to begin.