Page 136 -

when software teams adopt good requirements engineering practices, they find that these
problems are greatly reduced, and that their projects go much more smoothly.

Iteration Abuse
Iteration, or the repetition of a particular task or activity with the goal of improving its
main work product, is a practice employed by many programmers. There are several pop-
ular development methodologies (Extreme Programming and Rational Unified Process, for
example—see Chapter 12) that rely on iterative development. These methodologies use
iteration effectively, by planning and executing a series of small steps that build on previ-
ous iterations to produce a series of intermediate builds; each successive build adds new
functionality to a previous build. Each build is intended to be production quality, and is
fully tested. Changes are controlled by having each new iteration concentrate on adding
new functionality, rather than making many changes to existing behavior.
However, many software teams abuse iteration. They do not use successive iterations to
add new functionality to a build that is already production quality. Instead, the iterations
are meant to be a sort of guessing game. The first iteration is presented to users and stake-
holders, who are expected to tell the programmers what’s wrong with it. The program-
mers then go back, fix those things, and deliver a second build, which the users and
stakeholders again correct. This is expected to continue until the software does everything
that the users and stakeholders need it to do.

This sort of iteration makes intuitive sense to everyone involved. The programmers like it
because they can dive right into the project and do what they do best: program. And it
feels right to the users and stakeholders as well, because it’s much less work for them than
sitting down and really thinking about what they need out of the software. All they have
to do is play with the demo versions and give their opinions.

Unfortunately, this is all too good to be true. The first iteration is easy to deliver—expecta-
tions are low, and people are excited to get their hands on a build so quickly and to give
their input. The next iterations seem to be doing their job, and the software does look like
it’s starting to get better. But as the software gets more complex, each iteration takes
longer and longer to do. There seem to be more bugs in each new build. The programmers

find that they have to take more time to rip out things that they put in earlier. The code
starts to degenerate into an unmaintainable mess because the programmers keep patching
and repatching code that they should have built differently in the first place. The iterations
finally end, but not with fully working software. Rather, the users and stakeholders get
increasingly fed up with long delays and with buggy software that doesn’t do what they
need. They eventually settle on a build that is close enough to something that fulfills their
needs; they can concoct workarounds for any remaining problems that keep them from
getting their work done.

This sort of “iterative” development falls apart because software is difficult to change. After
an object or function is written, it is generally used elsewhere in the code. The objects or
functions that reference it, in turn, are called from other objects or functions, and so on.

128 CHAPTER SIX