Most developers familiar with agile methods are familiar with the idea of the spike. A spike is a time-boxed task that concentrates on clarifying the unknowns in your project. Usually these are technological (“can this be done with this technology?”) but they are also sometimes in the area of the business domain (“is this a good idea?”) too. One key idea is that the at the end of the spike, it is thrown away. It’s not supposed to be used as production code, it’s just supposed to answer some questions about the project, to validate or invalidate particular approaches to a problem, to provide further clarity around unknowns, to explore risk, to help with estimation, etc. I think this can be a useful general idea when dealing with technology, even in a “production” context.
Recently I was learning ANTLR, trying to decide whether this was a right technology to pursue a particular project which involved parsing a preexisting message format. After a week of a spike, we decided that it was worth pursuing and started on earnest on the grammar for our project. However a week into this process, I had an epiphany … I was doing some things wrong with the ANTLR grammar which were now slowing progress in adding the new characteristics it needed to be complete. Many developers know this feeling; the features of my grammar that I had built over the first week were naive and now hampering it from expanding into the new requirements. I took it on myself to kill the entire grammar and start again. It took less than a day and half to replicate that week’s worth of work (i.e. pass the test suite which had built up around it). I’ve done this before; scrap the first attempt at building a domain and try again. Here my domain was the same (it was after all defined in both a standards specification and in the many hundreds of thousands of sample messages we captured from an existing system), but its implementation needed refinement.
So I think that the rule about throwing away spikes can in fact be made a general axiom of programming:
When you are learning a new technology, make sure you throw away the first thing you build that works – to avoid accumulating your mistakes.
Thanks to Robert for the important qualifier “that works”.
N.B. my views about system rewrites have not changed regardless.