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
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
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.
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?
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.
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.
- -- BillTrost
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.
, 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.
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
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.
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:
- The worst things can be worst because they ultimately require a paradigm
shift in thinking for a solution, and paradigm shifts only happen after your
ideas have had sufficient time to germinate and evolve and time has a way
of running out.
- Worst things can be worst because they involve completely foreign material, and new material needs time to be digested.
- Worst things can be worst because they touch on or determine the
behavior of many other parts, are therefore powerful determinants of everything
which follows and need to be done first for stability's sake.
- Nothing needs clear thought like worst things and nothing ruins
clear thought like panic, and nothing is as panicking as a looming deadline
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.
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.
EditText of this page
(last edited January 8, 2002)
FindPage by searching (or browse LikePages or take a VisualTour)