Sure, but the pace of these changes is significantly different. Clearly part of this is due to Moore's law; perhaps standards in aeronautical engineering shifted about as quickly during the transition from biplanes to supersonic jets as our software standards and frameworks are changing today.

But that's no reason to reflexively dismiss the very good and very interesting question of why one should have to largely rewrite a Django app in 2019 that does the same thing that it did in 2010, in a language that is virtually functionally equivalent in any respect that is relevant to that particular developer. Software does not inherently need to be as ephemeral as it is.

This is a scope problem. If thousands of people were constantly attacking your door's locks you better believe that locks would constantly be changing and that a house with older locks would need to have them upgraded.

Changes to physical items are costly and not affected by the same types of security scope that _any_ code connected to the internet is. The code in my decade old microwave has never needed to be upgraded and probably never will be upgraded, but it's also not under constant attack.

His Django app continued to run, he just couldn't make use of the most up-to-date features and security unless he upgraded.

I get the need for security updates. That’s why you use high level frameworks to write your application and update the rest of the stack that runs underneath. The issue is when parts of that stack are replaced with backwards-incompatible-but-functionally-equivalent parts, for reasons that have nothing to do with security.

But that's why you have to look at the maturity of the tech when first building it--sometimes you just don't know. Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

If you had built your page using static html there would be a lot less surface area of attack and a lot less maintenance. Even with Django, the amount of churn depends on which features you use.

You hear similar stories about people chasing the new Javascript framework treadmill. Some people stuck with Vanilla JS, others are still using jQuery.

I just don't see the real world being all that different. Blackboards still work just fine like they did 100 years ago. Some schools transitioned to marker boards, and some moved again to "smart boards." Many were forced along because repair/replacement supplies were harder and more expensive to find. I see the same thing with washing machines or people's favorite pen/pencil.

In fairness, I suspect the author would agree that it was a mistake to use Django in the first place. I think that's what he was trying to get at!

> Python 3 was first released in 2008. Python 2 EOL is 2020. If I built an app in 2010 using a Python 2 stack you have to know by 2019 you're going to have to rewrite it completely using a new stack or modify it heavily (assuming Django would move to Python 3 and be active 10 years later).

In 2010, the conventional wisdom was still, "nobody uses Python 3, there is no library support for Python 3 so just use Python 2". Django itself didn't support Python 3 until 2013.

In hindsight he can say it was a mistake, but it was glaringly obvious back then that Django, Python 2, or Python 3 wouldn't give you a situation where you would have minimal maintenance for the next 10 years because of the volatility already publicly discussed.

But maybe you're right that this isn't something people think enough about when choosing technologies and the author is trying to raise awareness.