We've all been there:

  • Your project failed or got cancelled.
  • The code you spent days working on got rejected by your team.
  • The design pattern you introduced to the team created chaos.
  • Everyone ignores your ideas.

My question is, what is the most productive way for a programmer to handle development-related failures such as these?


7 Answers 7


Your project failed.

Software development is highly prone to project failures, and depending on the severity, this is best handled by management.

Many projects have failed and many more will fail, so take notes! Learn why your project failed so you don't make the same mistakes next time. You learn much more from your failures than from your successes.

What you have spend coding days on was rejected by your team.

Save your work (for later). There are two possibilities: (a) It sucks, and the fact multiple people responded the same way is indication of this (b) It's truly genius work, but far ahead of what people are used to or can understand. People generally do not like what they do not understand. Perhaps its better to show it when the time is right OR in a different place with a different "Culture"

Nobody listen to your ideas in your company.

Its probably a bad idea, OR the culture is not aligned with your thinking. Either move to a place that supports your culture or critically evaluate your idea again (objectively without your own bias) -> is my idea really that good? <- Kill thy ego

The design pattern you introduced with force in your team created a mess.

Be honest, you tried your best but it did not turn out how you planned it. It may be better to start again or learn from the mistakes made in the design as a team and move forward.


They're not failures - they are experiences

You learn and grow from your experiences by reflecting on how they made you feel and if you want more of that feeling.

If it's a bad experience (like that list you offered) then the accompanying bad feeling is probably something you'll want to avoid (assuming you not so thick-skinned that you didn't care about the impact of your actions).

Overall, don't get too involved in comparing yourself to others, they're having just as much trouble working through it all as you are.

  • Stay calm - don't panic, it won't make anything better
  • Damage control - save what can still be saved
  • Learn from your mistakes - doing the wrong thing again probably won't make it work
  • Consider a fresh start - start your next attempt without a backpack of disappointments and guilty feelings
  • Look at bigger failures - compared to Ariane 5's first flight, your failure is negligible
  • Consult a psychotherapist if you can't handle it alone

You build something.

For me (I don't think it's right for everybody), building something (comics, drawings, little games, anything) is like building a bit of confidence to get back to fighting failure. It might also be a good way to express your anger or bitterness or any feelings relative to the failure, but in a "constructive" way.

That works for me anyway.


Well, you asked :) One by one:

* Your project failed.

That is hardly new. We've all failed privately, and we've all failed in full view of our peers. Anyone who has gone through primary and secondary education has experienced this.

If I can't make mistakes and expect stable employment, you should consider sending a memo to HR letting them know that human beings will be banned from future consideration.

Several failures in a row means you either have unreasonable demands and specifications, or you don't learn from your mistakes. Either scenario begs immediate action.

It is conceivable that many people sign onto something just to gain employment, then work out some way of making the requirements happen.

* What you have spent days coding was rejected by your team.

That happens. As others noted, save it. Do it again. This is why we call it work. I think, in this case, you probably did not involve the team very much in what you were doing.

It could also be that requirements changed yesterday, or an hour ago. This should be an exception, not a norm, however. Peer review is as brutal as it is helpful. If your code is constantly dismissed as 'inadequate' (or something like that), you should spend more time picking brains and involving others. I believe this question to be a fallacy in most team settings, unless the 'team' is anything but self describing.

* Nobody listens to your ideas in your company.

Again, this needs context. How long have you been there? How much do your fellow hackers trust in your ability? Have you considered that ideas that result in more work for many people might invite ANY reason to dismiss it? I once had something dismissed because it was not IPV6 ready, yet it used a simple domain socket on the loopback device (exclusively). The person who sunk it simply couldn't take any more work to do.

Also, how well do you articulate yourself? Can you make friends and influence people?

* The design pattern you introduced with force in your team created a mess.

Hence why force should have been avoided. Being able to talk is not a prerequisite for being able to listen. No other comments.


Oh boy, that's a lot if you really meant everything happened to you!

