Tracer Bullet Development

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

Answer 2

If you take approach #1, you will have 90% of the functionality working pretty quickly. However, your client will also think you are 90% done and will wonder why it is taking you 9 times as long to finish the job.

If you take approach #1 then I would call that nothing more than a prototype and treat it that way. To represent it as anything more than that will lead to nothing but problems later on. Happy day scenarios are only 10% of the job. The remaining 90% is getting the other scenarios to work and the happy day scenario to work reliably. It is very hard to get non-developers to believe that. I usually do something between #1 & #2. I attempt to do a fairly good job of identifying use-cases and all scenarios. I then attempt to identify the most architecturally impacting scenarios and work on those.