Developers tend to think in On-Task Time, because that’s what matters to them

It’s axiomatic that developers are bad estimators. That statement irks me as much as any other software developer, but in general, it’s true and we know it. Yes, there are good ones out there – those who live and breathe PSP , for instance – but by and large, we really don’t have a good track record of delivering software when we say we will. I’m not talking about projects – those are a whole different animal, and worth a separate discussion. I’m talking about individual programming tasks.

The reasons for this are legion, but I think that one thing often gets overlooked. People tend to think in different time frames – but the real trouble is that they usually don’t realize it.

If a manager asks a developer, “how long will it take you to code that functionality,” most will give a straight answer, assuming it’s reasonably well understood. “Two days.” Or, “three hours.” Or, “a week.”

What most of them really mean when they say that is, “if you lock me in a room with sufficient Diet Coke, hold my sister hostage, and give me just enough internet to be able to do whatever research/downloading I have to do and, above all, keep those sales guys off my back, I could do it in _______.”

This is a measure of what we call “On-Task Time” –  the time that a developer actually spends “in the zone,” which means fully mentally engaged on the task at hand, coding like the well-oiled machine she is.

Unfortunately, according to the SEI, developers only spend about 40% of their time “in the zone.” The rest of their time is spent on non-project tasks such as answering questions, going to meetings, reading email, installing patches, etc.

Developers tend to think in On-Task Time, because that’s what matters to them. When all of the cruft is removed, how much work is really involved in this task? When my manager asks me how long something will take (i.e., how hard a project is), why would I add in the time I’m going to spend trying to explain how something works to a sales guy? What’s that got to do with it?

To the manager, of course, that’s got everything to do with it. Most managers have a team of people whom they’re trying to manage (hence the name…). If I’ve got 10 developers, then I have 400 hours per week. Or 500. Or 600, if the pace of work is really gruesome. So if Martha tells me that this task will take 12 hours, then that’s 30% of one developer week. I’ve got another 28 hours of work to assign her. Ok, maybe 23 –  let’s face it, she has to read email, too.

Managers tend to work in “Active Time” –  that is, how much time do I have to spend on these tasks? Typically, the sum of all of my “Active Time” will add up to about 40 hours a week. Or 50. Or 60. Maybe it’s reduced a bit for nominal email reading or random meetings, but few managers will say that they only expect their workers to put in 16 hours a week on actual coding tasks. That would be absurd.

Of course, the VP of Sales doesn’t care about that at all. Nor does the CEO. What they care about is when the product becomes available to sell, and how quickly it will start producing revenue. People at that level tend to think in Elapsed Time. When they ask how long some particular feature will take, they’re not interested in how many “On-Task” hours the developer will spend on it. They don’t care how much “Active Time” the manager will assign the work. They care about when it’s going to start generating money for the company.

And hence the disconnect. It’s not that a good manager won’t try to translate a developer’s estimate (which she should recognize is really an “On Task” number) into Elapsed Time (which she should likewise know the CEO really wants). Often they will. But it’s difficult.