Extreme Programming (XP) defines a concept called a spike. A spike is an activity to find out answers to a touch technical or design problem. Extremeprogramming.org defines a spike as:
Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story’s estimate.
When a technical difficulty threatens to hold up the system’s development put a pair of developers on the problem for a week or two and reduce the potential risk.
So a spike should be the minimum work required to demonstrate the suitability of the solution, reduce the risk and help estimate the overall effort. Now to a problem outside of programming…
I’ve been meaning to replace the battered wooden lattice around the base of my deck that is attached to my house for several years. I was planning to use a plastic material (plastic lattice sheet and accompanying edging with a pre-cut channel) rather than wood so it is maintenance free and doesn’t rot. I used this plastic lattice and edging the previous year on a project, but was not happy with the way I assembled the lattice to the frame to form a panel.
I realized I was procrastinating on the deck lattice replacement project because of my previous mediocre experience with the plastic material coupled with the fact that I was not sure how long it would take, how much material I needed, what it would cost, and most importantly how I would anchor the finished panels to the base of the deck.
Furthermore, underneath the deck there are no vertical supports on the edge of the deck to which I could screw the panels. As a result, I was not sure how to fabricate and install the appropriate vertical supports without making this a huge production. And I also wanted to make sure the decorative panels were built to last and didn’t fall because they are not secured properly.
Then it occurred to me, I really needed to do a spike to better understand what I was up against. To remove the unknown, determine the effort involved and material needed. I had some scrap lattice and frame left over from my previous project, so I assembled a small panel the way I thought I wanted to do the whole deck. Given that it was a spike, I was prepared and expecting to throw out the panels I was building, just like I would do with code on an agile development project.
When I positioned my first panel in place below the deck, it fit beautifully and I was able to find two excellent and easy locations to secure vertical posts to which the panel was screwed. I was feeling good, but realized that the panel I installed was different from all the other locations and that it was likely easier to install. So, just like with software, if you find your spike does not represent the true unknown, you need to continue the spike. So I decided to continue building a second panel that would be installed in a more typical and potentially more difficult location.
After building the second panel, I held it in position and pondered how the heck to install it without any vertical supports. At this point, it would have been extremely helpful to have a pair carpenter to collaborate with on ideas, but I was out of luck, I was alone. After inspecting the way the panel met the bottom of the deck I realized an easy and hidden way to use metal strapping to secure a post just about anywhere I needed a post. Using this technique, I was able to successfully and easily screw the second panel to its supports. At this point I felt I learned enough and brought the spike to an end.
Photo of one installed panel that was built during the spike
With the information I learned from the spike, I was able to estimate the materials needed, the cutting I had to do and the time to cut, assemble and install. Given these discoveries I knew how much it was going to cost and roughly how long it would take to build and install the remaining panels for the deck.
Just like with code built in a spike, I ended up discarding the first two panels I built during the spike because I built them with an emphasis on experimentation and was not concentrating on quality.
The most significant benefit from the spike was the pressure lifted from my shoulders by just committing to do a single panel in a spike and letting go of the complexities for the remainder of the deck skirt. Just like in a software spike, I only addressed the problem under examination and ignored all other concerns. That shift in mindset was freeing!