Watsonx: IBM's code assistant for turning COBOL into Java

That happens, but what also happens is that everybody is painfully aware of the situation and they do the best they can. Just like you or I would.

And of course, if you start a bank today you'd do the whole cycle all over again, shiny new tech, that in a decade or two is legacy that nobody dares to touch. Because stuff like this is usually industry wide: risk adversity translates into tech debt in the long term.

I suspect that the only thing that will cure this is for technology to stop being such a moving target. Once we reach that level we can maybe finally call it engineering, accept some responsibility (and liability) and professionalize. Until then this is how it will be.

Why would software technology ever stop moving? To a first approximation it is unconstrained by physical reality (unlike other engineering disciplines) so I expect it will keep moving at roughly the same rate. Maybe even accelerate in some areas.

Individual organizations can consciously choose to slow down. Which works for a while in terms of boosting quality and productivity. But over the long run they inevitably fall behind and an upstart competitor with a new business model enabled by new software technology eventually eats their lunch.

> if you start a bank today you'd do the whole cycle all over again

It is worth noting that we now have much better processes and tooling than software developers had in the 60s. Some Cobol systems predate the invention of SQL or database normalization (3NF, BCNF, etc). Never mind the prevalence of unit testing and integration testing, automating those tests in CI, the idea of code coverage and the tooling to measure it, etc. Programming languages have also come a long way, in terms of allowing enforceable separation of concerns within a codebase, testability, refactorability, etc.

Sure, you can still write yourself into a codebase nobody wants to touch. Especially in languages that aren't as good in some of the things I listed (say PHP, Python or JS). But it's now much easier to write codebases that can evolve, or can have parts swapped out for something new that fits new requirements (even if that new part is now in a new language)

We have better processes but we don't necessarily have better programmers, and better tooling is no substitute for that.

Tech debt is can come from risk adversity or from taking risks on new shiny things. I think you're right that as long as technology is a moving target, it's always going to be there. To me, the trick is not cornering yourself in a situation where your whole ecosystem is essentially abandoned and not rewriting for the sake of chasing the latest craze. That means parallel re-development, from scratch, of all the existing features, on something like a 10- or 15-year cycle. You want to pick a technology you're certain won't sunset in the next 15 years (with upgrades and further development along the way, of course), then spend a couple years rewriting everything in parallel while still running your old system, test it in every way possible, then blue/green it. I've done this three times in my life for one company on the same piece of large business software.

Companies should think of their software the way automakers or aircraft manufacturers think of their platforms. Once new feature requests are piling up that are just more and more awkward to bolt onto the old system, you have another department that's already been designing a whole new frame and platform for the next decade. Constantly rolling at a steady pace prevents panic. Where this breaks down is where you get things like the 737 MAX.

One thing the parent's post suggests, though, is that we do have better standardization and interoperability. Data normalization is a problem that has largely been solved. So is reading and writing data at scale. Once you've gone to SQL, you presumably won't ever need to go to some other database language or drastically restructure your data in order to rewrite your backend or frontend next time. Similarly, there aren't fifty different schemes for serializing data anymore. JSON is "good enough", every language can now parse it and probably will for the next hundred years. So parts have become more interchangeable. The burden on experienced programmers is less, and it's easier for novice programmers with a shallower base of knowledge to work on pieces of a project even if they don't understand the whole thing. In this sense, tech has become less of a moving target.

That makes perfect sense. Extra points if you designed the system to be replaced in time.

We have significantly worse programmers, that’s what better languages and better processes enable. People that would have washed out when the only option was bit twiddling and pointer chasing can now be productive and add value. That’s what progress looks like.

Hahah. The last one was a close call, since the entire front end of the system from 2009-2020 was a responsive single page app written in Actionscript 3, to replace the old PHP page system... but we saw the deadline looming about a year in advance and accelerated it.

Software technology moves when we figure out new ways of doing software that bring some kind of advantage. If no one is finding new ways to do software that have any purpose, technology will stop moving. Physical reality doesn't really have anything to do with it - we're limited by human ingenuity, and possibly by the mathematical space of algorithms (though that's likely to be much larger).

For an example of this happening in a field, look at the glacial pace of advancement in theoretical physics for the last few decades, compared to 1900s. Or at the pace of development in physics in general in the centuries before.

Software trends seems to repeat themselves as we forget the lessons learned a decade ago. It’s more like fashion, in that sense.

You don't need better programmers to maintain a js project, you only need hireable programmers.

Tooling and processing definitely helps, I have seen it with my own eyes!

(1) Start with experienced programmers who know how to write code

(2) Have them establish good culture: unit testing, end-to-end testing, code coverage requirements, CI (including one on PRs), sane external package policy, single main branch, code reviews, etc...

(3) Make sure that there are experienced programmers have final word over what code goes in, and enough time to review a large part of incoming PRs.

Then you can start hiring other programmers and they will eventually be producing good code (or they'll get frustrated with "old-timers not letting me do stuff" and leave). You can have amazing code which can be refactored fearlessly or upgraded. You could even let interns work on prod systems and not worry about breaking it (although they will take some time to merge their PRs...)

The critical step of course is (3)... If there are no experienced folks guiding the process, or if they have no time, or if they are overridden by management so project can ship faster then the someone disables coverage check or adds crappy PRs which don't actually verify anything. And then formerly-nice project slowly starts to rot...