> code written 5 years ago will often not compile today.
citation needed. Yes, there's a few programs that relied on unsound things for which this is true, but that's a relatively small part of the overall amount of code.
It seems like this day and age is precisely when this sort of code is normal. We had a brief window of hopeful optimism in the mid to late 90s and even into the early 2000s, but since then it seems like code quality in general has declined tremendously.
Got a real kick out of this blog post as it seems to imply that code written two years ago is "old".
I've been surprised quite a few times in the past year that what I thought was "relatively new" code actually ended up being 5+ years old when I went back and looked at the commit history.
I still regularly see code here that's 10-15 years old and some code that's older than the company itself. It's both surprising and a bit scary to see how much code is still flying around that hasn't (or has barely) been touched in so long. Or even the idea that code can transcend companies and end up in entirely different places.
Yes, I'm always extremely wary of programmers who claim they advance so fast in the art that code they wrote in the last year or two is "garbage". It's more likely that they are just no longer familiar with that old code.
> Many 2005-era enterprise coding practices are still in very wide use for new projects
Just because something is older doesn't mean it's not still useful. Many developers these days hold an odd kind of logical fallacy that if something hasn't been done in the last few years, it's outmoded completely. Many concepts still hold high value dating back 40 or 50 years.
The code in question is actually 9 years old and I wouldn't exactly call the article fawning over brilliance, in fact the author discusses the fact that a lot of things changed in the language over time and the code itself is quite clumsy and has workarounds for things that were unimplemented.
It's funny, my experience is that the same handful of technical problems keep arising regardless of the age of a code base. After a while, it becomes rarer to find yourself saying something like, "well, I haven't written one of these before."
It's scary how much code out there is less than 4 years old, and even scarier how much of it is because someone decided to somehow rewrite it unnecessarily and thus introduce this bug. I don't even want to know how many people think the code they wrote will be in use for more than 4 years.
The GitHub example actually is pretty spot on. If you wrote a non trivial piece of code in 2016, then in 2020 it was used verbatim in another program, what would your conclusion be?
I’m not sure that article really aged well. Code rots pretty quickly nowadays. Convoluted old code no one understands starts to create wicked bugs as future teams wedge in new features. Processors get overloaded. Memory leaks appear. Libraries evolve. Design trends change.
I do not find it shocking that 25-year-old code is obsolete.
Heck, most any project I've worked on that was started more than 3 years ago has obsolete code. If it was started before it was a near-universal habit to write tests, oh yeah we're scared to touch it.
But I agree with the author that this is a sign of things to come. Our digital empire is built on layers upon layers of bad code, and the economic cost to fix it would be enormous. And that's what's shocking. Expect things to get a lot worse before they (maybe?) get better.
It's also a piece of code that hasn't been rewritten to fit whatever buzz is the buzz today. I wish more of the world was written with code that need not be rewritten every five years.
reply