The Agile Architect

Learn Faster with Agile Spikes

A spike is the agile terminology for a short period of research unfettered by the constraints of test-driven development and the other disciplines necessary to produce production-quality software. In this article, our Agile Architects gives the low-down on how to use spikes and, more importantly, how not to use spikes.

• By Mark J. Balbes, Ph.D.
• April 22, 2015

The loaded gun is pointed straight at your head. You can feel the beads of perspiration running down your face. Behind you, your iMac hums softly. In front of you, your boss's finger twitches on the trigger of an ivory handled Colt .45. "Do it!" he yells. Next to you, your developer pair has a knife pressed against your side. "Don't do it," he whispers. "It's wrong." You've got an important choice to make and you've never been this scared in your life. As the clock on the wall ticks to 5 o'clock, you can't help but ask, "How did things get to this point?"

You think back to this morning. The day was fresh and wonderful. You were starting on the next story, something shiny and new, a fresh technical challenge that promised new cool things to learn. As one member of a pair of developers tasked to work on this story, you had quickly realized that neither of you had any clue about how to do it. After a quick discussion with the team, you decided to time-box a spike, allowing you time to think about the problem and to write code to investigate possible solutions without worrying about the technical disciplines that make your production software sustainable. You knew that this would mean that you have to throw the spike code away. But that's OK. It's the learning that's important.

So you and your pair spent the day learning by writing code, testing and researching. In the end, you came up with a piece of hacked-together code that demonstrated just enough functionality to prove you knew what you were doing.  It was time to start over, developing production code that met the story's acceptance criteria by following good agile software development disciplines

And that's when your boss got involved. "It works," he said. "I saw it. You showed it to me. Ship it and let's keep this project on schedule."

"Oh no," you said, astonished at the naivety of your boss. "We can't ship this. It's not tested. We need to throw this code out and start over."

"Throw it out? Throw it out??? Why did you waste time building it if you were going to throw it out?"

"We didn't know how to build it," you stammered. "This gave us a chance to figure it out."

"Great. You figured it out. Commit the code and let's move on," he said, obviously frustrated. "Commit the code," he repeated and pulled back his jacket slightly to reveal the gun hidden inside.

That's when your pair blurted out, "We will not be intimidated! This code must die!"

"If something's gonna die," your boss screamed, "it's not gonna be that code." Pausing for effect, he continued, "We're gonna take this slowly," he said, "one step at a time. First you are going to type the commit command," his finger pointed directly at you.

So you typed the commit command. After all, nothing happens until you hit Enter.

"Now," said your boss, "you are going to hit Enter."

"Never," said your pair as he swiftly pulled the knife as if from nowhere.

In response, your boss pulled his gun, and now here you are. What will you do?

You are younger. Five years younger. You are a dough-eyed developer fresh out of college. You've drunk the TDD Kool-Aid and are adamant about having a failing test before writing any code. Your pair is Denny, a cool customer, experienced in the ways of agile. Denny's got at least 10 years on you.

Everything seems smooth at first. You are working on your story together, playing the pairing game. Denny writes a test and you make it pass. Then you write a test and Denny makes it pass. Every couple of cycles you take some time to refactor to a better design.

And then Denny pauses. "What's wrong?" you ask.

"I don't know what test to write," Denny responds.  And then Denny does something unexpected, closing the app project in the IDE and starting a new project.

"What are you doing?" you shout. "We're supposed to be working."

"We are working. We need to do a spike to figure out what to do next."

"We should write a test to figure out what to do next," you retort. Geez, do these old fogeys know anything about modern software development, you think to yourself.

"OK," Denny says, handing you the keyboard. "Write a test."

"I don't know what test to write. You write the test."

"I don't know what test to write either."

"So we're stuck," you say dejectedly.

"Not stuck," Denny reassures you. "We just need to change our strategy. Rather than focus on producing high-quality production software, we need to take some time to learn. For this app, we are using a new software library, and while we've both read the documentation, we won't really understand it until we've used it. So let's write a test.

"Wait," you exclaim in surprise. "You just told me you didn't know how to write a test."

