Engineering Blog

The idea of deferring decisions to the Last (or Latest) Responsible Moment is a common theme in several flavors of Agile and is likely not a new concept to many readers of this blog. As an engineering team, we often apply this principle when making decisions about what to do next. When this idea is combined with the old saying that “premature optimization is the root of all evil,” then the decision making matrix can take some interesting turns.

Recently, we ran into a case where it was the responsible moment to implement a particular optimization. It turns out the optimization caused as many problems as it solved, but we fixed the problems. We also wrote a test to verify they wouldn’t recur. It’s a a pretty interesting test.

For our team, writing a test to cover the regression case for a defect is nothing new. It’s part of our team’s working agreements, and has been since before I worked for Rally. What’s interesting about this particular test is not that it verifies that the problem in question cannot recur. This test eliminates the potential for similar bugs anywhere in our codebase.

I intentionally settled on the word “interesting” when deciding how to describe this test. I considered saying “unique”, but that would be a lie. It’s not the first time we’ve written a single test that prevents an entire class of problems. Or the second. Or the third. Each of these tests, while no longer unique, are interesting in the approaches they take to preventing particular classes of problems.

These tests document, in an executable fashion, conventions that prevent problems. Some of the engineering team has taken to calling these “convention tests”.

In this series of posts, I’ll discuss how our convention tests are written, look at what problems they solve, and guide you through writing your own.