5 ms·

Embracing “Old” Tech

72 points by zdw 4y ago

adamnemecek 4y ago
Why are there so many articles like this written? Who are they for? > New technology is always better than old technology No one believes this.
- randomdata 4y ago
  > Who are they for? You can determine who something is for by looking at who is paying for it. This one is provided to us for free and without any obvious source of third-party revenue (e.g. advertising), so, like HN comments, it is no doubt for the author.
- eschaton 4y ago
  No, nobody _says_ this. An enormous number of people make statements that imply they believe this. Honestly, that’s one of the common criticisms I see of HN: That it’s full of people who believe they’re doing something new when they’re just recreating something old, but because theirs is new it’s better, usually because of why it’s new. (Blank but in Rust, Blank but in Go, blank but in JavaScript…) In my own experience, this was demonstrated most starkly by how suddenly Subversion became “terrible” when everyone decided to switch to git, while many of the same people considered it great when they were switching to Subversion from CVS. And the same for the SCCS+clones to CVS transition.
  - wernsey 4y ago
    Upvote for mentioning Subversion. Back in 2016 I briefly worked at a old, large corporation that was still using CVS. During that time management decided that company policy was now to be hip with the younger generation. One very senior manager actually used the expression "we must strive to be the Uber of [our industry]" This also led to a mandate that we should switch to Git because it was new and shiny. You can just imagine the how steep the learning curve was for all the old hands, especially as some of them joined the company in the previous century as COBOL programmers. We were also pulled in to team building sessions where we were encouraged to "think outside of the box" and be "innovative". During one of those sessions I suggested that "you know, we should just use SVN instead" and was promptly shot down.
    - ihatepython 4y ago
      I feel like I'm the only person who thinks Git is terrible. I hate using it.
      - JohnFen 4y ago
        You're not the only person. I know a handful of devs who heartily agree with you, and most devs I know don't really love or hate it. It's just the tool they have to use. I don't hate git, but I do like subversion more. That said, I completely understand why someone would hate git.
    - JohnFen 4y ago
      > One very senior manager actually used the expression "we must strive to be the Uber of [our industry]" Oh, boy. That's a very bright signal to run, don't walk, away from that company.
  - deleted 4y ago
    [deleted]
- bmacho 4y ago
  Some people believe that old technology is always better than new. (For example I do.) This article is for us, reinforce us in our believes.
  - jollyllama 4y ago
    Same
Aloha 4y ago
I live in a world on the trailing edge. Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.
- drewcoo 4y ago
  These days a generation (major version) can be under a year. How far back do you lag to feel safe?
  - stakhanov 4y ago
    Personally, I've set 10 years for myself as a reasonable timespan, and I round up or down the version number to where it makes sense in terms of larger changes that have happened throughout the version history of the respective piece of software. There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it. 10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter. This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise. With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all. This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.
aobdev 4y ago
Heads up to the author in case you’re here, you reference a tweet about Next.js but subsequently refer to it as “Nest”.
- prokopton 4y ago
  Was about to post this!
- NerdiOrg 4y ago
  Completely agree. I could care less if it's not about Next. The fact that nobody caught this when proof reading says it all. Probably written by a Jr dev or non-techy writer.
  - FollowingTheDao 4y ago
    ...or it could have been written by someone with a disability. Man you all can be so intolerant. Does it change the facts in the article? No? then whatever, get over it.
Clubber 4y ago
New tech allows people new into the field to be on the same level playing field as the salty folks who have been in the trenches for a while.
- dbtc 4y ago
  More like a separate field without the old wisdom.
