Embracing “Old” Tech
blogs.newardassociates.com
blogs.newardassociates.com
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.
Sure, the system is stable. Until somebody finds it, then it can be a threat to the entire network.
This is why I used Debian Linux.
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.
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.
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.
How far back do you lag to feel safe?
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.
If it's not worth spending one of your innovation tokens[0] on this new fangled technology, then use the old version that doesn't require the bleeding.
Also related is my policy of "never rely on anything until it reaches at least version 3". (Figuratively speaking, as version numbers don't really mean what they used to)
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.
not only is it cheaper to use a version that's a few years old, you know the pitfalls, documentation is easily found etc.
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.
> New technology is always better than old technology
No one believes this.
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.
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.
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.
I don't hate git, but I do like subversion more. That said, I completely understand why someone would hate git.
Oh, boy. That's a very bright signal to run, don't walk, away from that company.