But it solves the problem users want solved. It's lego-level blog assembly, which is as technical as many users want to get. A much "better" system - maybe a nice type-safe Haskell static HTML templater with a command line build system - wouldn't.
Flipping this around, from the user's POV, "I wrote some code that almost does Thing X" is not a solution - it's just some code that doesn't quite do the job.
It's nice that it uses functional programming or formal methods or $shiny_language or ML or whatever. But if it doesn't do the job, it doesn't solve the problem.
never again.
Yes, there's backwards compatibility to maintain, but surely some of it can be contained, maybe with shims, like Windows does it.
In all likelihood, because the people maintaining Wordpress are the people who created it in the first place, and they don't know any better.
Why did PHP apps suffer from SQL injection attacks, long after PHP supported prepared statements? Why do Java apps often have ridiculous classes like AbstractSingletonThingFactoryFactory? Why does the Javascript community (still) promulgate useless leftpad-like packages? Why do Ruby apps often end up so heavily metaprogrammed that you can't trust any line of code to do what it says?
Cultures are hard to change. The people that are turned off by Wordpress' programming style probably pick other projects and other communities. Lots of the folks working on Wordpress probably cut their teeth in that codebase. They might not like it and they might realize there are better ways, but there probably isn't a critical mass of them that share a vision out of the morass.
Personally, I took one brief look under the covers of Wordpress and immediately decided to avoid it.
https://old.reddit.com/r/webdev/comments/bx51vk/we_need_to_t...
I was expecting to see some ill-advised use of WordPress in a critical software system, but no, it's about inconveniencing web developers. </rant>
That's what I think of when I hear technical debt.
What are examples that make sense and don't just explode in your face?
In your particular case, that MS Access DB was almost certainly the right choice when it was written, and the gotcha in that story is that they didn't start planning the migration away from Access until it was too late — effectively, they didn't pay off the tech debt when they should have, and got foreclosed on.
Our code wasn't built to be generic enough to be able to work on anything but Facebook. So what we did was simple: copy the whole project, change the stuff that didn't work right.
The next time a social networking site released a platform we refactored our main code and introduced the proper abstractions so we could use it on all 3 sites. That code ended up working for most of the other social networks that launched an app platform.
I don't think it's the type of debt that's the issue, as much as how you manage it.
I hate this term, because worse isn't better, it's worse. But good enough is good enough and technically-better-but-not-available-yet is worse than adequate-and-available-right-now.
[0] about that, there seem to be a 'foot in the door' effect at play. If you get users with a good enough but imperfect product, they won't mind too much if you take responsibility for problems when they arise. Another instance of worse is better.