Dealing with personal failure

Question

A while ago I was given the task of updating and extending the functionality of a software project. I was given a year to make the needed changes working solo.

A month into development I came to the conclusion that it would take longer to change the existing product than to rewrite it from the ground up (a decision I now regret). I'd never attempted a complete rewrite so I talked with my boss about it and he was thrilled with the idea.

I'm a fan of agile development but had never had the opportunity to take advantage of all of the prescribed practices so when I set to work I tried to incorporate as many as I could. I didn't have direct access to the customer and my coworkers (non-programmers) knew the business domain but were already so busy they didn't really have time to participate in design meetings so I resigned to working in the dark and occasionally calling one of them over to my desk to get feedback on my progress. I used TDD and refactored mercilessly and even tried taking a domain driven design approach. Things went well for a while.

As the deadline came closer and the complexity of the project grew my productivity start slipping. I found myself cutting corners and ignoring the practices I had established as the pressure increased to meet the deadline (basically the same things that had resulted in sad state of the previous version). I also started working late nights and weekends to keep up with the load.

In the end it made little difference how hard I worked. The project missed its deadline and what was completed wasn't enough to give to the customer. I had failed. Not only had I not finished on time but the previous version had sat untouched for almost a year so it wouldn't be of any help. Luckily we had another product that offered some of the same functionality. My boss decided to cancel the project entirely and moved all our orphaned customers to the other product. I spent weeks (along with everyone else at the company) manning the phones providing technical support for those customers. After it was all over, my boss was gracious enough not to fire me for nearly ruining the company. I was moved to the other product and have been trying to redeem myself ever since.

Where did I go wrong? Has anyone else had to deal with this kind of defeat? How did you recover?

Answer 1

If I were to pinpoint a precise point at which you "went wrong," I'd say it was about the time that you figured out that the project was too complex to finish in time and you didn't communicate that effectively to the stakeholders.

Answer 2

I read an article from Joel Spolsky (JoelOnSoftware.com) a while back that may have saved you some heartache. It stems from your decision that "it would take longer to change the existing product than to rewrite it."

This doesn't help the situation that you got yourself in, but I've seen co-workers get themselves in the same pickle for the same reasoning. Maybe this can help someone before they head down that road.

Answer 3

You are a human, and you made a mistake by choosing to rewrite. Best thing to do is learn from the mistake and move on with your life.

Things You Should NEVER Do, Part I

Answer 4

I had experience very much like this. I completely failed at a multi-year task to rewrite a large computer program. The underlying problem was that I spent about two person-years on something that needed more like five person-years.

The failure of the project doesn't necessarily mean that you personally failed.

You will eventually decide whether anyone, even the greatest programmer ever, could have completed the project with the effort you were able to give. If you just convinced yourself that it was just a matter of pounding out some code, then perhaps your mistake was in poor estimating. If the project could have been completed but you didn't, then perhaps it is personal failure.

Why didn't you and your manager include some milestones within the year to determine whether you were on track? I suspect that over the year there were opportunities to assess the circumstances and figure out that things were going badly.

The lesson to be learned is not that you estimated poorly, but you and everyone around you missed opportunities to notice that reality was diverging from your optimistic schedule. Review the year and figure out when you all could have determined that you needed to do something else.

Many software projects fail, some because of the personal failings of the people involved, others for reasons that have nothing to do with the qualities of the personnel.

Pick yourself up, dust yourself off, and move on to the next project.

Answer 5

Where did I go wrong? Has anyone else had to deal with this kind of defeat? How did you recover?

It's a known fact that 2/3 of SW projects are failure. Yours is one of them, and I've also be part of a few ones.

The good news is that you didn't ruined your company and weren't fired. You started a retrospective on your failure, which means you will learn from your mistake.

Some say that the biggest problem that the SW industry if facing compared to other industry is that things change so fast, that we can't really apply the same technique from one project to the other to have reproducible success. You obviously jumped on a new venture where pretty much everything was new. There's then little suprise that you got overwhelmed by the complexity and couldn't make it.

