Taken Out Of Context
The other day I across some funky stuff in some code we inherited. It worked, but it wasn’t the cleanest or clearest way of doing things. I thought, “Well, I should probably refactor this.” The funkiness was at a high enough level that no unit test was going to explain what was going on. So, I went to the appropriate acceptance tests.
I figured I’d have enough information to know what was going on and to verify my changes didn’t break anything. The tests did provide some documentation, but it was really about the mechanics of what we were doing. I knew that I could make changes, but still felt a little uncomfortable. For me to be really comfortable making the change, I needed some context—the “why”.
I know others had a few of these uncomfortable moments with the code. A number of times we might have wanted to make a high level change, but because we didn’t know the “why”, we didn’t have the necessary confidence to do it.
This got me thinking about some aspects of the BDD-type stuff that I like. One of them is the whole “As a..”, “I want to..”, “So I that…” preamble for story frameworks (see RSpec or JBehave for examples). With some documentation about the roles, the actions, and the outcomes, you have that necessary context when you come back to the code several years later.
This context is absolutely needed at the acceptance test (story) level. At that level, it ceases to be about the units, and is about the whole. When we start making changes at that level, we need to know the “why”. Otherwise, our software just ain’t gonna be soft.