A common strategy for a software company is to focus on getting proficient at a limited range of tools. Soon enough, a client will come with a project so specific, that it requires knowledge and skills outside of the company’s current know-how. It can then offer a spike as a solution.
The anatomy of a spike
Spikes derive from Extreme Programming. A spike is a period of time used entirely for research and done early, best before a project officially starts. It’s meant to assess the risk involved in software development. If a project can completely fail due to a missing or incorrectly implemented feature, that feature needs to be tested early. For example, risk of failure increases when developers are not familiar with a library or they want to test different solutions to a problem which they never solved before. A spike can give developers, and ultimately the client, time to figure out the best course of action, maybe even create prototypes for testing. It won’t be pretty. In fact, the result artifacts will probably be thrown out after testing but it will provide valuable information.
It’s important to force a deadline when doing a spike because the outcome is unknown. The goal is to find how to decrease risk enough, within a cost-effective period of time, to proceed with the rest of the project. If we can’t do it — because the solutions we found aren’t good enough or there are none — the plan for the project should be rethought or thrown out. Otherwise, the project would end up missing a critical quality determining its success. In the end though, money was saved by not doing something that was doomed to fail anyway and by consuming a fraction of the whole budget planned.
Example 1
Let’s assume we want to create a mobile application for Android and iOS using a framework that let’s us write the same code for both platforms. Our company has iOS and Android developers but no one developing on both platforms at the same time. It can shorten the time it takes for projects to finish significantly but there’s risk involved as well. The framework might not support all the functions that iOS and Android provide and be buggy. The client has two options: pay for two developers, one for each platform or invest in finding out whether the framework is good enough for his project.
Example 2
The purpose of a project is to determine the sleeping pattern of a person and wake him up only when he’s well-rested. There are benchmarks in the form of wristbands and mobile applications that do this but they’re unreliable. There might exist a library online that could be used. Also, we could talk to universities and ask them about their research on the topic. We’re not experts in the field of sleep analysis and therefore have to do some research before deciding whether to do the project.
When we suggest spikes to clients a question often arises: who should pay for it? There is no definitive answer. Investing in a spike must be beneficial to the client. The only alternative is for him to find other specialists who already researched the same thing earlier. Oftentimes, it’s not easy to find them as spikes usually tackle very specific problems. Conversely, a software company might not be interested in learning an obscure technology for free that won’t be used in many future projects. If we can confirm that a risky project is technically feasible by using, say 5% of the budget, it’s a good investment.
Spikes are a powerful tool in the right circumstances. They may be a good investment but their goal and deadline need to be clearly set. They’re only useful in special situations, when the risk and price of failure are high.