Building Modern Cathedrals

Managing a team of software engineers, as I do, was once likened to ‘herding cats.’ I knew immediately what was meant.

We expect a lot from software engineers. Their work requires them to obey very specific rules – rules of the computer. So when it comes to controlling them in other ways, their energy for obeying is all spent. The tedium of the machine’s demands dominate any demands that I may have.

The software engineer, or programmer, has to work to a consistently exact set of rules. Everything she or he creates must comply, there is not escape. The code must compile! Before the code can be used, or even tested, the exact syntactical rules of a software compiler must be obeyed, without question. You have nothing until all the compiler errors are gone.

Now getting your program to compile is only the first step. There are other things I want our software engineers to do. I want their software to do something useful. I want it to meet the customer needs and do this better than the competition.

To do this, I want us to create software that is easy to use. Anybody who has used a computer has come across software that does not seem to make sense; you just can’t work out what buttons to click or what to type on the keyboard to get what you want. I don’t want that to happen with our software.

Also, I do actually want the software to do what it is supposed to. If is has to add up a column of numbers and then find the average, then that is what it must do… under all circumstances. Is that too much to ask?

Then there are the bugs. What happens when the computer’s disk is full? Does the program grind to a halt, but never reveal the secret of why it has stopped doing anything. If you do things in an unusual order, or simply use a feature that no one actually tested, does it ‘crash’ or ‘hang’ – i.e. stop working either by disappearing, or freezing. Does the program ‘crash’ or ‘hang’ just occasionally, for no apparent reason? That is the most difficult one to sort out!

Finally, how quickly does the program work? If the user asks for something, by clicking on a button on the screen, how long do they have to wait before it happens?

The compiler checks for none of these things; all the compiler is interested in is that it can understand the code the programmer has written. It checks for syntax, a bit like a very fussy spelling and grammar checker. If you get both these correct, it is happy. If the sentence you have written is complete gibberish, then that is of no concern to the compiler.

In order to build large and complex applications with lots of useful features and do this in a reasonable time (months not years) you need a team effort. All the discipline of the software engineer must now happen whilst a whole team work on all the code together. Each coder will be working on different bits, but everything must join up and work together. This is not easy.

In spite of the demands on software engineers, my greatest satisfaction is to see their devotion to their art.

Our application is not the biggest or hardest piece of software that engineers have created. An operating system, the bit of software that runs the whole computer and allows various applications all to run together, is even more complex.

In his book ‘The Craftsman,’ Richard Sennett talks of modern crafts: Linux (an operating system), for Sennett, is the work of a community of craftsmen “who embody some of the elements first celebrated in the (Homeric) Hymn to Hephaestus”. Craftsmanship is “an enduring, basic human impulse, the desire to do a job well for its own sake”.