How can I highlight how much better I've made our code and deal with a coworker that disagrees?

Question

I joined a company to help add some functionality to their code. The code is legacy and has been terribly maintained. The technology is ~15 years old.

It takes days to track down bugs and problems that should take minutes, due to broken/missing logging and so much untested and spaghetti code.

Because of this is seemed logical to me to rewrite some of it, namely the parts that have no logging or error handling, that are incredibly difficult to read and cannot be tested locally on the development machines due to their hard-coupling with external services.

It isn't a complex system, and I am not rewriting all of it. I am extremely aware of the desire for new developers to come in and wipe out working code and replace it, but the code here is really bad, and really old (.net 2/3.5, no DI, no unit tests, no SOLID, using COM rather than microservices). I should also emphasise, that this is code that is undergoing change daily and causing errors and bugs daily, rather than legacy code no-one has need to touch.

I have rewritten the main engine causing grief using all of the latest techniques. Management agreed that this needed to be done at some point, but as I'm in downtime, I did it now. It serves as a proof of concept/documentation. I've kept them informed of my progress and they're happy with it.

I'm an accomplished software architect and it was a breeze. The new code is fully unit testable with dependency injection and comprehensive logging, so any bugs and problems are super easy to track down. Deploying this code is simply a right click > publish job instead of 1-2 hours of manually copying DLLS, registering COM components, fiddling with the GAC etc like the old code involved.

Whenever we fixed a bug before we'd have to wait weeks to be able to deploy it to our test environment to allow deploying multiple things at once to save time.

I should also add that the code is much simpler, easier to read, bits of functionality are contained within their own areas so it's not a case of making it crazy complicated that only some kind of savant can understand - quite the opposite, it's now modular instead of monolithic.

This rewrite was also be required in the near future due to moving to the cloud which doesn't support much of the ancient stuff.

Onto the problem - there is one developer who is extremely resistant to this change. He was the main developer previously. His ability level is average but he has done nothing to improve the previous code over the past several years, it is a case of broken window theory combined with no understanding of SOLID principles. He has also started working less and less and does not seem to contribute much anymore even though his only job is on this project.

The problem is, that in the meetings he outwardly speaks against my changes and will derail them, without good reason. He believes that as the current system works, it shouldn't be changed and that taking 1-2 hours every time we want to deploy to our testing environment is not too bad, or spending 1-2 days tracking down tiny bugs like a client missing a field on a web service call is just normal when it's the kind of thing that should take 30 seconds to resolve by examining the log files.

While porting some of the code I have also found a lot of bugs that I fixed along the way that should have been avoided but couldn't be as there is no way to write tests for the old code, nor is there proper error handling/logging. All signs point to the move being a good idea. I'm referring to literal bugs like possible null reference exceptions or forgetting to save the database after editing it, not to incorrect business logic.

I believe he is resistant because it will push him out of his comfort zone. He immediately spoke out initially before I even explained my reasoning.

The issue is that management look at both of us and doesn't know who to believe.

Any competent software engineer would look at the legacy code and immediately agree that it is unmaintainable and that hours of work are being sunk into debugging. They would agree the new code is clean, maintainable, adheres to SOLID and solves these problems while the old code is a mess and often has just giant methods that do all kinds of work.

What I need to do is explain that I have significantly more experience and have done this kind of work in the past with stellar results (I wrote all the code for a startup exactly as I have done here, and they are still using it 6 years later going from just me as the only developer to a team of 40+ people).

I'm also getting bogged down with having to write a lot of 'documentation' explaining why this new architecture is better, but it's entirely technical (talking about SOLID, unit testing, dependency injection etc) so there's not really any point as management will not understand it. Only the troublesome developer would understand, but he already understands, he is just trying to put pressure on me to derail it by creating extra work for me.

There is another developer as well who is 100% in agreement with me on everything, which helps a little. But he is less experienced, so it's a case of me architecting and him following along so he understands and is able to work on it too.

I am looking for advice on what to do about the guy. The ideal goal is that management sees the huge benefits this will bring, recognise that I am a very competent software engineer (not for vanity reasons but because I need them to trust me), and work to prevent this project being derailed.

