0

I was hired as a project manager / senior programmer to manage an internal group of programmers in a company. I'm responsible for coordinating 12 programmers.

My boss has no programming background, how can I convince him to let go of an ineffective programmer? My boss's argument is that the programmer knows that he is not very good, but because of that he is cheap.

Most of his code must be cleaned up. Today I found code he committed which was filled with difficult-to-understand and outright misspelled content (which would increase cost of maintenance of the code later on):

public static bool isDivisibleBy(this int num, int numnum)
    {
        var tmp = (float)num / (float)numnum;
        var res = tmp.ToString();

        if (res.Contains("."))
            return false;
        else
            return true;
    }

    public static int reminder(this int num, int numnum)
    {
        var absNum = Math.Abs(num);
        var absNumnum = Math.Abs(numnum);

        //speedup
        if (absNum.isDivisibleBy(absNumnum))
        {
            return 0;
        }
        else
        {
            var tmp = absNum / absNumnum;
            var tmp2 = absNum - (absNumnum * tmp);

            var tmp3 = tmp - tmp2;

            //sign
            if ((num > 0 && numnum > 0) || (num < 0 && numnum < 0))
            {
                return Math.Abs(tmp3);
            }
            else
            {
                return Math.Abs(tmp3) * -1;
            }
        }

        return 0;
    }
}
  • 2
    Most of your post is irrelevant from a project management perspective. What is your level of authority, what have you tried within your organization, and why isn't that working for you? – Todd A. Jacobs Sep 20 '16 at 22:13
  • Doesn't your team do code reviews? They're good practice generally & a good way for people to improve their skills on the job, esp in the GitHub PR model. – Vicki Laidler Sep 21 '16 at 3:11
  • @CodeGnome I agree that the code sample was irrelevant, but when I wrote the question I was aggravated. I'm responsible for all aspects of software development but not HR. I tried to explain to my boss the impact of his work and that not only me, but also my colleagues tried to train him but it does not work. We are finishing one important internal project with tight deadlines, my boss want to concentrate only on that project, I tested to remove him from the project and it boosted the productivity. – ptms Sep 21 '16 at 8:50
  • 2
    I'm voting to close this question as off-topic because it isn't about project management - this is a question about line management/workplace.SE – Mark C. Wallace Sep 21 '16 at 11:56
2

Route Around Resource Constraints

My boss has no programming background, how can I convince him to let go of an ineffective programmer? My boss's argument is that the programmer knows that he is not very good, but because of that he is cheap.

Part of the issue here is that you are solving the wrong problem. Rather than trying to get the guy fired, which may or may not be justified and which your boss clearly isn't interested in doing, from a project management standpoint your objective is to deliver a working product within your project constraints.

In a comment you made above, you said:

I tested to remove him from the project and it boosted the productivity.

In PM-speak, removing him as a resource assigned to a deliverable improved productivity. Great! Rather than using this as the basis for an argument with your boss, a more pragmatic approach may simply be to assign non-critical work to this person. If doing so allows you to deliver a better product faster, then you are performing the essential function of your role.

While it seems like replacing the programmer may be better for the project, it may not be better for the company for some reason. The budgetary waste is really your boss' problem, not yours, once you've raised the visibility of the issue. Making efficient use of the available budget and talent is your problem, though, so unless it's a potential HR issue I'd simply move this person off the project's critical path.

As long as you're being transparent, your boss can:

  1. Insist on keeping an underperforming person on the critical path, and thereby accept whatever drag on the project this may cause.
  2. Be glad that you're delivering on time and within budget, while quietly ignoring the situation.
  3. Get tired of paying someone to play minesweeper or sort paperclips, and remove or replace the person.

If not having this person actively engaged on the project is truly more productive than having him participate, then it probably doesn't matter which option your boss chooses. Making those types of choices is what he gets paid for, after all, so leave that up to him.

3

Before jumping straight to 'fire the guy', consider other alternatives, such as providing training. If the programmer knows he has room for improvement, then chances are he'd be willing to put in the effort to actually do so. If he knows he's not very good at programming and he doesn't care about improving himself, then he should possibly consider alternative career options.

If your boss isn't okay with the cost of training the programmer (or hiring someone else, if the programmer refuses training or is somehow genuinely incompetent), then you need to make sure the costs of low-quality code and developer incompetence (such as increased maintainability, more defects, lower morale, decreased performance of the team overall, etc.) are fully visible to him. If you lay out exactly what the pitfalls of technical debt are, ideally in a formalised fashion with research to back up your position (which is, in lieu of such 'proof', can be taken as rather subjective), then hopefully he will make the decision to let the programmer go on his own. And if he doesn't? That's his call.

Normally I'd also suggest first making sure your opinion actually has some merit to it, but after looking at the block of code I can agree that in this specific case there is, at the very least, room for improvement. Assuming, of course, that the sample above is indicative of the programmer's actual ability, and not a result of time pressure, excessive workload, unfinished process (you said he committed the code - was it pushed to production? If not, it's possible he was planning on going back to touch it up and just hadn't gotten around to it yet) or any number of other possible, legitimate reasons.

  • The code represents the quality of his work, fortunately all committed code is reviewed before pushing to production. I tried to train him, but, I don't know if he does not care or has no ability to learn. He always says it works and does not break the tests (most of the time). I try to count how many time is wasted with refactoring his code in comparison with other programmers and calculate the cost of retaining him and show it to my boss. – ptms Sep 21 '16 at 8:43
  • "I don't know if he does not care or has no ability to learn" In your leadership position, that is something that you should determine. Explain your concerns, get his input, create an action plan together, coach, mentor, and evaluate. Keep a written record of these events that you both acknowledge and use it to make an empirical decisions. – Alan Larimer Sep 22 '16 at 17:23
1

I think you should explain your boss the existence of Net Negative Producing Programmers.

Software development is one of the professions where its possible for employees to have a negative production. This means they cost more time in the long-run then their results add value on the short-run. Even if they are cheap, they will waste time of the expensive developers. And we all know you always come a couple of developers short on a project!

Identifying and handling NNPPers is not so easy, but some signals as not delivering clean code could be a start. Still isolated signals might be resolved with proper training. The real NNPPer also have an attitude problem where they think their ways are the correct ones and are hard to train.

CowboyCoders are identified more by their attitude than by their circumstances. CowboyCoders prefer -- nay, insist! -- to avoid standards, processes, and policies, and hate working with others.

Be sure to read this pretty long blog about "Dealing with net negative producing programmers" and share it with your boss if you like it. Maybe even share it with the developer you are having issues with, this might give him/her insights about why you are having issues with their behavior.

My pick from that article as advice to you is:

Taking a poor performer off the team can often be more productive than adding a good one.

See if you can get him/her reassigned into another project or product.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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