It sounds like there are issues that aren't "code prettiness / maintainability" but rather "user can crash app / trash data" (e.g. SQL concatenation or entering bad data causes the app to crash). Hopefully OP can demo some of these to management and at least get those fixed.

I'd suggest @TheDemoLord that you read the entire problem statement. Other than that I pretty much disagree with almost everything you said. And I've been writing code for more than 33 years.

Speaking of business case, changes to improve maintainability is a good business case. Most software programs spend 80% of their lifetime in maintenance, so reducing maintenance duration will save money.

I think people are missing the point I'm making. It's not to say that code beautification is bad or that critical bugs are the only thing of importance - It's that you should be presenting the business case as to why what is being done/not done requires effort to fix. What is the time spent cleaning up? The user churn from bugs? The delay in resolution etc. Make the business case to management as to why they should care about these issues.

There is a big difference between "the UI is slow" and "the UI is freezing up" which it sounds like what the OP is talking about. Users definitely notice when the UI freezes up (e.g. for more than 1 second) and it doesn't respond when they click or type, so it's a business/product issue at that point.

@boatcoder Maybe in those 33 years you've never worked for an employer who has said "Yes we're fully aware of all these defects in the software, the business is running just fine and we're making a profit. The defects don't impact or disrupt our users in any meaningful way, we have no business case to pay for changing or fixing them. We're totally fine with that. We really need this new feature ASAP though..."

"Your code is difficult to read" directly translates into "working on anything around this code will take X amount longer because your code is difficult to read"

And abusing the 'because there isnt a business case for it' answer is a great way to end up with a shitty code base that is difficult to update and nobody wants to work on

@TheEvilMetal on the other hand, devs who run around saying "we need to maintain high standards, cost for the company be damned" do a lot more damage to a company than a few bugs ever could (and if you argue that high standards make more money and have proof for it, then you have made a business case, which is what DemonLord was suggesting).

"And abusing the 'because there isnt a business case for it'" - It's about selling what you want as something that management wants. Then you may get what is neccessary. You need to speak their language.

Unit Tests? Anying testing? If you're using them for your code, and try couple on the easy to crash inputs. Let the tests do the talking.

+1 after the asker's edit (at the bottom of his question), where he says it's an internal tool. If something is a quick one-off used internally by a small group of people, then it may well be getting the tool out the door quickly and never seeing it again is the extent of the ask, and the primary coder is cutting corners with intent. You should see some of the python tools I wrote for myself. Horrifying really. But then, only I use them.

""The UI is slow" isn't a business case either." -- and here we have a nice one-sentence summary of why so much software is total garbage. Honestly, if I give someone the requirement "when the user clicks the button, the software does X", and they come back with "ok, but you didn't say it had to do it at any particular speed!" they're gonna be out on their ass.

@GlennWillen - I get your sentiment, the practical reality, however, may differ. If a 1 second increase in load time leads to no user churn and no decrease in functionality, but requires a full 6 month rebuild and re-architecture, then it's not going to get traction.

There's definitely a balance to be struck. Some of it's just personal philosophy, and mine is definitely more aligned with OP's than with yours (but I accept it being a matter of taste.) On the other hand, I think there's a difference between "deliberately spending less effort, and accepting worse results" versus "being sloppy to no benefit" or "just having no idea what you're doing". OP's coworker does not sound to me like they're on the efficient frontier of effort versus results, as it were.

This makes a point that, as far as I see, many commenters are missing; and this also shows the difference between coding a piece of software vs coding a bussiness solution. Yes: writing great code is an art on itself, and a skill that programmers should always look to thrive for; but when you're coding a bussiness solution, UNLESS performance and software maintainance is critical, code quality comes second - sometimes third, as "solving the issue" is always first. And yes, this can kill a programmers' soul, which seems to be the case for OP's coworker, but that's another issue on its own