Cliff Saran's recent article about software engineering becoming a lost art raised several thought provoking points about how we write software 40 years on from Apollo 11, writes Keith Richard, director at DSDM 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'.