Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

It's not uncommon for projects to fail.

As a programmer, how do you deal with projects that fail?

Some definitions of failure:

  • Misses deadline.
  • Code and functionality does not do what it's supposed to.
  • Software becomes vapor-ware or endless number of phases, essentially undeliverable.

Or maybe you have your own definition(s) of failure.

Do you start pointing fingers? Do you blame yourself, the requirements, the technology, the management, the client, etc? Do you do a lessons learned session as a team?

share|improve this question
9  
I tend to cry like a baby. It doesn't work for everyone though. –  ChaosPandion Sep 22 '10 at 18:25
    
Is failure defined in this context as a good program (does what it is supposed to, no bugs) that nevertheless doesn't meet sales expectations? –  tcrosley Sep 22 '10 at 20:16

4 Answers 4

up vote 8 down vote accepted

You should do lessons learned for all projects, failed or succeeded. There is a lot to learn from a good project.

True failed projects have been very rare for me. In addition to understanding what happened, I do the "ask why 5 times" thing to try to get to underlying causes. There is also the matter of why I didn't notice what was happening and either do something about it or at least get out.

I think everyone's first position is to blame everything - the client, the tech, the business problem being tackled, the methodology, the team members, the language, the platform, heck even the way we take our coffee in the morning. The nice thing about a retrospective (even if it happens only in your own head) is the chance to reconcile with some or all of those factors and realize they weren't the issue.

In my only real failure of the last 30+ years, the project had been in requirements for literally years when we arrived. We got requirements settled. One came from management and hundreds from the end users. We wrote code, lots of code, some of it brilliant. There was testing and acceptance testing and changes and arguments and change requests and unpaid work and paid work and last minute bolt ons and surreal humour and escalations to VPs and all of that. Eventually it just all kind of stumbled to a halt. The reason for the failure was that the single management requirement was unacceptable to the end users. And no matter how many things they got their way on, they could not get past that one and would never accept the system. But management would not have it any other way. So that was that and though we got a lot of money it was, in the end, all horrible.

I still work in that technology, I still use those processes and I still work with the same people. I would even do another project for that client. But when the end users say they don't like something their own management has injected into the requirements, I will remember that writing good code that works does not protect you from a failed project. And I will do something about it then, not a year or two later.

share|improve this answer
2  
I smile rereading this answer. Towards the end the whole thing became more funny than sad - and I spent a year working on this without charging anything for it. One of my favourites was when I handed a user a change request to sign and she said "I'm not signing this - you'll hold me to it!" to which I could only reply "well, then, I'm not coding it." –  Kate Gregory Feb 9 '11 at 16:56

There is a great book on the subject called the Death March: http://www.amazon.com/Death-March-2nd-Edward-Yourdon/dp/013143635X

I highly suggest you to read it. You may recognize your project(s) in many descriptions.

There is no single answer as it highly depends on many complex components of your organization, including politics...

share|improve this answer

I blamed everyone except me.... haha, just kidding. I thing i do is write a "Mea Culpa" doc, with all the things "i did" wrong. maybe doesn't help to that project, but is a good way of not repeat the same mistakes

share|improve this answer

Walk away, bitch for a few days to a week while I avoid doing things of significance, then try to figure out what went wrong and how not to let it happen again.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.