Games are developed with huge teams, a large proportion of whom are artists of some stripe. They are performance-critical and have an urgent business reason to eke out every last scrap of performance. Most games are a one-shot release and few can even offer patches, let alone iterate. Budgets run into the many millions and deadlines are usually strict. They are usually paid for up front by a third party who bears all the risk and sets all the requirements. To me, they seem more akin to Hollywood movies than the type of software most Hacker News readers work on every day.
As a business software developer running a small shop, I have no more to learn from a game developer than a bicycle mechanic has to learn from NASA. We are solving totally different problems on a totally different scale.
The author points out, for instance, that the cost of change increases exponentially as the development continues. This is entirely correct in a game shop, where code bases are huge hairy balls of C and where vast amounts of art assets are necessary. As a web app developer writing clean, simple Python, I could rebuild most projects from scratch in a matter of days. My code is invariably based on sophisticated frameworks that reduce boilerplate code to an absolute minimum and make change cheap and easy. Of course, one of the goals Agile is to minimise sunk costs, iterate as early as possible and avoid writing unnecessary code, but that is beside the point.
In my opinion, Agile and Customer Driven Development are two sides of the same coin. I see little point in one without the other. If I am developing a business administration tool, I can solve many different problems and many subsets of those problems. There are innumerable possible solutions to each of these. My job is as much a process of discovery as it is development. A game developer produces an entertainment product, a monolithic entity based on a creative idea.
For a game developer, there is no minimum viable product. No game developer suddenly realises that their customers really want a different kind of product altogether. They know what their software has to do, they know their target demographic, they know their marketing channels, they even know their price point. As long as they meet the spec and the deadline, they get paid, regardless of whether anyone actually buys the software. Of course Agile would seem ridiculous to a game designer because they face none of the challenges and get none of the benefits of the teams that pioneered Agile.
To be more than a little blunt, I think that the author has been brain-damaged by writing games. He doesn't seem to realise that his part of the industry is a complete outlier. He may well be a very good games developer, but he seems to know little to nothing about the broader software industry.
He also seems to be completely unaware of the business of software, beyond shipping to a publisher - if he was aware that 96% of commercial games projects failed to turn a profit, he might be a little more sympathetic towards the "rotting corpses of software projects" that he so derides, and might understand why companies choose agility and responsiveness over efficiency.