Adopt Simple Rules that Shrink Your Problem Space

When faced with a problem, you naturally start thinking of a solution. By immediately jumping to the solution space, you forgo a deeper understanding of the real problem. One of the most famous (actually, mythical) examples is the Space Pen: legend has it that NASA commissioned a special pen that can write in zero gravity. Meanwhile the Soviets recognized that Cosmonauts would need something that can write in zero gravity: a pencil. Extending this example a bit, the Cosmonauts' pencils have a smaller problem space: What if the ink leaks? What if they lose the cap? Those questions do not even exist.

Back here on Earth, you sometimes have the opportunity to create a rule that slices off a big chunk of your problem space; a simple thing you can do to eliminate a whole class of problems. It does not matter how infrequent such problems are now. The point is to make a set of problems impossible forever. You'll always have problems, but in a smaller problem space, you can diagnose trouble without investigating the situations that your rule renders impossible.

Let me illustrate with two of my own rules.

One rule applies to computer system administration. When creating a new account, you usually need to define both a username and an email address. The rule is that the username is the local part of the email. Thus the username for jdoe@example.com is jdoe. This is what you would expect anyway. With this simple rule in place, any software or human at Example, Inc. can convert between usernames and email addresses by adding or removing @example.com. When jdoe@example.com needs to sign in with his username, he knows what to do. When I need to email user jdoe from within a program, I know what to do.

Another example (not my own of course) is Test Driven Development. This proven software development technique forces you to explore the problem space by writing the test first before proceeding to the solution space to write the functional code.

Another way to reduce your problem space is by examining requirements. If your spec demands a feature that is difficult to implement, investigate whether you really need it. Ask not only, "Do you want this feature?" ask the anti-questions "What's wrong with this feature?" and "What would you pay for this feature?" You may find that you can eliminate it, thereby shrinking the problem space from the outside.

So, linger a bit longer in the problem space and see if there are simple rules that collapse your problem space. This will make your solution much more universally useful. Like my examples above, the rule should be so simple and obvious that anyone would obey it most of the time anyway. The rule should just squeeze out rare, degenerate cases like 3@example.com. On the other hand, discard unnecessarily restrictive rules. For example, many companies declare that all usernames shall be the first initial followed by last name. That rule becomes a burden once Jane Doe joins the company.