in my opinion

His Brain is Squirming like a Toad

- by Tim Romero -

My client was somewhat dismissive of the company's new hire. "She's nice, but she's not really smart enough to understand computer programming." I had not met the programmer in question, so at the time I had no comment on the accuracy of his assessment. However, although I still have not met that particular programmer, I now agree with my client's comments. In fact, I've come to believe that nobody is really smart enough to understand computer programming - and that is a good thing.

It's not that computer programming is particularly hard; at least not in the way that high-energy astrophysics or the General Theory of Relativity are hard. However, the complexity involved in all but the most trivial of computer programs is far beyond what human beings can understand.

Without question, there are some brilliant people programming computers, but that doesn't mean that they actually understand what they are doing. The very best programmers will have a complete understanding of the particular part of the program that they are currently developing, but that's about all that can be expected of them.

A competent architect or civil engineer can look at a set of blueprints and understand what has been built even if he was not the designer, or if the structure was built years ago. This simply isn't the case in computer programming. In the push for Y2K compliance, upper management of not a few companies has discovered what the IT departments have known for years. No one actually understands the aging software that controls their enterprise. In fact, a running industry joke has it (with apologies to Arthur C. Clark) that any sufficiently old technology is indistinguishable from magic.

Advances in other engineering disciplines are usually measured by the extent to which they increase a particular quality of the end product. Advances result in things like making bridges lighter or safer, reducing building costs by using new materials, making a transistor smaller and faster, and increasing the reliability of a starter motor or the efficiency of a combustion chamber.

In contrast, every major advance in software engineering has resulted in larger, slower programs which are more likely to contain software errors than those developed with older techniques.* The value of a new technique is generally not what they contribute to the end product, but to what extent it increases an engineer's ability to understand what it is he is supposed to be doing - the extent to which it allows a programmer to deal with the complexity involved in programming. This has been true of everything from early high-level languages like COBOL and FORTRAN, and of more recent Object-Oriented programming techniques.

Of course, unlike other engineering fields, computer programming is not limited by physical reality but by human understanding. If a software program can be understood, it can be constructed. The same is not true of, say, bridge-building, in which what is and is not possible is determined by the hard reality of physics rather than the ability of an engineer to understand the problem.

Paradoxically, new techniques that enable developers to cope with greater levels of complexity are used not to make software more understandable, but to develop programs that are more complex. From the programmer's point of view, the level of complexity involved in computer programming remains quite constant. It is always sitting uncomfortably, just beyond the limits of human understanding.

The extent to which we humans can deal with complexity is the only significant boundary that exists in computer programming. It is the only thing that separates the possible from the impossible. In this light, the fact that no one is smart enough to understand computer programming is axiomatic. And, in an odd way, the inability of computer programmers to understand what they are doing has been responsible for every major advance in software engineering.

On this point, it is important to distinguish between "software errors" in which the program does not behave as the programmer has instructed it, and "programming errors" in which the program behaves exactly as the programmer has instructed, but not as the programmer wanted it to behave.

Tim Romero was not really smart enough to understand high-energy astrophysics or the General Theory of Relativity when he studied them in college. He is now president of Vanguard Consulting and often writes and lectures on Internet and software development issues. He can be reached at t3@vanguardjp.com.



Back to the table of contents