Title: Trial & Error

One of my hobbies when I was in my early teens was building radio receivers. I started off by making crystal sets (for those of you too young to remember these were simple unpowered devices that were fundamentally a tuned circuit and a simple diode.) In those days commercial diodes were made from germanium though I experimented with a number of other materials that exhibited semi-conductor properties.

I quickly got into the habit of experimenting with just about all aspects of the circuit. Finding the optimum connection point to my metal bedstead to act as an aerial, trying home made condensers, winding ever more complicated coils etc. Of course no great damage could be done because the only power in the system was that which the aerial was sucking out of the ether. Many of the bits I was playing with came from my grandparents' box-room that was a treasure chest of all manner of things from the early part of the century.

This all took place over one summer holiday before I had to return to boarding school. With my parents living overseas there was no chance to resume experiments until the following summer by which time transistors (germanium based) were available and just about within reach of my slim financial resources. So I moved onto amplified systems. Just as with the simple crystal sets, I started with published circuits and then experimented. I had no time for all the theory, it all seemed too complicated and required all kinds of arcane computation. But I also thought I could do better than the published circuits. My development method was largely based on making semi-random changes (sort of guided by some form of intuition) to the circuit and then assessing the result. I can still remember my delight when I managed to pick up the sound part of the existing BBC TV transmissions.

During the whole of that summer and the following one I do not remember ever burning out a transistor. On reflection that must have been a result of outstanding luck. By my mid-teens I was moving on to some other interest and it wasn't until the late 1970's that I was again going to dabble with electronics. By that time the cavalier attitude of youth had long gone and the first time I opened a computer (a Research Machine's 380Z) to fix a problem it was with considerably more respect for what could go wrong. I still find myself experimenting but very much constrained to what I know cannot do any permanent harm.

You may be wondering what all this has to do with programming. Well look around you and think about the way that so many of your colleagues write their source code. Very early on in my programming life (somewhere in the late 60s) I found myself writing carefully honed assembler. It had to be, because almost all mistakes resulted in failure. Failure meant hours poring over core dumps etc. trying to figure out what wasn't working. As I was also pushing the machine I was using (and IBM 1130 with 8k of 16-bit words) to the limit of its resources I had to write tight code that ran efficiently. By contrast with my radio building days I found that I had to understand what I was doing. There was none of the 'try it and see' because that way would result in nothing. A failed run cost me a day's work (well an evening's because daytime was devoted to teaching the young). Programming at this level taught me that 'almost right' was of no use.

Another feature of programming at assembler level is that virtually all errors are logic/runtime ones. Though not impossible, it is relatively hard to produce syntax errors at this level. By contrast the more complicated syntax of high-level languages means that new code written by almost any programmer will include syntax errors. These are usually quickly eliminated (providing that the compiler manages to generate something approximating a helpful error message - error messages that give the name-mangled names of template instantiation syntax errors are rarely helpful, the signal to noise ration is too low).

Unfortunately the end result of removing syntax errors from your code is often code that appears to run and do something. Indeed in my early C-programming days I can remember being puzzled by all the null-assignment warnings that I was getting at the end of programs that had run successfully and providing correct output. However debugging runtime problems all too often seems to come down to experimentation coupled with building a model of how we think a program is behaving. This even extends to rationalising the behaviour to fit our model.

Have you heard the (probably apocryphal) story about a young Oxford Chemistry graduate in his first job. His supervisor comes in one day to find him involved in doing a boiling point experiment. On being asked what he is doing, the graduate explains that he needs to know the boiling point of nitro-glycerine and he had been taught to check data experimentally. It had never crossed his mind that he should look the answer up - that would have been dishonest.

Curious how rarely programmers look up the answers to their problems. If an expression doesn't work the way you expect from prior experience it must be a bug in the compiler.

The low-level nature of crystal sets and simple allowed (indeed encouraged) an experimental approach while the low-level nature of assembler actually discourages experiment. Many programmers would improve their performance if they were less like the chemistry graduate. If you want to know how your code should work, look it up in a reference book or a Standard's document. Life is too short to do it any other way.