I’ve been working on a new feature for Agrilyst that helps growers keep track of what’s important at their facility. We’re calling it KPIs (Key Performance Indicators), and you may have heard of them before in important meetings or on good clip art.

Also a graph of our test suite duration

We’re just about ready to start our QA process, which includes several team members trying to break the feature and a quick pass with some engaged growers to make sure we’re on target for what they need. I spied quickly at the list of TODO’s left and noticed a pattern:

Footballs are for punting features.

Right in the middle, a crucial moment appears: Tests!!!!

For this brand new feature, my process was clear: first, I went digging in the mines of our back-end code to lay some new tunnels of capability. I excavated towards our front-end after discovering the treasures of new abstractions to extract. Other issues emerged as I was tunneling, and they got tacked onto the list.

Smack-dab in the center of this process was an important baseline: writing tests after figuring out some of the deeper back-end code gave me greater confidence and speed when dealing with the issues I unearthed. I was able to get through the issues found during the initial feature exploration quicker because the tests had my back.

Whoa! Why I didn’t write the tests first? I stopped to consider why I chose to write the tests when I did, and how we all got here.