The Fall of Waterfall

To me, game development has always seemed like business application development-plus. Game development comes with all the trappings of general software engineering with the added problem of not only having to be functional, but also fun. Beyond that, there are also the elements of art, audio, and story that we inherit from the film industry. Therefore, I couldn’t help but find it interesting when David Gregory kicked off a recent Gamasutra article on iterative development with these words:

Building interactive fun is a very different problem than building any other type of software, because “fun” can’t be planned: you can’t schedule a project with waterfall, execute the schedule perfectly, and expect to get a fun game 100% of the time at the end.

David is right on at least one count— you can’t plan fun— but I think what he fails to realize, or at least failed to point out, is that software development in general is already a tremendously difficult task to plan right from day one, and we as an industry inherit all of that baggage and create even more. Frederick P. Brooks told it like it is back in 1975 when he explained how the waterfall simply falls apart once projects reach a certain size. It’s simply not a viable method for developing software; but why then was it ever adopted in the first place?

In the early days of software engineering, people looked at the process of software creation just like any other engineering task— you start with the design, build the foundation, bring pieces together to construct the whole, test its reliability, and proclaim it finished. As scopes grew larger and stakes got higher, software engineers started to realize that building software is not like building a house, after all. Indeed, as Brooks explained, software isn’t actually built at all, rather it is more akin to being grown.

The problem? Requirements change, designs change, even visions change. The more clients begin to see their products coming into fruition, the more they realize that it isn’t what they need. Some key functionality may be missing, or perhaps something just can’t be done within a reasonable timeframe for a reasonable cost. Whatever the reasons, more often than not, it happens.

So what’s the solution, then? For most companies, it’s adopting good iterative processes and adhering to established best practices. For game development, we need to take it a step further. Our work is very much like IT development, but in some ways even more necessitates the use of practices that reduce failure, show consistent progress, and make the product as good as the vision that gave birth to it.

Getting past that initial head-scratching statement, David’s article does a good job of addressing a lot of the major issues surrounding iterative development and how to make the most of it with game development. So definitely, go check that out and tell me your thoughts.

For next time, I’ll try to have something to talk about besides other people’s opinions.