The number seven is very important in programming and many other intellectual endeavors. Why is is magic and what significance does it have for us poor limited humans?
All good programmers need to be part time psychologists, maybe even full time ones.
There are many but let's start with a very obvious one.
What would you say was the most important skill at creating user interfaces?
The Psychology Of Bandwidth
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 mostly 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 much 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. The idea was that the human wasn't so much a data processing system but a data communications system. The inputs were the senses and the outputs where what ever the human did or perceived as a result of the inputs.
It studied the channel capacity and the effects of noise on signal processing. There are some theorems relating things like reliability, bandwidth and noise and these are applicable to humans just as much as to networks and radio channels.
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' or Miller's law after the psychologist who discovered it. (See: The Magic Number Seven, Plus or Minus Two.)
After lots of experiments it was found 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.
You can argue about the fine detail and whether or not the number seven deserves its special position. You can also argue about the limits applying to different cognitive processing but the important point is that there is a limit not its actual value. Humans are bandwidth limited information processing machines. We have a channel capacity or a data rate limit just like any data bus.
Programming And Seven
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. You will often hear programmers talking about complexity reduction but actually what is going on is complexity hiding - also known in the wider world as "chunking".
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.
There is also a subtle effect caused by the nesting of control structures. One If statement is easy to understand but multiple nested if statements are much harder to untangle. The same is true of loops nested with in loops within ifs and so on. Nested control structures make it difficult to chunk.
The idea behind chunking is that a human can deal with about seven things at a time but you can work with different levels of abstraction to work with bigger systems. That is you can remember seven letters, or seven words or perhaps seven sentences and certainly seven titles and plots of seven very long books. The principle of chunking applied to programming is to build a hierarchy of code each composed of small objects that can be understood in a single look.
I have occasionally encountered too literal implementations of the 'seven' part of rule. 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 and too brutally.
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 an explicit 'seven' rule in object-oriented programming but I guess it's only a matter of time and a deep enough search.
The point is that seven is a guideline and the actual number depends on all sort of factors but "Keep It Small Stupid" is a much better statement of intent than "Keep It Simple Stupid".
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.
Easy to say but usually much harder to do.
The Unit Of Comprehension
Focusing on code for a moment it is clear that what matters is the structure of a function or method.
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.
We use hierarchies to manage complexity so that each level in the hierarchy is as simple as the next as long as you are working with the correct 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, in fact almost certainly will, turn out to be you.
The Seven Of Interfaces
The magic number seven has had its influence on programming methods but it has had less influence on the user interface where it is just as important.
If you have ever watched a TV program or movie that uses the multi-shot technique - multiple small panels showing different action at the same time - you might have admired the technique but why aren't all such programs made like this?
The answer it that it takes a lot of processing power to cope with a multi-screen bombardment - and sadly the vast majority of people just can't cope. We run out of bandwidth well before the theoretical seven strands of narrative.
No, the average viewer likes a nice simple, single-thread storyline - with one image following another preferably in a correct time sequence.
Anything else is for novelty value or something really creative.
If you agree with this then think for a moment what this means for interfaces based on hypertext, multi-media and GUIs in general.
A typical web page is crammed with links and is a clear example of where the human processing channel is threatened with imminent swamping by excess information.
In the case of followable links the swamping is a drawn-out sort of affair as the user follows multiple threads of information and forgets what the original enquiry was all about.
In the case of multi-media the swamping can be immediate; more like a tidal wave of information. To watch on-screen video and try to read text and listen to the audio tracks can be promising but it can also send the innocent who actually try to cope with the information into terminal overload.
Then there is the question of the rich GUI interfaces we can create so easily using any of the many technologies that give us far more than buttons. We tend to create interfaces that have the "gee whizz" effect and we can't help but be impressed by the clever implementations using any of the latest techniques - overload is now the norm.
In fact as programmers we suffer from being too close to the interface. Our unit of comprehension is too large and we manage to cope by being immersed in the system so that we understand it in much larger grouping.
There are two ways in which acknowledging the human information processing limit can help us produce better interfaces.
The first is to recognise that, no matter how complicated the display the focus of attention will rarely manage to cope with more than one or two things at any moment.
In the same way you shouldn't nest control structures too deeply in a function, you shouldn't nest dialog boxes, menus or windows too deeply. It is better to think in terms of a single focus of attention within your application. If the user opens multiple applications and so splits the focus, well that's up to them - perhaps they can cope.
The rule of seven is also an argument for skeuomorphism. Making things in an interface look like things in the real world reduces the novelty of the interface and so acts to make it easier of the innocent user to take in and process. Notice that much of this depends on the user being "innocent" and to a great extent "fresh". If you are familiar with a website or a UI then basically you see it as simple no matter how complex it really is. There is also a huge pay off in copying other people's designs so as to get the familiarity factor for free.
Overload and bloat
If you want to see an example of a program that breaks these rules then look no further then the standard Windows file manager - Windows Explorer. It has at least three menus structures on show - the two horizontal menus, and the task panel to the left. If you throw in the right-click context menu and any number of optional extras then you begin to realise that the user is overloaded. What menu to use for any particular task is a mystery.
Most of the existing Windows interface is like this. It has accreted alternative ways of doing things as we have succumbed to the need to add the latest interface widget or to simply improve by adding rather than improve by making better.When you throw in the need for backward compatibility you can appreciate that interfaces naturally grow from simplicity to overload.
You can apply the same accretion of complexity argument to just about everything in programming. It happens in language design
- C was a nice simple language but C++ grew beyond simplicity
- C# was light but C# 3.0 is bloated.
It happens in application programming as versions gain new features and still retain the old. It happens in operating systems as they struggle to remain compelling at each upgrade while striving to still run the old stuff.
At every stage software adds complexity and outgrows the human channel capacity in every possible way.
This is the reason why as programmer we eventually get an overwhelming desire to throw away what we have and start over.
The idea of a human as an information channel may have gone out of fashion in psychology but it is the only relevant model for software design.
The magical number seven, plus or minus two: Some limits on our capacity for processing information Miller, G. A. (1956)
Claude Shannon - Information Theory And More
Apple Goes Flat - Where's The Logic In That?
In Praise of Skeuomorphy
How Error Correcting Codes Work