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.
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).
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.
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.