.jpg?q=80&crop=entropy&w=442&h=442&auto=format&fit=crop)
Do the Easiest Things First. I’ve long recognized the value of this principle for ticket management situations, but I haven’t given it much thought in my personal life. I do tend to do “easy” things first, but then I run into problems once I run out of easy things. I then sort of just bump randomly up against the harder things until I happen to get a burst of inspiration, or force myself to get started on one of them.
The paradox of Steve Litt’s “Easiest First” analysis is that he claims that lowering carrying costs of issues is the key factor, due to the fixed overhead cost of keeping track of each item. If this were really the issue, then obviously you should only keep track of one item: “do stuff”. This will then reduce your carrying cost to one thing. 🙂
So, the paradox is that – at least in one’s personal life – it’s better to have five or ten times as many things on your to-do list, as long as all of them are actually doable. If you have something that you keep putting off, maybe the problem is that you haven’t yet broken it into enough pieces – enough to make every piece an easy one.
In other words, maybe the real rule isn’t “do easy things, then hard ones”. It’s “do easy things, and then break hard ones down into easy ones.” Apparently, the carrying cost of a doable item is much lower than the carrying cost of an “amorphous blob of undoability”, perhaps because the doable items don’t haunt your brain the way undoable ones do – especially if you write them down.
The XP crowd says this backwards: “Worst Things First”. You have to find the hardest thing, then break it down into easy things, before you can start doing easy things. It’s interesting how you’re advocating opposite approaches but the wisdom sounds exactly the same :).
The funny thing about that is that this was actually a commentary on some recent test-driven development I was doing. I was realizing that I tended to make TDD too hard, by trying to write full-functionality tests. Now, I’m trying to learn to write zero-functionality tests first, ideally ones that will pass as soon as I add “def foo(): pass” to the code base. Then, I add a slightly harder test, and harder, until the full function is written.
As you point out, though, it’s *all* “breaking big things into small things”.
Absolutely the best way to attack any problem is to break it down. The question remains: what’s the best way to do that?
Not everyone works the same way, but the answer for me has been “Mindmap”. I use http://freemind.org but I plan to switch to http://twistedmatrix.com/trac/infogreater/trac when it starts to come of age. The reason the mindmap approach is so useful is it makes the breaking down of amorphous hard things into discrete easy things the core operation. If you know you need to do something, you just add a node. You don’t have to work on it, just have it in your global map somewhere. Later, when you think of a possible solution to it, you add a subnode. Or perhaps you just thought of another subprocess you have to complete before the big one will be done.. add a subnode.
At a guess, using a mindmap to track all my tasks has made me 10%-20% more productive. Also, I *never* let things fall through the cracks any more. And this is the only system I’ve been willing to use for more than a few months. I’ve been working this way for over a year now, and I still bring the map up and work on it every day.
It also helps if the mindmap software you use produces some kind of text format; that way I can keep mine in version control and bring it up wherever I happen to be working.
Actually XP advocates doing the riskiest and more important things next, at any given stage of development. There are a few types of risk:
1. The risk of not implementing the feature: lost opportunity or benefit. Somewhat related to importance.
2. The impact that adding the feature will have on the current state of the system, ie. how much refactoring is necessary to incorporate it, which translates to time required to develop it, the amount of code you stir up in the process (possibly introducing bugs) and refactoring tests too, of course.
Importance refers to the customer’s priority to get the feature into the product and is supplied by the customer. The customer is supposed to take imporantance and risk (and time estimates) into consideration when prioritizing what development should be doing for the next iteration.
I agree that a risky task needs to be broken down into managable and possibly “easy” chunks, but the collective risk and importance of those chunks is what dictates what you do first, not that they are easy or hard.
So XP actually clashes with this post, and just to be argumentative I’m going to side with XP since the other side is already represented. 🙂 XP advocates riskier (often harder by not necessarily) things first because that’s where all of the major decisions need to be made, and they often have a more drastic effect on overall architecture, and thus the ability to refactor features in later.
The danger of doing the easy things first is that after you’ve done them the hard things become nearly impossible to add without major refactoring. The XP theory goes that doing the riskier things first saves time in the long run. It forces you to take into account features with big architecture impact early on, even though it might be more uncomfortable up front than doing the easy stuff.
XP also assumes that you’ll be getting feedback along the way, which is why doing the most important stuff first is also critical. Something “easy” now may not be important later, and could be axed. From a customer’s standpoint it’s much better to get the “sure things” into the product, not the ones that are easy to develop. You also get better feedback in the early iterations if you actually have features with considerable meat on them, not easy ones.
I agree in general though and I’m not a complete XP zealot. Sometimes it’s a lot easier to get started by tackling simple problems! It’s a good way to get the ball rolling.
Actually, the XP stuff isn’t really relevant here. While I didn’t make the point here, the site I linked to makes it quite clear that “Easiest First” is a strategy you apply to *independent* tasks, not dependent ones.
Note also that risk-first prioritization in XP, at least as I understand it, focuses on risk-first *within* an iteration. However, outside the iteration, prioritization is business-driven, and all else being equal, is going to lean towards easiest first. And, within a given technical task identified as a risky area, there are still breakdowns that can be accomplished in easiest-first fashion. (For example, testing or “spiking” to figure out the actual risk, rather than trying to actually implement the risky part.) Risk-first prioritization actually has a very narrow scope on the whole, even though it’s still extremely important.
Anyway, the point is to prioritize the things you *can* do in an easiest-first fashion, and at any point where risk mitigation is required, risk mitigation is the only thing you *can* do (IMO). This was an assumption on my part, though, because I’ve been doing risk-first management of dependent tasks for so long (about 15 years?) that I don’t consciously think about it any more: I just do it.
P J,
You're right about the necessity of breaking down tough tasks into easier subtasks. It's for exactly that reason that I still maintain the carrying cost of easy items, relative to their time to completion, is heavier than the tough tasks.
You said it yourself — when the time comes for the tough task(s), you just break it down into subtasks and searches for information sources. You know you can do that — you've done it before, so it doesn't wear on your mind.
I really enjoyed your thorough analysis of easiest-first prioritization. Most peoples' reaction to easiest-first is "bah humbug, that's not how we do things here" or else "then we'd never get to the hard ones." 🙂
Good article!