WARNING: In many of the points below you might feel like I criticize you and that I want to make you responsible for the mis-happs and not consider external factors. I don't. It's just that you don't give much details, and I just provide check-lists of actions to undertake to ensure that things don't go awry. I know I've done lots of mistakes myself (everybody does) and we only get better if we learn from them. And to learn from them, we need to start to see them as mistakes in the first place, and accept responsibility for what went wrong on our part. Hell, accept responsibility for what went wrong in other people's parts, you can learn from that as well.

Your project failed

Not much you can do to mitigate it now.

However you can do a lot to avoid that to reproduce in the future. I'd suggest trying to improve your project and time management skills.

One of the books with the best ratio ((valid advice) / pages) I've read on the subject, while maybe not the best, it Rob Thomsett's Radical Project Management.

You don't really specify what your project failed, but I'd assume a combination of thing which brought unbalance in the usual cost/time/qualiy triangle. The most important factor in my eyes is to lead the project and the development while being always in touch with both your technical actors (devs and testers) but also your stakeholders. Far too many projects fail because they don't listen to sponsors or stakeholders and don't push them to get involved in the process.

If they're not involved, you cannot know what they want. If you cannot know what they want, you cannot deliver it. If you don't deliver it, they'll be unhappy. That's a failure. Furthermore, if you don't involve your stakeholders, they're disconnected from the reality of software engineering, meaning they don't understand your issues. If they are often in touch with you, they get a better grasp of what you have to deal with. They'll be more able to understand when you tell them that a "small" [laughter] feature will take months. They can trust your planning better because they helped building it. A project cannot succeed with just "specs at the beginning, dev, testing, delivery at the end". It just never does. You might deliver what was asked for in the specs, but not what the customer really wanted.

Most important as well, do a retrospective, and ensure it is ego-less and not a blame-game. Just identify issues.

What you have spent days coding was rejected by your team

I have been in that situation. Again, not much you can do to mitigate that except:

  • Keep it in the SCM for later.
  • Maybe try to push small bits and pieces progressively into the major code base instead of a huge refactoring.

But there are things again you can do to prevent this sort of situation:

  • Why did it happen? What's the reason of the rejection?
  • Most of the time when I see this happen (and that was the case for me too), it means the developer went solo or in cow-boy-coding mode and produced things that were never asked for. Code that doesn't come from business requirement might be fancy and "better", but often a waste of time and money. Plus, it will cost even more if you integrate it as it will need testing again. Think like the people who deal you the money: you have to be efficient on that level as well.
  • Was the quality of the software produced satisfying? Did it comply to standards and conventions in activity at your company?
  • Did you periodically (and frequently!) report to direct managers about this? Did you occasionally exchange with other developers of the team? If not, they don't know anything about it, it will be a huge time cost for them to assess and review it now. It does NOT account to the same time in the end. It's like always trying to put off cleaning your rental apartment and then trying to clean it only when you move out: It's a crappy job, it's exhausting, it's harder than it would have been if done regularly, and it often won't be done right.
  • Did you produce produce tests? Units tests? Integration tests?
  • Was your code checked into the SCM regularly? Was it in a different branch? Did it need a different branch or could it have been done in trunk? Putting off committing code is usually a bad sign. Obviously sometimes you're tempted to do it, but you just shoot yourself in the foot.

Nobody listens to your ideas in your company

Well, there are 2 options here, and we'll look at both:

  • You're ideas were bad.
  • You're ideas were good.