I guess I should also emphasise that the majority of the work is completed making a proof of concept (which is really, a near-finished product - there wasn't a huge amount to rewrite and I work fast). There is downtime at the moment between project phases and so I figured I'd just write it while I had nothing to do. My only task was to document how I think we should proceed, and I was given 2 weeks to do that, but in 2 weeks I figured I could just build the new system and give the prototype as my documentation (along with a supporting architecture explanation), so I did. Everyone is happy with that including management, I haven't done anything clandestine.

I've edited my post to try and clarify the problem is with this developer because people jumped on the fact I was rewriting legacy code and assumed I was wrong for doing so. I also appreciate it is hard not to sound conceited when I say I've made everything better, but in this case, it really was bad. I'm not an amazing programmer but it isn't difficult to improve something that was this terrible.

Answer 1

The normal situation here would be for you to work with colleagues and management to argue the benefits of rewriting it, get your co-workers on board, provide documentation, provide time estimates, divide work up and tackle it. That way you get the sign-off from managers first, discuss various problems as a team and form a plan to overcome them. Coworkers will then be much more likely to be onboard with the project as a whole since they had a say in driving it forwards. If any coworkers really don't want to do it at that point, then there's little debate to be had, as a) they had ample opportunity to weigh in on the process and b) it's been signed off by management as an agreed project, so your position is clear cut.

However, in this case it seems like you've just gone ahead and done it alone (or at least done most of it), potentially alienating another dev that understands the old system perfectly well, but isn't necessarily familiar with the new libraries, tools, technologies, code paradigms and development practices you're using. Yes, there's a good argument to say he should have skilled up and stayed with the times, but in practice that often won't happen.

You then say:

Any competant software engineer would look at the code and immediately side with me

...and forgive me for saying, but that seems rather... bold. These things are rarely this black and white.

This part in particular makes me nervous:

While porting some of the code I have found a lot of bugs that I fixed along the way that should have been avoided but couldn't be as there is no way to write tests for the old code, nor is there proper error handling/logging. All signs point to the move being a good idea.

If there's no proper error handling, no unit tests etc. in the old code, then how can you verify that it behaves in the same way? How can you verify that the "bugs" you've fixed weren't actually corner cases, and no-one was relying on that behaviour? How can you absolutely guarantee that you won't introduce any critical, breaking changes with the new code? Management and customers don't really care how nice the code is, they care that it works. If it means deploying it takes longer but customers are happy and don't leave, then that's a worthwhile trade-off as far as they're concerned.

To answer the question directly here - you get management on board by demonstrating the time savings, and producing the necessary documentation and resources required to skill up the other dev and get him on board. That's not quick however - that's long & hard. In reality, IMHO anyway, you should have approached the situation very differently to begin with.

Answer 2

You've got a couple of problems here related to your lack of communication skills. I don't know how good your code is or how bad the old code is, but let's look at what you've written here.

1. Don't belittle others or come from a place of arrogance

What I need to do is explain that I have significantly more experience and have done this kind of work in the past with stellar results.

Stop looking at things like this. Appeals to authority like this will not win anyone over. It doesn't speak to the value of your code, it doesn't highlight any benefits, it literally just says "I think I'm the best at this so we're doing it my way". All this will do is piss your teammates off. Not what you want when you don't have their buy-in.

2. Ease up on the technical lingo

I'm also getting bogged down with having to write a lot of 'documentation' explaining why this new architecture is better, but it's entirely technical (talking about SOLID, unit testing, dependency injection etc) so there's not really any point as management will not understand it.

It sounds like your other teammate also doesn't understand it, so change the language a little. You need this document to not only get management buy-in, but also buy-in from your teammates. You talk about things like SOLID a lot but your average non-programmer (or even older programmers) won't know what it is, so use the term, explain what it is and explain the benefits of the framework. Then use it sparingly. Do this with all the technical terminology. You need this documentation for your manager's buy-in

3. Throw in some management point-of-view

I'm an accomplished software architect and it was a breeze. The new code is fully unit testable with dependency injection and comprehensive logging, so any bugs and problems are super easy to track down.

Stuff like this is good. From a technical standpoint. What you need to do now is translate this into management speak, which is simply following things through to their logical conclusion related to costs and return. These costs can either boil down to money or employee time (since they pay you for your time) For example:

