Ready, Fire, Aim

Sometimes it makes sense to prototype elements of an application - where you have the time and have no idea how to solve a novel problem (such as how to make a particular AJAX GUI usable). At other times, where you have a relatively well defined set of interfaces, it makes sense to use Test Driven Development to really lock down all of the component interfaces and then to code to that.

But what happens when you need to start to develop a novel project, you have spent time thinking about the architecture, but you don’t yet have your interfaces locked? That’s where tracer bullets can come in handy . . .

Prototyping is the process of creating a rough cut (whether using a whiteboard, Photoshop or some kind of programming language) of a specific concern within an application (usability, architecture, performance, etc.). However, sometimes you have learnt as much as you can afford to from prototyping but you still don’t have the component interfaces locked. What to do?

One approach is to use Test Driven Development. The process of writing the tests is sometimes enough to identify flaws in your interfaces and to help you to refactor the interfaces before you even start writing code. However, eventually on a project you have to start to write code to get a sense of how things will hang together in practice.

If you hit this point as part of developing a new architecture before you have your interfaces locked, I think TDD is a little premature. For example, I’m still trying to get a general feel of how my model is going to relate to my views and how user control state persistence will be managed within the application (more about this in another post), I really just want some simple working code to test my assumptions and to see how well the concepts will work as code.

If you can afford to prototype the entire application, that’s great. But if not, the tracer bullet approach of "ready, fire, aim" can save you from analysis paralysis.

With tracer bullets, you get something lightweight working and then refactor it as required. The difference with prototyping is that you throw prototypes away whereas tracer bullets provide a skeleton of code you can refactor and then expand to form the basis of your application.

With all of the buzz about Test Driven Development I was feeling embarrassed about the thought of writing code before my tests, but the more I thought about it the more I realized that TDD assumes a certain level of knowledge of component responsibilities and interfaces for your application. If you’re still playing with that, some tracer bullets can help you to get closer to the target. Then you can write the tests for those more stable interfaces and refine from there.