The frameworks that help us build software in half the time become outdated in half the time.
To see this in practice, look no further than the low-code ecosystem. Promises of instant gratification, but skills and technology that will be quickly outdated. Optimized software is inherently rigid (see antifragile), so it can't adapt to the fast moving technology lifecycle. Tech workers need to be re-skilled and learn new paradigms.
You can try and fight software half-life by choosing long-lasting foundational technologies, e.g., learning Linux system administration. The problem is that the longest lasting technologies either have (1) the steepest and longest learning curve or (2) little upside. You can also try to distill the foundations from First Principles. Lower down the stack, the half-life increases – JavaScript frameworks come and go faster than runtimes. But mostly, we have to adapt to the half-life.
The upside of software half-life is it's sometimes a great trade-off. Sometimes software should be designed to be rewritten, see Ship Thesean Software. The optimal level of technical debt is non-zero.
The important part is to keep evolving. I think about this whenever I have to reluctantly sign into AT&T's website. The website is terrible – redirects, long page loads, and all other types of non-standard behavior that any junior web developer could fix.
The domain was registered in 1986 (making it the 15th website to be registered on the internet). The site has mostly likely been through all sorts of rewrites and updates, but I'm sure some of the core technology has worked long enough to stick around. These legacy systems have proven to have such a long half-life that they haven't been replaced. Instead of being an asset, these long-lived systems are a liability. So sometimes, a short half-life isn't the worst thing.