Category: Elegant Code

I’ve been reading ReWork by Jason Fried and David Heinemeier Hansson, and it reminded me of one of my favorite rants. I’m usually even-keel, but this topic will get me as fired up as a libertarian on Wall Street.

The short version is this: There is no such thing as a ten-minute task.

What reminded me of this was the short and on-point chapter titled “Your Estimates Suck”:

We think we can guess how long something will take, when we really have no idea.

Their focus in this chapter is on the futility of long-term estimate, but there’s a related trap, and that’s when a developer says, “That’s no big deal. Should take about ten minutes.”

Nein! Das ist nicht gut!

Ten minutes is a tempting timeframe. It feels like “enough time to get a small task done.” But unfortunately, it’s also just long enough that our brains can fuzz a task and fit it into this imaginary ten-minute time block. Now and again we really do accomplish a minor task in ten minutes, and that feeds the evil fantasy that we should ever, ever tell anyone in the universe that we can accomplish something useful in ten minutes.

In the Getting Things Done system, you have to do tasks immediately if they’ll take less than two minutes; that’s basically one action. Putting a paper in a file folder. Looking up a phone number online. Texting a friend. Getting your mail. (And if you live in a rural area, even getting your mail might be a major undertaking.) Not a project, with multiple tasks: a single, immediate task. Two minutes. That approach works. But ten minutes? Too fuzzy.

When it comes to code changes, I’m no longer tempted to say anything will take ten minutes, but I understand the impulse. Even the most thoughtful, well-intentioned 10-minute estimate has two key factors are at play:

We count on a best-case scenario, and

We forget or minimize the preparation and follow-up involved in fully completing a task.

It’s like estimating how long a trip will take, but without allowing for time to find your keys, load up the car, stop to get gas (because you didn’t realize how low the tank was), wait for a drawbridge, find parking, and walk to the door. The driving portion might take ten minutes, but the rest of it could easily double or triple the total time.

When it comes to code repairs, I have a minimum “time to fix” of one hour (more often two), because even the smallest change has multiple steps and there are potentials for delay at each step:

Open the project (I may be working on something else).

Create a hotfix branch (this will require stashing if I was working on another feature; the productivity penalties involved in task switching is a whole other topic).

Find the file (it might not be the one I’m thinking of).

Open the file (my IDE might churn, depending on what mood it’s in).

Make the change (it might not be as simple a change as I thought).

Test the change (I might discover this little modification has a wider effect than I thought, or that the repair isn’t all that simple).

Commit the change and do a pull request (the build manager will now be interrupted to approve the pull request).

That doesn’t even include deployment to the sandbox, quality assurance, documenting the change, and slating the change for deployment to production, among other tasks. Even if I’m not doing those tasks, someone is. Even the tasks that are handled by an automated process may still require time for completion, which I also have to consider.

To combat the two key factors identified above, I’ve found these tactics to be useful:

Allow slack so you don’t depend on best-case scenarios. If you think something will take ten minutes, quote an hour; if you think something will take an hour, you should probably allow for at least two. If you get lucky and it really does take ten minutes, everyone will be happy.

Analyze projects thoroughly before estimating time required. Remember, a project is anything that involves more than one task, so list out each task. The more granular your plan, the more accurate your estimates are likely to be.