Enlightening Things First

The EvoFusion folk, Coleman, Cotton, Malan, et al. have been boosting evolutionary/iterative development for a few years now. They go with an initial long definition phase and then a 2-4 week design/code/test cycle rather than XPish NanoIncrements and ReFactor(ing), but still have some very interesting things to say.

Rather than WorstThingsFirst, they recommend EnlighteningThingsFirst - things that shed light on the rest of the task. Sometimes these things are the hard nuts in the problem domain; sometimes they're simple things like getting tools up and running. They pick the things that are most likely to reduce the perception of risk.

When your worst problem is that you don't know enough, the two approaches are exactly the same.

If they are reducing (perceived) risk, sounds to me like WorstThingsFirst. Bastards stole our idea. But we have a better name, what kind of wimp word is "enlightening" anyway.

"Worst" isn't a much better word. IMHO. The WorstThingsFirst page seems to equate it to "Hardest". This isn't quite the same as "Most Risky".

Another idea is to do first the thing which will have most dependants; which will have the biggest effect on the rest of the system if it changes. This might actually be quite an easy thing - an Observer pattern infrastructure, for example. Once the infrastructure is in place, you can put your best pair onto the Hardest problem while other people do other necessary but independant work. -- DaveHarris