[wildmusings]

I used to work on Windows and would pretty often edit source files that were written over 20 years ago, sometimes by the guy four levels above me in the chain of command, back when he was an individual contributor. I actually preferred the C and older C++ components, with no exceptions and manual memory and error handling, to the "modern" C++ components.

I recommend Raymond Chen's blog, The Old New Thing, for some cool stories about how and why ancient Windows/Office components were written a certain way, and what the effects down the line have been. Among other things. https://blogs.msdn.microsoft.com/oldnewthing/

What you're saying is probably more true in the web dev world.

[swsieber]

Heck, I work on a web product, and I regularly work on code a decade+ old. None of the developers who wrote that code are around anymore, except for the heads honcho. It always surprises me when I go to use git blame to see code that old (going to git blame to get a better understanding of the purpose), and at that point it's was actually an svn commit I'm looking at.

Fun times. It shouldn't surprise me that since the code from that time uses Hungarian notation.

[lj3]

> What you're saying is probably more true in the web dev world.

Any world in which OOP is the primary paradigm. Then again, I've seen truly horrid procedural code as well. Do you have any specific ideas on why the code you're working with seems to be the exception to the rule? Or is it pretty much all in that blog you linked?

[wildmusings]

A few things come to mind:

- Windows is (mostly) a platform, not an end application. So you need...

- Backwards compatibility. It is a pretty hard requirement, as one of the major selling point of Windows is that your existing stuff will keep working. Programs targeting 16-bit Windows from the early 90s still work on Windows 10 (though they recently removed the 16-bit subsystem from 64-bit Windows). I believe it's the same with Office document formats. You already have the code that handles all of the old APIs and functionality, so...

- If it ain't broke don't fix it. The old code has been thoroughly battle tested. Obscure edge cases have been addressed. Bugs have been fixed over the course of many releases. There is no chance that your rewrite will avoid regressions, and you'll almost certainly introduce new bugs too. It's better to make necessary changes to the old code than to try to start from scratch. And...

- It's a lot cheaper too.

Joel Spolsky has a great blog post about rewrites: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[watwut]

I have seen or worked multiple still maintained projects way older then 5 years - with parts of old code still there. Most of them in java or .net.

[reitanqild]

5 years old Java code is really no problem as long as it uses maven as build tool (and don’t use long deprecated code generation tools).

This is the main difference l see between maintaining old Java code and e.g old Delphi code:

In maven/java I can run a couple of commands to build it, open it in any of my three favourite IDEs (Netbeans, IntelliJ and Eclipse in that order) and it just works.

In other languages there is often some dependency hunt involved before you can even start. Bonus for dependencies that must be installed using .exe installers, in a specific order (hint: if you don't get it right - good luck with cleaning the registry before trying another installation order.)

I might have been very unlucky in my encounters with legacy code in other languages but so far every encounter makes me love the Java ecosystem more.

(Although I'll happily admit that parts of it might be related to the fact that Java developers seems to avoid using non oss code to a much larger degree than anyone else - maybe except from php and js devs?)