How to stop an employee from holding the company hostage?

Question

I work in a team that writes software to facilitate one of the key business units of the company. I joined the team a few months ago and found out that there is high turn-over in my team due to one person. This person (let's call him Mr. A) has been with the company for 7 years, he is very difficult to work with and he repeatedly makes bad decisions on purpose to keep the software product unstable, difficult to maintain and troubleshoot. This way, when there is an issue, only he can fix it.

He had left the company a few years ago because the company didn't allow him to work from home, but as soon as he left, the company had to hire him back (and allow him to work 100% from home) because the software had issues and no one knew how to fix it.

My manager knows this, but he says there is nothing he can do about Mr. A.

What can I do to fix this situation? I want to make the software modern, maintainable and stable.

FYI, the software monitors events, does some processing on them and then takes appropriate actions. Mr. A has:

• Purposefully kept away from modern software development frameworks;
• Written core business logic in languages that can't be tested;
• Re-architected software components into 30 modules to add complexity and version certification issues, and;
• Designed it in a non-scalable fashion, ensuring there is no HA (high availability) capabilities.

Update:

Regarding Untestable code, business logic is being moved from Java to groovy scripts embedded in XML. The Java code's unit tests have been discarded.

Regarding modularity/complexity, each module has been given its own git repo and has its own versioning. Now only Mr. A knows which versions are compatible together. You can't release 2.0 version of the product and deploy all 2.0 modules. You have to release Module A 2.0, which will work with Module B 1.0-2.0 and Module C 1.0-1.5. For me, that's bad design, it should all be versioned under one repo like Spring framework (Spring 5.0 means Spring-Core-5.0, Spring-Context-5.0, Spring-Web-5.0, Spring-Security-5.0, etc).

Manager says he can't do anything about this because Mr. A was let go of at first but then when issues popped up he had to be called back to fix it. So the product cannot be maintained without him.

I see this as my problem since I don't want to abandon the manager as he has been very nice to me. And my first instinct is to solve a problem, not abandon it, although I can see how abandoning this would be really easy, and part of me is tempted to do that.

Others have left the team because of him, because at lunch he is what everyone complains about. Any time there is a meeting with Mr. A, people come out of it shaking their heads (for hours).

2nd Update:

HA is abbreviation for High-Availability. In Software Architecture this means developing your software in a way that it can be hosted/deployed in production environment in a redundant fashion so if one instance of it goes down, the other instance(s) can take the load resulting in zero downtime. End user wouldn't even know something had gone wrong.

Regarding: This is seems like normal large code base. I don't think this is because of large code base as the product is not that rich in functionality. It's a backend system that crunches data. Other companies have similar products to meet their business needs, they're able to do this using modern HA/Scalable options, so I don't understand why this team needs to do it in Java 6 without HA/Scalability.

3rd Update:

Regarding 'Do latest versions of all modules work together?': Not necessarily. He's been rolling back certain modules in prod if there is a bug identified, but rolling back has introduced more bugs since certain module versions aren't compatible. All of this could be avoided if all modules were versioned and released together because then the entire product would be tested and as a whole would guarantee certain functionality. In other companies/projects where I've worked, that's how they've been able to develop and deploy far more complex projects with ease.

@pipe: I'm not fresh out of school. I've worked at various companies and on large projects for past 10+ years and everything I see Mr. A propose goes against convention and common sense. The 30 modules (in separate repos) was how he had originally set up the source tree. A smart developer who was in the team for 1 year, saw the compatibility issues and pushed for combining everything to one repo, making a multi-module maven project. That developer got tired of Mr. A's nature so he found a job at one of the top 5 IT companies. I won't name the company to keep this anonymous, but by top 5 IT companies I mean Microsoft, Google, Apple, Facebook, and Amazon. So this developer wasn't dumb nor was he incompetent. He had 8 years or experience. Mr. A reverted that change back to the way it was, 30 modules in separate repos. So these 30 modules weren't added to handle complexity of a large code base. They were put in place to ensure there are compatibility issues in prod. Unnecessary complexity.

More regarding "Why is this your problem?": When I talk to developers who work at (or have friends who work at) Microsoft, Google, Amazon, Facebook, Apple; I'm told that often you find people that are difficult to work with. I see this situation as a challenge that I will face repeatedly wherever I work no matter how awesome the company is. So I need to know how to handle this properly in order to continue to grow in my field.

Goal (for keeping this question on-topic):

I am asking this question to know what is the best way to handle situations like the one described above to meet the goals outlined below. I believe that difficult coworkers are impossible to avoid so based on others' experience maybe we can all learn something.

• Improve stability of product by minimizing spaghetti code and unnecessary complexity, as per management's request.

• Make it HA as per management's request.

• Use modern frameworks and language spec (Java 6 vs Java 8) so new developers are easy to find in the market and they can be productive quicker.

• Eliminate dependency on single person.

Answer 1

What can I do to fix this situation?

Nothing, you've only been there a few months, it's not your role and you don't have the power to do anything except whine about it.

Your superiors have a lot of recourses, but haven't used them in 7 years, so at this point you're just second guessing their reasons and analysing a colleague instead of concentrating on your own responsibilities and tasks.

Answer 2

Hire two or three of the smartest developers that you can find. Hand them all the code. Let them verify that they do indeed have all the code, everything that is needed to run the software. Have them learn what the code does, document it, refactor it, until they reach the point where they can fix problems faster than Mr. A. All this obviously without any knowledge of A.

At that point you make sure that you shut off Mr. A completely from any company resources, transfer the job to your new developers, and inform Mr. A that his employment has finished.

I would think that with Mr A's development methods, the amount of work that his code does is actually a lot less than seven years development would normally produce, and that the code is obfuscated, but not actually difficult, which makes the new guys' job a lot easier.

PS. Due to some comments, I want to emphasize this again: The problem is not just the money, the problem is that the software is much less well developed than it could be, because A focuses on making it hard to develop, not on improving the software.

Answer 3

Short Answer: Your organisation currently is in grave danger of The Bus Factor.

This is why you never let one person hold all the knowledge. It is a huge risk. What would happen if this person decided to quit, or literally got hit by a bus? If the situation is as you outline it, then the whole company is gone. You need to flag this to your managers as a organisational risk, not an HR issue.

Start getting other people across the code, with or without Mr A. Preferably without, because you've already identified him as the issue.

Remember, if Mr A won't assist in this risk mitigation to your organisation, then he himself is a danger to the organisation and needs to be managed out. Take away his power so that if he really does get hit by a bus that you don't all end up with no way forward.

Answer 4

The other answers are pretty great, but there's one additional thing I'd consider:

My personal advice would be to consider starting to look for other places to work... if management hasn't taken any action in 7 years, I'm not sure this is a place you'd like to work for in the long term. To me, this reads as a warning sign for other sorts of problems in the company.

Answer 5

and he repeated makes bad decisions on purpose to keep the software product unstable, difficult to maintain and troubleshoot

So why is your team letting these "bad decisions" get past design review or code review? If you don't have a code review process or even a design review process, advocate for that in the long run.

But until then, everything you need to know is in the Joel on Software blog article: Getting Things Done When You’re Only a Grunt

And he has a specific callout for dealing with bozos: FILE BUGS. Per Spolsky:

As a grunt, your goal is damage-minimization, a.k.a. containment. At some point, one of these geniuses will spend two weeks writing a bit of code that is so unbelievably bad that it can never work. You’re tempted to spend the fifteen minutes that it takes to rewrite the thing correctly from scratch. Resist the temptation. You’ve got a perfect opportunity to neutralize this moron for several months. Just keep reporting bugs against their code. They will have no choice but to keep slogging away at it for months until you can’t find any more bugs. Those are months in which they can’t do any damage anywhere else.

Otherwise, as a new hire on the team, your goal should be to develop your own reputation of excellence.

Answer 6

Just to say it more clearly than the current answers...

Your problem:

no one knew how to fix it.

Your solution:

• Learn how to fix it yourself.

There, now the company doesn't need the other guy anymore.

Answer 7

Post this on the wall: (You will have to change some of the names, and places).

Some years ago I spent a week giving an in-house program design course at a manufacturing company in the mid-west of the United States. On the Friday afternoon it was all over. The DP Manager, who had arranged the course and was paying for it out of his budget, asked me into his office. “What do you think?” he asked. He was asking me to tell him my impressions of his operation and his staff. “Pretty good,” I said. “You've got some good people there.” Program design courses are hard work; I was very tired; and staff evaluation consultancy is charged extra. Anyway, I knew he really wanted to tell me his own thoughts.

“What did you think of Fred?” he asked. We all think Fred is brilliant.” “He's very clever,” I said. “He's not very enthusiastic about methods, but he knows a lot about programming.” “Yes,” said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. “Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it.” His voice dropped to a reverent hush. “Fred tells me that he's not sure he understands it himself.”

“Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flowchart. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”

“Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple. She hasn't really proved herself yet --- if you see what I mean?”

“I saw what he meant.”

— Extract from the book Software Requirements & Specifications — Michel Jackson (Well worth a read).

Answer 8

The answer is simple: fire him. You may have to pay out a non-trivial amount of money in the short term to fix the mess he's made, but Mr. A isn't smarter than anyone else in the world - somebody else will be able to maintain the software in the short term, and make it better in the long term.

Answer 9

There is a perspective to consider.

The company likes it this way. If they didn't 7 years is a long time to let it persist.

We tend to forget as developers, that it's not our job to write good or smart code. It's our job to poof a product into existence. Writing good code just makes that process better, but you can a totally awesome product with totally crap code.

The company has stood behind his decisions, and even hired him back. They "like" him and his way of doing things. You're not likely to change this, even if you somehow managed to get him fired. What is likely to happen is they pick a new person to be "the guy" and the process starts all over again.

It's not your job to run the company. The company has made their choice. You need to make yours. Learn from the guy (he has held the same job for 7 years he must be doing something right) or move on.

Answer 10

For better or worse, neither nothing nor no one is irreplaceable. (some may be more than others, but still ) If people know the solution, they can start reverse engineering it.

I was in your shoes more than a couple of times in the past. In the most similar situation to yours, "Mr. A" was long gone, however, I had a monolithic solution working for the back end of a cable company where I had no source code for the local developed libraries, and to top if off I was a rookie in that industry.

I pretty much attacked it on a modular approach, having a look at the existing code, reverse engineering where it lacked and writing modules that replaced on turn with better functionality and speed core tasks. I perfected each module before going to the next. In a few months I had killed the former application.

Being irreplaceable is overstated.

Dealing also with legacy stuff is not an easy task, maybe your coworker does it out of inertia or because he does not know any better.

Answer 11

From a business perspective, there are basically two solutions:

1. Transition incrementally, in other words, take a small piece of the functionality, re-implement it to a high standard, and put it in production, and continue doing this piece by piece until the old system can be totally decommissioned.
2. Fully build a new system, and then transition to it, either all at once or gradually, e.g. starting new clients on it and gradually moving old clients to it. The new system doesn't have to be as featureful as the old one initially; its selling point can be a lower price, quicker support, etc.

The advantages of option 1 are that it does not need a large amount of upfront investment, your new code gets field-tested gradually instead of all at once, and you start to see benefits early (because the business spends less time and money maintaining the parts of the old system that are no longer active).

However, the disadvantages are that the new system's structure may be strongly influenced by the old system's structure, and in some cases it's really difficult to replace parts of a very messy system. Sometimes a bit of creativity is necessary—if all else fails, your new code can simulate key presses and button clicks on the old system! But interfacing with the old system may generate so much work that it's better to just go with option 2.

Either way, there is something that can be done. The question is, how much will it cost and how much will it save? Trying to estimate that for each of the above options will help determine which option to choose (if any). It will depend on the functional requirements, the structure of the existing system, and the willingness of the business to spend money/use credit upfront for future savings.

Answer 12

As a member of the software team your job is not to manage the company and its employees.

Your job is to write good software. So worry about the software not the people.

You see the problems with the software, and from your question, it sounds like you have some ideas to fix the problems. Bring these ideas to your manager and fight for them.

"Manger, this software is not tested and its current implementation is not testable. I suggest we work on reimplementing in a language that is more testable, using design patterns that allow for easier testing."

Now, it's very likely that:

A. This is a large undertaking that the company is not willing to invest in, because they don't see the need

B. Mr. A will argue against this stuff and will be listened to since he is more senior

If that happens then you tried to do your job well and were stifled. Time to look for a new job.

If this pans out and they listen to you, you signed up for a ton of work.

Answer 13

You can't assume intention behind the situation.

Purposefully kept away from modern software development frameworks

He might just be most comfortable with what he knows best?

I worked at big companies whose pipeline was a patchwork of ancient and brand new code and where certain pieces of code "just worked" and were never touched. On top the programmers who wrote it were long gone and nobody really understood how they worked, so they just added new functions to accommodate for changing requirements. Their pipeline was always live, so any major rollout could have disastrous(i.e. very expensive work and delivery interruption) consequences, so they shied away from touching it too much.

It is bad habit and makes for unoptimized infrastructure but actually has its merit.

What you could do, especially if you're to work on a lot or all of the code: If there is no proper documentation, either propose to create one (if you know you're qualified and have the time) or ask if there should one be made to speed up the work.

