Question

I’m working on a client server app using the Tracer Bullet approach advocated in The Pragmatic Programmer and would like some advice. I’m working through each use case from initiation on the client through to the server and back to the client again to display the result.

I can see two ways to proceed:

1. Cover the basic use cases, just writing enough code to satisfy the use case I’m working on, then go back and flesh out all the error handling later.
2. Flesh out each use case as much as possible, catching all exceptions and polishing the interface, before going on to the next use case.

I’m leaning towards the first option but I’m afraid of forgetting to handle some exception and having it bite me when the app is in production. Or of leaving in unclear ‘stub’ error messages. However if I take the second option then I think I’ll end up making more changes later on.

Questions:
When using tracer bullet development which of these two approaches do you take and why?
Or, is there another approach that I’m missing?

Answer 1

As I understand it, the Tracer Bullet method has two main goals

1. address fundamental problems as soon as possible
2. give the client a useful result as soon as possible

Your motivation in not ‘polishing’ each use case is probably to speed up 2. further. The question is whether in doing so you endanger 1. and whether the client is actually interested in ‘unpolished’ results. Even if not, there’s certainly an advantage in beng able to get feedback from the client quickly.

I’d say your idea is OK as long as

• You make sure that there aren’t any fundamental problems hiding in the ‘unpolished’ parts – this could definitely happen with error handling
• You track anything you have to ‘polish’ later in an issue tracker or by leaving TODOs in the source code – and carefully go through those once the use cases are working
• The use cases are not so ‘unpolished’ that the client can’t/won’t give you useful feedback on them