Jorge Cruz-Lambert
Agile development
Published in
2 min readJul 27, 2014

--

In software development there are times when is required to do what within Agile environment we call spikes. Each spike is a proof of concept for technical or functional challenges.

I've heard different comments about using TDD while developing a spike. I think the most important here and before write a single line of code is to know what is the purpose of your spike.

I wrote spikes sometimes for making a demo or for checking how a library is working. Most of the times the purpose of this spike was as a demo which we used for making sure we can achieve some of the highest requirements with protocols or libraries unknown until that moment.

You can argue that I could use TDD to drive my discovery process in this and you are probably right. I think the most you TDD the most you are used to it. So of course it could be a good idea, but sometimes and knowing that the spike you are writing is only used as a disposable piece of software, you can probably avoid the TDD process.

Once you finish your discovery process, you are ready to start a project which will be a final product using TDD.

But, if you are developing a spike and you expect to evolve the code you are writing into a final product, then I will use TDD. Relax, be patient, be professional and do TDD, you will invest in the future.

This decision will facilitate all the process. I know sometimes it’s tough to know but as a professional you will need to guide yourself from past experiences and background. Perhaps the decision is easier to take if you answer the following questions:

Is a quick demo for demoing a proof of concept? TDD recommended, but not required.
Is the spike a way of understanding an unknown technical thing? TDD recommended, but not required
Is the spike source code going to be shared or public? TDD required
Is the spike going to be maintain? TDD required
Is the spike going to be the base for a future project? TDD required

To sum up, I would always recommend TDD your code, but I think you can avoid it in case your code is a disposable piece of software with the only value of being a shop window in a customer demo.

--

--