Page 67 -

52 BERENTE AND LYYTINEN
Both modern and traditional practices focus on iteration as reactive fixes or improvements based
on new information, or uncovered problems. Many modern methods, however, also anticipate
the need for and inevitability of new information, and proactively seek it. Thus, the difference is
not the presence of iteration, but, rather, the timing and visibility of it. With earlier visibility of
iteration needs, designers invite user input and thus relinquish a certain amount of control over
iteration decisions. Because this visibility is staged earlier, its granularity with regard to founda-
tional details and assumptions of the system development is also greater. Fundamentally, “iterative
development” is not necessarily more iterative. But it is likely to be more open, and the control
over iterations is shared and at a much more detailed level.
Consider the code as an iterating artifact, for example. All application software iterates over
its life even if its design methodology is the systems development life-cycle model (Davis, 1974).
Each version of a software system can be considered an iteration. As bugs are fixed or enhance-
ments added to code—even if consistent with the linear life-cycle method—any new instantiation
of code can be considered an iteration. When all or some portions of the code are compiled, the
result is an iteration of compiled code. Anytime a designer replaces or adds to any part of working
code, he has iterated over that code.
In the traditional life-cycle method, however, the user is not highly involved beyond listing
requirements. Management is not aware of each subsequent iteration, but sees only the code that
is presented at key milestones. The bricolage of everyday workarounds, failures, and changes is
neatly hidden from everyone except the designer himself—as are micro-level assumptions and
decisions that can have disproportionately large impacts on path-dependent future designs. As sys-
tems development has become more “iterative,” the veil hiding this practice has been progressively
lifted. Prototyping invited other developers, users, and managers into discussions at a more granular
level of detail sooner during development. When participating in this activity, those parties adopted
more control over the process. Risk analysis (Boehm, 1988; Lyytinen, Mathiassen, and Ropponen,
1998) that focuses on continued risk mitigation—rather than overly detailed requirements that
draw no real distinction of risks—exposes the key requirements of design to scrutiny outside of
developers. Pair programming (Beck, 2002) opens ongoing moment-by-moment deliberations
of an individual developer to observation and demands a dialogue with a fellow developer. This
observation indicates that the key contingency for distinguishing the level of iteration between
development practices is not whether one engages in evolutionary prototyping or not. Observations
such as the following indicate that a focus on iteration as such may be misplaced:
• user involvement is a more important determinant of project outcomes than presence of
iterative development (Lichter, Schneider-Hufschmidt, and Zullighoven, 1994);
• the success of any development, iterative or not, depends more on developer experience than
anything else (Boehm, 2002); and
• for “iterative development” to succeed, the complementary practices such as co-location,
pair programming, and so on are essential (Beck, 2002).
Therefore, it is not the presence of iteration that primarily determines the outcomes of systems
analysis and design activity. Rather, these outcomes are determined by the activities that the types
and forms of iterations can enable and constrain. The black box of iteration should be opened
to understand structures and affordances of prescribed iterations and complementary processes,
and their effect on design process and its outcomes. Rather than asking whether an organization
should adopt “iterative development,” it is more applicable for organizations to ask what level of
granularity, visibility, and control over changes and decisions about design objects and processes
is appropriate at different times, and for different purposes of the design.