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?
Best Answer
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.