dottedmag 4y ago
There is one issue not mentioned in the article: authors of "old" tech quite often abandon it while developing a fancy new version, so the choice is not the imaginary one between old and new, the choice is real between abandoned and not-yet-ready. Abandonment would not be a problem in a stable environment (see, Clojure libraries last touched in 2014 don't need any maintenance, and old Go libraries usually need just a bit of touch-up), but in a chaotic environment of most other languages abandoned library bitrots immediately.
dgb23 4y ago
> The point is, the things we use to build applications are in a constant state of evolution and change. Evolution and change are great! The article misses a deeper issue though. There is tech that evolves with breakage (PHP, large parts of the JS ecosystem etc.) and tech that evolves with compatible change (Go, Java, Clojure etc.) There shouldn’t be anything wrong with starting on v(N-1). But there is something fundamentally wrong if vN breaks you. Programmers get anxious about that for very good reasons. We already have enough work to do! Breaking changes looming over our heads is not something we like having to worry about. I don’t know whether Next13 will or will not break Next12 code. But that’s besides the general point. Don’t embrace “old” tech! Embrace _stable_ tech.
- mpldr 4y ago
  This. So much this. It's fine to not use the latest version, but use a supported version. If the version is EOL, don't use it. Even if you have backports. Otherwise you will inevitably run into issues where the system is insecure by-design. I can't ssh into half the servers because I have to first enable insecure algorithms, the PHP version is almost old enough to drink, and the Debian mirrors don't even serve this version anymore. Sure, the system is stable. Until somebody finds it, then it can be a threat to the entire network.
- FollowingTheDao 4y ago
  > Don’t embrace “old” tech! Embrace _stable_ tech. This is why I used Debian Linux.
- bullen 4y ago
  I moved to Windows 10 for my MMO client, and I brought the cl.exe compiler with me and now I need to call "set __COMPAT_LAYER=WIN7RTM" before I run the game othervise file operations randomly fail. It messes with my head, and is fundamentally discouranging. Also I cannot distribute that compiler for legal reasons, so I need to add another compiler to my project delaying it many months. Linux has other problems, like 32-bit vs. 64-bit. It seems to me we're in a vortex of complexity that we will never escape, fundamentally fueled by peak lithography. Seriously considering going back to the C64.
trhoad 4y ago
I can't take this article seriously when it refers to Next but then calls it Nest 15 times.
- callahad 4y ago
  I'd recommend trying again; none of the article's message is specific to or contingent on Next, and it'd be a shame to dismiss it over something so superficial.
  - NerdiOrg 4y ago
    Eh, I disagree. It's a tech article and the writer clearly isn't familiar enough with the topic to catch this issue. It shows they are not actually really close to the tech or if they are, they don't proofread their articles.
mhd 4y ago
Everyone working for big corporations is going "Just a few versions behind? Lucky you!" now.
- mpldr 4y ago
  Hey, Kernel version 3 is not that old.
  - yakubin 4y ago
    And most books are about 2.6.
lp4vn 4y ago
The main theme of the article was: should I start with stable old tech or go to unstable new tech right away? First the author links to an article called "the Fallacies of Enterprise Computing" that I honestly didn't read but it's about debunking a fallacy "New technology is always better than old technology". Then he uses the case of python3 vs python2 for making the case that a lot of people worked successfully with python2 while python3 was unproven and finishes with a non-sequitur question: so why should stable old tech be recommended and used [in face of unstable new technology]? He argues in favour of old tech because, 1. new tech will be buggy, 2. you can't wait for the new version to be stable, 3. you will have to rewrite your project anyway to a new version some day, 4. technical debt is inevitable and not that bad. His conclusion is to develop with an old stable version and upgrade to a new version when the new version gets stable. Except for the first point, the one about the bugs, I'm not even sure that points 2, 3 and 4 even help his case. In fact I could easily use them to argue in favour of starting a project right away with unstable new tech. I might be a dumb guy and I might not have understood entirely the point of the author, but I don't like this kind of article. For me it all looks an incoherent assemblage of phrase of effects crafted with the intent of being provocative rather than having some real content. Props to the author for putting the effort of writing an article, but that's all of positive that I can say about it, the rest sounds only like platitudes.
NerdiOrg 4y ago
Was very interested in the article, but after 2 Nest 12 references I started questioning their credibility, and after a bunch more of the same error, I realized the author has probably never used Next. Some people here are saying it shouldn't matter. Of course it should. The author picked a tech for the analogy, most likely one they know the most about. And yet they call it Nest... which means they most likely aren't actually close to the development workflow whatsoever.
- projektfu 4y ago
  I think it's more likely they don't proofread and wrote the post on their phone.
dzonga 4y ago
I have adopted the Nintendo policy - of betting on "withered" technology. not only is it cheaper to use a version that's a few years old, you know the pitfalls, documentation is easily found etc.
- asddubs 4y ago
  don't you mean weathered?
  - dzonga 4y ago
    https://en.wikipedia.org/wiki/Gunpei_Yokoi https://en.wikipedia.org/wiki/Gunpei_Yokoi
googoo00 4y ago
[dead]
regularfry 4y ago
This is closely related to the effect you see inside orgs where nobody wants to touch the old thing because the replacement is coming but, critically, hasn't arrived yet and nobody can give you a date. That old service with all the bugs that nobody wants to add a feature to because the New Shiny Thing (which doesn't exist yet) will Make The Problem Go Away. No. The current thing is the only thing, until it actually isn't. It is a going concern until it gets switched off. Yes, this means it needs maintenance, security patching, support, and, yes, new features. The number of times I've seen teams fall into the trap of making their current situation worse by betting on an as-yet undelivered platonic future and intentionally ignoring their current estate because it's "not worth the effort for something that's going to be replaced" just makes me weep.

