Worst Things First

From discussions on the XP mailing list I get the impression Kent no longer uses WorstThingsFirst. Is that correct? --MartijnMeijering

It seemed to me that it's more that he realized that if you're doing XP, WorstThingsFirst is automatically done. It's the same as asking WhatIsTheWaterStrategyOfaFish -- JasonYip

Not at all true. But maybe Kent has a new way of saying what he means.

The notion of doing the "worst things first" is fundamentally a method of avoiding the purely human tendency to put off the hard stuff until later. If you do that consistently then you are in big trouble towards the end of the program.

When I worked for the Navy, large programs were managed out of the Naval Air Systems Command up near the Pentagon. The program were managed by a Program Manager who was a Captain or Admiral in the Navy. The typical tour was three years. There was a marked tendency for the first Program Manager to push problems that were too hard into the next Program Manager's tour -- so the second tour became known as the Dead Man's Tour -- because the program was invariably delayed when all the problems piled up. The first guy looked good, and the second guy got a bad fitness report and didn't make Admiral.

If you want to have any chance of finishing a risky program on schedule do the "Worst-Things-First" then you clearly identify the big problems up front. --RaySchneider
Alistair asks: "how do we select what to attack first, up front?"

In the PlanningGame , users assign priority to stories, among other reasons, because of risks they perceive. "System must be able to pay 60,000 people in two hours. High priority." Developers assign technical risk similarly. "System must be able to marshal up to 60,000 networked PCs simultaneously for 1 minute each. High risk." We sit together and build consensus on what is risky, what needs a SpikeSolution, what order to do things. Is there a better way to identify worst things than to get together and work on it? --RonJeffries
I sometimes find the only way I can do the hard pieces is by separating out all the easy pieces and doing them first. After repeated iterations of this, the hard part is stark, clean and pure, and it usually turns out not to be so hard after all. (Sometimes it evaporates altogether.) -- DaveHarris

I'll second this. I can't count anymore the number of times I have have a seemingly hard Smalltalk problem go away after I put in all the obvious objects with their obvious interfaces. On a big project, the issue is different. If you take the worst thing first, the team has not had time to jell yet, they don't have any successes behind them, they don't have the communications paths smooth, yet. So I like to do EasiestThingFirstHardestSecond . The first gets you moving, the second is the test of the system design. Yes, I know we delayed the possibly really bad news by one month, but if we did the worst thing first, and failed, we wouldn't know what was at fault - the problem, the thinking, the communication, etc. I like to debug our development system first before taking on a nasty. --AlistairCockburn
In ExtremeProgramming, WorstThingsFirst is the rule. But so is DoTheSimplestThingThatCouldPossiblyWork. How do they go together? Quite nicely!

Identify a high-risk area. Do some research. Do a prototype. Do a SpikeSolution. You'll learn something - usually enough to know that the risk is no longer high. Write a TechnicalMemo on the solution if you can't put it in place immediately. Repeat until risk is low.
In BigBallOfMud, BrianFoote adds a nice paragraph to this discussion, about the use of CreativeStupidity to select what and when. I also like his annotation to the idea of RiskReduction?, "kicking the nearest, nastiest wolf from your door". This is, to me, still slightly different from WorstThingsFirst . I am finding that my strategy on my current projects is sometimes kicking the nearest, nastiest wolf from our door, sometimes evaluating the worst based on near but not immediate futures, and sometimes opportunistically proactively reaching into the future to change the overall direction. --AlistairCockburn
What I mean by WorstThingsFirst is entirely consistent with this. First, though, you have to broaden what you think of as the problems you need to solve. If you think in exclusively technical terms, then WTF is a terrible strategy, because only by blind luck will you get a confident, gelled team. If you immediately attack a bunch of technical problems that you are unlikely to solve, you're dead already.

Getting the team pointed in roughly the same direction is the worst problem. Then, getting the trust of the client is the worst problem. Then, getting the team and the client aligned is the worst problem. Then, get a good handle on the technology is the worst problem. Doo-dah, Doo-dah... --KentBeck
I've applied WorstThingsFirst for years, just for the very simple reason that it helps me sleep better at night. -- MichaelFeathers

Converting between Risk and Opportunity (BigBallOfMud, etc) can be accomplished with a dash of rhetoric. Opportunity loss is a risk, and the ability to sleep better is an opportunity. The problem with focusing solely on the most imminent peril, though, is that it can lead to a chronic siege mentality, where the time to make things better always comes right after the last wolf has been vanquished. I'll grab the $10,000,000 sitting in the basket on my porch right after I unclog this dang sink. So headache reduction is an opportunity, and so are better factored components. Letting a project erode into a BigBallOfMud is a risk.

