> It seems they "drive out risk" by focusing on analysis and research, rather than implementing stuff. I think. Actually, spikes (originally called "spike solu

> It seems they "drive out risk" by focusing on analysis and research, rather than implementing stuff. I think. Actually, spikes (originally called "spike solutions") emphasize implementing as a form of research. You implement the risky thing so that you can learn how it really works in practice. You leave out all your normal production development practices and just focus on the question at hand, then throw it away (or archive it) when you're done. For example, let's say you had a need to send email from your software, but you had never done that before. You might create a series of spike solutions that send a hardcoded email from your server and through a variety of third-party services, then evaluate the results. When you're done, you throw away (or archive) the spikes and rewrite it at production quality in your real codebase. It's sort of like a prototype, but narrowly focused on a specific question.