Whoah, there. While your software may have nothing in common with games, there's a lot of software that does.
Products like TurboTax have similarly tight schedules and limited ability to patch. Business platforms like Oracle have massive game-like performance-intensive C++ codebases. Operating systems like OS X or Windows 7 also have big teams, tons of art assets, and a fixed ship date. There are a ton of software shops out there that can learn something from the author's original post.
Many of us on HN have the luxury of building server-based web apps. We live in a very pleasant world with minimum viable products, small codebases, and rapid iteration. However, let's not fool ourselves into thinking that this is the world that everybody else lives in.
Yes, but there are relatively very few of these huge products. While there are lots of people working on these huge projects, there are few managing them and even fewer with the seniority to decide on methodology.
If software is anything like the broader business world, then the overwhelming majority of software shops will be small shops. It stands to reason therefore that the overwhelming majority of people managing a software project will be managing a very small number of developers.
My statement about bicycle mechanics learning from NASA stands - there just aren't many people managing big projects. Game development has practically no relevance to practically all managers. I certainly can't imagine that many people reading HN are managing the development of an operating system or a DBMS.
If you happen to be building the pyramids of Giza, linear development is a good approach. For the rest of us, iteration is the only rational way of doing it.
I feel like we're talking at right angles. Your central point seems to be that most people will never build software like this. That's totally true, no contest.
However, I think it's still an interesting topic, and a significant minority can learn something useful.
I'd be more inclined to agree if the piece wasn't entitled "Games Development in a Post-Agile World". The central conceit of the article seems to be to debunk agile as a workable method. The article doesn't argue that agile is a hugely useful approach for most developers but a poor approach in some specific niches, it argues that agile is complete claptrap.
I will happily agree with you that there is room for a number of development methodologies.
No it doesn't. It says that Agile proponents who claim it's a silver bullet are talking claptrap. If anything, it says that Agile is a tool and you need to pick the right tool for the job.
Based on the Agile manifesto, the author proposes a scale with "people" at one end and "process" at the other. Ostensibly waterfall is strongly "process" and Agile is a more "people", but he argues that Agile consists of a number of elements that exist at different points along that scale.
He says that the elements down at the "people" end of the spectrum require good, experienced, self-motivated people. If you have these then Agile is more efficient. If you have juniors or average coders (more likely on a large team) then the overhead of a process-based system may work better.
He also identifies the points within the product's development lifecycle where Agile-like approaches work best and when the more hierarchical methods work best.
Products like TurboTax have similarly tight schedules and limited ability to patch. Business platforms like Oracle have massive game-like performance-intensive C++ codebases. Operating systems like OS X or Windows 7 also have big teams, tons of art assets, and a fixed ship date. There are a ton of software shops out there that can learn something from the author's original post.
Many of us on HN have the luxury of building server-based web apps. We live in a very pleasant world with minimum viable products, small codebases, and rapid iteration. However, let's not fool ourselves into thinking that this is the world that everybody else lives in.