Comment by luciusdomitius | Hacker News Reader

Comment by luciusdomitius | Hacker News Reader

Parent Full thread

Well, the car analogy is very good I think. A 35-year old Mercedes-Benz W124 that has been taken care of during its entire lifetime is actually usable and could be reliably maintained. A 10-year old Hyundai with 50k km old oil is meant to be scrapped though.

In the same way, there is legacy software and legacy software. In a decade of contracting I have seen both pieces of crap with 50%+ of dead code which are inmodifiable beyond adding/removing fields from some CRUD entity, and 15+ year old J2EE competently designed, maintained and documented systems, where the only difference to a fancy new project is that there is xdoclet instead of annotations and a ton of plumbing code around.

The big difference is in telling them apart in advance - with cars you know that some brands are more maintainable than others as you see them on the road and as all of them share the same components/weak spots it doesn't take long to figure out if it is an oldtimer or a piece of junk. With software it is much more complicated.

Telling non-technical people about UNIX is often eye-opening.

Development for UNIX started in 1969. It was done in a documented way, using well defined APIs (that later became standard) by world class engineers.

The original code (in C) is still readable. Running it on modern hardware would be a challenge, since computer architectures changed quite a bit, and modern CPU architectures were simply not invented yet! But it's not legacy code; the interfaces, ideas and libraries from 1969 have been improved on and are the foundation of the modern computing landscape.

Yet spaghetti code from two years ago, written by "best value" programmers in a language that's 100% still supported is very much legacy code. Unintelligible comments, no tests, copy-pasted code, inline queries, the list goes on. Often simpler to just re-write.

10 years ago I’ve attended a talk from one of German car producer - they talked about 25+ years of software maintenance. You invest into tools 5 years before release to market, and they should work 20 years after release. So companies need to plan the whole cycle not only code maintenance

It goes all the way down the stack, too. I talked to someone working on CI at Nvidia and they were testing up build toolchain to ensure some of their hardware accelerated libraries could be rebuilt in 10+ years (for automotive industry customers). The work mostly involved dynamic systems for ensuring the builds worked without an internet connection (monitoring network activity to make sure everything was cached/saved correctly).

> The work mostly involved dynamic systems for ensuring the builds worked without an internet connection (monitoring network activity to make sure everything was cached/saved correctly).

Documenting and archiving your build tools is also important. I knew a team that checked everything into source control, even Visual Studio. This ensures the tools were all preserved, everyone is using the same versions, and the code is synchronized with the tool versions.

Reply on news.ycombinator.com