For anyone working in software development, this paper “No Silver Bullet – Essence and Accident in Software Engineering” from way back in 1986 is a must read.
In fact, the paper by Fred Brooks should be a regular read and reread to bring us all back down to earth as we work through software development projects trying to meet every complex and demanding requirement presented to us.
While advancements such as agile (particularly) and others have moved software development on from 1986 in ways that Brooks approved of (incremental development), he does ominously point out that “building software will always be hard”, primarily down to, he says, “complexity, conformity, changeability and invisibility”.
For his description of those 4 challenges to software development, the paper is definitely worth a read – much of it as true today as it was 30 years ago (4 years after many of us started into the more complex programming on our ZX Spectrum machines).
It’s his notes around software complexity that are of particular interest to me in my role as a business analyst and deliverer of software for use by my clients and users. I see it as my role to balance the understandable desire of project stakeholders to simplify things as much as possible with maintaining a keen focus on the complexity of any development.
(On rereading this myself, I can see the difficulty in that statement. In other words, users requesting software functionality will always consider their needs as “I just need”, or “I only want”, whereas it’s often quite likely that the underlying software development required to satisfy just or only can be quite tricky, involved, and complex.)
Brooks refers to “the complexity of software (being) an essential property, not an accidental one”.
It is similarly essential for me as a business analyst to identify, understand and explain the necessary complexity in a software development project, but to do so in a way that keeps my stakeholders on board.
But more importantly, to do so in a way that doesn’t lead to what Brooks refers to quite beautifully as:
descriptions of a software entity that abstract away its complexity often abstract away its essence
Allowing such simplifications and assumptions seep into people’s understanding of what a project is about will only lead to an incomplete delivery.
A note on Brooks’ comments on changeability – that “all successful software gets changed”. I think this gives an interesting perspective on what we create as software professionals.
In most other cases where anything is manufactured, the item subsequently is never changed (e.g. a car or a washing machine), or is only changed when something goes wrong (e.g. the exploding Samsung Galaxy Note).
On the other hand, good working software will inevitably be requested to do more, and handle more scenarios, and process everything faster and more efficiently. Unfortunately, and for discussion at a later date maybe, bad software is rarely changed – it’s frequently tolerated and worked around until it’s very quickly dumped.
The paper also includes a very interesting discussion on where artificial intelligence (AI) might provide a “revolutionary breakthrough that will give order-of-magnitude gains in software productivity and quality”.
Brooks in 1986 didn’t think that it would. Going out on a limb here, but when it comes to the vast majority of software development that’s going on in day to day systems for most organisations, I don’t think he’s been proven wrong. Maybe I’ll add a caveat to this statement – in most legacy / monolithic type organisations where legacy code is more prevalent.
Business Analyst is King(?)
Finally, and not just out of “business analyst” self-interest, I must highlight where Brooks does point out some of the “abundance of good work going on now (i.e. 1986), and the promise of steady, if unspectacular progress”. While these developments wouldn’t provide the “magic bullet” to improve software development as much as hardware had / has developed over the years, he does highlight the importance of the business analyst in attacking the essence of the software problem – the complexity referenced earlier.
Okay, so he doesn’t directly reference a business analyst, but in his “Requirements refinement and rapid prototyping” section, Brooks states that “the most important function that software builders do for their clients is the iterative extraction and refinement of product requirements”.
He goes on to point out that, when it comes to detailed technical requirements, “no other part of the work so cripples the resulting system if done wrong”, and “no other part is more difficult to rectify later”.