(2020-06-02) Hill An Intro To Spikes

GeePaw Hill: An Intro to Spikes. I use spikes, periods of code-changing activity that end with no pushes, all the time, at small scale and large, as a way to develop my path. It’s a vital technique. (cf spike solution)

A spike is a stretch of time I spend mucking about in code, and that stretch of time has one rule: "Do anything you want, because you can’t keep it."

Why were we so strong on "no off-road artifacts"? Because every one of us had been through the pain of having what we were told was a "proof of concept" or "prototype" shipped to the field and causing massive heartache.

There’s an important idea embedded there, and letting it have its full flex actually brings me to my modern practice, of having many small spikes on a more or less daily basis. That idea is in this question: "If we don’t bring back code, what are we bringing back?"

we’re bringing back "mind stuff".

every single time of those 30 times, I threw the change away. Literally, "git reset –hard".

A thing that may surprise you, about that end. On my 30th try, I got it. And you know what I did? "git reset –HARD".

the 30th spike was the last spike, not the last action. The 31st step was to return to my on-road style and use it to create my on-road solution

The most important and readily controllable term of my equation for "what will I finish today" is nearly always "what will I start with".

couple of further points,

1) I sometimes spike in a whole other app than the one I’m working on.

when the eventual destination app has a bunch of parts that aren’t really relevant to my current problem. By working the problem outside that app, I get to skip dealing with all those parts.

2) I often roll an entire spike in a single test in my microtesting rig, JUnit in my most common case.

I’m using the test rig as an easy way to invoke code, not as a TDD thing.

3) I (internally) declare a spike before I start it.

But that’s not a pure rule. I watch my clock a lot when I’m working on-road. Sometimes, it runs long, in kotlin, say, 45 minutes between pushes. Occasionally, I’ll say, "okay, bam, this just became a spike, tho I thought it was on-road."

4) I spike refactorings, too, maybe even more often than I do in feature work.

The point of spiking a refactoring is to set the "green to green" path in my head.