"I'm an accomplished software architect and it was a breeze. The new code is fully unit testable with dependency injection and comprehensive logging, so any bugs and problems are super easy to track down, drastically reducing the number of man-hours required for bug-fixing and maintenance work, and therefore reducing costs involved in these labours, by both making it much easier for developers to find the problematic code and by detecting problems with new code in newer versions before they reach the next stage in the development lifecycle."

A number of other answers here also give great gems for examples of this. Work these in where you can and don't be afraid to come up with more.

4. Address your teammate's concerns

Now, let's address your teammate's argument for keeping the original code: 'It works'. Okay, maybe it doesn't always work, but it's been relied on for some years now. You can propose to management to have a test system running with your implementation concurrently with another system running the original code. Maybe even fire off a few test-cases, including some that you expect to break the original code. This way, your teammate no longer has that argument because you've proven to everyone that your code also works, and even works better.

5. Address unmentioned (but still important) factors

Let's throw in another argument the teammate might use: 'We all know the original code'. This is a little harder to shoot down because it is unequivicolly true, brings a cost impact that management understands and nothing you can do in your code can completely alleviate this. Your best mitigation is in your documentation, the same stuff that you say you're being bogged down by.

Therefore your documentation needs to accomplish two goals:

1) Persuade management of the benefits of your idea (I talked about this earlier)

2) get your teammates up to scratch (or at least as much as possible without trial-by-fire) on your code.

---

Only when you have addressed these 5 points can you get around the following problem:

The issue is that management look at both of us and don't know who to believe.

Answer 3

The customers and management don't care if something is coded well. They care about whether it works to an acceptable degree, they care about its cost, and they care about whether they get it on time.

The best way to justify your decisions is to explain then in terms of man hours and costs.

The time-saving measures should speak for themselves. If your changes save for example 2 man-hours per day, that's 10 man-hours per week or 500 per year. Assuming a completely arbitrary figure of €25 per man-hour in labour costs, that's €12,500 saved per year which can go towards more productive tasks.

If your changes mean a reduction in the amount of time spent correcting defects, that's more time you spend creating value for the company in terms of new features which customers can pay for. Customers don't pay for bug fixes, they pay for features. The less time your team spends on fixing bugs, the less money the company is wasting, the more money the team are making for the company.

Answer 4

I've been in a similar situation to yours more than once. What you seem to be missing is in code that old and messy, it's really difficult to tell what's a bug and what's functionality people depend on. It's also really difficult to see important corner cases that have been fixed. Your "troublemaker" is the one who holds most of that knowledge.

It's a little late now, but the best thing to do would have been to get him involved in test cases right from the start, and ask him about every little thing that appears to be a bug to you, and about every boundary condition. If you had done this, he would be a lot more confident that you actually understand these things. Knowledge of the "latest techniques" is not more important than domain knowledge. You need both to write robust software.

You also have no way of verifying that the system behaves like the old one. Writing tests that run against the old system is slower, but lets you be more intentional about what behavior you choose to preserve and what backward compatibility you choose to break.

So get him involved in those things now, to the extent possible. The more input you can get from him, the better the result will be, and the better an ally you'll have.

Answer 5

Show, don't tell

This is axiomatic for writing, but in all honesty it's axiomatic for the workplace too. Don't talk [theories] about the improvements you're making, show how they are [implemented] improvements. Jargon is a great way to shortcut an otherwise wordy description of what a particular structure is when talking to another domain expert, given the presumption that other domain experts understand what that translates to, but jargon is also frequently something that people who themselves don't actually understand what they're talking about hide behind. It's also a danger when talking to someone who doesn't "speak" that same jargon, as it can come across pretentiously or as intentionally obfuscatory, or even as a failure to understand the needs of the project as a whole (particularly in relation to wider business objectives) versus the view from a single member's perspective of what are effectively just one set of possible tools for working on that project.

If you've made actual, deterministic improvements, then they are also measurable.

This goes beyond merely software development, and is something you should always have a focus on when doing any workplace projects.

When pitching a project, it's fine to discuss things that are conceptual or projections made based on those concepts (but you should ideally have starting point data to show why the status quo might be a problem that needs solving, instead of just pitching solutions to something that isn't clearly a problem).

When defending a project, you want to be able to show that there are actual improvements that are being or have been achieved. This is the language at the meta level of the project/business itself, rather than merely technical tool specific talk that fails to broadly convey the import of the practices employed and choices made.

