I have been programming professionally for nearly three decades now. I know that some 24 year old code of mine is still running, essentially unmodified, at the company I worked for at the time. And now that you got off my lawn ...
I fail to see what you are trying to say. That a change once in 8 years in a user agent string is too frequent? Because that seems to be what you are saying. And if that is what you are saying, I don't think we have any common ground to base the discussion on.
I don’t see why this is a problem, I actually think it’s a feature. Do you really want to be using 20 year old software? I don’t. Furthermore, not being able to run old code has never impacted me in a meaningful way and I’m part of the small minority of people who write software for a living. I recon if you go ask pretty much anyone out on the street about this “problem”, they wouldn’t even care.
I think it is fair to say that unchanging software systems can be harmful. The unemployment benefits system in the United States is a good example. They built those systems in the 70s and never touched them again. Now that the requirements have changed due to Covid induced economic collapse and the systems are overloaded, there isn’t a single person who has a damn idea how to fix it. If there were people iterating on and improving the system this entire time, things would be much easier to fix, or maybe there wouldn’t have been a problem at all.
Data is forever, not code. Code should be fickle. Changing code is progress
I'm always amazed at the lifespan of some of the code I've written over the years. I wrote an api that we use internally in 1996 that is still being used in all of our new production code in that language in our organization. I've learned a lot in the intervening 23 years so looking at some of that code can be a bit jarring. We've had to adapt it a bit when our environment changed a few times, and we've certainly added to it, but I don't think the core code has had any problems that I know of this century. Millennium, I guess, technically.
Part of me really wants to rewrite it, but it doesn't make sense from a developer-time perspective (and I don't want to spend the time tracking down the inevitable bugs again).
Well that is ... sad. I have not been around for 30+ years and I see good code on a weekly basis. Maybe you should consider changing something in your environment. I assure you it is possible.
I don’t disagree with you, but I also don’t think that’s a bad thing. Things certainly don’t break quickly, there are years of warnings for deprecated functionality. I also think it’s not a bad thing to drop old functionality. It may not be warranted that code that worked 10/20 years ago should still work today. Languages evolve, and by pruning old features, footguns, or bad patterns, the language can evolve without carrying the weight of every mistake or legacy feature.
I've been doing this a long time and it doesn't matter to me.
And this attitude is why older developers find it harder to get a job (I’m in my mid 40s myself).
What older coders have that younger ones do not, is experience. This can often halve the workload on some projects. The older I get in this profession, the more results I get out of less and less code.
I keep seeing this as an excuse for older developers who don’t want to keep up the date and stay marketable. Code is code. At some point you have to put lines in editor to make stuff work.
Also, let's not immediately fetishize the newer stuff. It is often a less well implemented retread of older technology. Seems like people have less patience for learning existing systems, so they just re-write some quick and dirty replacement and call it good.
Perhaps it might be better if younger programmers learned the old stuff instead of just badly reinventing the wheel every few years.
The market can stay irrational longer than you can stay solvent.
Code sitting on the same machine can keep on performing the same way forever.
But other things change. The library changed its interface. You coded your crypto lib when MAC-then-Ecrypt was all the rage. You aren't handling HTTP/1.0 headers. Windows 7 doesn't even have those 16-bit drivers any more.
I hate the "throw everything away and rewrite with the brand new frame work every two years" that some parts of the web development community seem to have (and then get angered when you ask about a version over six months old because it is what you installed everywhere). But sometimes software does rot if it's old and no one is trying to keep it up-to-date.
I disagree. I think rewrites are sometimes the right thing, but rarely.
The Linux kernel is a good example. Should we rewrite it? No of course not. So was your point about code that hasn’t been maintained in a decade? Sure, maybe then. But I can’t square “code that hasn’t been touched in a decade” with “still in active use today”
There are some ecosystems where the experience is different. Perl, for example, does have deprecations, but not many. It's fairly common to be able to run 30 year old code unmodified, or with very minor changes. Of course, it has it's own issues, but it is very stable across time.
I think it's more a matter of as programmer mature/learn, they overly disparage old code and idioms. It's not the new orthodoxy...
I've seen in with RPC calls (hand-coded HTTP -> Hessian -> Protobufs), serialization languages (XML -> Json -> Protobufs/Bson), ad nauseam.
I think this kind of changes is the natural state of multi-year development efforts. On a 10-15 years old code base, you'll see all sorts of things like that cropping up and it's incredibly hard to steer clear of these kinds of things.
What are the alternatives? Wholesale replacement of all uses? Wasteful in resources! Not introducing new technologies? Offends the sensibilities of the devs...
I have an old project I gave up on - haven't touched it, done any code changes or maintenance in... almost a decade? At least a stubborn client is still using it, successfully. And it's not an old guy in a living room, but an honest small sized company that has this software as the core of its operations.
So yeah, I totally agree with you. No code changes = long life.
You would be surprised how long lived some code is. I used to work on codebase that was started during 70s and currently working on codebase written around 1995 - 1998 and maintained until today.
There is wast amount of code used daily that is decades old, especially if those systems are not user facing.
Well, that sounds about right from my experience, for some type of code and organizations.
The original developers have left after a few years, newcomers don't understand the system and may not even try to. It will ultimately get rewritten in newer technologies and frameworks, that happen to be nice for their resume, whether it was obsolete or not.
So, you're comparing my track record with writing simple maintainable well documented code to something you did in 1992 with ODBC? That's your experience that's causing all the paranoia?
The worst two things that afflict programmers today is:
1. They never update their information, even after 18 years (18! You realize that right!? Things change man!)
2. They have an irrational paranoia about trying new things, as if me trying this out is going to destroy the universe.
Also, how "X" will always be enough. It May be sufficient for the foreseeabke future, but software engineers are horrible about underestimating how long the software we write will stick around.
Pretty sure I made some short sited decisions as an intern, and most of that code is approaching 20 years old, and I bet it hasnt been fixed or rewritten, because for the time being, it works.
I fail to see what you are trying to say. That a change once in 8 years in a user agent string is too frequent? Because that seems to be what you are saying. And if that is what you are saying, I don't think we have any common ground to base the discussion on.
reply