The situation is: A developer has apparently been working on an important project for a year and hasn't been able to get the product in a commercially usable form.

Im sure there a plenty of situations that someone has to resurrect a project.

What we need from a developer to help ensure a smooth transition?

  • 7
    "hasn't been able to get the product into a commercially usable form" is not the same as "bad developer". That assumption (leap?) is very troubling.
    – Marcie
    Commented Feb 18, 2011 at 15:17
  • 1
    did it really take you 1 whole year to understand that you have bad developer?
    – ViSu
    Commented Jul 9, 2014 at 11:03
  • 1
    The current title of this question seems to imply that stop-loss (killing the project and getting rid of the developer) is more important than the salvage value of whatever work has been performed. However, the text of the question seems to imply otherwise (that there is salvage value in the work). Please consider making the title consistent with the details. Thanks.
    – rwong
    Commented Jul 15, 2014 at 1:59

6 Answers 6


"No bad soldiers only bad generals" Napoleon Bonaparte once said.

Let me rephrase him. No bad developers only bad managers. Start this transition from the analysis of your own mistakes, which are:

  • Misunderstanding of developer's weaknesses and strengths
  • Micromanagement
  • Lack of motivation model
  • Defects in project vision, scope, schedule
  • Unclear quality objectives (!)
  • Absence of risk management

Also, this article may help you: How to Fire Someone Right

  • 2
    +1 for laying the blame on the PM's shoulders. Ultimately, they're accountable for the project success or failure.
    – ashes999
    Commented Feb 14, 2011 at 18:48
  • 5
    I wouldn't be that quick in pointing fingers. I saw both projects doomed because of bad team management, project management or product management but I also saw those doomed because of wrong developers (which doesn't automatically mean bad developers) Commented Feb 14, 2011 at 22:00
  • 3
    Whose mistake is that these "wrong developers" were in the project?
    – yegor256
    Commented Feb 15, 2011 at 7:24
  • 1
    @Traroth agreed. My point is not conflicting with yours; my point is that even IF the development team is bad, the tools are bad, the sponsor is bad, ... at the end of the day, the project manager is the one who has to deal with it. Some failures are beyond your control, but what you do with what you have can make a big difference. That's my point; because ultimately, the PM is seen as the one who gets the glory or the (ultimate) blame.
    – ashes999
    Commented Feb 15, 2011 at 16:06
  • 1
    +1 for @yegor256. If it took a year to notice the dev wasn't delivering as expected, is not (only) the developer who needs to be reviewed.
    – Tiago Cardoso
    Commented Jul 25, 2011 at 13:57

If that developer hasn't been producing and was a bad choice for the project, then there isn't much more he/she can possibly contribute.

By bringing in another developer to take over the project, that developer is going to need to look through the entire project and make a determination of whether or not there is any value to any code written so far.

Ramp Up Period for New Developer

You'll need a developer who is capable of reading code, not just writing code. Many developers' first instinct is to toss out any code and just rewrite from scratch. That's not always the best decision, and you'll need to make sure the developer taking over knows the difference between something that can be brought to market with determination and elbow grease and something that is not salvageable.

Project Manager Must Understand Learning Curves Exist

The project manager will need to understand that the developer taking over can't just jump in and immediately show results. There will be a learning curve, and it will take time for the developer to assess the current state of the project.

Goals of Project May Change Based on Stakeholder Communications

Additionally, since it's an important project that is now a delayed project, the goals of the project may have changed. For instance, if time to market and timely delivery is critical, the PM will need to make sure the developer understands that -- if at all possible -- he or she absolutely must work with what the previous developer left. That means that things might not be perfect. The decisions here largely depend on the client/stakeholders and what their needs are.

In summary, the project can be salvaged, in most cases, but it takes having the right people take over, having a clear understanding of what the modified goals are of the project, and maintaining excellent communication with stakeholders.


In the ideal situation I'd start with a quick analysis what went wrong and why. It is possible that developer is a problem but it's also possible that the source of the issue lies somewhere else.

If you're sure you should address the problem to the developer it would be a comfortable situation to have someone other to work with the current developer hand to hand to take over the project. I could go into details here (like having both developers pair program) but well, we rarely live in the ideal world.

The next important answer is what happens with transited developer. If he's fired you'd tackle the issue differently than when he's moved to another project. In the latter case you can expect much support for a new person in the project. If the former is true, it's tougher issue.

If you have enough time you can ask to document the work, which would help to take the project over. If you don't I wouldn't reject quick and dirty method which is overtaking the project in whatever state it currently is. Actually I did a few times and I'm always surprised how easy it went comparing to the hell I'd expected. A bit of well-tunneled motivation works miracles.


Openness to answer questions from the new developer while the new developer gets up to speed.

Learning someone else's code can be challenging. Having the original developer available for questions can make all the difference in the world. That's not to say the new developer will use what the old developer wrote, but it provides a frame of reference in understanding the approach they were taking to solve the problem/deliver the solution in the spec.

With that said, you do need to have a good specification describing what it is they are supposed to be building.


As a manager, I would make a list of all the skills needed for the job - technical skills as well as soft skills.

The statement made by yegor256 is right. As a manager I need to be clear of what is needed in a resource to be able to make my project a success. So if the developer does not have enough experience, or enough brains to debug things, or enough teamwork to ensure they work with the team to produce good results - then it is my problem as a manager that I recruited this person.

I would immediately concentrate on what I 'can do' and get another developer, but first learn from my mistake of recruiting the other guy.

Some qualities I would look for:

  1. Give them sample code to write in the interview and ensure they follow the coding standards that are important to my organisation.
  2. Give them something to debug to test their persistence and that they dont give up at the first available opportunity
  3. Give them some real life situations in my projects and check that they are good enough to face these
  4. Test them on design patterns and other practices that my organisation employs
  5. Get a round of interview with the good developers so they can judge from their perspective

It is difficult to get good people, and even more difficult to retain them. Sometimes people who are good at what they do display an arrogant attitude. But not all people with an arrogant attitude are good at what they do.


If the developer hasn't been able to deliver it (in a year) then look for mistakes somewhere else.

  • Bad documentation / no documentation.
  • Wrongly specified user requirements and translating them to the developer.
  • No clear planning.
  • Bad communication with the developer and the management.
  • Lack of training.
  • Go and ask him what he thinks went wrong and what could have been done better.
  • Make him someone you want to work with rather than you wanting to get rid off him.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.