Projects from hell – chill or scream?

In June last year, at Tech Ed in Orlando, Red Gate announced that we’d soon be launching an archiving tool for Microsoft Exchange. The beta was weeks away, and we’d release a final version by November. But the signs were already bad – the team was hitting problems and deadlines were whizzing past. The target release date hurpled relentlessly from November to December, then to January and then beyond. And although the team worked as hard and fast as Achilles himself, and the gap narrowed, it seemed they would never catch it. Zeno would have been proud.

It’s a reminder of how even the best teams (and the team working on this is awesome), can get bogged down. But there’s a bright side. We’re not as bad as some people, and although I shouldn’t revel in other people’s mistakes, sometimes it can be reassuring.

Legend has it that in 1966 Marvin Minsky – a man who Isaac Asimov described as one of only two people cleverer than himself – assigned Gerald Sussman, an undergraduate, the task of solving computer vision. As a summer project. Forty years on and, although some astonishing advances have been made, the problem remains unsolved.

In 1960, Ted Nelson founded Project Xanadu, software that would allow people to cross-reference and version the world’s information. In 2007, Project Xanadu released version 1.0 of XanaduSpace.

On 28th April 1997, 3D Realms announced the upcoming release of Duke Nukem Forever. It still hasn’t shipped. According to the web site, it will be released “when it’s done”.

No matter how competent – nay, brilliant – you are, and no matter how hard you try, things go wrong. What defines you is how you react. Do you bang the table, shout “THIS IS NOT ACCEPTABLE” and force the team to ship something, anything? Or do you say hey, shit happens, c’est la vie, it’ll be ready when it’s ready? Of course, either of these actions can be appropriate in the right circumstances, but how do you make sure you’re not screaming when you should be chilling, and chilling when you should be screaming? And when is something more measured appropriate? Post here.

And what’s the worst project you’ve ever been on? Post here.

Liked this post? Follow me on Twitter.

P.S. We’re currently hoping to get the product shipped by Tech Ed 2009 and have even got a pre-release build out. Try it out and you can win a free pass to Tech Ed.

7 responses to “Projects from hell – chill or scream?”

  1. Chilling in all circumstances? says:

    At the risk of generalizing, most tension in my projects comes from people who feel they don’t have options. “Of course it’s got to be done by Decemberween, otherwise the market will just steamroller us!”
    The worst projects I’ve been on include one person, usually a manager, whose life is now equivalent to, and intertwined with, the work being done. That leaves very little latitude to modify features or dates, since you’re pushing them emotionally, not just strategically.
    I personally prefer to chill in all circumstances.

  2. All software has bugs. The trick is to figure out which ones are really important. Enter the concept of heinous.
    How much of the delays are simple perfectionism vs. that which can be documented and worked around?

  3. Involve the team in the business and they will make magic happen. When someone is invested in the success or failure of a product, they rise to the occasion just about every time.
    I don’t think chilling is the answer, nor is it to slam tables. The answer is in establishing a team that knows the score, fully understands the ramifications of failure, and who is equipped and trained sufficiently to achieve the objectives. Then lead the way, stay out front, demonstrate you are equally committed to success, and make your decisions MATTER.
    At some point it may be necessary to modify the objectives. This should be deferred as long as possible so as to have the most accurate picture of what limited victory looks like. Make the trade-offs. Deliver the highest priority items at the highest quality possible and live to fight another release cycle.

  4. DA says:

    I get the point of the analogies you used, but those are eminently insolvable problems. (Not sure about Duke Nukem, but I suspect that’s down to pure laziness/lack of interest. The world has moved on.)
    In real life examples, it’s important to understand the nature of the delays. Are they one-offs (never such a thing, though), are they systemic failures denoting an improper architecture/design/choice of technologies/SDKs, or are they simply execution failures (unmotivated team, lack of alignment among disciplines (dev/test/PM)? Perhaps the project was severely underestimated, or worse, suffered a bad case of scope creep? (Is the release manager on vacation/overwhelmed by devs? :-))
    Chilling is not usually an option *before* the release, at least not while one is behind schedule. And banging the table sometimes is absolutely necessary, lest some forget the goal is to ship.

  5. Greg says:

    I can’t really answer the question that was posed, but it does bring another question to mind – what is the value for a company to announce a product they are not near absolutely certain they can deliver by the stated release date? I’m sure at the time you announced you felt pretty confident that you would hit the target but why not announce when the product is near completion?

  6. Rachel says:

    I have a beta I was hoping to release just before Christmas and it’s still “nearly finished”. Other stuff happens: bugs, hardware failures, VSS problems, Visual Studio incidents, sickness, time off etc etc.
    To survive a “delayed” release, I apply the principles of GTD (Getting Things Done, by David Allen). Also when it gets crazy and the adrenaline surges beyond being a useful motivator, then it’s time to chill. Step back, do something different for a couple of days, have a rest and come back refreshed. It’s all too easy to get too close to the code and lose sight of the goal.
    It’s just a matter of holding off just adding a new feature and being disciplined and drawing a line under adding in anything new, and setting small attainable milestones.
    Oh and having a reward for getting it finished helps too!
    The line: it will be released “when it’s done”, made me laugh! 🙂

  7. Dave Chapman says:

    Worst Project I have been involved on? Working on a new site launch, when during ‘beta’ testing the MD decides he wants it ‘2.0’
    Which I wouldn’t mind
    But it is for a law firm, where web2 is not used nor wanted.
    Needless to say the project lumbers on, I moved jobs and luckily have a great job with a more understanding MD (seriously).
    Some project deadlines are meant to be missed, its part of my English Heritage, Wembley Football Stadium, Millenium Dome – etc etc.
    Over here if you hit a target, you are regarded as a freak of nature!