You should (as you already do) talk about adapting new technologies or improvements with your manager but expect that nothing might come of it, even if he agrees with you.

Chances are that nobody higher up sees the benefit of spending resources on this and your attempt might be looked as ah, the new blood thinks can change the world and teach us about the error of our ways.

Unfortunately company structures resist sudden change and modernizations are a matter of gradually wearing down the resistance or implementing it bit by bit unless you can show your "revolutionary changes will bring upon a golden age of financial profit without risks".

Even if he is maliciously doing this to keep his job, I don't see it being your responsibility to blow the lid off, especially if your immediate superior is informed about it.

What would you do? talk with your manager or without him to higher management or with the colleague in question?

Seeing as your manager decided not to pursue the matter he probably won't want to talk to his supervisors with or without you, or he already did and met a blockade there.

If you talk to his supervisors without him you risk alienating him.

Talking to the colleague will most certainly make for a very bad work environment afterwards and he surely will deny any accusation.

Answer 14

The only way to fix this is to take away Mr. A control.

First get management approval.

Make a brand new git.

1. Import a good, agreed upon starting point.

2. Start from there, and bring the code forward.

3. Don't give Mr. A access at all(don't even tell him it exists)

4. Port Mr A. changes to your own repo, or rewrite.

5. Let Mr A. Do whatever he wants to his repo, as you won't be using it.

