Iterative Development

Iterative Development is my shepherd I shall not want

There’s this old phrase, some call it the mantra of business, that says:

Fail fast, fail often.

Nowadays it’s regarded as a hype. Whether that’s true or not, it certainly describes very well something called iterative development.

When working on a project, there are several ways to break down and structure the whole development. For instance, there’s the infamous Waterfall model; a sequential approach where the project is divided into various steps that don’t repeat: just like a waterfall, backtracking is impossible. Usually, these steps are: requirements, design, implementation, verification and maintenance.

In Rework, authors Jason Fried and David Heinemeier Hansson (from Basecamp) talk about the nature of plans. They argue that «plans are inconsistent with improvisation», guesswork at best. There are many unknown variables at the start of a project (specially longterm ones) impeding a clear view of all the roadblocks on the way; roadblocks that may require expensive solutions. Sadly, the waterfall model operates this way; first the requirements are determined, then a solution is designed and later implemented, finishing with some QA and a wrap up of the project. But, what happens if the requirements change or a redesign is considered necessary?

Such philosophy probably comes from the industrial age, when businesses centered around factories with assembly lines. However, it doesn’t fit the 21st century.

Failures are bound to happen, the goal is to minimize their cost.

Iterative development is about approaching the desired state, one step at a time. Instead of planning all the steps beforehand, the next steps are calculated taking into account the current state of the system (roadblocks included). «Divide and conquer», as the famous quote goes by. Also, features and objectives are added as needed, making it easier to focus on what’s important now and not later; because of this, the method is also called incremental.

This methodology stands upon the iterative design philosophy popularly known as the scientific method: define a question, make an hypothesis of a possible answer, test it and collect data that can be reproduced, analyse such data, draw conclusions and create a new hypothesis from it; rinse, repeat. If this sounds familiar, maybe it’s because that’s the foundation of prototyping.

Now, although it may seem only of the interest of scientists and engineers, it’s also used by artists as well, albeit not explicitly.

Iterative Development applied to drawing

Michelangelo, the renowned italian renaissance artist, once said that sculpture was the «art of taking away». And like music, drawing, writing and plenty of other arts, sculpture is, by essence and practice, an iterative process. Game development is no exception.

Games are systems that can’t be designed once, they require testing and molding to fit the player’s needs and expectation. While QA is the hunt of software bugs, playtesting is in part the hunt for design bugs. Most of the times, what the designer thinks is natural or essential isn’t even close to what the user will actually experience.

Iterative Development, according to Spotify
Iterative Development, according to Spotify

How is it done? By creating a first draft containing the core mechanics and, as they get polished, adding new features into the mix.

For example, in Snap! I began using this approach. The first build had only the two core mechanics: movement and photo capturing in the most basic expression. It wasn’t until later builds that I added several ways to rate each photo.

Iterative development is as hard as the developer is disorganized. If clear local goals are defined, the results in the longterm will be beneficial. Just remember to reevaluate what you have compared to what you may want.

In other words:

while (!there) { Approach(); }

Do you have any particular story about iterative development? Leave your comments below.

Leave a Reply