Does It Have To Be Hard?
In 1987 a software engineer and computer scientist by the name of Fred Brooks wrote a great article called: ‘No Silver Bullet — Essence and Accidents of Software Engineering’. Brookes argued that "There is no single development, in either technology or management technique, that by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity." Essentially, he was saying that there is no single solution to the problems we face when trying to deliver on time, on budget, and to the exact specification of a client’s set of requirements.
Help! We’re having a crisis!
Back in the late 60’s, early 70’s there was a period in software engineering known as the ‘software crisis’, a term first coined by some attendees at the first NATO Software Engineering Conference in 1968. This was the name given to the period when projects ran over budget, over time, didn’t meet requirements, were low quality and difficult to maintain. This was over 40 years ago. Does it sound familiar? Various processes and methodologies have been developed over the last few decades to try and tame the software crisis but what’s been generally agreed, as mentioned in Brooks’ paper, is there’s no silver bullet. Even today, well-planned projects can go off the rails.
Brooks Revisited
Brooks makes a distinction between ‘Accidental’ and ‘Essential’ Complexity: Accidental Complexity relates to issues that we create and therefore are able to resolve; for example the creation of high-level development languages, such as .NET, Java, PHP etc help developers be far more productive in the development process, more so than the ‘old days’ when developing in assembly language or worse… punch-cards.
Essential Complexity relates to the problem being solved by the software to be developed. Essential Complexity by definition cannot be removed: if a customer wants their website to do 20 different things then the solution must deliver those 20 things. By reducing Accidental Complexity to zero does not give us any significant improvement to the problem.
Let’s follow Brooks’s ‘conversation’ as he describes the problem of Essential Complexity:
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
“…the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem in the detail necessary for specification.
“…it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.”
What about Agile?
Some time ago Bullseye chose to address these all-too-frequent issues by making Agile our preferred approach to project delivery.
The Agile Manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
There are twelve principles behind the Agile Manifesto:
-
Customer satisfaction by rapid delivery of useful software
-
Welcome changing requirements, even late in development
-
Working software is delivered frequently (weeks rather than months)
-
Working software is the principal measure of progress
-
Sustainable development, able to maintain a constant pace
-
Close, daily co-operation between business people and developers
-
Face-to-face conversation is the best form of communication (co-location)
-
Projects are built around motivated individuals, who should be trusted
-
Continuous attention to technical excellence and good design
-
Simplicity
-
Self-organising teams
-
Regular adaptation to changing circumstances
A bit more from Brooks
“Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision – revision that provides for iterative development and specification of prototypes and products.”
“Incremental development – grow, don't build, software.
So, even back in 1987 some of the key aspects of Agile: Customer satisfaction by rapid delivery of useful software, working software delivered frequently, were seen as the basis for successful software delivery.
So is Waterfall wrong? Nope! Bullseye continue to use waterfall where appropriate. Even in Agile projects we have some sequential or waterfall steps. We call this type of project ‘Wagile’.
Surely Agile is the Silver Bullet? Nope! Agile projects can fail as readily as waterfall, or any other method of delivering projects, though with Agile you get early visibility of issues. However, Bullseye believe that by using Agile and Agile principles we improve our chances of succeeding in the ultimate objective of any software project: giving our clients the software that they need rather than what they think they want.
Much of what is written above comes directly from Brooks’s article and I make no apology for that. The issues described in the article are as relevant in today’s Digital World as it was back in 1987. I urge everyone to read the full article (see link below), and perhaps even buy his book, “The mythical man-month”. In it, amongst many other topics, he describes Brooks's Law: Adding manpower to a late software project makes it later. But that’s a topic for some other time.
References:
· Brooks, Fred P. (1987). “No Silver Bullet — Essence and Accidents of Software Engineering” - http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
· http://agilemanifesto.org/
- Duncan Keir, National Solutions Director, Bullseye