Etymology of Spike in the context of Agile software development

ßehrαng ∑αeedζαdeh
Turingg Computing
Published in
2 min readJul 6, 2016

An excerpt from the Agile Dictionary:

My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.

Similarly, a spike in XP does not produce production code — it does not develop an actual story in the backlog — but rather it enables future story development. I was taught in the XP Immersion workshop (given by Robert Martin, Ron Jeffries & Kent Beck in 2000), that spikes are not given story point estimates because they do not contribute to forward velocity on completing the backlog — they are in essence, research overhead and absorbed into the team’s ongoing story velocity. XP was never as obsessed with “precision” in release planning as Scrum has become.

It would be interesting to ask someone like Ron Jeffries, who was no doubt very close to the creation of the spike concept, where the inspiration for the term really came from. — Source: http://agiledictionary.com/209/spike/#comment-57

Yet another pointless term for activities that already had proper names: research, investigation, prototyping, etc.

A team I used to work in thought of spikes as time boxed activities that drill through all the layers of a system (e.g. from front-end, to the API calls, and finally into the system’s database).

I totally agree with Gary’s comment (emphasis mine — almost):

Why did he dub it a “spike” as opposed to an “auger” or a “spear” or a “fruit salad”??? I have issue with this as many programmers I work with hear the term and chuckle (in a bad way… as do I).

Agile lingo is very juvenile and foolish compared to other disciplines of software engineering and computer science. Compare the agile lingo to the terminology used in GoF’s original book on Design Patterns: literally all design patterns explained in GoF have sophisticated, purposeful, and substantive names. Even pre-Agile era textbooks on software engineering were not dumbed-down to sell something complex as an easy endeavor.

The next generations look back at us and burst out laughing at all this Agile nonsense. In the meantime it has become this opioid religion for the mass of software developers and criticizing it might have grave consequences. Heresy!

--

--