Tracer Bullets

From ThePragmaticProgrammer; a method of software engineering that is likened to firing a machine gun at night. You can either know exactly where you are, where the target is and do the the maths to work out how to point it and hope you're right... or you can load every other bullet with tracer (which glows in the dark) and then just turn the outgoing line of bullets (which you can now see) onto the target.

Programming-wise, it involves short cycles of development, then delivery and asking the customer if it's closer or further from what they think the target is... rather than finding out right at the end that you've misunderstood something.

Essentially the project now has high visibility not only to the customer (they can see the solution getting "better") but also high visibility of customer desires to the developers.

I don't think that tracer bullets are just about making adjustments to requirements. Aren't they about making invisible things visible - so that you can handle them?

I was introduced to an interesting TracerBullet? at LondonXpDay...

When you have a working TestCase, modify the code so that the assumption under test breaks. Watch the TestCase fail, then fix the TestCase. That way you know the test is checking what you think it's checking. If you change the code under test in a way you believe should break the test and it still works - you know that you're not testing what you thought you were.

Arggh! Testing the test! (head explodes) Actually, very cool...

Real tracer bullets aren't about illuminating the target - you might be able to use flares for that. Tracer bullets are about knowing where your bullets are going.

TestingTheTest? is indeed very very cool.

Keep in mind that real tracer fire allows your enemy to track back to the source of fire - you; TracersWorkBothWays. Is there a software development corollary?

The client always knows the project status. Perhaps the "bullet" part of this metaphor is problematic.

TracerBullets are an easy way for machine gunners to (1) see where their bullets are going, and (2) adjust the trajectory to make the bullets go where you want them to go. Rather than do a bunch of up-front calculations involving wind direction, angle and elevation, distance to target, etc. (which would be equivalent to a BigDesignUpFront) it is easier and quicker to just start firing, get the immediate feedback and reactively adjust (ala ExtremeProgramming).

In PragmaticProgrammer, they talk about TracerBullets in the context of building an ArchitecturalPrototype? - a bare-bones skeleton of your system that is complete enough to hang future pieces of functionality on. It's exploratory, but it's not really a prototype because you are not planning to throw it away - it will become the foundation of your real system.

Sounds like a SpikeSolution

See also: http://www.pragmaticprogrammer.com/ppbook/extracts/rule_list.html (for the other pragmatic pearls)

See: MutationTesting