6. Make fake code changes to make it seem active if necessary to hide your new repo from him.

7. Eventually code will diverge far enough he will become automatically obsolete.

You need to make a critical decision to keep or abandon the modules strategy. Modules are not necessarily a bad them, you need to keep them sync'ed and in working order.

This is going to be a lot of work as you have to re-write a lot of existing code.

An additional benefit, is the code will eventually diverge far enough that he will no longer be able to claim its his code. It will be completely foreign to him.

Answer 15

Be aware that as a non-manager, this does not HAVE to be your problem to solve (apart from following instructions to do things that have been decided on as part of a solution).

Also, never blindly interpret "We want problem XY solved" into a statement "...because of problem XY".

Also be aware that once you drive any initiative, even with approval, to change the situation, you are involving yourself in company politics. In company politics, there is no such thing as "an innocent innovator with no personal agenda, that we can't hold responsible for unintended consequences".

If you do it, do it with a personal agenda, and own the consequences either way.

Answer 16

@MightyPizza - You are wasting your time. Go work for another company that has a brighter and better future. You should only spend this much energy on solving this problem if this company is your last stop.

This is the absolute best answer you are going to get. Prep yourself for the jump.

"I want to make the software modern, maintainable and stable."

The best way to do this is on Day One, first line of code, not with someone else's hot pile of garbage.

