I've been working on quite a large project since February. It's hard to believe that it's been just about 10 months already. Such a project, with 20-30 developers, is quite different in nature from the smaller projects I've been involved with before. For one thing, one has less control over the code. People of varying abilities and inclinations are submitting code all the time, so --to borrow Fred Brooks' idiom-- maintaining conceptual integrity is a more difficult proposition. As such it is not unusual to run into less than optimal code in the application. The problem is that while I may sense bad smells in the code, in the midst of all the complexity it can be difficult to ascertain exactly what I should do about it. In some cases, I've found that simply trying out various refactorings just isn't as helpful as one might hope. One strategy I've found helpful is to start a completely new codebase and to quickly write some very simple code to model the functionality in question. That way I am not burdened with the production code base. I write the code test-first in order to generate what I think is a reasonable solution to the problem. Often I can get working tests and a reasonable sense of what the solution I want looks like much more quickly than I could by working on the production code base.I consider this to be a spike, but on our project, most people refer to a spike as an experiment applied to the production code. Once I've found a solution that seems to fit, I try to adapt it to the actual project. Often I can refactor reasonably large parts of the, ummm, less than optimal code, to match the general layout of my new solution to the problem. Sometimes I have to re-write some parts entirely. In any case, I've found that doing this kind of spike, away from the production code entirely, can help to quickly generate a fresh view of the problem and its solution.
I had a look at the definition for a "spike" on the c2 Wiki and came upon concepts that appear basically identical to what I've described in this post: