Inside every large complex system, there is a small simple system struggling desperately to get out

(John Gall, Systemantics, 1975)

In class on Monday, Cem pointed to an axiom of most software metrics, and challenged its truth. The axiom was that every large program is at least as complex as the sum of the complexities of its components. He brought up the example of two (or more) pieces of a program that are each examples of a pattern. If you, the programmer, see multiple instances of a pattern, you are more likely to see the pattern. So, you'll see one (possibly complex) pattern, and two examples of it. So, the second example actually makes the entire program simpler.

I see an opportunity here. Anytime you have such a situation, you can use it as a clue that you should change the program. You should encapsulate the pattern and then (call it, subscribe to it, instantiate it, whatever words you feel work best here.)

(This relates to point 3 of McGee's Manifesto, http://cs.fit.edu/~jpmcgee/SWE5620/Manifesto.html. Never copy and paste anything. (Cut and paste is a way to implement move, which is OK.) Paste is your enemy. It leads you into creating situations where you could have abstracted a pattern, but didn't.)

Assume that we have a complexity metric that actually shows that something is simpler if it is longer. We can use that metric to clue us in that we have found an example of an abstraction that should have been in the program, but wasn't. I think that we won't find many metrics like this. But, maybe we can. We could define a metric that compared various blocks of code to see how similar they are. The more similar they are, the less inherently complex the code as a whole must be. We as a field haven't made much use of pattern recognizers applied to software, even though software people use them to look for patterns in a lot of other things. ("The cobbler's children go barefoot.")

OK, where have I seen this in practice? I've seen it in, I think, four different kinds of places. I'm sure there are others.

First, I've seen it where the programmer didn't see the pattern.

Second, I've seen it where the programming language used didn't allow certain types of patterns to be encapsulated, or added enough overhead that it wasn't worth the effort.

Third, I've seen it in''boilerplate' code, which was required for some framework. For example, creating a user interface in Java / Swing requires a lot of code that is pretty similar in order to create a bunch of buttons or menu items.

Fourth, I've seen it in cases where people tried to optimize the output of the compiler by rearranging things. I heard a conference speaker once talk about the efficiency gains in C++ code if you put all your conditional object creations at the beginning of each routine, which required more code to handle the other cases. I thought it was extremely short-sighted to pervert the clarity of a program in order to make it run faster on a specific compiler.

What should we do about this?

If you're a programmer and you see a pattern, abstract it. The half-life of a production program is unknown, but probably several times longer than the tenure of a programmer working on it. So, if you have some knowledge and don't put it into the code, you're throwing that knowledge away. The later generations of programmers working on the program will have a harder time because you didn't.

If you can't implement a pattern in your chosen language, find a modern programming language. Learn to use the C preprocessor or another macro package that will generate code in the language you have to compile.

If you have boilerplate code, put that in a macro or subroutine.

If you have to optimize the input to the compiler in order to get good output, FIX THE )(*(%$ COMPILER!

Questions:

1. What code have you seen that matches this description?

2. Were you dissatisfied with the code you saw?

3. What would you have changed about the code if you could have?

4. What other questions does this suggest to you?

5. How many dissertation ideas are there in this?

This website's first version is by Ryan Knowles and is maintained by Pat McGee.