Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Death Sprint : an anti-pattern

By Bert Peers in Technology
Fri Jul 12, 2002 at 11:21:14 PM EST
Tags: Software (all tags)
Software

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

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
How do you rate your company's software process ?
o Excellent -- we ship software that matches our programmers' full potential 5%
o Good -- could be improved, but the final product is solid 35%
o Adequate -- it's ok, yielding software that is "typical" 22%
o Poor -- it adds a few good things, but generally sits in the way of quality 12%
o Horrible -- if it were allowed, freestyling would probably yield better code 24%

Votes: 77
Results | Other Polls

Related Links
o http://www .antipatterns.com/
o http://www .extremeprogramming.org/
o http://www .joelonsoftware.com/
o Also by Bert Peers


Display: Sort:
The Death Sprint : an anti-pattern | 48 comments (28 topical, 20 editorial, 0 hidden)
Extreme programming (4.20 / 5) (#4)
by rdskutter on Fri Jul 12, 2002 at 06:45:36 AM EST

XP is not "Design as you go". You still need a well thought out design process before you start coding.

XP does allow you to deal with errors in the design as they are found. Redesign can happen even if all to code is not complete because of the approach to coding.

It's not top down and its not bottom up - its just "build the smallest thing that works then gradually make it more complex".


If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE

Agreed (3.50 / 2) (#6)
by Rogerborg on Fri Jul 12, 2002 at 06:54:55 AM EST

    XP is not "Design as you go"

Good spot. I interpreted this as "design only what you need and when you need it", but that's because I know that's what it's supposed to mean, as opposed to "design everything before you start". But I can see how it could be interpreted as "make up the design any way you like", or implying that design isn't important in XP. Needs clarifying for the benefit of those not familiar with XP. Also, some links would be nice.


"Exterminate all rational thought." - W.S. Burroughs
[ Parent ]

XP Design Myths (5.00 / 3) (#8)
by rdskutter on Fri Jul 12, 2002 at 07:07:09 AM EST

If your approach to XP is "Design only what you need and when you need it" then your project will fail.

You need a good solid design phase and a very good idea of what the FINAL product will do. If you don't consider the full scope of the project in the initial design phase then you will find that the last (And often most complex) parts of the project will be hacky to bolt on to the existing design. Even worse - the existing design will be set in stone because you've already coded it.

A successful XP project has: A good solid design and A project plan. The project plan breaks the design up into stages: for example:

  1. Core architecture
  2. Essential features
  3. Nice to have features
All of them are fully designed before anything is coded. It is the coding and testing and redesign phases that are done incrementally NOT the initial design.


If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
[ Parent ]

You must be thinking of some other process (none / 0) (#43)
by Ghost Ganz on Mon Jul 15, 2002 at 04:46:25 PM EST

Before we discuss XP we should maybe have a clear idea on what XP is.

What you are describing sounds more like some parts of the Rational Unified Process. A "design phase" is  something you won't find in a by-the-book XP project.

More info on XP can be found on http://www.xprogramming.com/

[Bottle 'B' is for the monkeys only]
[ Parent ]

I know what XP is (none / 0) (#45)
by rdskutter on Tue Jul 16, 2002 at 05:23:25 PM EST

I've also taken part in/managed many successful projects using XP and there has always been a complete design before the code was started.

Its worth noting that this design changed a lot during the project and the final product was very different from the original design because we were able to modify the design to suit the client's ever changing requirements as the project progressed.


If you're a jock, inflict some pain / If you're a nerd then use your brain - DAPHNE AND CELESTE
[ Parent ]

Complete design? (none / 0) (#46)
by Ghost Ganz on Wed Jul 17, 2002 at 07:34:53 AM EST

What do you mean by "complete design"? Did you have a XP-style Metaphor or a suite of UML design documents before you began, or are you refering to requirements or something else?

In general XP:ers refer to a complete design before starting a project as "Big Design Up Front", something XP is intended to avoid. Is what you are doing something different than this?

[Bottle 'B' is for the monkeys only]
[ Parent ]

Agree, but... (4.00 / 2) (#7)
by Bert Peers on Fri Jul 12, 2002 at 06:57:02 AM EST

Yeah, "design as you go" means "design as requirements become available and important", not "design as you program". The problem is maybe that the difference is subtle -- "designing" can mean "sketching out" some interfaces in C++, in what could become the actual header file. Especially with the suggestion to "travel lightly", it is likely that the only design document available is the code.. Redesigning is dangerously close to "fixing" the code, then..

[ Parent ]
Right On (5.00 / 3) (#12)
by bugmaster on Fri Jul 12, 2002 at 08:20:46 AM EST

Bravo ! A relatively large design cycle is crucial even (or, perhaps, especially) when using XP. Otherwise, pair programming quickly degenerates into "the blind leading the blind".

The Death Sprint project that I am currently on has fallen victim to this problem: we did not design our code at all, initially, and now the release cycles are too short to refactor anything. Result ? Constant hacking of code together. The common statement is, usually, "well, let's just fix this one special case in release N, and then we can rewrite it correctly in release N+1". Gee, guess what happens in N+1...
>|<*:=
[ Parent ]

Am I the only one (2.75 / 4) (#10)
by Bob Dog on Fri Jul 12, 2002 at 07:21:27 AM EST

Who suspects that Design Patterns and XP is an oily substance with scales.


Yes and no (4.75 / 4) (#11)
by Cloaked User on Fri Jul 12, 2002 at 08:19:52 AM EST

I have my doubts about XP, but I've never tried it, so I'm willing to be proved wrong. Design pattterns, on the other hand, I see nothing reptilian about.

All design patterns are, after all, are tried and tested solutions to particular problems. Hell, the client/server system architecure is a design pattern, as is the use of a proxy. Both of these are clearly fundamental to the way in which the internet works currently (okay, so proxies are less important, but still widely used).

I have personally used a number of different design patterns in the course of my work, and have generally found them to be very helpful. Whilst I recognise the value of an intellectual challenge (and am more than happy to engage in interesting ones), I also see no point in wasting time trying to come up with novel solutions to problems when perfectly acceptable ones already exist, at least when I have a deadline to meet. In my spare time things can be different, of course, but even then I'll generally use a suitable pattern.

Cheers,

Tim
--
"What the fuck do you mean 'Are you inspired to come to work'? Of course I'm not 'inspired'. It's a job for God's sake! The money's enough and the work's not so crap that I leave."
[ Parent ]

Design Patterns (4.80 / 5) (#13)
by bugmaster on Fri Jul 12, 2002 at 08:23:17 AM EST

I think the key point to remember is that design patterns != holy commandments. They are guidelines, and maybe helpful examples, but not any kind of holy writ. Too often, managers and project leaders force everyone to use some design pattern because The Book Said So (tm); the results are usually a disaster.
>|<*:=
[ Parent ]
Too specific (5.00 / 3) (#32)
by p3d0 on Fri Jul 12, 2002 at 01:49:14 PM EST

Any design methodology that claims to alleviate the need to think is doomed to fail. Whether Design Patterns and XP fall into this category depends on who's trying to sell it to you.
--
Patrick Doyle
My comments do not reflect the opinions of my employer.
[ Parent ]
Baahahahahahahaahahahahaahaaaaa (3.00 / 4) (#14)
by porkchop_d_clown on Fri Jul 12, 2002 at 08:30:07 AM EST

Thanks. I needed that. We've posted it in the office.


--
ACK.


This whole story (none / 0) (#15)
by FredBloggs on Fri Jul 12, 2002 at 08:35:34 AM EST

reminds me of this:
http://www.qs9000.com/level2/Bingo.html

Can you be more specific ? (4.00 / 1) (#16)
by Bert Peers on Fri Jul 12, 2002 at 08:48:47 AM EST

I'm not offended or anything, but maybe you can offer some suggestions ? Is it the general style of writing, the buzzwords that annoy you ? Or do you think the actual content is nonsensical ?

I hope it's not the content -- I decided to write this after thinking about some real life experiences, where I couldn't figure out why things didn't work. After all, we were combining elements from various tried and true practices. Things only cleared up after realizing we were mixing the wrong things, in a wrong way, hence the "worst of both worls".

I tried to relay this with the story, maybe clearing things up for others.. which turned it into an anti-pattern.. So I'm interested in hearing if you think it's not doing a good job of that, or if it's just plain stupid :)

[ Parent ]

I`ve heard (2.00 / 2) (#17)
by FredBloggs on Fri Jul 12, 2002 at 09:19:29 AM EST

of the problem that adding people to a project doesnt make it any quicker to complete, but i`ve not heard of a `Death March` (outside of history lessons). I`m not sure what an `anti-pattern` is. I`ve been programming for years, but I have no experience or knowledge of `extreme programming`. So although it looked on the surface like something i`d be interested in, I`m afraid I just cant approach it in the style you`ve taken. Perhaps its just me...or perhaps it could be written using standard CS terminology. I believe Microsoft (yeah, yeah) have written a book on this exact area (it came out around the same time as `Code Complete` and `Writing Solid Code`).

I certainly am not implying your story is bullshit!

[ Parent ]

Hmmm (2.85 / 7) (#19)
by speek on Fri Jul 12, 2002 at 09:43:35 AM EST

You've been programming for years...
....never heard of 'Death March'
...never heard of 'anti-pattern'
...never heard of 'extreme programming'

Maybe it's time to take a break from all that programming and educate yourself.

--
what would be cool, is if there was like a bat signal for tombuck - [ Parent ]

What this corrorsive individual means (4.33 / 3) (#38)
by X3nocide on Fri Jul 12, 2002 at 06:12:35 PM EST

I'm sure he meant to say, "extreme programming is a an emerging process of software development. Here are some places to learn more."

Having said that, standard CS terms will not get you far in the world of Software Engineering. Linked Lists are useful for talking about programs, but not so useful in measuring how they're made. Wikipedia has one useful section devoted to eXtreme Programming (XP). Anti-patterns take on the concept of patterns discussed in the Gang of Four and illustrate common bad solutions to problems, typically development related, rather than the software itself. The 'Death March' is one of these anti-patterns. The author has also provided a few useful links for the interested.

pwnguin.net
[ Parent ]

SE, not CS (none / 0) (#44)
by tpv on Tue Jul 16, 2002 at 03:16:09 AM EST

Without knowing your history or location, I'd guess that the gap lies in your use of the phrase "CS terminology"

Anti-patterns, death-marches, and extreme-programming are not Computer Science features in the way that Linked Lists, algorithms and Inheritance are.
Rather, they are Software Engineering (i.e. methodology) features, in the same vein as UML, Use Cases, and design patterns.

I have a reasonable (but limited) understanding in that section of software development, and the author's use of these "buzzwords" seemed appropriate to me.
Perhaps he should have structured the article with more upfront explanation of these concepts, but the article itself was (IMO) appropriate.

[ Parent ]

Freestyling will PROBABLY yield better results? (4.33 / 3) (#28)
by Vygramul on Fri Jul 12, 2002 at 11:57:00 AM EST

WE USE Freestyling where I work, and any attempts at standardization is not only lost on people, but you're punished for it. Were it not for the pay, benefits, and poor job environment, I would have left by now.
If Brute Force isn't working, you're not using enough.
Portland Pattern Repository Wiki (5.00 / 3) (#36)
by Tyberius Prime on Fri Jul 12, 2002 at 02:40:03 PM EST

you should consider posting this here

It's a great resources for discussing patterns and other, software design related fields.

Responses (5.00 / 2) (#37)
by Scrymarch on Fri Jul 12, 2002 at 05:43:27 PM EST

That wiki is both at ease with the design patterns concept and watched by some genuine luminaries in the field, eg, Kent Beck and Ward Cunningham.  You'll probably get better feedback there by avoiding the worthy but dull arguments erupting above, which represent the conservative rite of passage that all new ideas in software must pass through.  Though they're not exactly in the vanguard of the critics if they haven't heard of a pattern before.

Personally I think management-ish patterns are harder to describe well; but the author definitely communicated something I both recognised and had no name for.

[ Parent ]

This is how Netscape died... (4.50 / 4) (#39)
by tapir on Sat Jul 13, 2002 at 06:35:00 PM EST

Netscape's original codebase died this death.  From Netscape 0.9 to Netscape 3,  Netscape kept adding features,  getting better and better.  Netscape 4 added even more features,  but it was a buggy piece of crap -- and the new stuff didn't work well enough to be worth using.

Netscape's codebase grew exponentially throughout this process,  until it became entirely unmanagable.   Worse than that,  the fundamental design couldn't adapt to new web standards.  Netscape's internal representation of a web page had nothing to do with the W3C's Document Object Model,  so it was almost impossible to implement correct CSS support in Netscape.  (I wonder if Microsoft knew this when they pushed CSS.)

When Netscape first released the source code for Navigator,  it was hoping that the code could be saved by either refactoring or building a jerry-rigged mechanism making it possible to implement CSS support.  However,  the community realized the codebase was unsalvagable,  and forced Netscape to start from scratch.

As a result,  it took years for Mozilla to see the light of day.  On the other hand,  Mozilla is a pretty good browser.

ral reason of death of Netscape (4.00 / 1) (#41)
by axxackall on Sat Jul 13, 2002 at 11:57:25 PM EST

Netscape at its v4.x was better than IE in both terms of bugs and features.

I cannot tell the same about the top managers of Netscape - they gave up very good line of products and a good company, probubly under the persoanally commisioned pressure from Microsoft. Opening the source code was decided as a part of the deal when they closed the company. Mozilla shows exclusively excelent results counting in which political conditions it was recarnated.

Similar story is about how some just-returned top managers in Apple gave up CyberDog - still looking modern and revolutionary. CyberDog is just waiting when Apple will either restore own development of CyberDog or open the source.

[ Parent ]

Ouch (none / 0) (#47)
by bodrius on Thu Jul 18, 2002 at 01:09:49 AM EST

This comment seems to have a couple of valid, good points. But I can't be sure because my eyes hurt trying to parse it.

Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]
Mozilla - instructive release cycle (4.00 / 1) (#42)
by arvindn on Mon Jul 15, 2002 at 07:18:15 AM EST

Talking of Mozilla, it is instructive to see how they manage to maintain that enormous codebase and still go on adding features. From their Roadmap :
... each major milestone takes one quarter of a year or thirteen weeks to be delivered, and starts with a five-week "alpha" milestone, during which destabilizing development should be done. This is followed by a five-week "beta" milestone period during which less risky bug fixes, in particular followup and cleanup of the alpha phase work that tend to restabilize the codebase, should be targeted. Finally, a two to three week "done" period, where only driver-approved changes can be checked in, completes the milestone.
As a related issue, for most projects, a developer coordination model such as "Benevolent Dictatorship" is essential instead of complete anarchy.

So you think your vocabulary's good?
[ Parent ]
This reminds me of Linux's release schedule... (2.87 / 16) (#40)
by Steve Ballmer on Sat Jul 13, 2002 at 08:22:35 PM EST

... "Release Early, Release Often" without ever becoming complete.

Fortunately, there is a better alternative. Using Visual Studio.NET from Microsoft, developer productivity can increase exponentially. Linux, on the other hand, well, they have to give that shit away.

Steve: A desperate plea! (3.85 / 7) (#48)
by Steve Jobs on Fri Jul 19, 2002 at 03:53:51 AM EST

Look Steve. I'll be right to the point here. That party we had last night, I placed my Diner's Club card down on the table and we had agreed that we would split the cost. You didn't put down your plastic on the table, footing me with the bill. Here are your options: 1) Buy me a whopper, 2) Refund me to the order of $3.37, or 3) Find your marketshare dropping because of "Mac OS X for X86: He didn't fucking pay for my goddamn Burger King meal edition

Checkmate. It's up to you now, big boy. Wink wink.

[ Parent ]
The Death Sprint : an anti-pattern | 48 comments (28 topical, 20 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!