Incremental vs Iterative Software Development

Recently at my university, the fourth year students had the excellent idea of having a trivia night to help study for their upcoming Software Project Management exam. From the sounds of it the night went fairly well – I think anything that making studying even marginally fun is to be applauded. The questions were taken from the subject text book and one seems to have generated some controversy. The question was what is the difference between incremental and iterative lifecycles?

The general idea as retrieved from the Wikipedia is that they are, essentially, synonyms. Some of the students prefer to believe that there must be a difference because they are called different things! Personally I think that this reasoning doesn't hold as much ground in software engineering as one would think (there are several different names for a variety of things) but that's not what I'd like to discuss.

Since I love controversy, and I'd like to be able answer this question properly if I ever get asked, I did some digging into the topic of whether or not incremental and iterative really mean the same thing. I deliberately avoided the subject in question's textbook as I wanted an "unbiased" opinion and I'm sure that the students looked there already. Also, I don't own it myself!

The first place to look is from a purely linguistic point of view. Merriam-Webster's dictionary gives the following definitions:

iterative: involving repetition: as a : expressing repetition of a verbal action b : relating to or being iteration of an operation or procedure

incremental: of, relating to, being, or occurring in especially small increments

So it would seem that there are two things to note here:

  1. iterative implies repetition
  2. incremental implies small changes

From there we can go on and see what other software engineers have said about the subject. Let's first look at a favourite book of mine – The Pragmatic Programmer. Here's an excerpt from page 68 (emphasis mine):

This needn't be a paradox if you practice incremental development, repeating the following steps. … Initially, you may have only a vague idea of how many iterations will be required or how long they may be. … So you complete the coding and testing of the initial functionality and mark this as the end of the first increment. Based on that experience, you can refine your initial guess on the number of the number of iterations and what can be included in each.

From this it seems obvious that Andy Hunt and Dave Thomas consider increment and iteration to mean the same thing. They use the words interchangeably. Mark another one off in the "synonym" column.

The next quote is pulled from Code Complete by Steve McConnell (on page 850; emphasis again mine).

Iteration is appropriate for many software-development activities. During your initial specification of a system, you work with the user through several versions of requirements until you're sure you agree on them. That's an iterative process. When you build flexibility into your process by building and delivering a system in several increments, that's an iterative process. If you use prototyping to develop several alternative solutions quickly and cheaply before crafting the final product, that's another form of iteration. Iterating on requirements is perhaps as important as any other aspect of the software-development process. Project fail because they commit themselves to a solution before exploring alternatives. Iteration provides a way to learn about your product before you build it.

This is interesting. McConnell seems to be saying much the same thing as Hunt and Thomas but his focus is entirely on the word iteration – increments are mentioned as being a subset of iterative development. Looking at some of McConnell's other books (Rapid Development, Software Project Survival Guide) I get the impression that an increment is something that encapsulates the construction process itself (detailed design, coding and testing), rather than something that can be applied at any point. Rapid Development gives this further definition of incremental:

Incremental Development Practices

The phrase "incremental development practices" refers to development practices that allow a program to be developed and delivered in stages. Incremental practices reduce risk by breaking the project into a series of small subprojects. Completing these subprojects tends to be easier than completing a single monolithic project. Incremental development practices increase progress visibility by providing finished, operational pieces of a system long before you could make the complete system operational. These practices provide greater ability to make midcourse changes in direction because the system is brought to a shippable state several times during it's development – you can use any of the shippable versions as a jumping-off point rather than needing to wait until the very end.

Lifecycle models that support incremental development include the spiral, evolutionary-prototyping, staged-delivery, and evolutionary-delivery models.

Again, McConnell doesn't mix the words around: he uses increment every time and makes no mention of either iterations or repeating things. Instead, he provides us with something closer to what the English definition of incremental means, namely "doing something in small parts". We already have some contradiction!

The next source is Balancing Agility and Discipline by Barry Boehm and Richard Turner. When describing agile methods, the following descriptions are given on page 17:

A truly agile method must include all of the following attributes: iterative (several cycles), incremental (not deliver the enitre product at once), …

So here, we see that Boehm and Turner are also of the opinion that they mean two different things. These (brief) definitions seem to be in line with what McConnell was talking about in his works. Iterative means to repeat the software development process several times (hopefully improving things each time); incremental means to break up the product construction into smaller, more manageable, pieces. Incidentally, the book mentions these practices as being useful for non-agile projects as well.