It's important to correctly assess the amount of novelty that a new project can tolerate. Little novely means that strong commitments on deadline and deliverables can be made. The more novelty, the harder it becomes, no matter how agile you are. Ultimately you reach a point were you can't guarantee anything. In which case the project should be considered as an internal research or prototype.

"The only people who never fail are those who never try."

Other quotes here, to regain morale.

Answer 6

Depending on how much experience you have, your manager might be more to blame than you. Did he have any involvement along the way? Was he aware that you couldn't get access to the business analyst & customer resources you needed? If you were doing Agile, shouldn't there have been regular deliverables to show your progress? How was the project becoming "more complex"? Who was managing this complexity creep?

Bottom line, assigning a complex project with an indeterminate time frame to a solo developer is a recipe for disaster.

Answer 7

Things you should never do.

Answer 8

I've never been in that exact scenario but I think your problems started here:

"A month into development I came to the conclusion that it would take longer to change the existing product than to rewrite it from the ground up"

That wouldn't be so bad, if it wasn't for this:

"I didn't have direct access to the customer and my coworkers (non-programmers) knew the business domain but were already so busy they didn't really have time to participate in design meetings so I resigned to working in the dark"

Given the situation (lack of business participation) there's no way a rewrite was the correct solution. Add to that all the new stuff you were attempting and it was a mammoth undertaking.

BUT, you kept your job and learned a great deal. I wouldn't worry too much about it now (you can't change it) and use what you've learned in the future.

Answer 9

I reckon that you did not get fired because you are good. You had a failure, but you are not a failure.

The problem can be traced to poor discretization of goals, and this is not easy to do. If you had decomposed the big victory into a series of small victories (i.e., a road to success) you would have quickly realized that you were not going to finish. Many people fail to do this because it sounds like MBA lingo, but it is important to recognize that 'success is a series of small victories'.

In addition, could it be that you knew that you were set for failure but your personal pride kept you from asking for help?

I'm sorry that you had to go through this.

Answer 10

I don't see anything in your question about a project estimate.

Without estimates and a schedule, without a clear cost-benefit analysis, your project is doomed. I don't care how "Agile" you are; if you have no metric by which to judge whether or not the schedule is slipping, then you cannot succeed.

I'm sure you're a good programmer, but project management is a different skill set. Sounds as though you need to work on that, or work with an experienced software PM.

Answer 11

Complete rewrite is begging for trouble. Joel Spolsky is right there.

Also, I wouldn't dare to use a language/technology/framework that I'm not already comfortable with for a solo project spanning over an entire year. There's always loads of bumps down that road and new things you have to learn. Using the "lastest thing", which you have no experience in using, is going to take AT LEAST twice as long as using any stupid old less-hyped technology that you're already used to and have completed projects with before. Learn new things when you're working with people who already know them or when you're doing smaller projects than this.

Plan ahead. Split everything into tasks that can be completed in a work day or less. If you cant complete a task in that time, you haven't thought enough of all the parts the task consists of and should split further. Update your schedule every time something changes, dont hang on to old numbers.

Estimate how long things will take. Follow up on those estimates and note how much slower (or, grasp, quicker) you completed every single task. Take these errors into account next time you're estimating something.

Produce something that supplies a minimal amount of functionality, but works, as soon as possible. Work in increments. Make sure your product is actually working all the time (or as much of the time as possible at least) and keep adding functionallity.

Always fix bugs before you write new code. Estimating how long it will take to develop new things can be hard, but estimating how long it will take to fix bugs is always harder.

Some kind of supervision is great. Even if it's just once a month, someone should really look at what you've done. Someone should review it from a users perspective (preferably an actual user, but your boss or a coworker how know's what it's about would do as well). Someone else should review it from a programmers perspective; let them look at your solutions, listen to your ideas, provide feedback, tips and criticism.

As for recovering from defeat when it's already hit you: I'd recommed doing something small and doing it well. Proving to others (and especially yourself) that you're capable of producing awesome things. Know that everyone makes mistakes, but not everyone are honest enough to say it on stackoverflow in order to learn even more from them.

Answer 12

