Ready Fire Aim

A concern voiced about Analysis/Test/Code/Design.

But then, ReadyFireAim works pretty well for laser guided bombs. -- JohnClonts

Good analogy! Instead of counting on the aim being perfect, they make in-flight corrections. Very XP. Perhaps. Information recently released by NATO suggests that, in the recent Balkan engagements, the so-called "smart" munitions were woefully inaccurate. They are somewhat better than glide bombs, but not much. Certainly not much when you consider the fabulous cost. The models used in Iraq in 1990 were marginally better then just dropping dumb bombs. The models used in 2002 were pretty much everything the propaganda said they were in 1990.

Be careful here, when you ReadyFireAim, you're not firing in the conventional sense, but instead firing off an aiming process. There's another "fire" that comes later.

Remember that many combatants hate guide bombs and missiles. Why? Because they have to remain exposed after launch. How does this relate to software? It probably doesn't; it is just a reminder to carefully choose analogies and make sure they are well understood before use.

To stretch this analogy way past the breaking point, let's recall that many terminal guidance devices only need source illumination at launch and in the last few seconds of projectile travel. Therefore, if the time between weapons release and impact is, say, thirty seconds, then the source of the illumination ("music") need only be exposed for a tenth of that total flight time. Not the kind of risk the old-style laser guided munitions required.

CodeUnitTestFirst definitely doesn't feel this way to me. I force myself to split my thinking about the interface from my thinking about the implementation.

The other problem with ReadyFireAim is that it embeds the assumption that change is difficult. If you are shooting a gun, you better aim as carefully as you have time for before you pull the trigger. Software development is not like this for me. I resonate much more strongly with the DrivingMetaphor. -- KentBeck

ReadyAimFire? doesn't work so well if you are trying to ski down a mountain.

It doesn't matter if it is good for laser bombs or skiing or driving. It matters if it is good for developing software.

I was just pointing out that your analogy assumes that you can predict where your target is going to be when the bullet hits, as you do (reasonably well) if you are shooting. The major assumption of XP is that you can't.

Surely that's the whole point of tracer bullets. They were very popular with WW2 air gunners. They could fire in approximately the right direction and then 'walk' the stream onto the (fast moving) target.

ReadyFireAim is exactly how tracer bullets work. Such exploratory development is often the best way to determine if a software development is on-target too. -- DavidThomas

A more positive way of looking at this pattern, that describes it more appropriately, is ReadyFireAimFire. -- RobMandeville

What makes writing UnitTest the Fire phase? I would CodeUnitTestFirst as aiming before you fire, not the other way around. I am wondering if you guys are somehow deluded about the effectiveness of BigDesignUpFront. I would say that AnalysisDesignCodeTest? is more like Walk up to the target, Walk back, Fire, Aim. Chaotic development is Ready (maybe), Fire, Aim (maybe). XP is Ready, Aim (test), Fire. -- JohannesBrodwall

If the phrase ReadyFireAim is being applied only to coding activities, I would agree with the assessment of XP above. Writing the unit tests defines what answer (target) you want, so that's aiming.

But if you're talking about a whole project, it seems to me that it is most useful to liken 'aiming' to ElicitingRequirements / UserStorys. You can certainly validate software against its design specification (aim for that particular target). Personally, I think that aiming to fulfill your users' needs is more valuable in the long run. This can be validated through AcceptanceTesting (also an XP approach, of course).

I don't think these are trivial distinctions. In my current company, I've got a boss that will say things like "I need a piece of software by Y date" - and there are coders that will go back to their computers and start writing based on no more detail than that. The end result of this approach is that "hitting the target" becomes final cleanup of any errors that are glaringly visible to the end user and the project is declared to be a rousing success. That, to my mind, is ReadyFireAim in a nutshell.

I think...

So... or maybe

as a subtle but important difference from above.

Wouldn't a prototype be...

Oh boy, I guess to be precise, a prototyping effort is just a regular effort scaled down, since you still design a prototype (don't you?). The apparent difference in orderings of aiming and firing are a matter of when you start observing and when you stop. Once you've fired, any following aiming can only affect a subsequent firing. But thinking linearly about this is misleading. Once firing and aiming become iterative, you're likely to be in a feedback dynamic.

Ready, fire, aim, spam, spam, spam, spam and eggs!

See: WaterfallModel, ReadyFireAimFire

EditText of this page (last edited November 9, 2005) or FindPage with title or text search