In some places the web GUI was precisely designed exceptionally well, items placed together precisely, all designed expertly around the specific domain of concern.

On the other hand, there were race conditions, corrupted data, sql injection, mountains of source files that re-implemented the same things, IE6-7 era compatibility issues, etc.

Then there was the mysterious parts of the program which I never understood, like the auto-email capabilities whose scripts could never be located, mysterious mirror servers that I would figure out existed by looking at the ip addresses of odd requests, little bits of domain logic which I would accidentally break and have to cobble back together.

In a lot of ways, many of the problems just stemmed from age, it was an early 90's application in an early-2010's world. There definitely were some not ideal software development practices that contributed to difficulties as well. But I still had a sense that the previous developer had crafted this beautiful, unique, intricately complex and inter-dependent little world.

Sometimes I was sad I had to brush all of that aside even when my changes made things more robust, reliable and compatible with the modern world.

The hope is that as time passes, the generation that had first-hand experience with the old thing will die off and the new generation will re-discover things unjustly forgotten.

Certainly, but it's the kind of cost that comes with having a lot of users, so it falls into the "nice problem to have" basket. If you've got no users, you have a lot more freedom to throw things away.

I understand where you're coming from, because I also do mostly-sole-maintenance on a large codebase with all the issues that come with a 20 year legacy. One strategy that can work in such a situation where you can't maintain perfect backwards-compatibility forever is to boil the frogs slowly - gradually deprecate and remove features over a longish time frame, because a single changed or missing feature is easier to adapt to for the userbase than a whole slew at once (many people probably don't even use the feature and won't notice).

I worked on a periphery of a big mainframe system that was designed and implemented before I was born. I think release 1 was in 1975. It still runs really well and is hard to displace because operationally, even though the people who understood it fully are retired or dead, they left behind strong materials so a moderately intelligent person can run everything.

The “other” systems, old .Net, Java, etc that support the interfaces to the old app are hot garbage, and tend to steal the budget dollars that are needed to migrate off the 1970s stuff. My team had to fix one of these… argh.

What we have now is frequently a mystery. Simple changes are difficult, difficult changes verge on the impossible. Every new feature requires reverse-engineering of the existing code. Sometimes literally 95% of the time is spent reverse-engineering the existing code (no exaggeration - we measured it); changes can take literally 20 times as long as they should while we work out what the existing code does (and also, often not quite the same, what it's meant to do, which is sometimes simply impossible to ever know).

Pieces are gradually being documented as we work out what they do, but layers of cruft from years gone by from people with deadlines to meet and no chance of understanding the existing code sit like landmines and sometimes like unbreakable bonds that can never be undone. In our estimates, every time we have to rely on existing functionality that should be rock solid reliable and completely understood yet that we have not yet had to fully reverse-engineer, we mark it "high risk, add a month". The time I found that someone had rewritten several pieces of the Qt libraries (without documenting what, or why) was devastating; it took away one of the cornerstones I'd been relying on, the one marked "at least I know I can trust the Qt libraries".

It doesn't matter how smart we are, how skilled a coder we are, how genius our algorithms are; if we write something that can't be understood by the next person to read it, and isn't properly documented somewhere in some way that our fifth replacement can find easily five years later - if we write something of which even the purpose, let alone the implementation, will take someone weeks to reverse engineer - we're writing legacy code on day one and, while we may be skilled programmers, we're truly Godawful software engineers.

There's also the idea NOT that it was bad when it was written 30 years ago, but that 30 years of patches by people who didn't write the original code mean it's no longer clean code.

Also the quality of the test suite makes a huge difference in combination with the willingness of developers to refactor. No testsuite automatically means no refactoring. With a testsuite the question remains whether the organization penalizes or encourages larger code changes (sometimes with old code bases managers demand pinhole-surgery only).

And then there is this funny thing that perfectly acceptable code bases age without a change to their code. Idiomatic C++ code from the 90ies is from our perspective not clean, even if the person who wrote it was a dedicated and smart programmer following the best practices that they could get a hold on.

With functional code bases you might see similar patterns. A Haskell person of today may look at an older common lisp code base with similar reservations as a java programmer to the visual basic 3 app.

I just sat down and wondered how a tech stack potentially used by a startup could age. In the future i think we will see much more dependency problems. When you get to maintain a Django/nodejs/ruby on rails application, you always take pypi/rubygems servers for granted (or your local mirror on artifactory). Think about the time in 40 years when the dependencies are not available. Or the small languages we sometimes see and still are able to find tutorials for, how will it feel to take over a Lua codebase in 40 years? I hope that enough docs stick around, but already when I browse the web on Smalltalk stuff most links are broken because actually information can disappear from the web.

Or database technology. How will that NoSQL db appear to a maintainer in 30 years?

So while today we are unhappily having to maintain software that was written without version control, it may be that future generations will have it even worse because they dont even have a monolithic code base in front of them but something with dependnecies they cannot install anew anymore.

I have projects that are 10 years old. The code isn't unusable, but I know I can do better. Sometimes adapting the old code just makes it ugly, hard to maintain, and error prone. So when it makes sense, I usually start fresh.

I'd say, yes, there are a lot of lessons buried in old code, but often, there is an equal amount of baggage we are too fearful to abandon because of backward compatibility and "bug became feature"-situations.

And even then, it's not you who is abandoning that, which makes the attitude even more baffling to me.

But many have awkward, confusing UI are brittle in face of required changes and the documentation out of sync with the code which often has confusing and contradictory comments.

The management is always screaming for the latest fix, change to be made ASAP. So the programmers do their best in adverse conditions. Any attempt to do a proper job is a career limiting move.

Changing code (or UI or UX or anything really) just for the sake of changing it is just nonsense busywork to me.

For example, what was once a file based batch process meant that other processes had to wait and split their processes accordingly. Replace that with an event based system and everything can run contiously and a lot of the restrictions disappear.

Looks like many agree with you, so I'm really curious about what problems arise long-term from decisions like that.

I mean...our legacy code is in BASIC...but if they told me I needed to maintain the BASIC programs, I would probably quit.