Answer 17

Why does everyone want to fire Mr. A so much? I think he did nothing wrong here. Software development is not about making new things using cool tools, or a framework. It is about making a stable thing that just "works." Your company loves Mr. A and is satisfied with his work.

Purposefully kept away from modern software development frameworks

Your system is current in stable condition, so why do the team even need to use modern software development framework like Scrum or agile?

Written core business logic in languages that can't be tested

Is there a requirement that the core business logic has to be automatically tested?

Re-architected software components into 30 modules to add complexity and version certification issues

How much more did this implementation cost your company?

Designed it in a non-scalable fashion, ensuring there is no HA (high availability) capabilities

Still the same question - how much more did this implementation cost your company?

In my opinion, all the things you write down here is just your complaint against him. If he did a lot of "terrible" things the system itself would have melted down in the first year, and he couldn't have had stayed for that long in your company.

Answer 18

For him to have stayed in the position for so long shows the business is consciously or unconsciously applying Hanlon's razor:

Never attribute to malice that which is adequately explained by stupidity.

It sounds like it's very difficult to find actual cases of malice, just things that have worked out not so well over time. In fact, it looks like Mr A has let people try to change things and then heroically fixed them when they have gone wrong.

You should also consider that Mr A may be suffering from the Dunning–Kruger effect, in that he is unable to see that what he is doing is wrong.