In an ideal world, software products were well designed and implemented in a domain driven way. In the real world, deadlines loom, requirements change and people go, so when inheriting a legacy codebase, one often measures the costs of maintaining the whole mess vs. rewriting it from scratch. Whatever you are planning, remember what is true for the whole life: alone, you won't succeed. The most important principle: communicate! The failure of communication is the root of most project failures. Talk with the former developers about their design decisions, (mildly put) implementation compromises etc. Consult your manager about the estimated money and time the rewrite would need. Document everything you learn this way!

Regarding your personal "failure": you learnt from it, and that also shows the exigency you approach software development which led to the demand to get a clean system instead of a ball of mud. The only point where you did not proceed wisely is, as I said, working in solo. But just like you incorporated agile practices in your career, you will also incorporate this experience. What you described is unfortunately a common pattern in software development. Thanks for honestly showing a real-world, practical scenario about what could happen in this case so that also others can learn from it!

When it ultimately comes to the decision whether to rewrite, apart from really hopeless cases, I strongly suggest to refactor step by step, one pace at a time when possible instead of starting from scratch. This way, you always have a working product, which is very important from the viewpoint of the customer and the management. And as you refactor, you inevitably have to understand every piece of the code you touch. Yeah, this might sometimes put your mental health at a risk, but if you manage to perform the actual step, the code will be more maintainable and also you will see clearer - you will understand others' intentions, recognize patterns etc. If you document this also, maybe the other developers will learn the strategies you followed and strive for cleaner code. Rewriting is risky - but this way, there is a possibility for every participant to benefit.

Answer 13

This isn't really personal failure as there shouldn't be anything personal about a project. This is organizational failure. Where was the project planning? (Was this given to you? Do you have prior experience with project planning?) There are so many IT shops/departments that are so poorly managed, their cost to the company is astronomical. A little bit of project planning and director level experience can go a long way. Was this present...?

At this point, it may be the case that your best bet isn't to try to impress them, but leave them for greener (and more better managed) pastures.

Answer 14

Many ppl post that "you should never rewrite". Here's a counter-story to that, just to balance things out a bit.

I sort-of did this in a project five years ago, deciding that the existing code base was a pile of spaghetti and that I could probably do it better myself.

However, given that we had to change two major parts of the system (the graphics and physics engines were ripped out and replaced), and that we could keep the tricky part (the statechart machine), the "rewrite" wasn't that bad, as it mostly added a decent scripting system and some structure to facilitate events, updates and multi-threading.

We did go over time (1,5 yr instead of 9 months) but not over budget, and also we luckily had an understanding customer and was able to show progress at regular intervals. We also used this internally to motivate the rewrite and to show that we were "on target".

There were only two of us, I did graphics and "framework" and my partner did the physics and haptics. However, being two helps a lot. Also, having done something similar before (at my previous job) also helps, since we didn't have to invent and rediscover every wheel from scratch along the way.

Anyway, a rewrite might be called for, but you'd better know what you're getting into and you need to be in sync with everyone around you while doing it.

