Continuous Integration and Testing: Mere Child's Play

My youngest son loves to play the game “Mouse Trap”, and last Christmas vacation, I had the opportunity to play many rounds of it with him. The object of the game is to build the mouse trap contraption piece by piece as the players take turns rolling the dice and moving around the game board. One thing he insisted upon was turning the crank and running the machine every time a piece was added — even when the crank wasn’t attached to anything.

Now, I’ve been playing this game for decades, and my vast experience told me that there’s no sense in turning the crank until we had the machine significantly finished. Besides, I had other things I needed to get to, and running the machine every time we added a piece made the game last longer. “We only added one tiny piece,” I’d say. “There’s no reason to test every time. What could go wrong?” At the start of one particular game, though, I decided to do my best to be a patient dad, so I gave in and agreed to do it his way.

What I Learned From My GPS

I recently took my family on a vacation that required us to drive several hours to a place we had never been. Instead of reaching for my worn road atlas or even using an online trip planner, I decided to rely totally on my GPS. As I prepared to pull out of the driveway, I plugged in my destination and in seconds was informed of how many miles I had in front of me and my estimated time of arrival.

As we rode along, what caught my interest is that each time we exited the interstate for food, etc., the automated voice would announce "Re-routing". Then, after getting back in the car to resume our journey, we'd be given instructions to get us back on track, and the information in the GPS would be updated to reflect the distance remaining and the new (now later) ETA.

I thought, "Wow -- talk about inspecting and adapting".