All good programmers need to be part time psychologists, maybe even full time ones.

The reason?

Well what would you say was the most important skill at creating user interfaces?

Psychology in practice

True you have to have the technical skill and equipment to implement your ideas; but without an understanding of how users work then your ideas will be rubbish. Understanding how users work, in the broadest possible sense, is usually called psychology - hence my opening statement. Rather than launch off into another discussion of user interfaces, an admittedly important topic, the time has come to consider something more simple - overload.

One of psychology's early phases (there have been many) was based on information or communications theory. It viewed the human processor as an information channel. It studied the channel capacity and the effects of noise on signal processing. The exact details aren't particularly important, but what is important is the obvious statement that humans are a limited data channel. One of the nicest and simplest results in this area is the 'magic number seven'. (See: The Magic Number Seven, Plus or Minus Two.)

After lots of experiments it was discovered that, on average, humans can manage to keep in their short term memories seven items of information. The variation observed in the experiments was such that a more accurate statement of memory capacity is seven items plus or minus two - hence the title of the paper referenced above.

What has this got to do with programming?

The answer is quite a lot. As a programmer you to are subject to the same information processing limits as any lesser mortal. This is the reason why all programming methods endeavour to hide the complexity of a program in a layered structure.

In modular programming programs are built up out of small chunks of code in the form of subroutines, function or modules. Each module should be small enough to fit into the seven plus or minus two category. Each layer should equally be confined to the same size limits, so that every layer can be easily understood.

I have occasionally encountered rather too literal implementations of the 'seven' part of rule rather too much. For example, a project I was involved in had the arbitrary limit of no more than seven lines of active code per subroutine - the project leader was brother to Genghis Khan and a fine warrior, but he applied rules too literally.

In some more elaborate design methods such as Yourdon/Demarco you will find people converting guidelines such as 'no more than around seven bubbles in a structure chart' into a similar and exact law.

I have yet to come across a 'seven' rule in object-oriented programming but I guess it's only a matter of time and a deep enough search.

Well now you know the origin of the magic number seven that crops up so often and you also know that seven could just as well be five or nine. In fact the situation is much vaguer than even these loose numbers would suggest. The real confounding factor is what exactly constitutes an item that the "seven" applies to? Should it be seven characters, seven words, seven lines, seven subroutines, seven objects, seven programs.... Clearly the unit used in the rule of seven matters. Basically the unit should always be scaled to fit into the situation so that it is one chunk of comprehension or memory.

Unit of comprehension

Do you understand and work with a method as a single thing or a composite unit. Again the rule that each layer should have a limited complexity is justified in terms of the sliding scale of the fundamental unit of comprehension.

There is another more subtle problem. The unit of comprehension can change with time and who exactly is doing the comprehending. When you write a small chunk of code you are on top of it all and your unit of comprehension might be very large - it all seems so simple. But when you come back a few weeks later your unit of comprehension has shrunk. Now it would be better if the method consisted of just seven lines of very simple code. 

If there is a lesson to be learned from this aspect of "seven" then it is not to overestimate yourself or your colleagues If you write a nice little code chunk today imagine the lesser mortal  who will have to maintain it If you expect this then plan for it! Make your code easy enough for the dummy to cope with; who knows the dummy may turn out to be you.

<ASIN:0195091604>

<ASIN:0201596202>