|
 In
this article in the series on Extreme Programming, Pradyumn Sharma
discusses how simplicity is the key word in design, and how design
evolves
Conventional software development has often been
likened to a waterfall. You gather and document the requirements,
analyse and design to fulfill those requirements, the programmers
then implement the code, and then you deploy the system.
Contemporary wisdom favours iterative and incremental
development. Instead of developing and deploying a large and complex
system in a big-bang delivery, you evolve the system through a series
of iterations, each iteration providing incremental functionality
over the previous ones. The larger and more complex the system,
and the more unstable the requirements, the smaller the iterations
you should work with.
Small waterfalls
The more formal methodologies like the Rational
Unified Process (RUP) usually talk in terms of two to eight weeks
as the typical iteration size. Most iterations have requirements
determination, analysis and design, implementation, and deployment.
Since this cycle repeats from one iteration to another, such an
approach is usually considered as consisting of small waterfalls
within each iteration.
Extreme Programming (XP), as seen in the earlier
articles, recommends small iterations of one to three weeks. You
more requirements (the customer writes user stories), you design,
and implement more in each iteration. Though you do not deploy after
each iteration of one to three weeks, you nevertheless measure the
progress by establishing that acceptance tests run for the user
stories you claim to have implemented.
Thus, the waterfalls in XP are tinier. So tiny
in fact that it would be difficult to justify calling them waterfalls,
since within a single iteration, there is no clear separation between
design and implementation.
No architecture?
So what exactly is the XP approach to design?
To begin with, in XP there is no architecture phase. Instead, XP
uses a metaphor to provide a big picture of what the system is supposed
to do.
What is a metaphor? It is a simple story of how
the system works. The story uses common terms that everyone—from
the customer to developers—understands in the same way. In
technical terms, the story typically involves a small number of
classes and patterns that shape the way that the rest of the system
is built.
Simple design
One of the core values of XP is simplicity. And
no other practice of XP illustrates this better than its focus on
keeping the design of a system simple. XP strongly recommends against
doing too much design in anticipation of future requirements or
features that would be nice to implement.
In the first iteration of the project, you take
up a few user stories to implement. You do the necessary design
for these stories and write the code. Of course, you first write
the test cases.
How much design do you do while implementing
the user stories for the first iteration? It depends upon how stable
the requirements are.
Designing for unclear requirements
If the requirements are unclear or are likely
to change rapidly, there is no point in doing too much design for
anticipated features of future iterations, because the requirements
may have changed by then. Providing too much flexibility that may
help in incorporating the requirements of future iterations may
look smart, but if such flexibility never gets utilised because
of the volatile nature of the requirements, then providing for them
is a waste of time. Besides, it is likely to make the design unnecessarily
complex.
In the face of unclear or changing requirements,
design only for the amount of functionality that you are sure of.
In other words, design only for the user stories to be implemented
in the current iteration. Do not design for the functionality to
be added in subsequent iterations. When you reach the next iteration,
evolve the design further to incorporate the functionalities of
that iteration.
Of course, in the first iteration, you may have
to decide about some important design mechanisms cutting across
user stories (e.g., authentication logic, maker-checker concept,
etc.) as well as ways of achieving the non-functional requirements
(e.g., local caching of data for good performance, etc.) that may
have a profound impact on the implementation of the user stories
to come. Your design will still include only what is essential for
the user stories being implemented in the current iteration, and
not what may be required for future iterations.
Pros and cons
The benefit of this approach is that you stay
focused on delivering the greatest value to the customer, and do
not waste effort on things that do not deliver immediate value and
may not deliver any value later on.
Will this not lead to suboptimal design and wasted
effort in changing the design frequently?
This is where many of the practices of XP that
were discussed earlier come into the picture. Your team knows the
art of refactoring, and therefore, as new functional as well as
nonfunctional requirements surface in subsequent iterations, requiring
modifications to design, you can easily refactor your existing code.
Refactoring, in turn, is easy because you have automated test cases
for everything. You are also doing pair programming, so you are
likely to do a simple but correct design, and not a stupid design.
When the requirements are clearer...
Of course, when the requirements are relatively
clearer and more stable, then you would look at future iterations,
and provide for tomorrow’s solutions by designing for them
today. You can generalise things by considering future user stories,
provide the hooks for specific behaviour for variations, etc.
But remember, you are taking a chance that if
the customer withdraws those requirements that you are anticipating
today, you will still end up wasting your effort. Or, you may discover
better ways of doing the same thing before they are really needed.
In which case, your current effort may be in vain.
Even when the requirements are fairly clear and
stable, draw a line about how much design to do in anticipation.
With the techniques of refactoring in your arsenal, you can always
reorganise your design without wasting too much effort.
Pradyumn Sharma is the CEO of Pragati Software.
He is a trainer and consultant in the areas of Object-Oriented Analysis
and Design and Extreme Programming. E-mail: pradyumn.sharma@pragatisoftware.com
|