Also, kicking a few pups away from the door first can build confidence and experience, where going after the big mean one first can make you a meal. --BrianFoote (who does not advocate cruelty to canines)
I'm with Brian. My first reaction to a big technical problem is "Oh, my God, I'm too stupid to tackle this one, I've bitten off more than I can chew!" I address this by picking some small easy problem and solving it. After I've done that, I think "Gee, that wasn't so bad", and I'm ready to tackle one of the hard problems.

Isn't there an EarlySuccesses? pattern somewhere in JimCoplien's Organization Patterns?

--BetsyHanesPerry (who does)

Question is, seems to me, which way do you lean? If you lean to always doing the least risky thing, your last step will be a big one. If you lean to always doing the most risky thing, things get easier as you get closer to the sharp end of the project. And that's when you need things to get easier. So, if you need one easy one to gell the team, OK ... but then? --RonJeffries

A manager of years ago gave sage career advice: when you land at a new company, pick a gnarly problem--one that people have been avoiding--and solve it. It gets you up the learning curve, and it gains you credibility and respect, both of which you'll need to be an effective developer and influencer. --DaveSmith

Maybe there's some kind of a pattern in there: ListenToYourCoworkersFears?, or something like that. Points to a CodeSmell, or maybe an OrganizationSmell?? -- FrancisHwang

A suggestion lifted from the EvoFusion literature: EnlighteningThingsFirst.

I am troubled. I get the vague feeling that WorstThingsFirst contradicts the EconomicsOfXp, even though they both seem to stand well enough on their own. What am I missing?
-- BillTrost

WorstThingsFirst is about risk. Think of risk in terms of probability - the chance the bad thing will happen, and impact - how bad it is if it does. Highest risk is kind of the product of these two.

Worst things first says address the high-probability high-impact risks, reducing them. This is economically sound, because it preserves the investment (when addressing the risk works), and reduces the loss if you can't in fact get rid of the risk.

EconomicsOfXp says, "... you want to do everything in your power to increase the probability of a project surviving ...", which goes to the same point.

DoTheSimplestThingThatCouldPossiblyWork and YAGNI are also economics rules, both going to minimizing the investment, preserving the project for the longest time, and increasing ROI. Arguments against these rules are essentially economic in nature, suggesting that it will be more costly or impossible to put in the needed function later. In XP we use WorstThingsFirst to select important (risky) issues to resolve, then DoTheSimplestThingThatCouldPossiblyWork to reduce the risk, and use YouArentGonnaNeedIt to avoid "opportunistic" diversions from the overall plan we're working.

WorstThingsFirst is in danger of becoming a tautology. For any criticism or alternate suggestion, the reply will come back, "well, if that is the worst thing, then you should of course do / have done that first". That makes for great project management in hindsight, which is not what any of us need. The question is, how do we select what to attack first, up front? --AlistairCockburn
One view that I like to take is that it isn't strictly WorstThingsFirst, but rather LeastUnderstoodThingsFirst? . If there is something I do not understand, I want to do it first since it is one of the things that I can not estimate (and therefore a risk). When I start a project, I don't have any idea what the worst thing will be, but I have some idea of what I do not understand. Forgive me if I just restated SpikeSolution in a different way. -- MichaelFeathers

Not at all, but a good statement of one of the best reasons to DO a spike! --rj
I hope we agree that assessing the impact side of worst things is generally easy. We know whether the world will come to an end if X, we just don't know the probability of X. (If this isn't agreed, let's come back to it.)

The main heuristic we use on C3 to decide on the probability side of worst things, is how big the estimate is and how sure we are of it. If we have no idea how long it will take to do some important thing, it is probably high risk. If we are sure it will take a week, it's probably quite low probability for a risk. If we are sure it will take three weeks, it might be a moderate probability because three weeks is a big estimate for us. If we think maybe it will take three weeks, maybe two maybe four, it's a higher probability. --RonJeffries
On EasiestThingFirstHardestSecond , I suggested doing the easiest thing first so that the team has a chance to meld, to get a success with each other. The unsigned reply (but I lean toward suspecting you, Ron) was: WorstThingsFirst never said anything about "most difficult technical problem first". It says to work on your worst, most pressing, most likely to cause trouble, most restricting problem first. Early in a project, getting people talking is far and away the worst problem. Doing something easy is a great way to address it. That strikes me as turning good advice into a tautology. If the easiest thing can be the worst thing, then WorstThingsFirst has no meaning. We might as well say Anything First, and define the choice of Anything as whatever you later discover would have been the best thing to have done first.

I don't think I wrote that, it doesn't sound like me. Cleaned it up anyway, check it now. I think we're in agreement if we only knew it.

