Programming Principle to Ponder

In my years as a programmer I have discovered a number of simple facts about computers that aren’t obvious at first. I thought that I’d share a few of them with you.

The first is what I call the fundamental theorem of Computer Science. It is in any system you can trade processing for storage and vice versa. An example may serve to help illustrate what I mean. Say for instance you need a function that returns the sine of the integers between 0 and 89. You can either write an algorithm that computes the sine or you can have an array of 90 floats that are preloaded with the sine of the first 90 integers.

The first will be more expensive in terms of the time that it takes to return a result. The second will be more expensive in terms of the memory that it takes to store the table. The correct choice will depend on whether you need a fast answer or a memory efficient one.

Another fundamental principle of programming I learned from a book entitled The Pragmatic Programmer by Andy Hunt and Dave Thomas. They call it the DRY principle and it stands for Don’t Repeat Yourself. This principle was first espoused by database gurus in the form of first normal form.

The idea is if you store the same value more than one place in your program you run the risk of changing it in one of those places and forgetting to change it in the other. It is a simple thing to do but it helps avoid hard to find bugs.

One more and I’ll call it a night. It was first brought to my attention by David Heinemeier Hanson (or DHH as he is commonly referred to by the community), the original architect and author of Ruby on Rails. He calls it configuration by convention. To explain I need to describe how people handled configuration of their programs before.

There were two popular approaches. One was to specify the configuration of your program with so called command line options. These usually consisted of symbols, either single letters or entire words, that were associated with a value for the option.

This soon got rather cumbersome if there were a lot of options. The first attempt to simplify the specification of options was by creating a file that had a special syntax that made it easy for a program to associate the option specifier with the value to be assigned to the option. The problem was that the configuration file syntax was often complex and error prone. For example, XML was a popular syntax used in configuration files.

And, when people started using configuration files the proliferated such that every new library that you adopted in your program would have it’s own configuration file.

DHH observed that a large percentage of the things that are configured by configuration files can be established by having conventional configurations. For example, a common configuration parameter was the specification of the directory where particular files of interest to the application could be found. Instead, DHH established a default directory layout that the application used and documented it.

He asserted that software should be opinionated. It should expect things to be done a particular way and reap the benefits of simplification that these assumptions enabled.

I think the thread that runs through these principles is that the most important thing a programmer needs to do is think about the problem that they are trying to solve and ways that they can solve it instead of what most of us do which is to try to reuse techniques that were successful on previous projects.

This is only bad if it is done without careful thought about the project at hand. Are you trying to drive a nail with a monkey wrench? Programmers are often too quick to start coding instead of taking the time to think about the problem.


Sweet dreams, don’t forget to tell the ones you love that you love them, and most important of all, be kind.