Ideally, you have data, and the strongest data is longitudinal with like compared to like (as well as can possibly be done)

How you want to approach this if you had data preceding your changes is up to you. Ideally, you would compare something that keeps things largely equitable and won't be down to vagaries of randomness.

At the same time, when we're discussing faults, faults usually aren't hit in some kind of reliable and repeatable fashion, nor are all faults equal, so this is always going to be an issue when making comparisons between before and after.

For something like this, here are some things that can be used but must have some attention to the fact that without a long enough period of time for statistical significance (and a way to determine what constitutes that in this case) you are by degrees just playing with numbers:

• Time from initial report of problem to finding where the issue is within the source code
• Time from finding locus of issue to achieving a fix
• Average time to resolve reported bug
• Average number of bugs logged per reasonably framed window of time [week/month/quarter]
• Average developer hours spent per reasonably framed window of time working on bugs

You may not have access to all of these, but your manager or the project manager for this may.

Because this isn't something where the data is going to be consistent, another approach you can take is to find comparable individual incidents both before and after the improvements (very similar fault modalities/etc), and create case study comparisons. Step through the fix process in each case, the time taken at each step, etc.

Similar things can also be done for changes related to feature improvements, if your re-architecture was successful. Keep in mind that you will want to showcase aspects which reduce faults up front and therefor are saving time in the long run. If possible show the number of faults incurred in a past feature addition or similar change, the related average time costs, and then show how the perhaps higher upfront costs of the newer methodology pay off over time. Don't just talk about the related theories. Show them as applied in context.

Lift up, don't push down

I'm not going to make assumptions about how you've been communicating with others on this, but it's fairly clear that you've managed to step on at least one set of toes. This isn't about fault, but it is about finding positive ways to either move forward or at least mitigate the situation.

This is perhaps the real underlying issue you're now going to be facing.

It's easy to find situations like this extremely irritating and stressful. While it's not necessarily fair, the best way to come out ahead is usually to remain calm and only speak towards forward looking positives rather than bad mouthing, particularly in terms of previous work. Don't denigrate the previous work, don't call it out for being out of date, just talk about the demonstrable effects of your improvements.

Sometimes you will make enemies from doing good work, and you can't control this. What you can do is try to come out looking like you have handled it calmly and maturely and been the one to reach out and try to pull up rather than the one standing there being a jerk about it.

The best approach, whenever possible, is to recruit people who may create problems to your side ahead of time. Once things have begun going downhill, this becomes tricky or impossible: the ideal time is beforehand. Show them, individually and from their perspective, how this is both going to make their life easier, not make their life harder (again, careful of jargon, even if talking to someone else in your profession when it comes to this), and hopefully involve some things they might even find exciting. This requires actually understanding them to some degree. Find out what their concerns actually are (outside of a group setting) and both alleviate them and show how this will be an improvement for them, not just for the business/project.

Ideally this isn't just about yourself, it's the type of thing where ethically hopefully we all would like everyone around us to be having a good work experience and be happy.

Note that this isn't always possible. But at least in group settings, how you comport yourself is something you have a modicum of control over, so that's the time to not talk down to someone, not denigrate anyone else's work (or concerns, or perspective, or actual complaints), and just focus on your positives.

If someone is bringing up concerns, use them as a pivot for how it was "a great point to bring up" because you'd like to address how this will be an improvement in context to those concerns. Don't dismiss the concerns. Don't invalidate the act of having concern. Do find a positive, forward looking angle. Don't bog down on details if things are getting too derailed, it's ok to say that you'd be happy to go into more detail separately in regards to a given concern, but for now you want to re-assure that in terms of the wider picture aspects of that concern, things are well addressed. Schedule a related meeting, on the spot if necessary. Defer any related derailments to that meeting. You'll probably need to make sure that whoever is supervisory to both you and this other person will agree to this in advance (and you'll definitely not want to do anything like this without them present).

This is one approach you can to take to come out looking like someone who gets things done and also handles workplace disagreements productively rather than creating headaches for everyone above you. Ideally, it's not just how you appear, but it ends up actually being the case.

