Soapflakes - July 1999
For the sake of simplicity
Software development is about many things, one of which is the management of complexity. It is a lesson that has been oft repeated, but apparently not as often heeded. The inherent complexity of a software system is something that we can do little about. We cannot eliminate it, but we can hide and abstract it. We can also create complexity.
The fact that software systems are getting bigger and more pervasive is testimony to the fact that we can at times muster the wherewithal to manage the inherent complexity of constructing large systems. At other times, it supports the view that creating complexity is easier than hiding it: the creeping featurism, physical size, and bugginess of certain operating systems and wordprocessing packages is tantamount to a public admission of software engineering failure. ‘The software to solve your problem is larger and more complex than necessary, because we did not have the ability or resources to make it smaller and simpler,’ to misquote liberally Blaise Pascal.
The inherent complexity of a software system is related to the problem it is trying to solve. The actual complexity of a software system is related to the size and structure of the software system as built. The difference is a measure of our inability to match the solution to the problem.
This deficit (or surplus, depending on your perspective) is caused by, and manifested in, many aspects of the software and its development process. This reflects the structure and culture of the organisation and people that created it. It is reflected in its interface, by which I broadly mean GUI, configuration, public API, and so on. And it is reflected in its reliability and adaptability, ie a more complex system will inevitably have more bugs and be harder to change – all other things being equal – than an equivalent simple system.
Note that there is a major, but nonetheless subtle, distinction between ‘simple’ and ‘simplistic’. Dumbing things down, and sweeping complexity under the carpet, is an example of ‘simplistic’; the complexity still leaks out. Far from eliminating the need for skills, when simplistic tools (and mindsets) are applied to non-simple problems they highlight that technology alone cannot solve the problem, and that skills for managing complexity (okay, call it programming) are needed as much as ever. Zero- and minimal-programming models solve particular categories of problem for particular categories of people. Beyond that scope they are simplistic rather than simple, and create rather than solve problems – just remember that the majority of spreadsheets have bugs.
In this context, what is simplicity? Simplicity is related to minimalism, as defined by John Pawson in his book Minimum (published by Phaidon, ISBN 0714838179): ‘The minimum could be defined as the perfection that an artefact achieves when it is no longer possible to improve it by subtraction. This is the quality that an object has when every component, every detail, and every junction has been reduced or condensed to the essentials. It is the result of the omission of the inessentials.’
In other words, leaving or taking things out by constantly examining the difference between inherent and actual complexity: questioning and reducing the number of features, and questioning and reducing the amount of code (for benighted management that still measures productivity in terms of KLOCs, this is scary: it appears to represent negative productivity). Less code, less bugs; fewer features, greater ease of use; etc.
This leads to an interesting marketing possibility, and one that I have seen in action only a few times: the idea that a subsequent release of a product will be smaller and/or have fewer features than the previous version, and that this property is actually considered to be a selling point. Perhaps the market is not mature enough to accept it yet, but it remains a promising ideal: less is more.
In software development we have already had these principles enshrined in our vocabulary for nearly three decades: low coupling and high cohesion. As David Parnas said, ‘Partition to minimize interfaces.’ The wisdom has been captured, but most developers today either do not know what these terms mean or they do not understand their significance. The practice of aggressively managing dependencies between parts of a software system applies at every level: function to function; class to class; component to component. A separation of concerns leads to separation in software architecture.
A software system reflects the principles used to build it. Personally, I find it quite disturbing to see some of the files being copied or replaced when an application is installed on Windows: ‘Hey, isn’t that file part of the operating system? Why is the application layer messing around with the operating system layer? And why do I need to install this completely unrelated piece of software to make this other one work? ... Hey, why don’t some of my other applications work any more?’
It is not technology that solves problems, it is understanding: simplicity and minimalism are not criteria to apply to our understanding, but criteria that should be applied to the products of our understanding. We are often in the situation of having technology before understanding, and without principles to guide us we can end up with logical absurdities. To illustrate this, and reinforce the message of inherent versus actual complexity, I will leave you with the following thought: why is it that when I install new software on a Windows machine it typically requires me to reboot (or, as is often the case, rerereboot) the operating system, and yet plugging in a new piece of hardware does not?
(P)1999, Centaur Communications Ltd. EXE Magazine is a publication of Centaur Communications Ltd. No part of this work may be published, in whole or in part, by any means including electronic, without the express permission of Centaur Communications and the copyright holder where this is a different party.
EXE Magazine, St Giles House, 50 Poland Street, London W1V 4AX, email firstname.lastname@example.org
Soapflakes - July 1999