[gbog]

> Technology and business requirements move too fast to worry about writing software that will be around 10 years from now

This is a common belief but I do not think it applies very well in most cases. If you write the last pic sharing thing, maybe you can dismiss worries, but if you build the next Google, entreprise or scientific software, or even something like Github, you should hope your baby to be well and alive in 10 years, and choose your tech stack accordingly. I guess.

[nkohari]

Google in 2002 was nothing like Google in 2012. The only thing the same is the name. The entire software industry has changed at least twice in the last decade or so. If more than 10% of the original code that powered Google is still in production, I would be absolutely shocked.

Remember how Twitter was originally written in Rails, and then it collapsed under its own weight when they tried to scale it? Their business requirements changed, so they rewrote the parts that needed to be rewritten. On the flip side, if they had originally set out to try to build the system that now powers Twitter, not only would they likely have built the wrong thing entirely, they never would have launched.

Software services are evolutionary. You have to always be willing to burn pieces of it down and rewrite them as conditions change around you.

[gbog]

> Software services are evolutionary

Sure, but changing the tech stack is much harder than rewriting some parts of it. And some setups are easier to adapt than others. Thus choosing the best available option when starting a new project is important, and the likeliness of the technology to be alive and well in ten years should be taken into consideration, among other parameters (your own experience, the current availability of good developers).

Moreover, the "trendiness" of a technology should be counted as a negative factor, because it would tend to be overestimated and cast shadows on potentially better (but less sexy) alternatives.