Let's start assuming they were bad (again, self-reflecting on that and accepting your idea was just plain bad might be difficult, I know). What do you do to change that?

  • Why did you come up with the idea? What's the rationale? Is there a real need to what your idea tries to bring to the table?
  • How did you come up with the idea? Did you do it on your own? Did you share? Brainstorm? Plan? Prototype? (do these in the right order. If it fails on the way, then discard the idea, don't keep going. Or at least not on your work schedule.)

Ideas are only ideas. If you just suggest them as ideas and they are rejected, I don't see why you would feel bad about it. If however you act up on them without notifying anyone and THEN only submit your ideas and they get rejected, obviously I feel the frustration at the time wasted. And your managers do to!

Assuming your ideas were good:

  • Was your presentation good?
  • Was your way of delivering the presentation good? (I'm a developer, I know what I'm talking about: We're grumpy, arrogant, pedantic PITAs who are always right and with whom it's hard to work with because often of our disproportionate egos).
  • Do you have a plan to implement it? Did you think about the cost and time? Did you think how it benefits users/customers? Did you think how it impacts sales? Did you think how working on that idea might impact other projects and priorities? You're going to tell me, "why should I do all these, they're the job of my manager and the marketing or sales teams?!" Except right now, you are trying to do part of all their jobs.

The design pattern you introduced with force in your team created a mess

  • Why did you introduce the pattern?
  • If it created a mess, then it probably either:
    • wasn't the right pattern,
    • wasn't implemented right,
    • wasn't integrated right.
  • How did you introduce it? How exactly do you define the state "mess"?
    • less readable code?
    • less maintainable?
    • builds are broken?
    • There are different kinds of "mess". Knowing what the mess is might help to know what the failure in there was, and if it was the design pattern's fault.

Also, I am a bit surprised by the approach itself. You had to actually push for a design pattern to be introduced? That seems rather odd. A pattern is either there already, or you need to refactor a part of your solution according to the pattern. You don't push it like you would the adoption of a framework or technology (like people pushed really hard to have XML everywhere, and now like people start pushing to be able to write HTML5 on their product cover in big bright letters).

Why did you have to push? Why was there resistance? Maybe it was justified.

Were you able to you provide examples that this particular pattern would help to improve your code base in significant ways (for instance, by matching it with an example of Refactoring to Patterns).

Completely off-topic note but that's what I first thought of when I read the question's title as I thought it referred to software failures... I had a software who implemented a BlackHole class to manage a very special kind of exceptions in one of the components. It may seems like (and really is) an obviously weird and dirty hack, but the naming itself was so superb we all appreciated it for a fairly cool way to handle a failure! :)

  • @Rachel: thanks for the edits to align with your META-SO effort. I hadn't noticed the question had been re-phrased since then.
    – haylem
    Commented Feb 28, 2012 at 15:59

Step 1: It's ok to get angry!

First, it's understandable to be upset or angry when encountering failure. If giving advice to someone in such a situation, they are most likely not going to want to hear "Just get over it and move on" or "Just think of it as a learning opportunity".

In fact, I think it can be healthy and productive to get upset and vent your frustrations, provided that you do it privately or with a friend. People have different ways of doing that, but I think one of the most productive ways is to write an angry fake letter (Important! do not send this letter to anyone). Explain your feelings, such as why you feel that whatever happened was unjustified.

Step 2: Take some time to calm down.

Make sure that you've expressed everything that you're feeling, and after venting your anger just take some time to calm down. Maybe you only need a few minutes, or perhaps a few hours.

Step 3: Review what happened in step 1

At this point you will hopefully be able to think more objectively about the situation. If you wrote a letter, then read it to yourself. If you confided in someone, then try to remember what you said. If you just imagined shouting at someone, then just mentally review that.

I often write a letter when I'm angry and then after I've calmed down I will work on refining the letter to more clearly communicate what I was originally trying to say until I'm satisfied that someone reading it would understand what I was feeling at the time.

The point is to objectively try to pick out what your points were. Did they make sense? Perhaps they need clarification or further detail. Are they unfounded? If you were to objectively put yourself in someone else's shoes, would you understand the points that you made? Would you agree with those points? You can use this opportunity to evaluate yourself. What did you do well? What were some things that you could have done better?

Step 4: Decide on a course of action

Is there something that can be done to remedy the situation or to at least improve it? Take a moment to consider if there is realistically anything that can be done to fix or improve the situation. Often there isn't, but sometimes there is.

If you are at fault for something, then that might be as simple as a formal apology to someone, clearly explaining what went wrong, what you did, why you did it, and what you will do to fix it or prevent it from happening in the future.

Next, consider what you can do to improve the future. What can you do to prevent the same thing from happening again? Decide what it is that you want to achieve and use what you've learned from step 3 to create a plan for yourself.

If all else fails, try rebooting:

            // ...
        catch (OhNoes111Exception)
            // reboot fixes everything!
            System.Diagnostics.Process.Start("ShutDown", "/r");