Easiest Thing First Hardest Second

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

Somewhere in this hypertext we describe that on C3 we started with a one-week project that actually went through the entire process, end-to-end, of creating a check with our proposed architecture. Then we threw it all away and got down to actual cases.

Maybe that was EasiestThingFirstHardestSecond.

My own opinion, though, is that WorstThingsFirst, with DoTheSimplestThingThatCouldPossiblyWork, is the way to work day to day. In any case ItsJustaRule. --RonJeffries And RulesAreMadeToBeBroken :)--RaySchneider

Easiest Thing First is a good way for a newly-formed team to share a low-risk "shake-down cruise" to gain comfort in working with one another. Crank up the pressure right away, and people will often fall back on behaviors that worked in their last team, but which aren't (or aren't yet) part of the current team's culture, and may seem mysterious (and provoke anxiety) in other team members. --DaveSmith

Two arguments have been given for using this process instead of WorstThingsFirst: 1) building project momentum, and 2) debugging the development team (and/or process).

To address the first argument ask yourself - What builds more project momentum having the easy task done, or having the worst task done?

AlistairCockburn uses the possibility of attempting the worst task and failing, as justification for using EasiestThingFirstHardestSecond. I don't think this is a good enough for the following reason - even if you attempt to select the easiest thing, you might still fail.

So another question you might want to ask is - If I were going to attempt a task and fail, would I learn more about the system (and debugging the team) by attempting the easy task, or by attempting the worst task?

The previous paragraphs discussed the same outcome for both the easy and the hard task - and ignored the possibility that WorstThingsFirst is more likely to fail than EasiestThingFirstHardestSecond. So, consider that the easy task would succeed, and the worst task would fail. Both processes have the same result (i.e. failure on the worst task), but EasiestThingFirstHardestSecond has it later. The success of the easy task gave you momentum, but you still aren't going anywhere unless you can solve the worst task.

As for the second argument I think it is possible to debug the team using either EasiestThingFirstHardestSecond or WorstThingsFirst. However, I think the difference between the two is similar to the difference between dating and marriage. If you are doing something easy there is no struggle or conflict; it is easy to be reasonable, and everyone is on their best behavior (just like dating). On the other hand,if you are doing something harder, there is the potential for disagreement and conflict (like marriage, for better or worse). Since conflict is sure to arise at some time on every project, the team cannot be considered debugged until it can handle conflict.

DaveSmith also makes the point that people behave differently under pressure. What better time to crank the pressure up than right at the beginning? After the hardest thing is done, the pressure will probably easy up. If you have done something easy, the pressure is still waiting to build. And you still don't know how your team will react to stress. --AnnAnderson

People do behave differently under pressure, and until those differences are understood and appreciated by others on the team, cranking up the pressure leads to perceptions of bizarre behaviors among folks who haven't yet worked together. The team may form, but it probably won't norm.

Once team members are comfortable with one another, and have developed some agreements on how to behave (procedures, etc.) then by all means take on the difficult stuff. --DaveSmith

Starting with an easy thing first to build the team is not contradictory to WorstThingsFirst. WorstThingsFirst doesn't say "work on the 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 some easy technical task, whose real purpose is teambuilding, is a great way to address it. When getting people talking is no longer the worst problem, move on to whatever is. So the two ideas are not in contradiction at all. Do an easy thing first because the worst problem is team-building.

If you think about it, even the WaterfallModel sort of follows WorstThingsFirst, it just doesn't know when to quit. It starts with RequirementsAnalysis. That really is the worst problem at the beginning(*). However, WaterfallModel would have you do RequirementsAnalysis until done. On most typical IT projects, a few weeks of analysis will reduce the requirements risk. It's not worst any more. Now the worst problem is that you don't know the cost of implementing the requirements. The best thing to do is stop doing more requirements and scope out cost for a while. Etc, etc.

(*) TeamBuilding? might really be the first worst. Waterfall, like many methodologies, doesn't acknowledge that there are humans and feelings involved in the process.

WorstThingsFirst requires that you do two things at once. First (this is the hard part) you must be aware, in a very broad sense, of what your worst problem is. Second (and this is the harder part), 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.

In a programming course, your first assignment is typically to print "Hello world!"

You do this, not because it's hard. Quite the contrary; you do it because it's easy: Having printed "Hello world!", you've demonstrated that you can log on, edit a file, compile it, and successfully run it. Now that you're "rolling," you can start to put some weight on the cart, and do real work.

For guidance that doesn't have anything to do with difficulty, think about FirstThingsFirst.

Exactly the contrary advice EasyThingsFirst.