"It's not that kind of test," Denny explained. "This isn't a test to drive development. This is a test to drive learning. Basically, we are going to use the testing framework to allow us to quickly exercise the new software library to see what it does. The alternative would be to create our own small program to do the same thing. This just saves us some setup headache."

"So we are going to write a non-test?" you say thoughtfully. "Instead of using the test to define a result and then making the code give us that result, we are going to use the test framework to exercise the code in different ways and then see what results we get back."

"Exactly," says Denny. "When we are done, we'll throw away the spike code and any tests we write."

"Wait. That's crazy. Why would we throw out the code we just invested so much time in figuring out?"

"Because it won't be good code. We just use it to learn. We won't write real tests. We won't drive to a good design. That's all overhead we don't need while we are trying to learn."

"Yes," you fight back, "but we could add tests and refactor it and make it good."

"Maybe," explains Denny patiently. "But we won't know that for sure. Some of the bad code will stick around. Or we'll get lazy and decide we just want to be done, and we don't refactor enough or write enough tests. Or the code we write isn't fundamentally testable and we end up wasting a whole lot of time trying to reuse the spike code only to give up and start over anyway. Besides, when we rewrite the solution using TDD it will be a lot faster because we'll already have done it once."

"OK," you sigh. "Let's get started."

"We're not quite ready yet," says Denny. "We have to do two more things. First, we need to decide on the specific purpose of the spike. What do we want to learn? Second, we need to decide on a time box. How long will we allow ourselves to spike?"

"Um, that's easy. We want to learn everything about the new software library and we will spike until we're done."

"Not so. If we don't have a goal or a time box, we are likely to spend too much time on the spike chasing down minor details we can figure out later. How about we give ourselves two hours to demonstrate that we can use the library to meet the first and third acceptance criteria in our story? If we still don't know enough after two hours, we can discuss it with the team and decide if we want to extend the spike."

"Sounds like a plan," you say. "Are spikes usually this quick?"

"Not always," Denny explains. "You use a spike any time you want to accelerate learning. As long as you have explicit goals and a time box, it's a spike. We are doing ours in the middle of a story. It's pretty common to start a story with a spike, especially if you aren't too familiar with the code you're working in. Some teams like to make a spike into a story all by itself. Instead of estimating the story with story points, its time boxed just like we're doing. Our team has a rule that a spike can't last longer than a day. After that, we have to review what we've done with the team and decide if we really want to continue. Since we know we are going to be throwing out the spike code, we don't want to spend time polishing it."

"So a spike always runs from a couple of hours to a day," you say confidently.

"Nope," Denny responds quickly. "Sometimes a spike lasts two minutes. You'll see this soon enough. We'll hit some snag or have some small question. So we'll stash our working code, write a few quick lines of spike code to figure out what's going on, then revert back to our working code."

"Cool," you say. "Sounds like I'll be using spikes a lot."

"Remember that it's important to share what you learn with the rest of the team. If we are investing time in learning, let's get the biggest bang for the buck. Just don't let anyone pressure you into using your spike code in the production system. There's always the temptation  to skip the rewrite and just commit the spike code. If you do that, you've started down a slippery slope that leads to low quality, buggy software that no longer delivers on the promise of agility."

"To the death, so swear I!" you joke.

Final Thoughts
The pressure is getting more intense. Your boss isn't looking so good, nervously playing with the trigger. He releases the safety. "Commit!" he says. "Good employees commit!"

"Don't do it," repeats your pair, and you feel the knife blade press a little deeper against your side. "You'll regret it. It might feel good now but its false hope. Soon, very soon, the spike code will break and our entire production system will be compromised."

You see the anger in your boss's eyes. As he raises the gun slightly, you see him put pressure on the trigger. As everything starts to move in slow motion, you feel your pair increasing pressure from the side. "Great," you think, "Stabbed and shot at the same time. And all because I wanted to spike."

You hear the gun go off, your pair continues to press against you, pushing you out of your chair and onto the floor. The bullet flies through the space you occupied just moments before, hitting your iMac dead center. The screen sizzles as it bursts into flame.

"Well," says your pair, "I guess we're not committing that code!"

"Meh," says your boss and walks away.