6.4. Project Management Strategies¶

Waterfall

Historically, the first formal software design methodology was known as the waterfall method: first you design the entire game on paper, then you implement it (programmers start writing code, artists working on art, etc...), then you put the pieces together, do some testing - fix any obvious issues, and then you ship it.

Waterfall is so named because, like water in a waterfall, once you drop off an edge there is no going back. It is based on the assumption that the design can be completed in isolation in a reliable fashion and that once that design is done, you probably won’t have to go back and make any substantial changes. This approach was ported to the world of software from physical engineering projects. In the world of physical engineering, common problems and their solutions are pretty well understood - engineers can sit down and design something and have their be a high probability that the basic design is sound.

At some point, people realized that things don’t always work that way in software. When doing creative design work to solve new problems, it is harder to come up with a design that works perfectly the first time. While this is true of physical engineering projects as well (think of the cost overruns typical of new military fighter jet programs), software by its nature tends to involve more solving of new problems. The field is so young that just about every project involves doing something new.

Iterative

The alternative is what is known as an iterative approach. As with waterfall, you first do design work, then implement it, and then test it to make sure it works. But in the iterative approach, there is an expectation that testing will often result in a failure that results in going back to the drawing board. In the waterfall approach, the assumption is that any fixes will be relatively minor ones that do not call into question the original design.

Even more importantly, iterative design focuses on breaking a project into separate features and doing the design/implement/test cycle on each individually. We don’t design a whole software package in detail all at once. Instead we come up with an overall rough design - a list of features we want to have; then we prioritize those features, figuring out which are most important; then we pick one feature at a time to implement. After we have designed/implemented/tested a feature and decided it is done, we move on to another feature.

This iterative style of development is the methodology behind the Minimum Viable Product. A piece of software that is built one feature at a time, starting with the most critical features is less likely to catastrophically fail at the last minute. Why? As we will see in the next stage, iterative design is about managing risk.