One final consideration is that when you're doing things that can be interpreted to make someone else or their work look bad, take time to highlight all of the good they've done, how it positively impacts or facilitates your work, and how you are merely standing on their shoulders to take a step forward. Ideally, involve them in this: ask them to discuss some related aspect, or better yet to explain a given detail. Give them room to continue looking good in relation to what you're doing, even if much of it could be seen as doing away with their code. Find ways to change the perspective of this so that it's not about getting rid of their work.

Broader picture reflection

One thing to step back and consider is that if you have a colleague who isn't keeping up with more modern practices but has been essentially dedicated to the project, you might not be hitting the business goals you think you are.

Sure, from your perspective, this is a waste of money. It might be. It might not be. Your concerns about how much they are or aren't working from your perspective are notable, but depending on your position you may not have the wider picture in relation to this. No one is individually indisposable, but sometimes there are balances involved in replacing someone where it's not worth doing so, but where reducing the workload on that individual doesn't free them up for anything else meaningful, at which point related resources are better spent elsewhere rather than on improving whatever they've been assigned to/focused on.

It's not something I personally agree with, but it's worth being aware that there are sometimes wider political realities at stake, and upsetting the rather stable worlds of certain people might save some money but might not be worth doing from other viewpoints. Anytime you do this, you need to be prepared to show significant savings. And ideally you need to be able to do it without making someone else look bad or otherwise making them your enemy in the process.

Software doesn't occur without people. Software isn't useful except in how it serves as a tool for people. The same is true of development work. Yes, it involves telling the computer what to do. But it's also about teamwork and communication. I would say it most importantly is about teamwork and communication.

Most of the software development principles you're bringing up are, at their core, really about creating consistent frameworks serving teamwork, communication (even when working individually this is true, as it's about communicating with your future self), and basic realities of human fallibility. You've had a lapse in communication with members of your team and this friction has been a result. It's easy to be dismissive of "workplace politics" as something that people "shouldn't have to deal with to get things done" but really, what that really means is that we need to communicate with each other to move forward as a team. Ideally, this is the role of someone who is managing the team. But the reality is that if you want to be someone who gets things done and makes significant positive changes, you need to manage expectations and communication with your coworkers too. You can get your manager on your side on this, but you can't just bury your head in the sand to the necessity of it and pretend they can just handle it all alone.

It's easy to carry the pretense that principles like SOLID, TDD, etc are something that an individual can just plop down and implement via sweeping changes on a poorly coded project, but in reality doing so can effectively be self defeating in terms of the underlying goals of SOLID and similar principles and theories of software architecture. Just like the best software implemented algorithm is rendered effectively useless if no person who needs it can actually use the related software, the most well architected software is useless in terms of those architectural aspects if the team working on it can no longer do so effectively (this admittedly cuts off some other related angles for the purpose of this discussion).

Sometimes, this does point to a need for a change in personnel, but unless you are in the position to be making related decisions, it's important to remember that that's not really your choice or your position. Pushing ahead on your own, particularly if a different timeline had been developed and agreed to, might really even be the worst possible move, and you might be creating a worse mess for yourself than just the one that's right in your face, because other people might have had plans for how to handle the situation and now instead it just blew up. The point to most modern software engineering principles is to stop just pretending that code is written in some perfect vacuum, so remember, it's really about being realistic about the people involved. This includes the rest of the team.

Answer 6

I doubt you are going to make any gains on this, it's very hard to justify rewriting anything to management without delivering new functionality, it's new shiny things to play with that management care about, the more new UI involved the better. I just turned a single threaded lumbering dinosaur into a multithreaded masterpiece and nobody gave a shit because there was nothing new they could click on the screen

Answer 7

Coach The Veteran

Other answers have given good advice on dealing with legacy code and management. I want to focus on what I feel is your core issue: dealing with the original developer. So you don't see eye-to-eye on a lot of things. If you want him to stop undermining you, you need to get him on your team. Which means you need him to see the world the way you do. And the way to do that is to start out by understanding what his world looks like, in significant detail.

Read the legacy code and try to distill the patterns and implicit rules which you disagree with. Make note of these, because this is where you want to get on the same page. Then, think about why you disagree with them. Don't focus on why the legacy pattern is bad. Focus on why your replacement pattern is better, but also acknowledge the Fundamental Theorem of Engineering: everything is a trade-off. Even your "better" pattern has a weakness under some conditions. You must be able to identify and understand these failure modes to successfully argue that they are least relevant to the scenarios at hand. Once you've done this prep work, you are ready for the next step.

