My first job was writing simple glue scripts that talk to a database for a small biology lab, to help them keep track of their samples and orders. It was ancient. I was so grateful to have the job. Man, I was happy.
This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".
The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.
What makes you think the hypothetical rewrite on a new technology is going to have any less technical debt?
By the time you get to feature parity with the old shitty system, your new system is also going to be shitty. In my experience, technical debt comes from three places.
1. The people who built the system didn't know how to do things right the first time.
Solution: Employ experienced people when you're building the system, the first time. If you didn't do that right the first time around, have experienced people rewrite the bad parts.
Non-solution: Rewrite the whole thing in a new technology that nobody is experienced with. (On average, your new team isn't any more skilled than the team that built the original system.) Waste time rewriting the parts that aren't bad.
2. The problem is actually incredibly complicated, and has no clean solution.
Solution: Don't do anything.
Non-solution: Rewrite the system, re-discovering all the reasons for why it was built the way it was.
3. Most of the system is actually fine, there's just a few bad parts.
Solution: Refactor the bad parts.
Non-solution: Rewrite the whole thing, even the parts that are maintainable.
--
I have seen a lot of painful rewrites, but I've never actually seen any featurefull software project that did not have a lot of technical debt.
Technical debt is always a problem. But generally I prefer refactoring existing code rather then rewriting to address technical debt, because I think the old system is well understood, and the deficiencies are known. When you blow it away, you are also creating more technical debt, but you just haven't discovered it yet.
This isn't to say "never rewrite". I am saying we rewrite way too much now.
This is the 99% of programmers who are a lot more grateful to have a stable API that reliably works than they are worrying about "obsolete languages".
The more time I spend in this industry, the more I begin to think that developers are really not the friends of users or even of their employers. Developers hate maintaining code they didn't write, which is the most important need most businesses have, as well as the most important need customers have. This creates a real tension where companies, especially as they become a monopoly, tend to lose the customer focus and start focusing on internal constituencies. And in a tight labor market for devs, that usually means mass rewrites, rolling out complicated ambitious new frameworks and models, rather than, you know, adding features that customers use to existing code.
The result of these rewrites is generally something with fewer features, an unfamiliar interface, and more bugs than what preceded it. Joel Spolsky has a nice article about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...