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! :)