Cliff Saran'srecent articleabout software engineering becoming a
lost art raised several thought provoking points about how we write
software 40 years on fromApollo 11,writes Keith Richard, director
atDSDM
Consortium
However, a central thrust to the article was that the quality of
source code is now poorer. This is a moot point and does not take
into account the context in which software development takes place
today and the relative merits of the various agile development
processes.
One of the most fundamental questions to be asked about software
development is 'is it a science?' In many ways it is, but in many
ways it isn't - it is also an art.
In the early days, software development processes were taken
straight from the engineering paradigm and very soon the term
'waterfall' was coined despite the best efforts of people like
Royce, who suggested that this linear approach was flawed when
creating software, which was a lot more malleable than a rocket
booster, for example.
Speed to market
There is a need for agile approaches in today's marketplace
because, unlike 40 years ago, speed to market and adaptable design
are essential to create viable software. When developing software
to hit tight deadlines there is a need to adapt and adjust to meet
a customer's requirements, because those requirements will not
necessarily be understood in black and white terms at the outset of
a project. Pragmatism and realism are needed to handle the large
areas of grey that exist on most projects.
Does this excuse a drop in the quality of source code? No it
does not! In fact, the appropriate use of a suitable agile
development process actually protects the desired level of quality
and increases the likelihood of achieving this more than the
linear/waterfall processes which, 40 years on, struggle to stand up
to the commercial realities of delivering software.
So why has agile development created this perception of poorer
code? The answer is quite simple: in the rush to be pragmatic,
reactive, responsive and quick, there is also the need to be very
disciplined - just like the programmers on Apollo 11 - and this
doesn't always happen.
Choose the right approach
It is essential that the right agile approach is used and used
in the right way. Cliff Saran's article referred to several
fashionable agile approaches but they need to be positioned and put
into context. Some are good at certain things and not good at
others.
Extreme programming is an incredibly powerful agile approach
and if used appropriately is excellent at helping to deliver code
of the appropriate quality.
However, extreme programming is a software delivery approach,
not a project management approach. What do you do about the things
extreme programming doesn't do, such as managing the software
engineers? Extreme programming does not contain the formal project
management or governance disciplines needed to be agile 'at the
coal face'.
Scrum offers a small, simple to use approach at the
delivery/coding level. Used in this context it performs well, but
when scaling up lighter agile methods to work on projects involving
tens or hundreds of people how are you going to control the
project? Where's the governance? Where's the rigour?
If I were an astronaut and told that all of the IT on board a
rocket had been written using Scrum or extreme programming alone, I
wouldn't get on it.
Code and fix
The reason why agile development is starting to build a
perception of 'organised hacking' or 'code and fix' is because the
agile methods in today's marketplace are often misunderstood or
misused. They need to be used at the right level of a project and
when they are scaled up this needs to be done very carefully.
This is where more formal approaches to projects can be adapted
to fit with the new agile wave. An example would be
Prince2, which is not often seen as agile but certainly can be
if implemented appropriately with the correct agile approaches
sitting underneath.
DSDM
Atern is another long-established project management approach
that embraces the agile mindset. It does this by blending the
pragmatism of managing the detailed scope of a project with the
need to ensure that strategic alignment and firm governance are not
compromised. This in turn leads to a greater probability of
shipping software at the right level of quality.
There is no reason for agile approaches to produce inferior
quality software to traditional approaches. In fact, quite the
opposite. However, there is a very big qualification that needs to
be made here: you must use the right approaches at the right level
in the right way. You can hit a nail into a piece of wood with a
pair of pliers if you want to, but you would be far better using a
hammer.
Agile needs to sit in a strong project management environment.
With this you get 'agile with rigour', without it you get 'fragile
agile'.