The Death Sprint : an anti-pattern (Technology)
By Bert Peers
Fri Jul 12th, 2002 at 11:21:14 PM EST

The Death March antipattern describes a situation that all too many programmers have been stuck in : despite a team of quality programmers, putting more effort into the project only seems to increase the time before it is good enough to be released. Ultimately, the project is canned, or it ships in a state making everyone deny involvement.

At the other end of the spectrum is extreme programming, with short release cycles and incremental design forcing a regular flow of releases that are reliable, even if not very feature complete.

Is it possible to combine the worst of both worlds ? Suggesting it is, I introduce the Death Sprint anti-pattern.

 

Anti-Pattern Name : Death Sprint

Also known as : Overheating; Institutionalized crunchtime; Nonstop featuritis

Symptoms :
Software is released iteratively, with the time between cycles being shorter than what the underlying development process supports. As a result, the project appears to be a success -- it ships and has the features -- but the quality of the product, both technically and visibly, suffers. It gets worse with every "successful" iteration.

Related anti patterns :

  • Death March -- Death Sprint and Death March are opposites. A death march project drags on forever; it seems to take an eternity before a useful version can be shipped. At best, one or two alpha/beta versions are released, but they are usually explicitly marked as of inferior quality. Its failure is visible to everyone, since not a single milestone is met. A Death Sprint looks succesful, hitting milestone upon milestone; only the developers are aware of its shaky foundations.
  • God Class -- As the pace never slows down, there is no time to design with, or refactor to industry standard solutions. A common net result is one or more god classes with a typical haphazard collection of random features.

Causes :
Sometimes, survivors of a Death March will want to avoid getting trapped into the same situation, by adopting the Release Early, Release Often style. Other times, a team is under pressure from maintenance or sales contracts to provide updates at negotiated, regular intervals. The contract may require new features, not merely bugfixes. Yet another force may be market pressure, a competitor releasing updates with new features every few months.

What turns the good intentions into a Death Sprint is the omission of a crucial element that distinguishes Release Early, Release Often from Hack And Fix. This element is refactoring, a non-stop focus, as an integral part of the development process, on minimizing the bug count, on improving the general quality, and on incorporating new insights in the problem back into the code and design.

Without this focus, a vicious circle develops : new features need to be added onto a code base that is not really suited for them. This in turn produces a code base that is even more resistful to future changes. Inevitably, trade offs need to be made to keep hitting the milestones; depending on the choices made, problems can be degraded performance, reliability, security, or general feature regression.

Solution :
Since the release velocity is higher than the process velocity, there are only two solutions : lowering the release velocity, or increasing the process velocity.

As the vicious circle is very real, every sprinting team sooner or later needs a hard stop -- a feature freeze to clean things up, effectively slowing the release speed to zero. The project is usually too big by this time to right all wrongs. However, the team can probably anticipate the mid-term future demands and prepare the project for those. This does not fix the existing quality problems, but it may at least break the circle in the next few milestones.

A more fundamental approach is to fix the development process itself. As shown in Causes, the root problem is an adoption of a high-speed release philosophy, without using a process supporting this speed. A Daily Build is useless, from a quality point of view, if it is not paired with a Zero Defect mentality. Awareness and tracking of quality problems is pointless, when fixing those problems is postponed until the feature tasklist is empty.
In Extreme Programming, a crucial element is refactoring, to compensate for minimalistic up-front design. A Death Sprint has the "advantage" that quality and reliability are already suffering in a major way, and therefor agressive Refactoring is an attractive way to clean up. This is true even if there are no resources or time available for unit or functional testing. There was, after all, no properly working product before refactoring started anyway.
These examples come down to recognizing, company-wide, that quality metrics are not only important, but that optimizing for them must be an integral part of development, not a time-permitting postprocess.


Links