Sorry for the long post, let me know if some parts should be shortened. I feel that some backstory is needed to understand what's happening.

Quick recap: my company's development department grew from 3 people to 20+ in the last 5 years. The original members used severely outdated practices. The users in other offices had long given up on getting that team's tools deployed to them and bought external ones instead.

I came in as an intern, got hired, and created libraries and small frameworks to help the team share code. I introduced unit testing, automatic deployments from a VCS, and a common task runner (call it A) to run our pipelines, and shared ownership of all that with multiple colleagues who are now co-maintainers. The situation improved, management and multiple colleagues agree that these efforts improved the situation, and the team built multiple new products on top of these projects.

One of the original 3 members, who had been here for years before I got hired, went off on their own to write a completely different task running system (call it B) and re-implemented multiple features of A, in addition to some of their own. They didn't coordinate with anyone on their design and didn't give a reason for this new tool. B basically re-implements some of A's tasks, then calls A to run the most complex part of the pipeline, and processes the outputs some more.

Over the past months, this has caused these problems:

  • Per a colleague who works on B, B's code will be very hard to test (currently it isn't tested at all) because it hasn't been designed with testing in mind. Its functions are mostly monolithic with a large number of edge cases.
  • A is built on an async framework, while B doesn't use async. This makes interactions more complex and causes B to call A in ways it wasn't intended to be called. (B's author doesn't know much about async and isn't interested in learning.) We made efforts to make those work anyway, but it's a drain on my time.
  • For the same reason, B's use of A is sub-optimal, and the more we optimize A, the larger the gap will be. I estimate that we can make A 50 percent faster in some cases. B's author isn't interested in refactoring parts of B to use this.
  • B's output hides all of A's logging. This wastes a lot of my time when debugging customers' issues. I often take an hour or more to answer an email that I could have answered in one minute if I had the full log.
  • B's own logging is mostly nonsense. Messages like "foo", "bar", "foo2", single numbers with no context, broken English, etc. This makes it that much harder to debug.
  • I'm responsible for multiple customers who have to use B because some features are only implemented there. That means I have to work around all the aforementioned issues in my daily work, in addition to frequent bugs in B, and these customers suffer from those issues.
  • Some of my deadlines depend on changes in B. B's author commonly hides issues for weeks, only mentioning them orally to other colleagues and letting me discover those by myself. They also promise to fix issues, say they are fixed, only for the same issues to be reproduced by customers. They don't update our issue tracker and I have to come back to them 2 or 3 times to get information about what they promised to fix.
  • The way B is configured bypasses the defaults in A, meaning we went from maintaining one set of defaults to one set of defaults per customer (B's author doesn't own the features with the most complex configuration, so the effort falls on others.) There's no clear line between the two systems, and in practice a feature is implemented in one or the other depending on which team member added it.
  • B generally doesn't communicate before implementing anything. They only come to us after the fact, when their implementation doesn't leave us another solution than duct-taping their code to ours. This has happened multiple times.
  • B doesn't follow A's interface, instead depending on implementation details. B already broke once because of this. B's author tried to blame this on A until I found their bug and explained what they did wrong.
  • B puts the onus on its user to provide a configuration file for A. I've seen our customers hire a coder to write a script that works around this because B was too hard to use that way.
  • Now B's author is asking us to change our design to make B's use case slightly faster. It would make A more complex and not benefit A's users at all.

I have already confronted B's author constructively, with multiple technical arguments to increase code sharing, merge and co-own the two systems, like we do with other large projects. They usually spend some time giving weak answers that don't make sense technically, then start cutting me off and talking louder than me when they are out of ideas, such that I can only leave.

Overall, I have a low opinion of that person's competence, I think their reasons for creating B were their own promotion (they now own this user-facing program) at the cost of the team's and the customers' time, and I don't want to waste more of my time dealing with B's defects or trying to win a scope war. I don't want to hurt the pretty good relations inside the team, but I'm OK with confronting B's author again. I have the support of the managers who are technically capable, but B's author has long been allowed to do what they want due to internal politics.

What's the best way to deal with this without making my own life harder? Should I keep trying to make both tools work well together, or try harder to get the managers to force B's author to merge the two tools? Is it a good idea to complain openly to higher management that can actually do something? Or at least share my concerns?

TL;DR: Team of developers is building common pipelines and frameworks with great results. "Senior" colleague of questionable competence is trying to supersede some of these systems with their own inferior alternatives for their promotion and that wastes everybody's time. What should I do?

  • 3
    I was in a somewhat similar situation myself long ago, and the following approach helped me somewhat: create technical workarounds for every problem, but treat them as development projects and document their cost. For example "B's output hides all of A's logging" - make sure A logs every little detail when B calls A. Document the cost of coding this, and the cost of keeping these logs around for a while. " multiple customers who have to use B because some features are only implemented there" just implement each missing features in A. Jan 28 at 22:20
  • 2
    This could all be simply summarized as senior colleague is acting like a cowboy and not a team player, and is making your life harder by doing so. We don't need to know (or care about) the details (unless you want to pose questions on Software Engineering SE). This fundamentally seems to be a managerial issue between your colleague and their boss, and not a technological issue.
    – Peter M
    Jan 28 at 23:46
  • 3
    Not sure I'm following why it wastes your time. B is his tool, you have not agreed to provide support for it, anyone who wants support either takes their issues to him or uses A, and you are not obligated to tune A to better support B. Though as others have said, it's possible that B -- however poorly implemented -- has ideas that you might want to adopt into A eventually. He's wasting nobody's time but his own (and perhaps that of anyone who tries his toy ad decides it isn't ready for production use, but that's not your problem) Let a million flowers bloom, weed, crossbreed, repeat
    – keshlam
    Jan 29 at 1:15
  • 2
    When B's author tells you to change A in a certain way, do you have to do it, or not? (i.e., are they your manager in the sense of assigning tasks?) Jan 29 at 3:44
  • 2
    Why do they "waste your time"? Is it something your manager wants you to do? If not, why do you do it?
    – nvoigt
    Jan 29 at 8:05

2 Answers 2


A potential solution is to build in all of B's capabilities into A. I tend to do something similar so I don't have third party issues to worry about later down the line, or things breaking when a third party does an update.

I'm not sure how feasible this is in your situation, but it's what I always try and do to retain control over things. It just makes troubleshooting and everything else so much smoother.

  • This is my preferred solution, but I worry that it will turn into a stupid contest, or B trying to turn it around on me trying to replace them.
    – MKyu
    Jan 28 at 22:52
  • 2
    I own my systems so can do what I want. But if you have managerial support then you can just do it. I always just tended to do whatever was necessary and so long as it works there wasn't any real issues. It's difficult to complain about things that work well.
    – Kilisi
    Jan 28 at 23:02
  • @MKyu With the way B's author is working, why aren't people hire up actively trying to move things away from that? Are they not aware of the support cost? Maybe it's time to let B support go to the author, and you replicate B's feature back into A just like how he did it, and show that your system actually functions.
    – Nelson
    Jan 30 at 5:48
  • @Nelson the only person higher than B’s author is responsible for the state of the company when I got hired: nothing deployed outside of that office, unit tests didn’t exist, people copy pasted their code to target machines with no versioning. They are fine with a big ball of duct tape.
    – MKyu
    Jan 30 at 12:26
  • @MKyu Well, from your perspective maybe, but from their perspective, they're in no position to really criticize anyone since they don't know any better. If it is something you want to take on, you can show that your system simply takes less work to support by making things efficient, but you may not be compensated for the effort.
    – Nelson
    Jan 31 at 1:10

The only people who can fix this problem are your managers. It seems like you should talk to them about your concerns. Maybe you have and nothing happened; maybe you are reluctant for other reasons. In any case, your best hope is being able to persuade them. To facilitate that, I'd advise documenting the situation as much as possible: Create a timeline of events, and keep a diary that describes relevant things from day to day. This way when you are called to defend your position you can more easily lay out the facts in front of them.

  • Actually, my own manager knows my concerns and agrees with my idea, while the other developer’s manager is less involved but tends towards supporting their system. There is no one above them with interest in technical matters. I think I’ll follow the advice I got here and try to work on my own part only.
    – MKyu
    Jan 31 at 8:28

You must log in to answer this question.

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