It could be that he was once good, but stopped learning and stopped trying. Who knows. What you have to take as a first principle, is that no matter how exasperating he is, you have to deal with him as though he is not a malicious agent.

Your question seems to take the assumption that he is just after job security and refuses to update things to embed this. You may be right, but you can't deal with him on this basis.

I'm sure some of your bright ideas come up with the resistance of "we tried it once and it didn't work due to X." From a business perspective this makes sense, they took a risk something didn't work so why should they try it again.

You state as your goal.

I want to make the software modern, maintainable and stable.

Lets break this down by business need

1. Modern

There is no implicit business value in modern. It is arguable in any case. You say Java 8, others would say Rust or Golag are modern. So long as a system is supported there is no great value in updating it.

2. Maintainable

This could be difficult to argue as well. Mr A will argue that it is maintainable, as he maintains it. You would have to argue that the maintenance cost would go down drastically to justify a wholesale change of framework.

3. Stable

You say that you want to make the system HA, but you also say that it

the software monitors events, does some processing on them and then takes appropriate actions.

Which does not sound like it needs HA.

So what to do?

Your system sounds like a big ball of mud defined by

A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair.

Tackling this head on, with an uncooperative developer managing this will be very frustrating, and probably fruitless. It sounds like many others have tried and failed.

What you can do is start to circumvent it:

• If you can't make the system HA, then use a message bus system or such like to capture the messages that way if the system goes down you don't lose data.
• If you can't write unit tests, write system tests. These are not as neat but they will allow for testing to be done on the system
• The next time some action is required start to build that into an independent subsystem which can listen to the message bus and perform it's own action.
• If you can start to affect some downstream effects (for example encapsulating the actions which are taken) then put these in a subsystem.

There is some argument to support the majectic monolith over microservices, but it assumes that the monolith is well engineered. In your case, the system may be fine as a well-engineered monolith but if it is not well engineered you need to split things out.

This looks like a good article to start you with:

A more common approach is to start with a monolith and gradually peel off microservices at the edges. Such an approach can leave a substantial monolith at the heart of the microservices architecture, but with most new development occurring in the microservices while the monolith is relatively quiescent.

However it is important to play along with Mr A, do not tell him you are replacing the system, but that you are "improving reliability" or adding redundancy. If you attack what he has done he will make it harder for you to achieve your goals.

You may get flak that you are making the system more complex. It is true, but necessary if you are to move forward long term.

Answer 19

Simple, the business has to offer him a generous raise to document the current state of software and all the knowledge that's not being documented then they fire him. Or alternatively, they hire a tech consulting firm to document everything and he'll see the writing on the wall and eventually leave.