0

This question already has an answer here:

I work in a relatively high-paying and high-pressure SAAS company on a legacy (no tests) c++ backend component that is critical to the business. A flaw in this component could easily result millions of dollars of losses.

Despite its importance, it has been maintained by a team of three marginal developers, all 15+ years senior to me. After spending the last year managing them part time, I don't believe they are going to get any better; one because of lack of motivation and the other two because of a lack of intelligence.

I've tried talking to them, asking them why they use things like c-style casts, hand-written new/delete for containers instead of smart pointers, use singleton for everything, etc. etc. The typical response is something like a shrug and mumbling something about it being easier that way. One suggests that using singleton for every class is a matter of taste, not to be discussed. Another just cannot understand or accept that global variables cause problems; a recent commit message was "Because JQ insists it be this way."

There is a strong possibility that I will be managing them full time beginning next year, and I feel like they should be replaced with people who are able to do more than what they are told. Their current manager (who is retiring soon) knows that they are sub-par, but we can't hire enough people so they are still around. What can I do?

|improve this question

marked as duplicate by gnat, Jim G., IDrinkandIKnowThings, enderland, Michael Grubey Aug 11 '14 at 12:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 5
    Have you looked at the over-all picture? You obviously want to change the programming style, but how does your programming style mesh with the legacy code? Could it cause it to break? Are you better off rewriting the whole thing from scratch rather than make the single change of medication that's going to kill the patient? At the moment, your question raises more questions. It looks like this code has been around for a while. What would happen to this code, if you did such a basic thing as updating the standard libraries? Will your enterprise app collapse like a house of cards? – Vietnhi Phuvan Aug 10 '14 at 19:18
  • 2
    Can you show them an improvement in performance, design or code readability because of your suggestions ? If not, then its going to be hard to convince them to change. – Borat Sagdiyev Aug 10 '14 at 19:19
  • 6
    Treat tinkering with this legacy system like you are defusing a bomb. One bad move and the bomb blows up. Well meaning changes, if you are not wary of the consequences, could be such a bad move. Plan for this as thoroughly as you were planning to commit a first-degree murder. Don't do a thing unless you're damn sure you'll get away with it. A Roman philosopher used to say that being either at point A or at point B is not where the challenge is. It's the transition from point A to point B that could kill you. – Vietnhi Phuvan Aug 10 '14 at 19:32
  • 6
    Unfortunately, there's a pretty good chance that if you take your subpar developers with years of familiarity with the subpar codebase, and replace them with excellent developers with no familiarity, the outcomes will be even worse. – Carson63000 Aug 11 '14 at 0:33
  • 3
    What @VietnhiPhuvan said. It sounds like you've made assumptions about how coding should be done. But those 'sub-par' guys are the ones waist-deep in the code, which is a 'legacy' codebase and has 'no tests'. Perhaps the code predates the patterns you want to adopt. And perhaps the patterns you want to abandon are pervasively established. Trying to refactor them out with no tests would be a huge risk. And from a code-sanity standpoint it's better to consistently follow an established pattern (even a subpar one) than it is to mix patterns. Sounds like micromanagement, TBH. – aroth Aug 11 '14 at 6:07
4

If they don't do what they are told, you have three options:

  • Teach them what they need to know, this is split into two steps: If they don't understand why they need to use smart pointers, they will hardly start learning about them. Show them the consequences of what can happen and how the smart pointers avoid that. If they don't understand smart pointers at all, they cannot use them. Give them more time for learning, free their schedule, get them books, courses, an external coach who teaches smart pointers. Make clear smart pointers are important to you and the project stability.

  • Get rid of them. If it is such a critical system, letting people handle it who have not the required skills is just a recipe for disaster. Million dollar losses doesn't sound as as bad as lives of children and puppies, but is still a bad thing.

  • Try to evaluate if their system is maybe as good or better than smart pointers. If they are used to doing it this way, they are maybe really good at it and thorough and it might be less harm leaving it as is than changing it. One rule is to never change a running system. You need to find out if it is really running.

As you can imagine from my answer, I have no idea what a smart pointer is, but I'm also not working on critical SAAS systems, so I feel excused. ;-)

|improve this answer
  • 3
    Beware of point 2). You might end with subpar colleagues which have not years of experience in the system. – SJuan76 Aug 10 '14 at 23:38
  • 1
    @SJuan76 Even an exceptional colleague who lacks hands-on experience with the legacy codebase would likely be less effective. And more generally, 'telling' programmers to do something is usually a losing proposition. You'll get better results if you can demonstrate why the way you want things to be done is better. And in this case "better" means not just "theoretically better because that's how modern C++ is done", but "better in practice because it fits easily into the existing codebase and will provide benefits A, B, and C". – aroth Aug 11 '14 at 6:17
1

What can I do?

You have already concluded that this team isn't motivated and isn't intelligent enough for the tasks as you see them. The bad news is that it's going to be hard to turn that around immediately. The good news happens when you become their manager next year. The other bad news is that once you are their manager, the problem is all yours.

Once you are their manager next year, you can do anything you choose (within corporate guidelines).

Once you are their manager, you get to set the performance standards for the team. You can decide what they must accomplish, and within what timeframe they must accomplish tasks. Based on all of the work that your team must accomplish, you can decide if what they are currently doing is good enough, or not.

Once you are their manager, you can tell them how they should be coding. You can choose to dictate the standards and style that you feel are appropriate. You can teach them yourself, pay for training, or expect them to learn on their own.

Once you are their manager, you can decide if have a "subpar" team, but a team who is already experienced with your company and system, is better than having a "par" team who is inexperienced with the specifics of your company and system.

Once you are their manager, if you continue to hold the same opinion of them as you do now, you can choose to get rid of them. You may need to go through a formal Performance Plan first, so it may take a while. And if you do fire them, then you'll need to go through the work of budgeting for, hiring and training their replacements. Perhaps you already have some people in mind as replacements.

|improve this answer

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