72 points by zdw 4y ago

Why are there so many articles like this written? Who are they for? > New technology is always better than old technology No one believes this.

randomdata 4y ago
> Who are they for? You can determine who something is for by looking at who is paying for it. This one is provided to us for free and without any obvious source of third-party revenue (e.g. advertising), so, like HN comments, it is no doubt for the author.
eschaton 4y ago
No, nobody _says_ this. An enormous number of people make statements that imply they believe this. Honestly, that’s one of the common criticisms I see of HN: That it’s full of people who believe they’re doing something new when they’re just recreating something old, but because theirs is new it’s better, usually because of why it’s new. (Blank but in Rust, Blank but in Go, blank but in JavaScript…) In my own experience, this was demonstrated most starkly by how suddenly Subversion became “terrible” when everyone decided to switch to git, while many of the same people considered it great when they were switching to Subversion from CVS. And the same for the SCCS+clones to CVS transition.
- wernsey 4y ago
  Upvote for mentioning Subversion. Back in 2016 I briefly worked at a old, large corporation that was still using CVS. During that time management decided that company policy was now to be hip with the younger generation. One very senior manager actually used the expression "we must strive to be the Uber of [our industry]" This also led to a mandate that we should switch to Git because it was new and shiny. You can just imagine the how steep the learning curve was for all the old hands, especially as some of them joined the company in the previous century as COBOL programmers. We were also pulled in to team building sessions where we were encouraged to "think outside of the box" and be "innovative". During one of those sessions I suggested that "you know, we should just use SVN instead" and was promptly shot down.
  - ihatepython 4y ago
    I feel like I'm the only person who thinks Git is terrible. I hate using it.
    - JohnFen 4y ago
      You're not the only person. I know a handful of devs who heartily agree with you, and most devs I know don't really love or hate it. It's just the tool they have to use. I don't hate git, but I do like subversion more. That said, I completely understand why someone would hate git.
  - JohnFen 4y ago
    > One very senior manager actually used the expression "we must strive to be the Uber of [our industry]" Oh, boy. That's a very bright signal to run, don't walk, away from that company.
- deleted 4y ago
  [deleted]
bmacho 4y ago
Some people believe that old technology is always better than new. (For example I do.) This article is for us, reinforce us in our believes.
- jollyllama 4y ago
  Same

Aloha 4y ago

I live in a world on the trailing edge. Sometimes the best of the last generation is better than the new of the next. While I don't know how strongly this author makes that case, it's true in a general sense.

