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.

Having worked on a failed project is one of the few things that most programmers have in common, regardless of language used, industry or experience.

These projects can be great learning experiences, soul-crushing disasters (or both!), and can occur for a multitude of reasons:

  • upper management change of heart
  • under-skilled / under-resourced team
  • emergence of superior competitor during dev cycle
  • over/under management

Once you've worked on a couple of such projects, is it possible to recognise at an early stage exactly when a project is doomed to fail?

For me, a big sign is having a hard & fast external deadline combined with feature creep. I've seen projects which were well planned out and proceeding right on schedule go horribly off the rails once the late feature requests started to roll in and get added to the final "deliverable". The proposers of these requests earned the nickname of Columbo, due to rarely leaving the room without asking for "just one more thing".

What are the warning signs you look out for that set off the alarm bells of impending doom in your head?

share|improve this question

40 Answers 40

Heroic Coding

Coding late into the night, working long hours, and clocking lots of overtime are a sure sign that something went wrong. Further, my experience is that if you see someone working late at any point in the project, it only ever gets worse. He might be doing it just to get his one feature back on schedule, and he might succeed; however, cowboy coding like that is almost always the result of a planning failure that will inevitably cause more of it soon. So, the earlier in the project you see it, the worse it will eventually become.

share|improve this answer
10  
The only excuse for pulling an all-nighter is to address a SPECIFIC issue for a SPECIFIC inflexible deadline. Maybe it's just me, but code I write at three in the morning when I'm grouchy and sleep-deprived tends to look bloody hideous viewed in the cruel light of day. –  BlairHippo Sep 9 '10 at 14:08
4  
Well, the other excuse it being a student. Poor project planning is par for the course then. :) –  Fishtoaster Sep 9 '10 at 14:59
13  
Oh, Christ. College. I remember sitting in front of my terminal as the sun rose, shoving *'s and &'s more or less at random in front of the variables in my C++ code in the hopes that the damn thing would start working. Not a part of college I miss. –  BlairHippo Sep 9 '10 at 15:04
2  
Earlier this year we had a project like that - one guy was regularly working until 2am and I was starting a 4am. We got the job done, though, despite the ridiculous time-scales imposed upon us (we'd been committed to being complete by a legislative deadline). We're still tidying up and refactoring now! –  Chris Buckett Sep 21 '10 at 19:18
2  
Good answer! I would say that heroic coding late into the night is not only a sure sign that something went wrong, but also a sure sign that a lot more things are going to go wrong in the very near future, when the bugs from the heroic code start bubbling to the surface. –  Carson63000 Oct 7 '10 at 2:22

When the programmers start to win the argument "The code is horrible, we need to start over from scratch." on any mature application.

You may think you can build it better, or understand the problem more fully, but you really don't. Oh, and all those ugly patches? They are fixes to real-world issues that you are going to likely re-introduce in the rewrite.

Plus, one day you are going to have to explain to the project manager why after 6 months of work you are almost up to 85% of the capability and 150% of the bugs the application had when you started out.

share|improve this answer
6  
Isn't this just a summary of the infamous Netscape rewrite? –  Jasarien Dec 13 '10 at 11:32
7  
2  
I disagree. There are certain dangers to rewrites (e.g. the second system syndrome), but if you know about these, a rewrite isn't more dangerous than any other green-field project. –  nikie Feb 5 '11 at 19:24
4  
Sometimes you need to amputate and replace with something that will make the app stronger, better, smarter. But the key word there is amputate, not kill and resurrect. –  Erik Reppen Jan 20 '13 at 16:40
1  
This may be largely true, but not strictly true. I underwent such a project about 9 months ago, and it was a success. Spent over half the time on it devising tests to prove it was correct and that old/new bugs weren't introduced to the new version, and found a bunch of new bugs in the existing one in the meantime. (Though, I suppose, this makes this answer true as a warning sign) –  Izkata Jan 21 '13 at 4:22

A new tool as a problem solver.

When people start planning to use unfamiliar tools, I don't mind, but I keep my eye on it. When they start planning all the advertised benefits of those tools into the schedule, I get worried. Fun examples:

  • We can shave a month of the schedule because we're going to try using an object oriented language (even though all we have are c developers).
  • We'll try out this new scrum thing- that'll fix all our process problems!
  • I know it's halfway through the project, but what if we changed ORMs to something new?

New technologies and practices are great, but you almost never get all the benefits out of the gate.

share|improve this answer
2  
I was once on a project that had two forks due to two interfaces -- desktop and handheld gadget. Time estimates were based around the notion that we could use these shiny new "EJB" things to reuse model-layer code between the two. Unfortunately, the database was such a horrific rat's nest that all data plucked out of it had to come from specific carefully-constructed SQL queries; fully populating the beans would have been too brutal a performance hit. When it turned out that (surprise!) the desktop version needed more data than the handheld version, the timeline went STRAIGHT to hell. –  BlairHippo Sep 9 '10 at 14:03
1  
"Wonderful! Now that we've salvaged the unit testing framework, we can start cutting time from that overlong QA phase!" –  Arkaaito Oct 13 '10 at 8:40

To me the single biggest problem, and one you can spot immediately, is when business considers written requirements as a waste of time.

So basically; No Written Requirements

It's the kiss of death.

share|improve this answer
2  
Or worse, written requirements that no one reads. In fact, I've been on projects where extensive requirements were written and never shown to the programmers. –  JohnFx Sep 8 '10 at 22:23
1  
@Adolf Garlic - Written requirements won't ensure your on time or on budget, but you'll never meet expectations if expectations are not communicated, do not have all the gray areas nailed down, and are constantly changing (your mental ideas will change). –  John MacIntyre Sep 9 '10 at 15:14
4  
I once had a Business Analyst tell me requirements were not needed. Just what is the job of a business analyst again? Oh yeah to write requirements! We would get requirements like make this work like hkjk.com does. –  HLGEM Sep 10 '10 at 14:54
1  
If you're developing for a custom product for a single client, sure. But if you're writing the next version of Powerpoint or the next version of an in-house software system, I don't see the point. You will always learn more about the requirements during development (e.g. that some requirement isn't useful and another isn't feasible). I'd rather use that knowledge and change the requirements during development than releasing an inferior product. –  nikie Feb 5 '11 at 19:17
1  
@nikie - I'm not saying the requirements should be static, and never change. I'm saying you should write it down to prevent mis-communication and prevent ideas from changing in peoples head over time. If the requirements should change, then change them, but keep the current requirements written down. Does that make sense? –  John MacIntyre Feb 6 '11 at 16:02

Management Disconnect

When those responsible for deadlines, features, staffing, etc get disconnected from the people responsible for delivering the project. This can lead to:

  • Feature creep when the customer is talking with someone who doesn't understand feature cost
  • Man-month syndrome, where new developers are thrown into a project late enough to be more of a hinderance than a help
  • Unrealistic deadlines, created by people who have to deal with the business consequences of deadline decisions but not the implementation consequences.
  • Products that don't solve the problem, when customer-dev communication is hindered by management in the middle.
  • Poor risk management, where potential problems aren't communicated early enough between devs and management.

So, when it looks like management is uninterested in the project, is communicating poorly, isn't listening to the customers, or isn't listening to the dev team, run for the hills.

share|improve this answer

The first time someone, usually management says "we don't have time to .."

Usually preceding something that we don't have time not to, like documentation or code reviews (which statistically find and correct more bugs that anything else, including all forms of testing)

share|improve this answer
8  
got a reference for that? it'd be great ammo to use... –  Alex Feinman Dec 30 '10 at 14:27
1  
@Alex Feinman: IIRC Code Complete contains lots of references to statistics like these. –  nikie Feb 5 '11 at 19:20

When management is too weak to say "No" to the business.

It leads to deadlines that will never be met, which leads to a lack of confidence in the IT department which leads to developers creating hacks (i.e. access db running on someone's machine...somewhere) which leads to a nightmare for IT when the 'critical system' has to be migrated which leads to...

share|improve this answer

Let the customer, marketing or management pick a date and then try to work backwards to an imaginary schedule

share|improve this answer
  1. When key developers leave and management doesn't care

  2. When key developers leave and none of the other developers care

Number one is usually indicative of managers who are severely out-of-touch with the team dynamics (who is the "10x super star", who are the decent programmers, and how they interact with each other etc).

Number two usually indicates severe lack-of-interest on the part of the remaining developers.

share|improve this answer

First bad sign I can think of is when management is not willing to pass bad news up the chain or to the client in the hopes that it will go away - i.e. management by wishful thinking. I can't think of how many times, devs have proven they can't meet the deadline weeks or even months ahead of it and yet no one wants to tell the client. I've rarely seen a client who wouldn't push a deadline when there is genuine reason to when the need is explained well in advance; I've often seen a pissed off client when told the day of the deadline that it wasn't going to be met and that it wouldn't be met the next day either but two months down the road. At this point they, rightly I might add, question your processes - how come you didnt know this earlier. (True answer but the one we never give - we did know but we were afraid to tell you.)

Another sure sign that failure is coming up is to assign new developers to the hardest most complicated, most critical part of the process rather than the people who understand the current system already. Then don't watch them carefully to see if they really are getting work completed properly or have questions (BIG BIG RED FLAG if there are no questions). New employees need to be monitored until you know they really have the skills they claimed to have. I can still remember spending one painful summer redoing the work (already past deadline when I got it) of a new employee who got a critical piece of a project and told everyone everything was fine for months and then quit without notice one week from the deadline and nothing he did was usable.

Another sure sign of failure is when devs are working on pieces that depend on other things being done first and those things are not done or even started. If management can't get the work assigned in the right order, you are going down the tubes.

Of course feature creep without pushing the deadline back every time is one of the most common signs things are going to go bad. You add 20 hours of work to my plate, the deadline gets moved by 20 hours. If it doesn't then the project will fail, guaranteed.

share|improve this answer

When non-technical managers start insisting on making technical decisions that they are in no way qualified to make. Big, big red-flag!

share|improve this answer

Bored team members.

share|improve this answer

One sure sign that I've seen in my career is when management starts talking about bringing in more bodies to make up time in the schedule. I've never actually seen more bodies on a project help.

share|improve this answer
4  
I once had a manager who wanted to bring in a front end web coder to a project (the right decision) but because someone else on the project had gone long term sick wanted hit written into the new guy's contract that he wasn't allowed to get ill. –  Jon Hopkins Dec 10 '10 at 14:36
1  
@Jon - That is sad... funny, but very sad! –  Walter Dec 10 '10 at 15:00

The most obvious sign is a high staff turnover. When everybody is looking for a new job, you probably should, too.

The other highly obvious sign is lack of progress. If a year has passed, and it doesn't seem like you are any closer to the target, you're doomed. This happens especially when requirements change faster than you can implement them.

share|improve this answer

If the project plan calls for a single iteration of design, development, testing and deployment - the classic waterfall - for a project longer than 1 month, I'd run a mile.

You don't need to be fully agile, but having short development cycles allows you to demonstrate progress to everyone (customer, management and developers themselves) and cope with changed requirements when the inevitable happens.

share|improve this answer
6  
There is nothing wrong with waterfall when it is used correctly. Unfortunately it is never used correctly :) –  adolf garlic Sep 9 '10 at 12:52

Cowboy coders, big egos and management acceptance thereof

share|improve this answer

You're "90% done", the delivery is next week, but it's ok because all you have left is "testing".

share|improve this answer
1  
Seems very funny now that you say it. Happened to me though. Wasn't funny at that time. –  user7197 Dec 10 '10 at 19:02
1  
It's funny how every schedule has testing as the last step as if testing won't find any bugs. If not, why bother with the testing? –  JohnFx Jan 20 '13 at 21:22

Developers Running Wild on the Range

This has happened when you realise that other developers (or, unfortunately, you) have developed a component that varies significantly from the design, and that this isn't picked up up until well into system/UAT testing. I'm not talking bugs; I'm talking about significant system components are missing features or have unasked for functionality and are never going to pass UAT without significant rework. This issue indicates that:

  • Your quality system is broken; why didn't the developer concerned pick up on the issue in the design/implementation phase. Wasn't the code per reviewed/inspected? Why did the unit and integration tests not pick up on this? If you don't have some sort of consistent unit/integration testing in place, you're screwed.
  • Your project manager/technical lead aren't in control of their development team. If they can't get the developers to deliver what is required, they will never be able to deliver a complete solution.
share|improve this answer

When a key developer on a project hasn't checked in any code for weeks and a serious milestone is coming up.

It was a contracting job and the more senior developer and PM on the job decided they wanted to team up to try to get a bigger cut so the other developer held 3 weeks of critical code hostage. In the end, we fired the incompetent PM (who had been spending 6 months putting the project on a course for ruin) and talked things out with the developer.

Suffice to say, the rest of the project was a masochistic death march, the spec freezing was delayed, the customer was given a bunch of concession features to make up for the terrible scheduling the PM left the project, and the quality of the project suffered all around because of it.

The PM even had the nerve to fly down for CDR (Critical Design Review) only to ditch the meeting with the client and throw a hissy fit. When he demanded that his travel expenses be paid for under the project he was politely told to go fornicate with himself.

I can easily identify with at least 5 of the other answers found here that affected that project. In short, I learned a lot of hard lessons on my first serious coding project.

share|improve this answer
  • Everyone is physically and mentally exhausted
  • Customers / users are clearly unhappy either about timescales or what they're seeing
  • The originally beautiful design now feels compromised
  • You're resigned to shipping with some relatively significant bugs that you'd really rather fix but aren't going to be able to
  • You're remaining pride is in the act of shipping rather than what you're shipping - closer to a survivor mentality than professional pride
  • The team is scared that there are certain things that don't work and are ignoring those sections and hoping for the best because they're scared of what might be in there
  • Everyone is convinced that they've gone above and beyond (and they're right)
  • People are showing signs of burnout (general pessimism, disinterest, anger)

