This was written from the point of view of a technical director of a gaming shop, but it's very much relevant to startup (and other) software development as well.
Games are freakshow software. They resemble practically nothing else in the software world in how they are produced and are practically the diametric opposite of the projects that spawned the Agile approach.
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.
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.
I don't see how this invalidates the point that bashing every non-agile method as waterfall and thus bad is wrong and that planning and establishing processes are not entirely evil but might even be beneficial if they are not overdone.
> "No game developer suddenly realises that their customers really want a different kind of product altogether."
Not true. Games publishers are known to change their mind at a moment's notice. I've also experienced sweeping changes after the product has been focus tested: it's an entertainment product so human experience is everything.
Designing for change is something you have to do in the games industry. This applies to the artists as well as the coders.
No game developer suddenly realises that their customers really want a different kind of product altogether.
Probably because they realize that their customers always want a different kind of product altogether. I've read a customer review of Dragon Age where the person thought it was terrible because it wasn't a first person shooter.
Imagine developing a billing system and having your customers complain because it wasn't a good word processing application.
He seems to really hate the idea of agile development, though he takes pains to deny that. It makes sense that he wouldn't really understand it in his world though.
One thing is for sure... the author got a high score on the verbal portion of the SATs. I got kind of bored half way through, but the words were entertaining.