Pair Programming

Tell your buddy that you got off on the wrong foot, you're sorry for being an arrogant, condescending ass, and you just want to figure out how to get on the same page. Pick some code that epitomizes the anti-patterns you identified above, and look at the old vs. your "improved" version side-by-side. Ask the dev to critique the two, and give him plenty of time and space to do so. Look for opportunities to agree with him, rather than to disagree. You are trying to build bridges at this point. The disagreement is already implicit. After he makes his observations, ask leading questions to illustrated why you think your version is better. In particular, bring up code execution scenarios where your code is obviously superior. In the very best case, have test cases on hand (unit or acceptance) which illustrate the superiority of your version, and just ask him to review them.

Your goal is not to catch the guy in a trap, but to help him see the world from your perspective. And that will only work if you first validate his perspective at some level. In particular, you must be exquisitely sensitive to history. Many things which we regard as "bad" today were common, or accepted, or even good decades ago, because the technology was different, the knowledge was different, the hardware was different. Try telling Grace Hopper that "GOTO is considered harmful." She would retort: "Young man, I'd like to see you write an assembly program without any JMP instructions. Come back when you're done."

That means you can and should understand the architecture of the system in the context of when it was first built. Even if it wasn't cutting-edge technology then, it may have been built on relatively mature patterns that were later superseded. You will get a long way by demonstrating some awareness and respect for this developmental history. This is all to say the most important thing you must learn: "Code isn't good or bad. It's good or bad relative to some context." It's quite possible that if you were present when the code was originally written, you might have written it in a similar way. Just a decade ago, I was arguing with my entire team at a major Fortune 100 tech company about the virtue of unit tests. There's no way I would have that conversation today. Many things change with time.

Ask For Help

If your buddy is especially intransigent, just pick a bug to fix in a bit of the code which you have not refactored. Ask him to peer with you on it. Say: "I don't have the context to debug this code efficiently. Can you show me your approach to this?" Let him guide you using his process. When he does something that invokes tribal knowledge, make him pause and say: "Oh, does anyone else know that?" "Of course not." "Ok, because I wouldn't have guessed that just by looking at the code. Can we take a moment to document that?" After a while, the hand-holding will grate on his nerves, and he will see that just because it's easy for him to navigate the code, it can be complicated and frustrating for anyone else to do so. If you really want to drive the point home, get him to peer with the junior dev while you look over everyone's shoulder. Coach the junior dev to use the same questioning-rather-than-challenging approach as you.

If you're lucky, he will get frustrated and say something like: "Ok, if you're so smart, how would you do it?" Then say: "Well, we have a bug report that shows there is a bug somewhere in some code that I've refactored. Let's take a look at that." Then let him navigate your new code, and question/challenge you on it. Use the unit tests you've written to help isolate the bug, and let the junior dev drive for part of the time to illustrate that it's not just about him or you, but the whole team.

Ideally, if you have focused on empathy and quality, rather than judgment and cruft, then you will help him see that you've actually made valuable improvements, rather than just mucking with the system that he built over a decade. Instead of insisting that you are the all-knowing architect that will bring Goodness and Light to all code, start over with a healthy dose of humility, and let your code speak for itself. If he is a reasonable coder, he will eventually have to acknowledge that better code is better code that even he would prefer to work with. And if you can't get him to that point, it may well have more to do with your attitude than his. Keep that in mind, and good luck.

Answer 8

TL;DR: if you weren't exaggerating, then there might be nothing you can do for that project. But you could try to call it a new project and run it separately.

I have been in almost-exactly your situation more than once. I can't say you're in the right obviously since I don't know everything about your particular project, but sometimes it really is black and white as you put it, despite what others are saying.

For my first employer in my career path, I was fortunate enough to have down-time too. I kept seeing so many awful blunders by a couple of the devs that I decided to help out. They refused, but I personally was one of the people who had to deal with the fallout of their junk when people complained so I stepped on their toes anyway.

I made a better version. I was in more direct contact with the end users than the guy whose toes I was stepping on, so I even had them test it. They loved it and some switched to it.

