Late last week I was working on a problem where I only had about an hour and a half to try and come up with a working solution before reviewing the code. While working on this I went down several false starts, and by the end was not very happy with the progress made. I was trying to create a working solution to a problem I didn’t fully understand.

This morning as I was getting ready for work, I was recapping various things in my head, as I’m oft to do. I began thinking about this situation from a different perspective. What if instead of thinking of the effort as trying to code a working solution, I thought of it as a spike. Suddenly where I was disappointed earlier, I now felt more confident in my progress. The fact that I had tried several approaches, failed, and thrown them out in favor of something else, was now a good thing. This is the purpose of a spike. Not to produce final code or even code you will move forward with, but to determine the approach you will take with the actual code base.

Generally I think we tend to consider spikes to be tied to complexity, and things that we don’t know how to estimate. What if we were to consider doing spikes early in the process in order to help drive out architectural approaches, and help find hidden requirements. I normally try to include a sprint 0 in a first release to allow for time to get project basics and infrastructure in place. We also normally do a few spikes during this time, but suppose we expanded our spike efforts. We could target business elements that are key, don’t have a lot of complexity, but that may have multiple ways of implementing. Once these spikes were complete the team could review the findings as a whole. It may be that architectural directions that are sometimes discovered over time, can be set correctly from very start.

This may not seem strictly agile to some, but it certainly does not break our agile principals. It simply means that you can take a wider view of what you consider for a spike. Early in the process where understanding of the business domain might be low, spending some time on a few targeted spikes you might not ordinarily consider, could save some hassle down the road. Remember that sometimes it’s the moderate problem with multiple solutions that a team can spin on while trying to decide the “best” way to solve it. Now in reality all of this is straight forward agile, but often times there can be pressure to reduce spikes in order to get right to usable code. We only create spikes for what we deem necessary and not to prove out architecture, or design path.

Now back to the original situation that brought this topic up. I have to wonder if I had walked into this session with the thought in mind that I was doing a Spike, would I have gotten further? Would I have stopped writing code sooner, after I determined my approach and switched to documentation? I’ll never know because I entered into the effort in the wrong mindset. Now, when placed in the same situation again I hope that I augment my thinking up front, but I’m human and occasionally I need to make the same mistake a few times before it sinks in.

PS: I think there is another topic hidden in here that may be worth exploring. The notion of integrating Domain Driven Design into Agile. Unfortunately DDD is not a topic I have much experience with, so any investigation down this road will need to be theoretical at the moment.