3 ms·

The insane race to adopt any fad to be cool, is a mindset I find far worse morally than using tried and true tools. It enhances risk. The latest tool language

The insane race to adopt any fad to be cool, is a mindset I find far worse morally than using tried and true tools. It enhances risk. The latest tool language and/or framework is uncharted territory A tried-and-true solution has had a lot of bugs and issues documented and some of them solved. It also mean the team must take a break from development to learn whatever the new thing is. Some will need more time than other, which may slow it down even further. A lot of systems are developed in domains where "go fast and break things", A/B testing etc. would not be at all advisable. The main selfish focus on "adopt whatever is hip this week" is to pad resumes with it, consultant can come in to help train people $$$. Consultants will fight for it to use the newest and greatest since it may increased development time $$$.

tdeck 4y ago
This is a false dichotomy though. Your comment makes it sound like the only options are to keep using the same tech stack for 30 years or to "race" to adopt the "newest fad". What about switching from a moribund 30 year old technology to a mature 5-10 year old technology every now and then, based on an assessment of the very real drawbacks of living in the past. Security is one of the biggest problems with outdated software that many people are only too happy to ignore.
- wellokthen2 4y ago
  Protip: you're much better off writing something in straight C than in [latest fad language du jour]
- cestith 4y ago
  Switching wholesale is often detrimental itself. Often the best thing is to leverage new tools for new development, and as certain older parts of your stack are retired move those from the legacy technology to something more modern. If something's getting so old that you're getting short on people who understand it, that part becomes more urgent to move to the newer technology. It doesn't kill a business to have two or even three generations of tech spread across teams so long as it's manageable. An older tech stack doesn't mean never updating the system. either. Perl still gets updates. Linux distros still get updates. In fact, often a newer piece of software will introduce bugs including security bugs that were fixed in older software long ago. All things being equal, though, using a language with better string handling and memory safety can be a boon if your old stuff is in something like C.

tdeck 4y ago

This is a false dichotomy though. Your comment makes it sound like the only options are to keep using the same tech stack for 30 years or to "race" to adopt the "newest fad". What about switching from a moribund 30 year old technology to a mature 5-10 year old technology every now and then, based on an assessment of the very real drawbacks of living in the past. Security is one of the biggest problems with outdated software that many people are only too happy to ignore.

wellokthen2 4y ago
Protip: you're much better off writing something in straight C than in [latest fad language du jour]
cestith 4y ago
Switching wholesale is often detrimental itself. Often the best thing is to leverage new tools for new development, and as certain older parts of your stack are retired move those from the legacy technology to something more modern. If something's getting so old that you're getting short on people who understand it, that part becomes more urgent to move to the newer technology. It doesn't kill a business to have two or even three generations of tech spread across teams so long as it's manageable. An older tech stack doesn't mean never updating the system. either. Perl still gets updates. Linux distros still get updates. In fact, often a newer piece of software will introduce bugs including security bugs that were fixed in older software long ago. All things being equal, though, using a language with better string handling and memory safety can be a boon if your old stuff is in something like C.