Most programmers are, at least to some degree, familiar with Top-Down design principles. The 3-10 rule applies human nature to the top-down design rules, creating a substantially improved method for project generation.
Top-Down Design Theory
Question: What’s the best way to eat an elephant?
Answer: One bite at a time
I love these lateral-thinking jokes, because they defy the methods by which we usually approach problems. Generally, we think of eating an elephant as a lump sum, but this joke encourages us to look at the trivial problem before us: eat one bite.
Parents use the same technique to make kids eat their vegetables. Kids don’t want to eat the whole portion, but if you make them take it one bite at a time they’ll keep eating.
This is the principle of top-down design: Break the complex problems down into a set of trivial problems.
For example, if you wanted to write an email client from scratch, you would attempt to break it into parts. Each protocol would require its own code. The GUI needs to be its own code. Database management requires its own code. Thus, we reduce the impossible to a set of possible tasks.
7 +/- 3
Those who study psychology (whether professionally or as a hobby) notice that people cannot hold too many thoughts in active memory at once. If you’ve ever crammed for a test, you know that by the time you get halfway through the terms, you’ve “put away” the meanings of the first few terms. Meanwhile, you can instantly recall the definition for the last term you studied.
Hypnotists (who actively manipulate the conscious and unconscious mind) have a rule: people can only hold between 4 and 10 thoughts in their minds at once. There are several powerful hypnotic techniques that rely on this truth (specifically the “hypnotic blitz”, which barrages the recipient with an idea until it sticks).
It’s important for every engineer, designer, and programmer to remember this truth: You can only generally hold 7 +/- 3 thoughts in your mind at once.
Niklaus Wurth’s Rule
I cannot confirm that Niklaus Wurth expressed it this way, but it was handed down to me with his name attached. I can confirm that he was a genius, and his writings are worth studying.
How can we combine the top-down, stepwise refinement approach to design with our knowledge of human minds?
The Niklaus Wurth rule is actually an algorithm:
For each “lowest level” task on the stack:
If task is trivial (can be done with a short piece of simple code), ignore
If task is not trivial, break that task into 3-10 smaller tasks
Mark the smaller tasks as “lowest level” tasks
Why 3-10 pieces, we ask?
If a task has only two trivial sub-components, we can consider the task trivial.
If a task has only two non-trivial sub-components, we are probably not thinking through the problem completely.
If we go above 10 pieces, we won’t be able to hold all those pieces in mind at once. That’s a great way to cause redundancies, accidentally forget portions, and substantially increase complexity.