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
   58   59   60   61   62   63   64   65   66   67   68