At AgileConf 2014, John Krewson presented “The Show Must Go On: Leadership Lessons Learned from a Life in Theater” in which he outlined parallels between the stage acting and software development. Among his points on how project management is like directing and hiring is like casting, John remarked that when a director is preparing a performance, they don’t assemble the actors, distribute scripts, and say, “We’re all professionals. See you on opening night.” Even when everyone on the team is an A-lister, they still need to rehearse.
The same goes for software development.
Writing software involves several layers of problem solving. At the highest level, there is a business problem to solve. At the lowest, code has to be written that makes the computer do what it’s supposed to do. In the middle is the problem of writing maintainable code that can be extended to meet future needs.
With all those problems to solve, not even the best programmers always get the answer right on the first try. And if actors with scripts have to rehearse, think how much more important it is for software developers without scripts to rehearse their solutions before rolling out to production.
That’s what a development spike is for.
Any given problem can have multiple solutions, all with different tradeoffs. One solution might better express the problem and the algorithm used to solve it, but be very difficult to change or extend in the future. Another might be very extensible, but so convoluted no one can tell what it’s doing or how to use it. Sometimes one member of the team might suspect a solution of being worse in theory than it turns out to be in practice. The only way to get the lay of the land is to do some quick exploration and survey the possible solutions.
Rather than committing large amounts of time to exploring the unknown, a development spike allows the team to try out solutions on small parts of the codebase or on example problems. Like trying samples in the grocery store, a brief experience can be illuminating. An idea that seemed good can quickly turn out to be a bad fit for the problem. A solution that was at first scoffed at may turn out to be just what’s needed. It’s hard to know until it’s tried.
A development spike is, for developers, an opportunity to rehearse their code, to work out the kinks and find the groove that let’s them best solve the problem. And it lets them find it without committing large amounts of time or resources.