Programming--Taming the Complexity

Programming is a complex activity. It must be the most complex activity ever undertaken by humans, because it's the only one I know of where its practitioners habitually make so many mistakes without (usually) being accused of incompetence.

The bad news is, as programmers, we're doomed. The computer is quite capable of exceeding any threshold of complexity that we might try to put up--certainly, any threshold that corresponds to what ordinary, or even extraordinary, humans might be able to deal with. Our machines are getting more and more powerful, but our brains are not.

On the other hand, just because there is a cliff, doesn't mean we have to go jump over it right now. You may not be able to avoid the complexity trap in the end, but there are ways to postpone it, just a little.

If it isn't clear already: there are no panaceas or magic bullets. There are a number of techniques that have been found to be effective, in that programs written with them turned out to be just a bit more manageable than those without. Most of these techniques are fairly simple, which shouldn't come as a surprise. After all, the programming techniques you use should be helping you tame the complexity of the problem, not adding to it.

What do I mean by "taming the complexity"? Here are a couple of points that any experienced programmer would identify with:

• The complexity of a large system tends to arise, not so much from the number of its parts, but from the number of possible interactions between them. This is very much true of computer programs. Hence, we need some way of tightly controlling the interactions between parts, and in particular preventing unwanted interactions.

• It's bad enough making mistakes when writing a piece of code once, it's worse making more mistakes when you write the same (or a similar) piece of code a second time. Therefore, code reuse is an important goal for taming complexity, and programming techniques that allow you to generalize a piece of code, to make it useful in a wider range of situations, are very worthwhile.

Here are some specific techniques for dealing with these issues:

• Compile-time checks. Humans tend to say things they don't mean, and programmers are no exception. One good way to be a little more sure that you're saying what you think you're saying, is if you're made to say it in more than one way (as opposed to simply saying the same thing more than once!). For example, a language like Pascal or Modula-2 forces you to explicitly put in a declaration of a variable as an integer, even though it's obvious to anyone looking at the code that the variable only ever has integer values. Both the declaration and the usage of the variable say that it's an integer, but since they express this idea differently, it should be coming through different pathways in the brain, and should therefore reflect agreement at a higher level in your thought processes. More...

  I like to think of this as adding creative redundancy, and I think that one important way in which programming languages can advance in future is to come up with even more applications of this idea. Imagine being able to declare a variable such that it can only be used in an associated control construct that guarantees at compile time that the variable will always be initialized before it is referenced, without the need for expensive run-time checks...

• Abstraction. What this means is that your code is structured into layers, with lower layers providing services to upper ones, such that irrelevant internal details of those services are hidden from the upper layers. I'm particularly concerned with the case of data abstraction, where the thing being abstracted is a data type and the operations on it. This is one area that "object-oriented" programming (OOP) tries to address, but it is also where OOP goes astray. More...

• Routines as first-class objects. That is, the ability to take a routine (procedure or function), store a reference to it in a data structure, pass it as an argument to another routine, and so on--exactly as you would a value of any other data type. This is a very powerful technique for reusing code, though it appears few people realize this. More...

I won't say that code reuse is easy. There is no magic foresight you can exercise to ensure that a piece of code is reusable from the start--though there are some habits you can develop with practice, that make it easier. The only thing that makes a piece of code reusable is the fact that you have succeeded in reusing it!

Usually, the moment when I realize that I can reuse a sequence of code is after I have written a second, very similar sequence in another place. Then I go back and look at how I can rewrite the two into a single, more general piece that can be used in both places.

In short, you mustn't be afraid to rewrite. Trying to reuse a piece of code for the second time is probably the hardest part: once you've got some code into a shape that you have successfully been able to use twice, the third time will be easier, and the fourth time easier still.

Here are some comments on Frederick Brooks' The Mythical Man-Month.

Back to LDO's Home Page