On some level, you gotta give 'em credit for trying.
A couple of years ago, they tried to recruit me into a platforms/SRE role for their consumer banking services. There seemed to be a pretty clear desire to Modernize All The Things! to do things the way Google/Facebook/etc. do it.
Story time! Years ago, I was a contractor writing (a small piece of) software for DBS. It was probably a couple of hundred lines of Java, and I probably delivered it by emailing a zip file to someone. I don't recall their code review standards being particularly ... existent.
Mine was a relatively small project with them.
There were other teams at my firm working on larger projects at DBS. Another story! A new employee joined my firm, and - on his first day - was sent to join one of these teams onsite at DBS. His day ended at 9pm /on his first day of work/. He gave notice on day two.
The DBS UX is absolute garbage. Their android app is extremely slow, and is full of (probably?) iOS patterns. It's almost like they decided to implement their own cross-platform framework, but poorly. (I apologize in advance if they are in fact using someone else's cross-platform framework, but poorly.)
Oh, and their web internet banking doesn't allow pasting passwords, because that's how we do security in 2021.
I've written software for them in the past. I... wouldn't say they have high standards. At least when I was working on systems like this (many years ago), a worrying amount of code was written for them by overworked contractors like myself.
I've always understood tech debt to be the shortcuts we take along the way to ship fast(er). A global variable here, a hardcoded constant there, that copy-pasted-slightly-modified function instead of adding a parameter.
Fixing those things seems qualitatively different from the maintenance examples.
I've tried Eclipse Che (listed in the article), and it's pretty good. I'm looking forward to Che switching its editor to Eclipse Theia, which promises to be "the VS Code experience in the browser".
At a previous company, we got burned using UUIDs as MySQL PKs. Turns out MySQL keeps data on disk sorted in PK order, so even a moderate INSERT workload would lead to lots IO and disk thrashing as pages kept needing to be rewritten.