

Game Development in a Post-Agile World - mmastrac
http://gwaredd.blogspot.com/2010/02/game-development-in-post-agile-world.html

======
jdietrich
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.

~~~
megaduck
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.

~~~
jdietrich
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.

~~~
megaduck
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.

There should be room for both perspectives here.

~~~
jdietrich
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.

~~~
teamonkey
> "it argues that agile is complete claptrap."

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.

------
mmastrac
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.

~~~
ra
Seemed more of a confused, high level ranting to me.

------
andrewljohnson
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.

