The technological innovations that have changed human life so much in the last few decades, and those that will do so even more in the near future, are in software.
IT hardware is now seen as a mundane underlying entity needed to support software functionality. This sudden and dramatic change of emphasis is as important as the industrial revolution of the last century.
But the industrial revolution happened relatively slowly: with mistakes, but also with time for good principles and practices to be developed and refined. That is not the case for
software, and those of us who care about how good software is and how well it is produced cannot help but be keenly aware of the flawed, too diverse, often chaotic processes taking place and the great dangers of that.
So there is a tendency to think about how good manufacturing practices could be applied to software development. That is a good idea: Many are fond of pointing out that adhering more closely to some of them, in particular formality, would benefit many software organizations.
The mistake many such thinkers make – and it is a bad one – is to draw an analogy between manufactured physical products and software. There is no such analogy. The two things could not be less similar.
Software is not a car
A manufacturing process aims to achieve an optimal balance between quality, productivity and cost. It is sometimes appropriate and legitimate to compromise quality. For example if a plastic molding machine can produce, per minute, either 10 perfect toy soldiers, or 25 of which on average 5 are faulty, no-one would hesitate to turn up the speed.
The concept of tolerance exists for the same reason. The goal is not to keep all products as close as possible to the centre of the tolerance range. It is to make products that are anywhere within the range as quickly and cheaply as possible. All those products are useful.
Trying to apply this logic to software development will lead first to numerous errors causing waste and/or failure and then to software that does not meet its requirements and is a lot worse than useless.
The term manufacturing is often used to mean mass production, but software is not mass produced, nor even produced in small quantities as in, for example, manufacture by handicraft. We do not aim to produce a program more than once. Despite what some developers might say, there is no such thing as “inventory” in a software process. There is only unfinished work.
A better analogy can be drawn with fabrication: consider for example a metal works commissioned to produce a unique staircase for a certain building, to the customer?s unique specifications. If the product does not meet all of those specifications it cannot be fitted nor used and will rightly be rejected.
Perfect is the enemy of good enough
This aphorism does not mean that it is OK for delivered software to meet only part of its specification. That would be a contradiction in terms: its specifications define, precisely, what is good enough. Rather it means that it is a dangerous mistake to continue to improve any work product beyond the point where it meets its specifications. A design document, once it can be shown to implement everything in the requirements document upon which it is based and to comply with all prevailing standards, must not be “improved” in ways not mandated by the requirements. If improvement is desired, the requirements must be improved first, and only then the design.
The same applies to all other work products including the delivered software. Before changing it, whatever is to be changed must be traced back until the correct product in which to make the change is found: all the way back to requirements if necessary. To do otherwise is to create discrepancy, making both the changed and unchanged items unfit for their purpose.
Software is quality
We have seen that software is not at all like physical products. So what is it like? Here lies the problem. Software is not like anything else. It is by definition highly variable and totally impalpable. That is why there are so many theories and there is so little agreement on how best to produce it.
Be honest with yourself. However good your software skills, you don?t know much about software. No-one does or can. Software is more complex than chess, bigger than the universe, better than life.
So we should look closely at what little we do know and understand, to try to go back to basics and identify that of which we are sure. So: what actually is software? What exactly is the main deliverable of a software project? This obvious question has been answered many times, but no answer is or can be satisfactory: as Willis and Danley put it, trying to answer it is like trying to nail jello to a tree. So, it is still asked often. I almost always ask it when I interview job candidates.
My own answer is that software is quality. The word cannot be used as an adjective to describe software, nor as a noun by which to call an attribute of software. Quality is the subject of software, its essence, the reason it exists. Software is what it does. If it does what it should, things happen that we want to happen. Otherwise, it causes other things, or nothing, to happen. Desirable happenings are the true, tangible deliverable: the software is used by people as its buyer intended, to do the things its buyer wanted them to do. The consequences of that not taking place are more tangible still.
Development is testing
It can be argued that Newton’s second law of thermodynamics dictates that it is impossible to write – or test – code without making mistakes. Imagine a good requirements document for a complex user-facing application, and a concerted effort to deliver them within which very many mistakes are made. The program delivered does nothing other than print “Hello world” to its current output device. It meets all requirements! It is just very defective. To make it behave as it should, so that it makes desirable things happen, we simply need to repair its defects. To do that, we need first to identify them.