The reply also says, RequirementsAnalysis really is your worst problem first. I'm sorry, I can't get from WorstThingsFirst, defined above as a method of avoiding the purely human tendency to put off the hard stuff until later, and In XP we use WorstThingsFirst to select important (risky) issues to resolve to WorstThingsFirst meaning either do requirements first or else do the easiest thing first.

'See if it's better now.''

To say WorstThingsFirst requires that you must be aware, in a very broad sense, of what your worst problem is. Second, you must be aware of when it is no longer your worst problem and have the courage to stop working on it on start working on something else removes the meaningful part from the advice. --AlistairCockburn

This objection I don't understand. What part of that is meaningless? Know (by navel inspection or any standard technique) what's bad. Reduce risk with as small an investment as possible. Reassess what's bad. Now it's probably something new, unless risk wasn't reduced enough. Select the worst. Repeat.
Ron, I moved the paragraph I feel is most informative up to the top of the page. That is the one I have seen that gives me an indication of what you consider "worst". If your readership can't figure out the rankings for worse or better, then they can't apply WorstThingsFirst. That policy should be, I believe, distinct from EasiestThingFirstHardestSecond, otherwise WorstThingsFirst becomes the tautology I have been threatening you with.

I really don't want to do the worst thing first, for two reasons: first is, I don't want to risk a failure early in the project. Second is, I really do want a success early in the project. As DaveSmith wrote, early success helps the team meld. "Making the team strong" is - to me- a different idea than "detecting a failure".

One more thing. All this is mere rhetoric and attempt to stick something into a formulaic phrase. I have a suspicion that if we were on the same project, we would actually agree quite quickly on the what would be the first thing to build. You might subsequently describe that choice as WorstThingsFirst or BusinessCaseFirst?, I might subsequently describe it as EasiestFirstHardestSecond? , or else we might change our formulations as to what those phrases mean. I detect a hazard here on wiki of getting stuck in what appears to be defending an insufficient rendering of our ideas in a medium not suited to the task. Do you get that sense, also? --AlistairCockburn

Indeed. It's not unlike the frequent occasions where someone rails at XP because of their interpretation of a catch-phrase whose subject page they've not grokked. Here we know what we're talking about and would surely agree in any real case. --r

I have a suspicion that if we were on the same project, we would actually agree quite quickly on the what would be the first thing to build.

Getting that first thing step right ... the smallest, most valuable step in business or risk resolution terms. You believe you would find that easy (with Ron)? I need to retire! I have never looked back at any evolutionary project without being able to improve that first choice with hindsight. The only choice I've made right since 1986 is to make the first and all subsequent steps short.

If you have a really small team, as I do at my company, you are constantly plagued by interrupts for doing something on a crisis basis. Examples are Marketing wants some small feature added to a product to sell a large order and they want it now . Sometimes we have problems that occur because a part has changed and we have to modify our calibration procedures which are computer driven to accommodate the new characteristics of the part. There are a large number of other examples. These all create interrupts.

What we do is a combination of RuleDrivenTasking : Rule 1 is 1) Interrupts Affecting a Shipping Product First, 2) Projects Nearing Completion 2nd, and 3) Standard Priority Development 3rd. A related rule is ClearTheDecks, which is a take-off on a Navy term. Clear The Decks means, don't let a lot of little things pile up. When you have several together, even though they may not really fit into the rules, do them anyway and get them out of the way. If you don't do that they nag on you and hurt your productivity on your main tasks.

--Ray Schneider

I think we can safely rename WorstThingsFirst to BestThingsFirst? and not lose any information content on this page. Do that first which is best to do first. Simply stare at your navel until you decide what is the Best thing to do first. Do it. Repeat. --AlistairCockburn

I haven't read the XP book, but I do the WorstThingsFirst. WorstThingsFirst is indispensible, at least for the following reasons which perhaps have not already been discussed:

--Chad Pratt
When I don't know where to start, I practice "Choose as if you were to die tomorrow". If I were to produce just one story/one task/one "thing", which one would be the most usefull, to the customer, to the team, to the project success, ... This helps me find the starting blocks.

Alain Ravet

You guys have all rediscovered TheoryOfConstraints, I think. Goldratt just used different terminology, but he worked from the same viewpoint and encountered the same difficulty described by Alistair above. The problem is how to find the constraint (the worst problem/best thing to do), not what to call it. --PeterHansen

Usually the worst thing has smaller building blocks. Create an initial success by completing these building blocks - then the 'worst thing' is no longer the worst thing, but an easy thing, by virtue of the building blocks. --Konrad Bloor
EditText of this page (last edited January 8, 2002)
FindPage by searching (or browse LikePages or take a VisualTour)