How fixed software release dates hurt customers, quality and budgets

Let’s say you’ve planned a release date of next January for a software release. (Yes, I know, we’re assuming the whole Maya thing comes and goes without any impact on you or your customers.) The date has been set by management and marketing is pounding the ground to build up the public opinion momentum for rushing out to buy the next software version on that date. What’s the problem? The problem is that a fixed software release date can hurt customers, quality of the product and even your budget for the project. How so?

  • A strict release date doesn’t offer extra time to fix bugs that are discovered. The development team can attempt patches without adequately testing them, target the worst problems and plan on fixing the less important bugs later, or plan on releasing a fix shortly hereafter while telling customers they are aware of the problems. In all three cases, the fixed release date acts like a brick wall that shatters product quality.
  • Another solution to fixing bugs is finding the time to fix it. Meeting the strict deadline without hurting quality requires more overtime from existing staff or hiring contractors to help with the work. Both additional contractor labor beyond the planned head count and paid overtime to existing employees are more costly than a month of additional but standard 40 hour work weeks for the team. If overtime is not paid to employees, the demands of unpaid overtime can lead to employee burnout, high error rates or staff simply quitting.
  • Meeting the schedule may be achieved by cutting short test cycles. Fewer test cycles or less rigorous testing catches the most obvious problems but reduces the odds of catching improbable ones. Product quality suffers as a result.
  • Scope creep with additional requirements adds time and cost to software projects. When time is of the essence, the opposite occurs, with the scope of the project artificially constricted. Planned new features are dropped due to the inability to properly code it or debug it while teams focus on bug-fixes. Or features are added while long-awaited fixes may not be implemented due to resource and time constraints. Users then get the new but not so improved software on the planned release date. This hurts users’ opinion of software that the new product is not quite so improved.
  • Setting strict software release dates without regard to actual software development time can put performance pressure on all areas of the software development chain. Two of the final areas of software development are user documentation and technical support. When the software development is not completed until the release date, user documentation cannot be completed until after the release date. Users may be given older versions of software support documentation and told to refer online to the updated versions to be created. Technical support teams are also left to struggle with incomplete or inaccurate support information. When software development runs up to the wire, users are left suffering with inadequate documentation and software support at the time they are most likely to need it, in the right after the software release or the “hyper-care” period.