Code in our codebase should fit into one of two categories. It’s either:
- Very new, or
- Very stable
Spike and Stabilize is a pattern for deliberately deciding which code should go from young to old.
A spike in agile terms generally means:
- It’s an experiment
- It’s timeboxed
- Any code created gets thrown away at the end
He talks about options in the stockmarket trading sense. An option being something you have a right, but not an obligation to fulfill. An option has a value, which changes situationally based on the fluctuations of the currencies it relates to. An option also has an expiry date. Common wisdom is to not commit an option early, unless you have a really good reason to.
The choice to make something a spike or production code is an option. We make that choice right at the beginning, before we have any working code.
Spike and Stabilize as a pattern then, says that all code is a spike. All code is an experiment. We create okay code, but we deliberately cut corners. We use TODOs to say, we know we should do things this way, but we just want to get the experiment out there. The experiment may not have amazing test coverage or documentation, but you deploy it anyway.
Some time later, you pair review the code, looking at all the TODOs. In the time since first writing it, there may be some TODOs that no longer apply for one reason or another, and so time spent addressing those TODOs at the beginning would have been wasted.
He gives an example centering around hard coding a password used in an Active Directory call used to get a list of users. He talks about what he should do, talking about moving out the hard coded password to a file and best practices around reading said file. All stuff that is just better, more hygenic code. He acknowledges that he should do that stuff, but he doesn’t, and just leaves the todo. When coming back to do the code review at a later date, turns out that a bunch of people wanted that list of users, so the Ops team has exposed it as a REST service somewhere, so now it’s just a GET call. We can replace all of our code with the password and the AD call with a single line, the GET call. Lucky we didn’t spend all that time on code hygiene up front.
When we come back this second time for review, this is when we pay down the quality. Now, rather than tests driving the code, we write characterisation tests, tests that describe how we actually use the code. Turns out that in order to test our code, we need to move it around a bit. As we write our tests, we’re pulling our code into a shape that looks a lot like it was test-driven in the first place.