Our own manager of customer service (a computer guy who understood the technical ramifications) said he wanted the official version replaced with mine, but the guys with seniority whined about it, my version was dropped like a rock... but about a year after I changed jobs the CTO of the old place got my number from my old boss and the CTO personally called and asked if I would come back under a temp contract to support my version of that tool! I was interested, but he didn't like the price I quoted (way less than what I know they spent on the junk version) and he never called back again.

At my next employer I got the blessing to make a "lite" version of one of their products. In about 2 months I created a version that had fewer bugs, ran way very faster even on lesser hardware, was easier to maintain and update, had better architecture documentation, and even started to become feature-richer than the original version (and some features they even wanted ported over to the full version)... until someone said "Hey, we should just replace the full version with this better one." Then bam! Suddenly the "lite" version got axed. I was put back on the full version, complete with all its hideous code smells (that's an understatement: the whole thing was the bog of eternal stench), lack of documentation, and bugs and such.

The full version actually crashed on startup a lot, sometimes requiring 10 attempts or more before it started properly, and the answer to that was to not call the software directly, but instead to make a startup script for it which just tried in an infinite loop to start it for several minutes. Didn't matter to the guy with the most seniority and his friend in management.

Sometimes there just is nothing you can do.

If your peer is truly as dense or as stubborn as you suggest and you're not exaggerating, then you might have to just abandon the idea of having his support. In that case you need to just convince whoever can make the decision and leave it at that.

If you cannot convince either your peer or the manager with the decision-making role, then it is a lost cause and you just need to get off that project. Hopefully the employer is big enough that you can switch.

Another route, though it's still sort of changing projects, is...

Sell your software as a new product

I don't necessarily mean to start up your own company to compete against your employer. That's an option, but what I mean is sell them the idea that your software could be considered "Our App 2.0" or call it a completely different software.

Microsoft has both Internet Explorer and Edge. They have Notepad but they also have Wordpad and Word, each one better than the one before it.

You can sell your software as the competitor of your peer's software even if it's the same company doing it. Then your peer can have their software just the way it is, and if nobody wants it then his project will die off on its own.

Answer 9

Present the new system

Arrange a large team\multi-team technical presentation on the new system. Demo the bug finding process using the old system. Then demo finding a bug with the new system. Ideally using actual example issues which the management know are legitimate, not some small orchestrated bugs.

Seeing is believing. The original developer will have a hard time defending the old system, when the new system is seen in action.

Then give statistics showing the quantity of bugs found using the new system over X time.

Don't knock the previous system and how bad it is. Sell the new system only and how good it is without any arrogance, which is important. You want to make friends to support the new system, not make enemies to resist it.

Answer 10

Show the time - require the reasons.

Run old code and yours and show how much time you're saving.
Show how old code would equal to rubbish when move to cloud. Show that if it will stop working the run time will be zero. If it stop working that would not only translate to more time/ work hours on fixing it but also would stop any "production".

Make them aware, to the point of personally proving it, that a bugged old system is much more vurnerable to exploit.

You basically need to prove that the system is not working. It's just "running". And even a small pebble will crush it.

Answer 11

If it becomes necessary for you to “help” management know “who to believe,” suggest they read this QA thread.

But keep your résumé up to date—I am certain that one of the causes of my lay-off was cutting compile time and executable size in half by an approach that a “more experienced” colleague had told management was impossible when I recommended it.

Answer 12

One of the answers already hit close to what I wanted to say, but I think it's worth condensing, so I'll keep this brief.

Managers, especially non-technical managers, like figures. They like graphs. They need hard numbers which can justify their decisions. This is all you really need to show them.

Put together a couple of slides showing (where possible):

New vs Old deployment time
Frequency of bugs with time
Time to fix bugs 

Things of this nature. Get a couple good statistics together, keep it short and uncluttered, show it to management, and you're guaranteed to have their attention if your contributions are as impactful as you claim. This is really all you need to do to convince management. The rest of the answers are primarily about office politics, which I advise avoiding in cases where you can demonstrate your point with solid numbers/graphics. Don't worry about the other dev, once you've convinced management the onus is on him to get over himself or find another job.

Answer 13

Sorry for such a concise answer, but here is one simple and important thing I learned from my past experience that I'm afraid you are missing:

Consistency is important