When I started as SWE, I was (more or less by accident) educated in the old way. And I, like the OP, don't like the new way. I think the article is spot on in t

When I started as SWE, I was (more or less by accident) educated in the old way. And I, like the OP, don't like the new way. I think the article is spot on in the factual, although of course it is biased in preference and author makes that clear. (And it pains me that people in the discussion are not really hearing the nuance, just like youngsters often don't listen to the older generation.) I have a brilliant coworker, who enjoys the new way, and we disagree a lot, and I think the article summarizes our disagreement very well. Ultimately, I think the divide comes down to your optimization horizon. In the old days, software was made to last longer, and there was more time to plan and design it properly, because the horizon was longer. Today, the horizon has been shortened, and more experimentation is done, and less forward thinking. And so the methods are different, and most of these differences (as described in the article) accounts to the shortening of the optimization horizon. I do prefer longer horizon, because I feel that if you have series of short horizons, you're not optimizing as well as you could, and spend too much time rebuilding stuff in an incoherent architecture. But the business seems to prefer the short horizon, for various reasons (one might be simply competition, the red queen effect of sorts). I think from an engineering perspective, this is a mistake (there is a reason why we don't build houses in "agile" way), but I came to recognize that neither side is actually "right". But I am going to appeal, if you are trying to build software that lasts, think about your time horizon, maybe you will find that you can actually use the past approach better, if your horizon is longer.