Ask HN: How to pick tech with longevity?
12 comments
You can pick technologies that are old and still well maintained. RubyOnRails or Java Spring are not going anywhere for example.
Mind the Lindy effect?:
https://www.johndcook.com/blog/2017/08/19/programming-langua...
NASA also does stick with old stuff/tech.
https://www.johndcook.com/blog/2017/08/19/programming-langua...
NASA also does stick with old stuff/tech.
I have been in and around the IT industry since the 1980s and I still can't discern a pattern as to what lasts. My only advice is let the market sort it out by always being slower to adopt something until at least it gets to the edge of mainstream. Cutting edge and shiny is only for when you absolutely have to have some feature nothing else provides. Plus when you pick something, figure on staying with it until it becomes a PITA.
IOW: be conservative (in your decisions) and move like a tankship and not like a speedboat. Old is good. NASA does this too, AFAIK. They use conservative/old tech that has stood the test of time. (Lindy effect?)
That's the reason I won't switch to Rust from C++. I wait until it is matured enough and standardized. (Also, I wait until it makes C++ less relevant. It hasn't so far.)
C++ does the job. There's no perfect language or other technology. Many things have pros and cons.
https://www.johndcook.com/blog/2017/08/19/programming-langua...
Naval Ravikant also shares this sentiment, as far as I am aware.
That's the reason I won't switch to Rust from C++. I wait until it is matured enough and standardized. (Also, I wait until it makes C++ less relevant. It hasn't so far.)
C++ does the job. There's no perfect language or other technology. Many things have pros and cons.
https://www.johndcook.com/blog/2017/08/19/programming-langua...
Naval Ravikant also shares this sentiment, as far as I am aware.
Stick with open source technologies that are widely used and stay on current-ish versions.
Other than that, stay as close as you can to what you're doing. Like if you build web apps, stay close to doing HTML, CSS, JS. If you start getting into derivative languages which compile down to or generate the base tech being used you are more likely to run into hardly used tech that becomes unmaintained or is ditched.
Other than that, stay as close as you can to what you're doing. Like if you build web apps, stay close to doing HTML, CSS, JS. If you start getting into derivative languages which compile down to or generate the base tech being used you are more likely to run into hardly used tech that becomes unmaintained or is ditched.
Unavoidable with web I think. I would bet on an enterprisey stack of React front end with typescript if you like and .NET or Java backend for longevity of support, available talent and available jobs.
Your 2001 .Net web app will probably still run and you can probably find devs to work on it as is or upgrade it.
Your 2001 .Net web app will probably still run and you can probably find devs to work on it as is or upgrade it.
hey, lamp and jquery still works.
I've also built stuff on actionscript 3/flash right at the tail end of the flash era, it sucks to have the floor fall from under you like that but what can you do.
who knows, maybe in 10 years the web itself will be dead and all we'll have left are walled gardens (shudder). It's probably best to learn to embrace the change.
I've also built stuff on actionscript 3/flash right at the tail end of the flash era, it sucks to have the floor fall from under you like that but what can you do.
who knows, maybe in 10 years the web itself will be dead and all we'll have left are walled gardens (shudder). It's probably best to learn to embrace the change.
Separation of concerns -- as long as the layers of your app are not dependent on each other, just rewrite one layer when its tech is dying. In your example, rewrite the Flex layer, keep everything else. Tech lasts when you can rip out a single piece and make a better version without requiring a full re-write of the entire stack.
Unavoidable but you can minimize it by not using the new & trendy stuff because that has too much churn.
PHP is a good pick to avoid that, but you need to make sure not to fall behind on too many major versions (note in PHP a major version is 7.1 or 7.2, it is not semver). Make sure that you are at least only 2 versions behind.
Upgrading one major version for PHP is not that much work because PHP values backward combability, but upgrading many versions in one go can become complicated. I upgraded an old system from PHP 5.2 to PHP 7.4, doable but time consuming. There are tools that can help you with this.
Other things to avoid with PHP is not using any odd or uncommon extension, try to always solve your problem with pure PHP and only use common extensions that are well maintained.
Don't rely on weird php ini settings (like unserialize_max_depth or max_input_vars) or hacks that exploits undefined behavior in either PHP or in the browser. Follow standards.
Try to do much as possible with server side rendering to avoid being dependent on a fancy JavaScript framework. If you need dynamic rendering of components on a page, send pre-rendered HTML fragments with ajax to the browser and use something like jQuery or htmx to swap in the new and out the old. This way you can have all UI components as backend templates, thus keeping it nice & simple. No need to send JSON from the server and then have fancy JS framework converting it to HTML.
Upgrading old PHP frameworks is a mess. I have learned that the hard way and even modern frameworks can be messy between major versions or if there are too many major versions (like Laravel). That is why I don't use large frameworks at all. Pick a small one (like Slim) or do it yourself (what I do). I focus more on using good & stable libraries when needed. Make sure to decouple your code from the framework, the majority of the project code should be outside of the framework or at least not be dependent on specific framework features, extract what you need from the framework first, then pass it on to your decoupled code.
Don't use an ORM, write SQL, that is more future proof.
Composer dependencies, that is also important to upgrade often.
You have to maintain source code, even if the project is considered feature complete. Plan a day or half a day a year to upgrade dependencies and fix any bugs.
Use an error reporting server software like Sentry to catch all bugs in your project and make sure to fix them a soon as possible. Always use E_ALL and don't ignore notices or deprecated warnings, in the future they can become bugs.
Use strict typing and type hints for functions, will catch any changes between upgrades that you missed, will throw TypeError and if you have your Sentry (or similar) configured correctly you can get an bug report immediately so you can fix it. IMHO it is better to fail fast than having hidden bugs. Make sure to have a fast deployment step so can push out bug fixes fast, ideally push to some branch in git and it auto-deploys.
Use tried and mature technology like the LAMP stack. Avoid newer technologies like NoSQL, message busses and other hyped technologies. Most problems can be solved efficiently with PHP, SQL and cron.
Minimize number of external dependencies, don't rely on specific operating system features, like bash, or make assumptions where you are running your application, like specific server addresses.
Don't have complicated build or setup steps for you project, like a huge Makefile or something, that also has a tendency to break down over time. Instead write your code to almost be zero configuration. It should be possible to do a git pull add db login to a simple config file then done. If you still need some setup code, do it in PHP, that way you also avoid duplicating project settings and avoid an extra dependency.
Don't have complicated .htaccess files with complex routing and what not, that will lock you into apache forever and the risk of having double routing, both in .htacces and php.
Always run MySQL with the strictest mode set, so you can't write bogus data to it (like non existing dates and zero dates). Makes it easier to upgrade MySQL versions.
Follow the KISS principle. Don't write overcomplicated abstractions that over time will become a nightmare to maintain.
PHP is a good pick to avoid that, but you need to make sure not to fall behind on too many major versions (note in PHP a major version is 7.1 or 7.2, it is not semver). Make sure that you are at least only 2 versions behind.
Upgrading one major version for PHP is not that much work because PHP values backward combability, but upgrading many versions in one go can become complicated. I upgraded an old system from PHP 5.2 to PHP 7.4, doable but time consuming. There are tools that can help you with this.
Other things to avoid with PHP is not using any odd or uncommon extension, try to always solve your problem with pure PHP and only use common extensions that are well maintained.
Don't rely on weird php ini settings (like unserialize_max_depth or max_input_vars) or hacks that exploits undefined behavior in either PHP or in the browser. Follow standards.
Try to do much as possible with server side rendering to avoid being dependent on a fancy JavaScript framework. If you need dynamic rendering of components on a page, send pre-rendered HTML fragments with ajax to the browser and use something like jQuery or htmx to swap in the new and out the old. This way you can have all UI components as backend templates, thus keeping it nice & simple. No need to send JSON from the server and then have fancy JS framework converting it to HTML.
Upgrading old PHP frameworks is a mess. I have learned that the hard way and even modern frameworks can be messy between major versions or if there are too many major versions (like Laravel). That is why I don't use large frameworks at all. Pick a small one (like Slim) or do it yourself (what I do). I focus more on using good & stable libraries when needed. Make sure to decouple your code from the framework, the majority of the project code should be outside of the framework or at least not be dependent on specific framework features, extract what you need from the framework first, then pass it on to your decoupled code.
Don't use an ORM, write SQL, that is more future proof.
Composer dependencies, that is also important to upgrade often.
You have to maintain source code, even if the project is considered feature complete. Plan a day or half a day a year to upgrade dependencies and fix any bugs.
Use an error reporting server software like Sentry to catch all bugs in your project and make sure to fix them a soon as possible. Always use E_ALL and don't ignore notices or deprecated warnings, in the future they can become bugs.
Use strict typing and type hints for functions, will catch any changes between upgrades that you missed, will throw TypeError and if you have your Sentry (or similar) configured correctly you can get an bug report immediately so you can fix it. IMHO it is better to fail fast than having hidden bugs. Make sure to have a fast deployment step so can push out bug fixes fast, ideally push to some branch in git and it auto-deploys.
Use tried and mature technology like the LAMP stack. Avoid newer technologies like NoSQL, message busses and other hyped technologies. Most problems can be solved efficiently with PHP, SQL and cron.
Minimize number of external dependencies, don't rely on specific operating system features, like bash, or make assumptions where you are running your application, like specific server addresses.
Don't have complicated build or setup steps for you project, like a huge Makefile or something, that also has a tendency to break down over time. Instead write your code to almost be zero configuration. It should be possible to do a git pull add db login to a simple config file then done. If you still need some setup code, do it in PHP, that way you also avoid duplicating project settings and avoid an extra dependency.
Don't have complicated .htaccess files with complex routing and what not, that will lock you into apache forever and the risk of having double routing, both in .htacces and php.
Always run MySQL with the strictest mode set, so you can't write bogus data to it (like non existing dates and zero dates). Makes it easier to upgrade MySQL versions.
Follow the KISS principle. Don't write overcomplicated abstractions that over time will become a nightmare to maintain.
For front ends? Use native HTML, CSS, and targeted Javascript, using its native DOM API.
I've seen this with front ends written in ExtJS, it's just so old now that maintaining it is a pain. The same thing with old versions of Zend. PHP 5.6 is no longer supported but most operating systems out of the box so we have to find an upgrade path.
Has anyone found a stack that lasts? Or a method of avoiding this sort of thing?