If it's one thing I've learnt is that you should never ever do something tricky alone. After 7 years since my M.Sc. it's slowly sinking in properly. Now I just need to make sure my surroundings don't make me the single guy on any part. (That's still work-in-progress. :-P)

Answer 15

Actually, all of use faces similar issues from time to time.

Most notably, the problem is that many developers fail to realistically think in the long term. We tend to underestimate the task and overestimate our abilities.

The other problem is that every project has some obstacles that are not foreseeable before you've devoted too much time to it. This - as others pointed out - is commonplace to programming-related work.

Answer 16

A month into development I came to the conclusion that it would take longer to change the existing product than to rewrite it from the ground up (a decision I now regret).

It sounds like this wasn't so much as a conclusion based on some kind of engineering principle as much as it was hopelessness at seeing a poorly written code base and giving up on it.

However, taken as a whole new project, you could then ask why did it fail? Reading between the lines, it sounds like one of the main reasons would be documentation. With clear documentation of the feature set, you should have been able to make consistent progress implementing one feature after the next. You would then have a clear picture of how long each feature would take to implement, and would have known as soon as the first set of deadlines was missed, early in the project.

Instead, you mentioned that until the last day you thought you would finish on time. How could this possibly be the case with the post you made? You made no mention of being 50% feature complete or 90% feature complete. A 90% feature complete project can usually be salvaged with an extended deadline. The point is I saw no evidence in your post that you worked in a methodical manner to identify features, implement them, then mark them off as "done".

This isn't necessarily your "fault" as others have also mentioned. Pretty much any competent manager should have been tracking your "feature list" and verifying your software was hitting more and more of it's goals on a consistent, on-schedule basis. If you didn't know how to get to the finish line, your manager should have gotten you on a program that would get you there.

Answer 17

A single developer; a complete rewrite; minimal access to business knowledge; a new development process.

How can you possibly see this as a "personal" failure?

Sure, attempting a complete re-write by yourself and using an untried (in your experience) development process are bad choices on your behalf. (Then again if you're inexperienced it is not at all surprising).

However any company that knowingly proceeds with a project like this deserves to fail horribly. So take responsiblity for the choices you actually had control over, nothing more. The failure primarily belongs to the company and it's (non) management.

Answer 18

Gall's law applies here: "A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

Rewrites of complex systems are almost always a bad idea. If you ever find yourself wanting to rewrite a complex system, chances are very, very good that you would be better off following this process instead:

1. Build a test suite if there isn't one already. If there is one, make it better. Much, much better.
2. Begin to refactor ruthlessly, but do it one piece at a time. Test that piece thoroughly.
3. Ship the refactored version. Get input, make changes.
4. Repeat steps 2. and 3. until you're happy.

If your boss doesn't like that plan, sell it as a full rewrite in stages, with much lower risk. Because that's really what it should be when you're done.

I find that one of the most common reasons people go down the rewrite path is that they don't like the language or framework that the original was written in. I posit that this is very nearly the worst possible reason to do a rewrite. If someone hires you to do a rewrite for this reason, turn the job down, even if you love the language they want you to use!

Answer 19

I have a story sort of like this one. It wasn't about a rewrite, but it amounts to similar. My first gig after college I worked at the college library. It was not a programming job, but I found ways of working programming in to automate tasks. Overall it was good. I was a valued employee and got a lot done. I force myself to remember that part of the story because of the next part of the story.

Being a college library, we were staffed with many students, and therefore had a great deal of turnover. We had training documentation, but it was very poor. I had the idea to try improving it and therefore help get students productive more quickly. Also having an art background, I knew how to use page layout tools and create a very nice manual, but my boss knew that wouldn't scale. I wouldn't be around long, nobody else knew the tools, and nobody else had the skills. So I devised a plan. I read about XSL-FO and thought like many other people at the time that XML must surely be the answer to all problems. I had no real development experience, and my boss didn't know the first thing about programming, but I somehow convinced him I could create a WYSIWYM WYSIWYG hybrid tool using Java Swing that that would allow any staff member to create and edit documentation and magically turn it into a well laid out manual complete with automatic table of contents and index, fancy margin notes, automatic image placement, etc. like a real how to manual. Plus, the tool would be easy to use and allow multiple users to edit the document concurrently. If you aren't laughing yet, you are probably about as naive as I was at the time.

I spent a lot of hours on this project, and needless to say, it failed miserably. When I got close to the end of my time there and I was expected to deliver, I abandoned the code base I was working on which was way too ambitious, and created something much simpler which could at least generate the xml I wanted. It was only at that point that I realized that XSL-FO was far to limited for my needs and that the automatic page layout ideas I had would never work without a lot more hours and knowledge. All I would be able to generate would be something that could more easily be done with Microsoft Word, so in the end I had to admit defeat. I felt really awful. Probably my biggest occupational regret. However, I did learn a lot.

I dealt with the failure by vowing to never make the mistake again, and just know that it was a learning experience. I'm still an ambitious programmer, but it was a wakeup call to seeing the pitfalls and seeing where the boundaries are. Of course, I also don't have to show my face there anymore ;)

Answer 20

One thing your boss or Project Manager did wrong was to assign a year-long task to a single developer. To have any one person working alone on anything for that length of time just isn't a sensible way to run a project. Doing that won't make effective use of resources, it won't help you develop your own skills and it puts the project at risk.

Answer 21

"Where did I go wrong?"

1. Your statements about access to the customer and coworkers (which you should have demanded) and the "growing complexity" of the project indicate you did not have a complete understanding of what was required and how it would be implemented. Therefore you should not have accepted being given one year (a suspiciously nice round number) for implementation until you first studied the problem and your proposed solution in extreme detail (including interviewing others as necessary) and carefully estimated and scheduled what would actually be required. Imagine how much investigation you would have to do to accurately estimate how long it would take you to single-handedly build (or modify) a house, including all the electrical, plumbing, carpentry, etc. There should have been that kind of study, thought, and attention to detail in planning your programming project. (The next time you do estimate something, base it on your past performances [not future hopes], double your best guess, and add plus/minus 25%. Eg, if you calculate it will take one week, estimate 2 weeks plus/minus 2 days; if one year, estimate 2 years plus/minus 3 months.)

2. I'm guessing that your rewrite idea one month into the project was caused to some degree by still not completely understanding the existing implementation and/or how to modify it, and essentially hoping to work around that problem by throwing everything away and starting with a clean slate. That would be kidding yourself. You can't estimate what it takes to throw away and replace a black box if you didn't know how it worked inside. On the other hand, if you did completely understand the system, you should have been able to come up with detailed rewrite milestones for the remaining 11 months. After month 2, if you aren't on or ahead of schedule, you have to recognize you're getting into quicksand.

3. Your "productivity" probably did not "start slipping". Your productivity was probably essentially constant during the entire project, it was just too slow to finish in the time expected. If after months 1, 2, and 3 you measured your productivity but it wasn't on target for the estimated year-end goal, then the handwriting was on the wall the whole time.

4. You apparently expected to give the customer only a completed product only at the end of the implementation schedule. It's better to frequently produce partially working implementations, even if only for internal review. While that does expose you to the common danger of having to change implementation plans in midcourse, it's OK if everyone is notified, and understands and accepts that the schedule then has to change accordingly.

5. It appears you did not seek help nor were you carefully managed during the course of the project. You needed a ruler (typically a detailed schedule) against which to compare your progress, and as soon as you digressed from that ruler you needed to identify why and what it would take to get back on track, even if it meant asking for help and/or advice.

"Has anyone else had to deal with this kind of defeat?"

Yes. The majority of non-trivial software projects probably end in disaster or at least far short of their original goals.

"How did you recover?"

There typically isn't any recovery for the failed project. It's usually just abandoned or limps along indefinitely, but hopefully becomes a valuable lesson that prevents the participants from repeating their mistakes.

Answer 22

ce, First, thanks for sharing your story. I think it's a great thing to learn from. Your question may look subjective inviting long answers, so I will try to be brief.

• Dealing with failure

There's only one way of proper response to failure: inspect and adapt. There's so much to learn from this. You may be considered lucky. Honda: "for every success I had at least 100 failures".

• What can we learn from this?

There's more to software development than coding practices. Most people here on StackOverflow wouldn't know what that means. They may work in a company where auxillary tasks are handled externally for them, and they would be sitting in the driver seat getting an illusion that what they code is the product. If you are working solo, you need to take care about these:

Management of development process: project management (the art of achieving small, externally visible goals at a time), effort estimation and scheduling, customer interaction and adaption to their needs, establishment of correct tracking and communicating the progress, risk management (many developers would not guess what this means, and yet it is vital to any software project survival), manual procedures, process improvement, and a whole bunch of things I forgot without which no real development is going to happen, and it's not just a matter of "well, we had to put more resources into this".

It looks to me like you should use this as a source of motivation for learning management of software development. There're many brilliant books written on the subject, and it may even put a start of a new career in this domain, because, good developers seldom care about these things, and people who know a lot about both are invaluable.

I will recommend you just one book as an introduction. http://www.amazon.com/Software-Project-Survival-Guide-Practices/dp/1572316217

Good luck, P.

Answer 23

In dealing with a personal failure, one should distinguish "personal" from "I was given " and programmed (eaily predictable) results from miracle wishes and unsupported by analysis expectations.