Page 85 -

68 Chapter 3 Agile software development

Task 1: Change Dose of Prescribed Drug
Task 2: Formulary Selection

Task 3: Dose Checking
Dose checking is a safety precaution to check that
the doctor has not prescribed a dangerously small
or large dose.
Using the formulary ID for the generic drug name,
look up the formulary and retrieve the recommended
maximum and minimum dose.
Check the prescribed dose against the minimum and
maximum. If outside the range, issue an error
Figure 3.6 Examples message saying that the dose is too high or too low.
of task cards for If within the range, enable the ‘Confirm’ button.
prescribing medication.

A general problem with incremental development is that it tends to degrade the
software structure, so changes to the software become harder and harder to imple-
ment. Essentially, the development proceeds by finding workarounds to problems,
with the result that code is often duplicated, parts of the software are reused in inap-
propriate ways, and the overall structure degrades as code is added to the system.
Extreme programming tackles this problem by suggesting that the software
should be constantly refactored. This means that the programming team look for
possible improvements to the software and implement them immediately. When a
team member sees code that can be improved, they make these improvements even
in situations where there is no immediate need for them. Examples of refactoring
include the reorganization of a class hierarchy to remove duplicate code, the tidy-
ing up and renaming of attributes and methods, and the replacement of code with
calls to methods defined in a program library. Program development environments,
such as Eclipse (Carlson, 2005), include tools for refactoring which simplify the
process of finding dependencies between code sections and making global code
modifications.
In principle then, the software should always be easy to understand and change as
new stories are implemented. In practice, this is not always the case. Sometimes
development pressure means that refactoring is delayed because the time is devoted
to the implementation of new functionality. Some new features and changes cannot
readily be accommodated by code-level refactoring and require the architecture of
the system to be modified.
In practice, many companies that have adopted XP do not use all of the extreme
programming practices listed in Figure 3.4. They pick and choose according to their
local ways of working. For example, some companies find pair programming help-
ful; others prefer to use individual programming and reviews. To accommodate dif-
ferent levels of skill, some programmers don’t do refactoring in parts of the system
they did not develop, and conventional requirements may be used rather than user
stories. However, most companies who have adopted an XP variant use small
releases, test-first development, and continuous integration.