Next I consulted another agile book, Alistair Cockburn's Agile Software Development, for this excerpt:

That people make mistakes is, in principle, no surprise to us. Indeed, that is exactly why iterative and incremental development were invented.

Iterative refers to a scheduling and staging strategy that allows rework of pieces of the system.

Iterative development lets the team learn about the requirements and design of the system. Grady Booch calls this sort of learning "gestalt, round-trip design", a term that emphasizes the human characteristic of learning by completing.

Iterative schedules are difficult to plan, because it is hard to guess in advance how many major learnings will take place. To get past this difficulty, some planners simply fix the schedule to contain three iterations: draft design, major design, and tested design.

Incremental refers to a scheduling and staging strategy in which pieces of the system are developed at different rates or times and integrated as they are developed.

Incremental development lets the team learn about its own development process as well as about the system being designed. After a section of the system is built, the team members examine their working conventions to find out what should be improved. They might change the team structure, the techniques or the deliverables.

Incremental is the simpler of the two methods to learn, because cutting the project into subprojects is not as tricky as deciding when to stop improving the product. Incremental development is a critical success factor for modern projects.

There seem to be a small few differences in what Cockburn is saying here but overall it is similar to what McConnell and Boehm and Turner are saying. Cockburn does point out the inherent difficulty in knowing how many iterations one will need for a project, which is good to think about. He also points out that the splitting of a large project into smaller subprojects is extremely important for the success of a project. This possibly differs from what the others have been saying in that they emphasise that it is the product that is split up and not the project. I think this is largely an academic distinction as any development on a small piece of the product would necessitate a small team, a subproject, to be created to develop it.

I think it's time to include the IEEE definition of the two terms. It seems that the current IEEE standard glossary of software engineering terminology is woefully out of date. The active version was released in 1990 – nearly two decades ago! This isn't uncommon with IEEE standards though so here's what it says:

incremental development. A software development technique in which requirements definition, design, implementation, and testing occur in an overlapping, iterative (rather than sequential) manner, resulting in incremental completion of the overall software product. Contrast with: waterfall model.

There is no definition given for iterative development. From this it appears as though the IEEE terminology considers them the same thing. Incremental development is referred to as being iterative in nature, which would make iterative development redundant. Looking in the guide to the SWEBOK results in a similar discovery, except that they at least refer to this type of life cycle model as "incremental/iterative delivery".

The book Managing Iterative Software Development Projects, by Kurt Bittner and Ian Spence, gives an interesting take on the debate:

To be truly effective, the development must be both iterative and incremental. If development is iterative without being incremental, activities can be performed over and over again in an iterative fashion without advancing toward the project's goals, or in other words, without reducing risk and incrementally building the solution. Progressive risk reduction and a steady march toward the project's goals are the hallmarks of iterative and incremental development. For the sake of simplicity, when we refer to iterative development, we mean both iterative and incremental.

Here the authors are really referring to the English definitions of the words and how they are used by other software practitioners. I think that this is a good way to go about things. Even based on the definitions previous that have iterative and incremental as separate things, it is clear that they are not mutually exclusive and are, in fact, almost symbiotic in nature.


From all this research I've come I've decided that iterative and incremental do mean different, albeit subtle, things in software engineering. My definitions would be something along the lines of:

Iterative development
A software lifecycle model that involves the repetition of all process to do with software development: requirements, architecture, detailed design, coding, integration, testing and release. Each iteration involves taking what was done before and improving it by either adding in new functionality or refining the existing product. This also applies to the development processes.
Incremental development
A software construction process that involves breaking the final product into smaller, yet working, pieces of software. Each of these can be worked on sequentially or in parallel.

What I'm trying to get at is that I think iterative development implies a more high-level concept than incremental, which focuses more on the actual building of the software and not necessarily the processes before and after it. This fits in well with the English definitions of the words and is fairly intuitive, at least for me.

Although, having said that, if I was pressed I'd refer people to Bittner and Spence's disclaimer about the relationship between the two concepts. I think that, if you are actually going about trying to develop software, it is much better if you try and incorporate both ideas into your processes, rather than try and pick one to do.