drewcoo 4y ago
These days a generation (major version) can be under a year. How far back do you lag to feel safe?
- stakhanov 4y ago
  Personally, I've set 10 years for myself as a reasonable timespan, and I round up or down the version number to where it makes sense in terms of larger changes that have happened throughout the version history of the respective piece of software. There's a thought that Nassim Nicholas Taleb mentions in one of his books that I've frequently used as a mental model ever since coming across it: For a book that has continuously been read for the last 100 years, you can expect it will continue to be read for the next 100 years. For a book that has only come out last year and been continuously read since then, you should have an expectation that one year from now, people will stop reading it. 10 years is a number I've arrived at by experimentation, thinking about version histories of various bits of software I build upon. For example, for Python this takes me back to version 3.4, before type decorators and many other things hit the scene that I disapprove of anyway. So now, I test all my code with both version 3.4 and the newest version (3.11). I won't use language features from 3.11 that weren't already there in 3.4, and I won't use code in 3.4 that breaks or throws deprecation warnings in 3.11. I also apply this test to dependencies, seeing what happens if I try to get the newest version of some Python library running on version 3.4 of the interpreter. This means, my code is engineered in such a way that it could have been in continuous operation for the last 10 years, while running continuous updates on what's underneath it. And this gives me a reasonable expectation that my code will require only minimal code changes over the next 10 years to keep up with whatever might arise. With the python interpreter itself, it's remarkably easy to do that, and I feel it doesn't limit me in my own coding in any meaningful way. With other bits of software, including many python libraries that one might depend on, it would be absolutely unworkable. In such a case, I take that as a clear signal not to use the software/dependency at all. This is a lot of work, but also a good forcing function that prevents me from becoming a dependency hog myself. It's also useful research, because I get to develop an understanding of what time does to a piece of software, i.e. what causes breakage through time versus what causes stability through time, because I see the breakage in other bits of software through the time axis that I simulate into the past. And this way, I can avoid those mistakes when designing my own software.

aobdev 4y ago

Heads up to the author in case you’re here, you reference a tweet about Next.js but subsequently refer to it as “Nest”.

prokopton 4y ago
Was about to post this!
NerdiOrg 4y ago
Completely agree. I could care less if it's not about Next. The fact that nobody caught this when proof reading says it all. Probably written by a Jr dev or non-techy writer.
- FollowingTheDao 4y ago
  ...or it could have been written by someone with a disability. Man you all can be so intolerant. Does it change the facts in the article? No? then whatever, get over it.

Clubber 4y ago

New tech allows people new into the field to be on the same level playing field as the salty folks who have been in the trenches for a while.

dbtc 4y ago
More like a separate field without the old wisdom.

dottedmag 4y ago

