Drawing Tools

Last night I was hanging a cabinet at home and I wanted to make sure that it was centered on the wall. I took measurements of the wall size, the cabinet size and where the anchors would have to be on the back of the cabinet. Then I did some addition and subtraction to figure out where I would have to drill the anchors and marked the holes on the wall; this is the point where you are really committing to the process – making holes in your wall.

Right before I started to drill the holes I remembered a piece of advice that my father gave me when I would help him with home improvement project: “Measure twice, cut once”. Now my father did not invent this concept, but I think he did a great service in teaching me the concept. So before I drilled the holes in the wall, I grabbed my yard stick and measured their location again. Turns out the first time that I measured, I marked the right hole at 11 1/4 inches from the wall and not the desired 11 3/4 of an inch from the wall (I was holding the yard stick upside down to measure and it is easy to make the mistake in that case). Since I measured the 2 holes separately, I would have wound up not being able to hang the cabinet at all and would wind up patching one of the holes (which would turn a 15 minute project into a 2 day project). Taking the extra 2 minutes to measure twice saved me from a lot of effort.

As with many things, I tried to relate the situation to technology, and in particular software development. The easiest analogy to make is to software deployment and testing. Deploying code is like putting the holes in your wall, you are really committing. Testing is expensive, but not as expensive as having to patch software after the fact. I am not advocating just running the same tests twice; normally you get the same results each time that you run a test (data differences aside, that is how software usually works). I think I am advocating running two totally different types of tests in order to double check your work. Maybe the best practice is to run a battery of tests and then to create a new set of tests independent of the battery that you ran before looking for edge or failure tests that you did not anticipate. Then the next time that you run those test you can fold those into the core test suite. Just thinking out loud….

Regardless of how you “test twice, deploy once”, you should be approaching your project with that mindset. It might make you father proud.