Spike Described

(An attempt to put the SpikeSolution in the form I used in my book - AlistairCockburn)

Thumbnail: You don't know how some domain works, so... Build a minuscule, core solution - discover what the domain really consists of.

Indications: You are working in a new problem domain or with a new technology you do not understand, and cannot create an initial design in which you can place much confidence.

Forces being balanced : You have to start on a relatively significant commitment to a design or plan. You need confidence in your plan.

Factors affecting the balancing of the forces : You think a core solution will reveal the information you need or that developing a core solution will give you the understanding you need to create the design or plan. You want to show early results to test your understanding and to build morale.

Recommended action: Build the smallest possible *core* solution in the shortest possible time. Use that core solution to inform your decision about your technology, the domain, your design and your process.

Resulting context: If you are fortunate, the core solution will naturally extend into your final system. You will, however, still have to adapt the core solution for the myriad of actual variations that make the domain complex.

Overdose effect: The solution is too small, and in fact does not shed the necessary light on the domain, technology or process. Done too small, too often, no solution is ever created which serves its final users properly.

Related patterns: ClearTheFog - the generic version of knowledge risk and acquisition. EarlyAndRegularDelivery - adds knowledge about your development process. Microcosm - returns measurable data about process and technology. Prototype - the more general version of SpikeSolution.

Principles involved: See DijkstraAndRefrigerators. Much can be learned from an attempt to locate the core of the problem, and the core is often small. The risk is low, the time is short, and the potential benefit high, both in cognitive learning and with the possibility of extending the result.

Sample situations:

A. See SpikeSolution.

B. See ChryslerComprehensiveCompensation, and would somebody please add a link to wherever that is described more fully, especially with respect to Spikes.

C. My favorite was TomLove describing how he bought a lot for his house in wooded Connecticut. He climbed a tree to about where his second story window would be. Only he knew the view he would have - the realtors had not realized that they were on enough of a hill to get a clear view of the neighboring countryside. He bought the lot immediately.

D. LowFidelityUserInterfaceDesign?. You are designing a user interface. Experience indicates that your developers probably will not get the design correct on the first try, either because the user experts did not know, did not speak correctly, or the designers did not hear correctly. So, you create a PaperPrototype in a few hours, or a screen prototype in a few hours or a day, using fixed data. You show this to the users to discover missing information. (see also SpartanUserInterface --RonJeffries)

Reading: There is massive literature on prototyping, rapid development, and user interface prototyping. SpikeDescribed and SpikeSolution are the only two places I know of where this particular strategy is described. Correct here if you know of another or a similar strategy.

That overdose effect can be a real killer. For a lot of domains the real problems are in things like scalability and robustness, which are easily ignored. A database with 100 records doesn't tell you much about how to organize one with 100 million. A parser that halts on the first syntactic error is much easier to write than one which recovers and usefully diagnoses subsequent errors. -- DaveHarris

I agree with you, Dave. I have recently encountered a number of projects who ignored the scaling issues until too late and then had significant redevelopment on their hands. However, missing scaling is simply improper risk assessment. Good to recheck here what SpikeSolution is about: "What is the simplest thing we can program that will convince us we are on the right track?" (So sometimes we need a different approach that looks for things to convince us we're on the wrong track, like EasiestThingFirstHardestSecond or WorstThingsFirst?)

If scaling is not on your radar, then the spike will not address scaling. However, if scaling is on your radar, the spike will perhaps write 10 million dummy records to the database and access them. Depending on the results, you might decide life is good, or you might spend the next weeks getting the db accesses into shape. I have seen this done, and suspect you might have, also. -- AlistairCockburn

I've found spikes particularly useful when dealing with large scale performance issues. Take the largest customers dataset and spike a fresh solution to the one, slowest operation. Once you've seen it work, you will think of dozens of ways of incorporating the now proven solution into the production code. -- WardCunningham

My best uses of spikes have been when I didn't know the first step or the next step, not when I was trying to plan out all of the steps. For me a spike should first be a goal then a reference point and finally a footnote in fairly rapid succession. So I wouldn't expect my first spike to do 10 million records, I'd just want to see something go in and come back out. Only later, when I had a 10 million record question, would I do a 10 million record spike. -- PhilGoodwin

Exactly. See, relatedly, PerformanceSpike. -- RonJeffries

A Spike reminds me of two other things:

The first is quite the opposite to a SpikeSolution: a QuickBrownFoxExample? - namely an example that contains one example of each topic at hand. For example, say you're writing a book about using C++, and in one chapter you describe the basics of OO. Then rather than have lots of scraps of code to describe each of the basic features of OO, you might have one QuickBrownFoxExample?, listed at the start of the chapter that demonstrates all of the features you will cover - you then spend the chapter showing how each piece works.

The other thing a spike reminds me of - and perhaps this is just an example of a Spike - is a particular approach to problem solving, in some scenarios, where you first ignore the end goal and try to prove there is no problem under the simplest possible conditions.

For example, a colleague comes up to you and says "I'm running a script that backs up a database, upgrades it, restores the backup with a different name and burns the upgraded database to a CD, and then play a little tune, but it keeps failing. It never gets to the tune, so I think the script must be broken." You can jump in the deepend and see if the script is correct or you can perform a spike test to see if the hardware is even capable of playing a tune. you ignore the script, take a quick look under the hood and find, yep, there's no speaker.

-- LeonBambrick

The very top talks about 'my book', but I know of two books by Alistair. I am guessing it is SurvivingObjectOrientedProjects and not WritingEffectiveUseCases.

-- DavidVincent