Page 63 -
P. 63
48 BERENTE AND LYYTINEN
This idea of iterative enhancement forms the foundation of evolutionary prototyping and
recent agile methods. Agile methods are based on the assumption that design communication
is necessarily imperfect (Cockburn, 2002), and that software design is a social activity among
developers and users. A popular agile methodology—extreme programming (XP)—promotes a
variety of iterative practices such as pair programming (cognitive iteration during each design
step through dialogue), test-first development (generating test information that guides subsequent
iteration), and refactoring (iterating the software artifact during each cycle) (Beck, 2002). The
structure of XP is almost identical to the early evolutionary design, where limited functionality is
first developed, and then incrementally expanded. However, XP can take advantage of a number
of software tools that were not available to early software developers. Powerful toolsets are now
available that enable unit testing, efficient refactoring, and immediate feedback, while object-
oriented environments allow for modular assembly of significant portions of the system. Also,
process innovations such as testing-first, time-boxing, collocation, story cards, pair programming,
shared single code base, and daily deployment mitigate the communication problems found in
earlier evolutionary processes.
The Promise of “Iterative Development”
The justification of evolutionary prototyping, or more commonly “iterative development,” centers
on trial-and-error learning about both the problem and solution. Users and developers do not know
what they need until they see something—similar to Weick’s (1979) illustration of organizational
sensemaking: “how can I know what I think till I see what I say?” Thus generating prototypes
assists communication better than traditional abstract upstream documentation and thereby sup-
ports mutual learning (Alavi, 1984; Basili and Turner, 1975; Beck, 2002; Boehm, 1981; Brooks,
1995; Cockburn, 2002; Floyd, 1984; Keen and Scott Morton, 1978; Larman and Basili, 2003;
McCracken and Jackson, 1982; and others). We now review some of the anticipated outcomes
associated with iterative development.
Anticipated benefits of evolutionary, or “iterative development”, are many. By “growing” the
design, software can be developed more quickly (Brooks, 1987). Beyond speed, evolutionary
development enables a “more realistic validation of user requirements,” the surfacing of “sec-
ond-order impacts,” and a greater possibility of comparing alternatives (Boehm, 1981, p. 656).
Prototyping demonstrates technical feasibility, determines efficiency of part of the system, aids
in design/specification communication, and structures implementation decisions (Floyd, 1984).
Prototyping is thought to mitigate requirements uncertainty (Davis, 1982), aid in innovation, and
increase participation (Hardgrave, Wilson, and Eastman, 1999), reduce project risk (Boehm, 1988;
Lyytinen, Mathiassen, and Ropponen, 1998; Mathiassen, Seewaldt, and Stage, 1995), and lead to
more successful outcomes (Larman and Basili, 2003). Because developers generate code rather
than plan and document, they are expected to be more productive (Basili and Turner, 1975; Beck,
2002; Larman, 2004). Therefore, projects using evolutionary prototyping can be expected to cost
less (Basili and Turner, 1975; Beck, 2002; Cockburn, 2002; Larman and Basili, 2003).
A problem often associated with strict evolutionary development, however, is the lack of
maintaining “iterative” process plans. Starting with a poor initial prototype could turn users away;
prototyping can contribute to a short-term, myopic focus, and “developing a suboptimal system”
can necessitate rework in later phases (Boehm, 1981). Exhaustive design documentation will still
be required even if prototyping forms the primary process (Humphrey, 1989). Also, the output
of evolutionary development often resembles unmanageable “spaghetti code” that is difficult to
maintain and integrate. These are similar to the “code and fix” problems that waterfall was originally