Taking your code for a walk

walking a dog

When I was in college, a friend of mine told me he liked to take his code out for a walk every now and then. By that he meant recompiling and running all of his programs, say once a week. I asked him why he would want to do that. If a program compiled and ran the last time you touched it, why shouldn’t it compile and run now? He simply said I might be surprised.

Even when your source code isn’t changing, the environment around it is changing. That’s why your code can break without anyone touching it. Peter Deutsch made this observation in the context of networks in his Eight Fallacies of Distributed Computing.

  1. The network is reliable.
  2. Latency is zero.
  3. Bandwidth is infinite.
  4. The network is secure.
  5. Topology doesn’t change.
  6. There is one administrator.
  7. Transport cost is zero.
  8. The network is homogeneous.

Kevin Kelly made the same observation in the context of data storage. Because data formats change and physical media decay, you’ve got to keep copying your data to save it. He coined the term movage to describe the active process of preserving data.

The only way to archive digital information is to keep it moving. I call this movage instead of storage. Proper movage means transferring the material to current platforms on a regular basis … anything you want moved to the future has to be given attention to keep it moving forward.

This morning I had problems running LaTeX (with Beamer) on an old presentation and thought about my friend’s advice.

Related links

4 thoughts on “Taking your code for a walk

  1. I started doing consulting work on an existing in-development project. In addition to being an absolute mess internally, the webservices and other other interfaces were changed without updating the codebase. The client would constantly be surprised that things that once worked (like a year ago) were now broken. Despite one of them being a past-programmer, they had a difficult time with this concept.

  2. +1 on John… I cant imagine my code without nightly( I would prefer as frequently as possible) test suites.

  3. I thought this post was going to be about literally taking a walk to get away from the computer and think about your programming task in a new light (definitely helps me once in awhile), but this advice is probably just as good if not better.

Comments are closed.