Spike As Design Aid

My experience:

I've been involved in an XP project for the past 2 years and we tried to follow XP edicts to the letter. As a disclaimer, I'd say I've become more XP-like, but doing is harder than saying. This project has acquired a large amount of TechnicalDebt due to a combination of both XP and OOD learning curves.

In the past month I have been given a new task - a clean slate. I was given a solo-gig of 'looking into' a re-implementation of a completely different, preexisting system. I felt freed from TechnicalDebt of the project I just left. Even though RefactoringIntoGoodDesign? is a powerful idea, it is still a lot of work. And the work spent refactoring the current object model to the unknown perfect solution can be reiterative and time intensive.

I began my new task with a SpikeSolution.

I've always known that prototyping is an important tool. I've always felt that minimal up-front design is the best starting point for software development, but I never had a way of accomplishing this in a structured manner. XP's use of CRC sessions gave me the structure/reasoning needed to employ minimal design. BUT it didn't give me the jump-start I needed in implementing the minimal design.

This past month I have realized that XP doesn't place enough emphasis on SpikeAsDesignAid. In my XP readings (KentBeck, RonJeffries), SpikeSolution has been referred to in the context of PairProgramming and StoryEstimating?. In PairProgramming discussions, prototyping is referred to as the only excuse to allow a programmer alone-time with his ideas and PC. In StoryEstimating?, it is referred to as a technique used to get an idea of how difficult a task would be. I would like to challenge this lack of representation by putting forth the idea that a SpikeSolution should play a much larger role in defining or refactoring to a clean implementation. As is described in SpikeDescribed.

A few things I got from my SpikeSolution:

A spike is a jump-start to a solution.
It is the target of a refactoring - if you know where you're going you get there faster.
It is the SimplestSolution? for the limited problem domain.
It is relevant only to the limited problem domain.
It is isolated from other problems.
It does not affect the existing system.
It is thought out in depth through critical thinking time - Programmers like this.
It is quick to build - Programmers like this.
It is easy to manipulate - Programmers like this.
It is easy to throw away - Programmers don't like this.

CRC sessions are great. They efficiently communicate the high level use of objects in a system, however they are prone to group-think and, as designed, don't provide implementation details. At this point in the design process, the programmer of the task should be encouraged to develop a SpikeSolution. The minimal implementation tests the group-thought solution and reveals any implementation issues. When using CRC cards, a programmer has a limited view of how a clean implementation will work, look, or fit into the current system. SpikeSolution is a QUICK test of a CRC/Refactoring design and will result in a better-thought-out solution.

To go along with CollectiveCodeOwnership, a SpikeSolution, however perfect it may seem, must be explained through the use of CRC or sketches to other team members before being brought to production code.

--BretWilliams?

Could we share more concrete examples of Spikes? --JuneKim

My above experience had to do with a UI to User to Application Model task. We have a huge system - 70 or so user screens - and our current UI Tool, IBMs Servlet Builder was discontinued in its latest version of VA for Java. So something had to be done in order to continue development. With that on my mind I started on this new task (not the current system). My new task was a small problem domain and focused on the UI only. That set me up to take the small steps I needed to create a SpikeSolution.

I first started with minimal implementations of the domain classes. 15 minutes max. Enough to get me a base to build the SpikeSolution on top of. Then I began to dig into the UI solution. I took that back to the team for a rehash, determined some problems, and went back to my desk to continue. Quickly getting a good solution for the UI problem gave me a DirtyLittleObjectModel? to add a User Framework to. And I continued this pattern of quick-and-dirty solution and explaining progress until I got the perfect target solution. Now I have a Framework that can be used as a target for the 70-so screens we have to refactor. --BretWilliams?