Do you two have a manager who cares when customers complain about the product ?

There's an old saying: "20 years of experience, or the same year 20 times?" Someone who doesn't want to grow or change might as well be replaced by documentation, manual pages are a lot cheaper.

This is not even about "new ways of coding". The things you mention where already wrong 20 or 30 years ago. So your issue is probably not that you are dealing with an older person, the issue is that he was mediocre to start with.

@DaveG I have tried a lot of stuff, even showing him how I can execute random queries trough input fields in his app, but I am always met with "Who'll try that?!" It is really annoying especially when a random ' can crash your app.

It sounds like there's some context missing here - if the app can crash or fail that easily, then why isn't senior management complaining and asking for improvement? Do these problems ever actually manifest themselves in bugs reported by users? Are those bugs recorded anywhere and prioritised to be fixed? It's generally not for developers alone to decide whether UI defects are acceptable or not; if the people who pay your salary don't care then your co-worker may be "right" from the point of view that the business is unwilling to pay tor more robust software.

Is the colleague still doing the bad practices in new code, or does it only appear in the old codebase? It will be harder to force a complete refactoring of the existing code compared to adjusting the style for new work. At some point the improvement will become apparent and you might force through a cleanup.

@Chieron it is manifesting in new code as well. Depending on how annoying I get, he may change something sometimes but it usually is the same stuff all over again.

@BenCottrell We are a wholesale business. Our supervisor, the head of IT is an administrator, doesn't code, doesn't understand the process of coding. They are happy as soon as they see something working. This usually means pressing the right combination of buttons at the presentation and then releasing the thing into the wild where it usually suffers a horrible death.

@CodeJunkie What do you mean by "suffers a horrible death."? Is it something that actually impacts the users or the business in any meaningful way? is it costing money/reputation or noticably affecting the ability to get business done?

@BenCottrell It means that when the end user gets to use the application, it is usually unstable and an unfinished product. This does not directly impact any financial income but it does have an impact on the time it takes to do stuff in the app as well as time to fix the reported bugs later on, interrupting other projects etc

@CodeJunkie in which case I'd suggest focusing your effort on building the business case; gathering data to measure how each incident of a software failure affects users. I would strongly encourage users to actively raise and record each separate occurrence; including the severity and impact on their job, so you know how much it affects business operations. Encourage duplicate bug reports if the same problems are frequently recurring so that you can measure their frequency, build up a picture of costs to the business over many months, and also record your own time investigating/fixing bugs.

From a business perspective, code quality and software quality are separate concerns. Software quality affects a business in ways which are directly measurable, and can be attributed to things that owners should care about around productivity, person-hours, risk of loss or damage to the business, risk of impacting customers and ruining reputation. The analysis might reveal a root cause as "bad code", but if the business doesn't care about software quality then they sure don't care about code quality. The first challenge is to explain to the business how software quality affects them.

What tools are you using here? Those names sound suspiciously like a RAD, possibly Delphi, and my experience is that here are very real issues trying to decouple the frontend and backend (in short, sessions are held open far longer than is good practice).

@MarkMorganLloyd I am a Net developer and mainly focus on developing desktop applications, but I've meddled with mobile and web development quite a few times also. He is using Delphi and intraweb to build a web application that compliments the desktop app I am working on. The desktop app is for management, while the web app is used in the stores. That was a pretty good guess tho! We both also admin our data warehouse systems and DBs

Learn from his experiences before criticizing. There might be things you do not know yet.

@ThorbjørnRavnAndersen I completely agree with you, that is why I asked how to handle this without being condescending. I am completely aware that no one can know everything, but some of the stuff he does like query concat is something that died decades ago and I think should be inexcusable in modern code (in respect to the case it is used in).

The reason why "query concatenation" is considered bad, is because if you trust data that for some reason cannot be trusted - like coming from a web form - bad people can do nasty things. What if the senior developer considers data to be trusted so these things cannot happen? "naming is important" - yes, but it is also hard. "no exception handling" - well, the users learn fast and the code works as is. So what has changed since you came that warrants changing working code?

@ThorbjørnRavnAndersen Like I mentioned in my post, the end users are employees that are not digitally educated. Their job is to work in the store, our job is to make that work as automated and as time efficient as possible. If we deliver a product that underperforms they are not being efficient and going back to manual labor. That means the time we put into creating the app is wasted and that means that further projects get delayed and so on.

@ThorbjørnRavnAndersen as for how competent the end user is. As with anything new, they need time do adapt to the change. Working on a product that will randomly crash or crash if you enter anything other than the expected input is silly to even talk about. We are talking about housewives, mothers, grandmothers here. They are selling fruits and veggies, you can't expect of them to know how to work around an error or anything similar. Any input is prone to input errors in this environment thus error handling should be handled accordingly.

@CodeJunkie Well, it never the less is what you have. Somebody must have the final say about how this software should work - what did he/she say when you reported your findings?

@CodeJunkie Yes, it /was/ a guess but I feel that unimaginative component names is rather a "Delphi thing": regrettably inherited by Lazarus. In general it's a perfectly usable "4GL" (to use a 1980s name) but as I've said I'm unhappy about the way it uses the database.

We tried some cross platform development with Delphi and it is more or less "meh". We switched to Net MAUI instead which is quite a bit better for our needs

What you say about the users is reasonable, but if your boss/employer doesn't care, then the subtext really is that the company's standards are rock-bottom and nothing can improve before that changes. It seems that you're not really employed to write good code or deliver good software here; as it's acceptable to deliver broken rubbish riddled with bugs. I'm inclined to think your co-worker has realised and understood this; their own standard of work seems more like a symptom, and something that can't be fixed for as long as this exceptionally low standard is enough to keep the boss happy.

@BenCottrell I think they really do care, but we lack a good hierarchy in our management. The higher ups(or up as in one person) are overwhelmed with information by all of the different sectors that it's almost impossible to track everything. The company went trough scrum and agile management recently so things are starting to get more organized and efficient. I hope this will bring to attention the problems we face (and will face) from outputting bad software.

If the other worker won't learn async, could you use background workers instead?

@AndrewMorton whatever the thing is, if he hasn't learned to use it yet or he simply does not wish to use it, he will refuse and dismiss it completely. I can't stress that enough. Again, the end user is someone who has 0 idea about software or computers, they work off what they are told, and when the thing you tell them to do does not work or freezes up during loading times with no indication they get confused and you get a reverse effect of what we are trying to achieve.