Our entire project is being held up because of one piece which is being handled by a single developer. When we did finally got the latest version of his code and started reviewing it, we found the code was horrendous! Its a relatively simply workflow, however the code is so complex that it's very difficult to step through and review/debug.

The developer responsible has a hard time accepting any kind of criticism, and feels he is more knowledgeable than others members of the team. It's difficult to even talk to him about his development work because it turns into "I know what I'm talking about and you're just wrong!" type of conversation.

A request has already been put in to replace this developer but management is not doing anything. This is probably because devs are in short supply where we are, and this is a corporation has a lot of office drama.

I'm just one of the developers, not the project manager, however I really want to see this project succeed.

What can I do in this sort of situation to try and keep the project on track?

Update: Lot of good answers. What I ended up doing is having a team meeting for code review of the problematic code, I included a manager. I went over the code and explained what was wrong, why it wouldnt' work and went over some general development education in a way that wasn't accusatory or hurtful but got the point across. Took 1 hour to rewrite it, and solve the issue. I think having the team with a manager really helped keep the anger/blame/attitude issues to a minimum. I treated it with a "Ok, who cares who did or didn't do what, let's just get it going." attitude. At the end of the day, the code got fixed, project is on it's way and no one got hurt.

  • 10
    I cannot help you with your dirty laundry. If your company does not know how to run a software shop and it bothers you, then leave.
    – Job
    Commented Jun 20, 2012 at 3:23
  • 14
    Why did no-one look at his code until the end of the project?
    – user16764
    Commented Jun 20, 2012 at 3:44
  • 4
    @ILovePaperTowels if code reviews are part of the process, it sounds like you have no process which is a bigger deal than a single person. That said, I would ditch the problem person and try and resolve the process issues afterwards.
    – user718
    Commented Jun 20, 2012 at 4:48
  • 5
    @ILovePaperTowels Good to see someone else around my age (I'm 65) that still likes to code (and cares about the quality), and wasn't forced/coerced into management.
    – tcrosley
    Commented Jun 20, 2012 at 18:27
  • 2
    Put him on the side, and have someone else redo it. Commented Jun 21, 2012 at 2:59

7 Answers 7


First, does the code work? You said it is badly structured and definitely needs refactoring, but for shipping purposes, does it do what it was supposed to do? If it does, then you may have to let it ship to meet the deadline. Horrendous is in the eye of the beholder, working code that is badly designed trumps well-designed code that isn't written yet when it is ship time. That's a sad but true thing.

This is partly a systemic problem. Your company needs better processes. You can't fix the system problems right now for this project. But you can start to fix the problems that allowed this to happen for the next project. First, institute code review. We do not let any code go to prod without review not matter how skilled the developer is. Even skilled developers make mistakes and those are often caught in the code review. Next you may want to get the team together and set up some coding standards. Once you have standards in place it is easier to rein in cowboy coders who think their way is always the right way even when it isn't.

Next you need a truly technical person in charge. A PM who is not technical doesn't know who is right in a dispute over code like this. You need to have a tech lead if your PM is not technical. And he needs to have the power to tell the guy to rewrite if he is not doing things in a maintainable way.

And frankly the inability to take any criticism is enough for me to move the guy off my team not matter what his skills are. I don't have time to deal with people who are unprofessional. No one is so skilled that there aren't valid criticisms that can be made. I don't employ children who never got past the age 3 level of personal development. Anyone in the workplace in any job must be able to handle criticism and must be able to follow management direction. If you can't do that you are not worth employing. So yes, you should pursue his firing. He is creating a problem for the whole team and should not be retained. I bring this up because once the pressure is off it is easy to say, "We need to keep him and really we got the project out so he isn't so bad." So document what he is doing wrong and why and keep documenting. If it works and gets shipped, document why it needs to fixed for maintainability and how much time that will take. If the code is convoluted and not working, document the hours it took to fix. Don't assume because they put you off with "we will do this after the project goes out" that they will. If they were serious about firing him, it is more likely they would have done it already.

Until he is fired, have whoever is in charge place him on less critical tasks.


See this question about dealing with an under-performing developer.

The recommendations are mostly to:

  • talk to the guys (they may need mentoring or simply to be made aware of the problem),
  • let management handle the issue (their job, not yours).

Depending on the outcome, a positive follow-up could be to become their mentor.

  • your link is dead :( Commented Sep 29, 2018 at 21:26
  • @YetAnotherRandomUser: Not exactly... The thread has been closed, so it's only visible if you have enough rep. I'd agree it's rather unfortunate.
    – haylem
    Commented Oct 14, 2018 at 23:24

I'm just one of the developers, not the project manager, however I really want to see this project succeed.

This will be the hardest thing to do. Partly due to the office politics you mentioned, and also because it isn't your job (you'll hear this from your office mates when you press it). Start with a spreadsheet of his promises, his deliveries, when bugs are reported to him and when they are delivered. With this data, you can build up a list of his faults that management could then deal with. Be warned that if you proceed down this route, your peers will never be able to stop thinking that you are going to stab them in the back next.

The developer responsible has a hard time accepting any kind of criticism, and feels he is more knowledgeable than others members of the team.

I am reminded of a chapter in Outliers where Malcom Gladwell calls it an ethnic theory of plane crashes. The problem lies in the power differential in many cultures. Some cultures have very low differentials (such as US & Australia), while other cultures have huge differentials (such as Colombia & India). In some languages, these differentials are embedded directly into the language (such as Japanese and Korean with different nouns and verbs that reflect the speaker-listener's social relationship with each other). If you are dealing with a person from a culture with large differentials, then some of the resistance you are experiencing is due to the fact that you are not their superior.

I have also worked for people who have taken any criticism of their business as a direct personal criticism of themselves. They had so much of their ego wrapped up into the business that when I identified how certain customers were stealing thousands of dollars per month in inventory, it was seen as if I had said "you are a fundamentally bad person!". The logic is somewhat like faulty inventory control becomes morally bad inventory control becomes morally bad business becomes morally bad owner becomes you are a morally bad person. You can't fix these people, just let them go out of business. For these people, one needs to learn to cope with them. Many books on "office politics" describe characters who explode at the slightest insult/criticism and call them things like "grenade" or "land mine".


Programmers are experts in handling complexity. If some code looks complex, it could be due to 3 reasons:

  1. Inexperienced programmers will try to create as complex code as possible to prepare beforehand to some future changes which will probably never appear
  2. More experienced programmers will see some complex modules in the future, but their code chooses the simplest possible route that will fullfill the current requirement. In this case, your software project starts to have some real complexity and it's getting difficult to avoid the complex parts.
  3. Experts choose the correct level of complexity. If your requirement looks simple but code turns to be difficult to read, then your requirements cannot capture all the necessary details to create the software.
  • 2
    Not very good (whether experienced or inexperienced) developers will create complex code because they just can't find a straight path to an obvious simple solution. One of the worse once was about 200 lines of complicated and not quite working code to convert a dictionary into a dictionary - where zero lines of code were needed.
    – gnasher729
    Commented Feb 25, 2015 at 15:29

Will the project team be better off without that single developer?

Instead of replacing the trouble making developer with a new developer, is it possible that someone else in the same team takeover his task?

What will you do when one of your teeth is rotten, causing you lots of pain?

  • Yes, we can do with him, but we don't have a choice. So the question is, how do we handle him without getting into a fist fight. If he were to just follow some best practices, things would be ok, but he doesn't and you can't tell him he needs to without confrontation.
    – ILovePaperTowels
    Commented Jun 20, 2012 at 3:49
  • If I was in charge and I couldn't get HR to get rid of him I would start assigning him such mindless menial tasks over talents are doing that he would eventually quite. Not like he is helping the development effort and it sounds like over the course of the project someone working an extra hour or two that was more of a team player would have had the task completed on time and correctly.
    – Rig
    Commented Jun 20, 2012 at 15:25
  • 2
    +1 for giving the task to someone else. Give the troublesome programmer an easier task, and let him know his code will be carefully reviewed. You'll have to convince the PM though, since you don't have the authority.
    – tcrosley
    Commented Jun 20, 2012 at 18:22

It seems there's a code quality issue - meaning that code may not be shippable at all. In other words, it is a sunk cost.

The first thing is to decide whether the component ("piece") can be shipped as is. If it passes all of the unit tests, and/or if the piece / whole project has already been extensively tested for bugs, I'd say go ahead and ship it, and rewrite the piece later (using the unit tests as the guide).

The second thing is to work on a parallel replacement project, possibly without that developer knowing. That is like buying an insurance that in case the piece cannot be shipped, the product can still work without that piece.

Release time is very stressful, and if there are additional HR conflicts, it may increase the fingerpointing in the entire team, further destabilizing the team morale. It may be better to postpone the HR actions until the software is released.

  • The requirements were clear and haven't changed. There is a lack of understanding in general development. It would probably take 3-4 days to redo the work which is what we have to do at this point.
    – ILovePaperTowels
    Commented Jun 20, 2012 at 3:51
  • +1 for team morale. The desicion to wait until after the project ships for dealing with HR actions was made by the team today, but we still have to deal with the dev until then.
    – ILovePaperTowels
    Commented Jun 20, 2012 at 5:25

Is this your problem? Are you responsible for delivering this project? If not, then the simplest thing is to simply stop worrying about it. If you can't stand it, and have to do something, be careful. It appears that your management fears confrontation more than they fear excess costs. If you cause a confrontation, you will not be rewarded, and are likely to be reprimanded. To win this one, you are going to have to be just as nasty as the bad actor, and a lot sneakier.

  • But being part of a failing project is never a good position to be in.
    – gnasher729
    Commented Feb 25, 2015 at 15:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .