The Rules of Programming

Rule 20. Do the Math

This isn’t a very math-y book. Sure, numbers pop up in a few of the Rules (like Rule 4, “Generalization Takes Three Examples”, and Rule 11, “Is It Twice as Good?”), but the Rules are more concepts than equations.

It’s sort of surprising that there isn’t more math in computer programming. Computers are just number processing machines, after all. Everything is reduced to numbers for processing—words are sequences of characters represented as numbers, bitmaps are pixels represented by colors represented by numbers, music is a pair of waveforms represented as a series of numbers. You’d think that some of that would leak through—that, as a programmer, you’d be figuring equations at some point. That doesn’t happen very often, though.

Most of the decisions a programmer makes are squidgy. Deciding whether the clarity a lengthy comment would add is worth complicating the flow of logic, say. Choosing between getPriority or calculatePriority as the name for a function.¹ Identifying the right time to switch over to a new version of some system.

It’s easy to fall into thinking that all decisions are squidgy, not just most decisions. Some decisions boil down to simple math, though, and you need to recognize them when they pop up. If you don’t, if you forge ahead without doing the simple math, you may be in for a painful realization later on. You may discover that the approach you’ve followed was never going to work, and that you could have saved yourself a lot of time by ...