Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated May 01, 2011 — Enterprise Agile Planning expert

Continuous Integration and Testing: Mere Child's Play

Enterprise Agile Planning
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. As the game played out, with him turning the crank after each piece was added, what I found is that some assumptions we were making when adding a piece weren't realized. Sometimes, a piece would have been installed backwards. Other times, installing a new piece would knock a preexisting piece out of alignment, and the machine wouldn't work as it had before. Any time the machine didn't work, we'd find out where the problem was, make an adjustment, turn the crank again, and make sure it worked before moving on to next roll of the dice. So, what started out as my indulging his fascination with the machine actually turned out to be him teaching me a thing or two about the value of continuous integration coupled with continuous testing. I was a little embarrassed that I hadn't thought of it first, and that a 7/year/old had come by it intuitively. My old habits were dying hard. He hadn't acquired any bad ones yet, and so it made perfect sense to him to test the system for no other reason than that something had changed. This experience solidified the answer I give when someone asks me when a software development team should test: "Any time anything changes". (In the context of TDD, of course, the answer would be "BEFORE anything changes".) This experience also reminded me of how we often resist doing something because it isn't the way the we've always done it, and how leaving the decisions up to the "experts" can result in missed opportunities. I now have serious game when it comes to "Mouse Trap", and a stronger appreciation of continuous integration and continuous testing // all because I've learned to think like a 7/year/old.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us