There is one issue not mentioned in the article: authors of "old" tech quite often abandon it while developing a fancy new version, so the choice is not the imaginary one between old and new, the choice is real between abandoned and not-yet-ready. Abandonment would not be a problem in a stable environment (see, Clojure libraries last touched in 2014 don't need any maintenance, and old Go libraries usually need just a bit of touch-up), but in a chaotic environment of most other languages abandoned library bitrots immediately.

dgb23 4y ago

> The point is, the things we use to build applications are in a constant state of evolution and change. Evolution and change are great! The article misses a deeper issue though. There is tech that evolves with breakage (PHP, large parts of the JS ecosystem etc.) and tech that evolves with compatible change (Go, Java, Clojure etc.) There shouldn’t be anything wrong with starting on v(N-1). But there is something fundamentally wrong if vN breaks you. Programmers get anxious about that for very good reasons. We already have enough work to do! Breaking changes looming over our heads is not something we like having to worry about. I don’t know whether Next13 will or will not break Next12 code. But that’s besides the general point. Don’t embrace “old” tech! Embrace _stable_ tech.

mpldr 4y ago
This. So much this. It's fine to not use the latest version, but use a supported version. If the version is EOL, don't use it. Even if you have backports. Otherwise you will inevitably run into issues where the system is insecure by-design. I can't ssh into half the servers because I have to first enable insecure algorithms, the PHP version is almost old enough to drink, and the Debian mirrors don't even serve this version anymore. Sure, the system is stable. Until somebody finds it, then it can be a threat to the entire network.
FollowingTheDao 4y ago
> Don’t embrace “old” tech! Embrace _stable_ tech. This is why I used Debian Linux.
bullen 4y ago
I moved to Windows 10 for my MMO client, and I brought the cl.exe compiler with me and now I need to call "set __COMPAT_LAYER=WIN7RTM" before I run the game othervise file operations randomly fail. It messes with my head, and is fundamentally discouranging. Also I cannot distribute that compiler for legal reasons, so I need to add another compiler to my project delaying it many months. Linux has other problems, like 32-bit vs. 64-bit. It seems to me we're in a vortex of complexity that we will never escape, fundamentally fueled by peak lithography. Seriously considering going back to the C64.

trhoad 4y ago

I can't take this article seriously when it refers to Next but then calls it Nest 15 times.

callahad 4y ago
I'd recommend trying again; none of the article's message is specific to or contingent on Next, and it'd be a shame to dismiss it over something so superficial.
- NerdiOrg 4y ago
  Eh, I disagree. It's a tech article and the writer clearly isn't familiar enough with the topic to catch this issue. It shows they are not actually really close to the tech or if they are, they don't proofread their articles.

mhd 4y ago

Everyone working for big corporations is going "Just a few versions behind? Lucky you!" now.

mpldr 4y ago
Hey, Kernel version 3 is not that old.
- yakubin 4y ago
  And most books are about 2.6.

lp4vn 4y ago

The main theme of the article was: should I start with stable old tech or go to unstable new tech right away? First the author links to an article called "the Fallacies of Enterprise Computing" that I honestly didn't read but it's about debunking a fallacy "New technology is always better than old technology". Then he uses the case of python3 vs python2 for making the case that a lot of people worked successfully with python2 while python3 was unproven and finishes with a non-sequitur question: so why should stable old tech be recommended and used [in face of unstable new technology]? He argues in favour of old tech because, 1. new tech will be buggy, 2. you can't wait for the new version to be stable, 3. you will have to rewrite your project anyway to a new version some day, 4. technical debt is inevitable and not that bad. His conclusion is to develop with an old stable version and upgrade to a new version when the new version gets stable. Except for the first point, the one about the bugs, I'm not even sure that points 2, 3 and 4 even help his case. In fact I could easily use them to argue in favour of starting a project right away with unstable new tech. I might be a dumb guy and I might not have understood entirely the point of the author, but I don't like this kind of article. For me it all looks an incoherent assemblage of phrase of effects crafted with the intent of being provocative rather than having some real content. Props to the author for putting the effort of writing an article, but that's all of positive that I can say about it, the rest sounds only like platitudes.

NerdiOrg 4y ago

Was very interested in the article, but after 2 Nest 12 references I started questioning their credibility, and after a bunch more of the same error, I realized the author has probably never used Next. Some people here are saying it shouldn't matter. Of course it should. The author picked a tech for the analogy, most likely one they know the most about. And yet they call it Nest... which means they most likely aren't actually close to the development workflow whatsoever.

projektfu 4y ago
I think it's more likely they don't proofread and wrote the post on their phone.

dzonga 4y ago

I have adopted the Nintendo policy - of betting on "withered" technology. not only is it cheaper to use a version that's a few years old, you know the pitfalls, documentation is easily found etc.

asddubs 4y ago
don't you mean weathered?
- dzonga 4y ago
  https://en.wikipedia.org/wiki/Gunpei_Yokoi https://en.wikipedia.org/wiki/Gunpei_Yokoi

googoo00 4y ago

[dead]

regularfry 4y ago

This is closely related to the effect you see inside orgs where nobody wants to touch the old thing because the replacement is coming but, critically, hasn't arrived yet and nobody can give you a date. That old service with all the bugs that nobody wants to add a feature to because the New Shiny Thing (which doesn't exist yet) will Make The Problem Go Away. No. The current thing is the only thing, until it actually isn't. It is a going concern until it gets switched off. Yes, this means it needs maintenance, security patching, support, and, yes, new features. The number of times I've seen teams fall into the trap of making their current situation worse by betting on an as-yet undelivered platonic future and intentionally ignoring their current estate because it's "not worth the effort for something that's going to be replaced" just makes me weep.