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.
Embracing “Old” Tech
31–40 of 47 posts
Re: Embracing “Old” Tech
#32Was 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…
I think it's more likely they don't proofread and wrote the post on their phone.
Re: Embracing “Old” Tech
#33Earlier quoted context omitted.
These days a generation (major version) can be under a year. How far back do you lag to feel safe?
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 contin…
Taleb calls it the Lindy effect. https://en.wikipedia.org/wiki/Lindy_effect
Re: Embracing “Old” Tech
#34> 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 fund…
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.
Re: Embracing “Old” Tech
#35I 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.
And even if the new _is_ better, it's called the bleeding edge for a reason. I find I bleed all over it - stress, bugs, and time. 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. [0] https://mcfunley.com/choose-boring-technology
As an example, I've worked in telecom - I can absolutely tell you that in 2003-5, while VoIP was available, you were 100% better off buying a legacy TDM PBX rather than buying a bleeding edge (immature) VoIP one.
Re: Embracing “Old” Tech
#36[dead]
Re: Embracing “Old” Tech
#37This 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.
Re: Embracing “Old” Tech
#38Earlier quoted context omitted.
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 experien…
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 ju…
I feel like I'm the only person who thinks Git is terrible. I hate using it.
Re: Embracing “Old” Tech
#39Why are there so many articles like this written? Who are they for? > New technology is always better than old technology No one believes this.
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.
Same
Re: Embracing “Old” Tech
#40I 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.
This is what I do as well.
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)