They might not agree that I've done things in the best way, because software devs never totally agree :-) but they would agree it's a significant improvement. I can be certain because I'm porting some of it across and it has things in that would straight up throw unlogged exceptions under certain circumstances. It's not so much a case of behaviour but the application would straight up crash. For example, I'm working on something now that has no null checking even though the database has null values in, so it'd crash. Another part that does x =x (literally setting x to itself). etc

@NibblyPig "Better" software is just software one prefer over another. To most devs, their own code is better. It simply is.

I'm in a company where a lot of code is inherited from someone who isn't even a professional developer. We are working on technologies even older than yours. We almost never rewrote anything. The company is hugely profitable. I could be fired for rewriting things in my work time instead of working in due tasks. Berry has it correct: if necessary get the management to agree, then rewrite as a team.

"No true Scotsman would look at the code and not side with me".

I appreciate all of that, but if you walk into the room and it's on fire, do you shrug and go 'heh, legacy code' and proceed to work while you choke to death on technical debt? I think the key difference here is that it's ongoing work in active development, not legacy code that has no need to be touched. I'd never touch something that was working or not otherwise causing a problem. But if every time we get any kind of problem, there are no logs or indication anything has gone wrong except an angry client 2 weeks later, the solution is not to investigate for a week, fix, and carry on.

@ArthurHavlicek That’s absolutely not true. Sometimes software is objectively better: Less buggy, faster, easier to understand, easier to test, etc.

Sometimes things really are this black and white. I'm cleaning up after a rockstar "senior" developer who wrote console apps that crashed multiple times a day and filled our customer database with garbage, turned 500ms page loads into 45000ms page loads, booted users out of our ERP by writing an integration that failed to dispose its user sessions, caused data loss and filled our logs with error spam because he was using EF DBContexts incorrectly... I could go on. Thankfully he's gone, and now I'm the rockstar for fixing all these things he told everyone couldn't be fixed.

"These things are rarely this black and white." We should be cautious yes, but I've seen them be this black and white enough times that I don't think "rarely" is appropriate.

Good answer, but I'm seriously confused by the sequencing in the first paragraph: "get your co-workers on board... then coworkers will essentially have to get onboard". So which comes first, getting support of coworkers or managers? Recommend you clarify that paragraph.

He said he went and did it with management approval, since he is on downtime.

Don't forget that some of those bugs may be 'features' that other units are expecting to fail or generate particular results that will need to be adjusted (like undocumented windows calls)

The OP's comment was incredibly painful to read. I've worked with 'experienced software architects' and my software program is STILL paying the price, 7 years later. The condescending attitude and the 'tis but an easy key stroke' statements will beyond piss your coworker off. How do you know the system works exactly as before? Because you wrote it? That's not an answer. And that's all I've read- we'll just push a new release! I... I wish the OP well in whatever career he goes to, but I hope to never see him at my company.

@DanielR.Collins Yes, that didn't really read how I intended. I've now reworded it.

@NibblyPig Of course you don't shrug and carry on - you make it better. But there's a massive chasm between "do nothing" and "rewrite the thing from scratch on my own in a way I deem best and then try to get everyone else on board later". I'm advocating something in between here - notably talking with your coworkers and management, starting a dialog, weighing up pros and cons of each approach and then deciding on a way forward together, before starting work. I really don't think that's as ridiculous an approach as you seem to be suggesting.

@J.Hirsch Who said “‘tis but an easy key stroke”? Sounds to me like you’re just attacking a giant strawman. “And that's all I've read” Clearly you haven’t read very far, then. The OP went into detail about why the codebase needed improvement, and you’ve rashly dismissed it out of hand. “I hope to never see him at my company” Rest assured that with your attitude the feeling will be mutual.

@user76284 OP said in the question, "I'm an accomplished software architect and it was a breeze" which is only semantically different than "'tis but an easy keystroke". I believe he's trying to make a point that most people who approach this situation by taking it upon themselves to make the changes they deemed necessary don't make good members of a solid team. That's not to say OP is wrong in their judgment of the code, just that they went about it in a way that was guaranteed to cause contention with the teammate and believe the teammate is the only one with the attitude problem.

It seems that everyone has had a horror story therefore somehow I am the same as the people in the stories. All I've done is take the core of awful code from 15 years ago and written it in a nice way. It's better. Seems hard to accept that, perhaps I'm not humble enough? It's not amazing but it is fully unit tested. The legacy code wasn't even testable, it was just giant methods that did 30 things and swallowed any exceptions without logging them. Bit harsh to say you never want to see me working at your company.

My belief is partially that sometimes you can't please everyone. Most people seem to want a solution that makes everyone happy. But when one person is stuck in the mud about change, there are limits. They neglect the fact that everyone else is on board and that this change is necessary due to needing to move into the cloud in the near future.

@NibblyPig "this change is necessary due to needing to move into the cloud in the near future" So the correct way to resolve this is to talk to management and explain BEFORE you do the work, what you want to do, and why it's essential. It is then up to them to schedule in the time. Now what you've done is rob other projects of your time because you presumed to know the priorities of the company; and then try and defend your actions in retrospect rather than just get the go-ahead to start with. Part of being in a team is to explain what you PLAN to do, not just what you've done

That's not true, as I said it's currently downtime at the moment. There is no work on. I've done this off my own back. Also I haven't replaced the existing code, I've written it separately as a proof of concept, with the consent of management. I've already told them, got agreement. All of these points are in my original question.

@user76284 It's fairly hard to define the objective value of software, which is close to art, so I suppose here you restrict the objectivity to company best interest. I believe it can be in company best interest to keep a software that is easily tested and understood by the team because it's theirs and already there, than a code that is foreign but respects more advanced quality standards. By that definition you could say, the existing software is often "better".