(Cribbed from Jim McCarthy's Dynamics of Software Development).

share|improve this answer

I think it's generally easy to spot a failing project when the deadline is approaching. Like you said, feature creep combined with a set-in-stone deadline is a sure way of killing a project.

The key however is to spot a failing project way in advance. I think the only real 'sign of doom' in this case would be a complete lack of the definition of 'when are we finished'. Unless we know this at the offset we're doomed for failure IMO.

share|improve this answer
1  
aka "definition of done", as agreed by both IT and the Business –  adolf garlic Sep 9 '10 at 12:52

My first sign on one was when they asked how many hours of overtime we each would commit to for the next ten weeks and offered salaried workers a bonus for working said overtime based on the success of the project and meeting deadlines.

Other major signs I've seen: Requirements defintion goes over schedule and the end date is not moved. We were behind before we can even start. They took the time away from design, so we started with no database design and no site design but expected to deliver on time by, among other things, doing imports to tables not designed and created yet.

When items on the critical path are being done simultaneously instead of in order. (If I'm required to use tool X and programmer A is just starting to build it, it is going to delay my task.)

When managers are committing code on Thanksgiving.

When you start getting emails that have a datetime stamp of later than 11 pm and earlier than 6 am.

When every question about how to handle some complexity is met with the same answer, "Don't worry about that yet."

When they are still making requirements changes the day betore you go to QA or go live.

When you start having daily meetings that take several hours to discuss your lack of progress. Oh that would be because I'm in meetings all day. Daily 5 minute meeting fine, daily meeting that goes over an hour, not fine.

When the database team and the aplication team don't talk to each other.

When the client can't provide the promised information on time. Especially when those are data import files and you need that data in the database to check to see how the code is working.

When you consider installing a stop light outside some manager's office to let you know if it is safe to approach him that day.

share|improve this answer
1  
The kicker on your first paragraph is that, if the management is doing that, the deadlines are probably already doomed and the bonuses unattainable. –  David Thornley Dec 10 '10 at 19:10

Paul Vick wrote an excellent post several years ago about black hole projects. I think all of the advice is relevant. (I've edited the items and summaries for length.)

  • Absurdly grandiose goals. Like "fundamentally reimagine the way that people work with computers."
  • Completely unrealistic deadlines. Usually this is because they believe that they can rewrite the original codebase in much, much less time than it originally took.
  • Unrealistic beliefs about compatibility. Like believing you can rewrite and preserve all of the little quirks without any extra effort.
  • Always "six months" from from major deadline which never seems to arrive. Or, if it does arrive, another milestone is added on to the end of the project to compensate.
  • Must consume huge amounts of resources. Usually by sucking the lifeblood out of one or more established products.
  • Involve using brand-new technology that has not yet been proven. As such, they get to flush out all the scalability problems with the new technology.
share|improve this answer

For me, it is when those that are responsible for the feature set (aka managers, product owners, customers...) stop caring or seem to have a hopeless air about their answers. Questions about features are meet with apathy and discouragement. It is clear that they have lost investment or confidence in the project.

This happened for me when a project I was on had the "upper management change of heart" hit it. I was asking questions about how it should work and all of a sudden no one had a real opinion.

A little while latter the project was canceled and all the beautiful code I had written was scrapped.

share|improve this answer

When the management pulls the project into different directions simultaneously and the carriage remains still.

I was once involved in a project managed by two guys. Either they didn't talk to each other or each one has some ego to resolve, but they were commandeering our work into opposite direction about each week or so. Didn't take long to realize there's never going to be any result. Gladly my participation only lasted a few months.

share|improve this answer

a couple of points from a dead project i was part of:

  • The management doubles the team to finish faster.
  • the developers start "burying" bugs to meet deadlines, and although its obvious, its being ignored during code review.
share|improve this answer

Having worked on a failed project is one of the few things that most programmers have in common, regardless of language used, industry or experience.

Good, that's a relief!

I think not having daily, helpful management oversight is key to spotting creep. I believe that if you have the right information, if you get your devs to input the right information, then you can spot slippage quite quickly. What you do with it after that - well that's more politics and less dev...

share|improve this answer

I mentally translate "Everything is fine. We have nothing to worry about." to "We're all screwed" every time I hear it management say it. You usually hear managers throw it in incidentally in unrelated meetings ("Oh and by the way, everything is going fine. There's no reason to worry!"), but it's an even bigger red flag to have a meeting specifically called to say that.

I have yet to hear a manager say something along these lines and have it not turn out to be a lie.

share|improve this answer

Well, the best way to answer this is with an example:

Bob starts a project by coming up with a genius idea. He begins by creating a plan for the software project that begins with specific steps that need to be completed. However, the steps do not lead to the end-result, but only go a portion of the way there.

In the end, the project fails because the plans were incomplete. It's not so much lack of planning as it is insufficient planning.

share|improve this answer

When management says "We're going to postpone the next sprint and do documentation instead"

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.