
Programmer Time Translation Table - chinchang
http://coding.abel.nu/2012/06/programmer-time-translation-table/
======
digikata
Two comments. To me providing good estimates for a single task below a half a
day seems like a pointless exercise in estimation. It feels like below that
threshold you're working in a micro-management environment where the task
tracking is taking away from time-on-task getting things done.

For planning larger projects of multiple man years, I think the threshold is
even higher for productive estimation. In those long term planning situations
estimates below a half a week to a week are more appropriate, because you'll
get a better plan focusing on improved requirement specs or use cases etc.
This is because the uncertainty of the project completion is better reduced
not via better estimates, but better definitions of the tasks or developing a
better feel for the technical uncertainties leading you to better estimates. A
more precise estimate is not the same as a more accurate estimate.

The second comment I'd have is that the most frequent mismatch in estimates is
that programmers instinctively estimate the time narrowly focused on
implementation, or the time for getting over the hump of the core problem
(subconsciously I think thats because after that's done it's boring stuff that
few people want to dwell upon). The estimation fix is to separately estimate
design and or implementation separate from testing (fixing) and deployment. A
good rule-of-thumb there is that testing and deployment will be Pi times the
implementation estimate. That factor is even higher if you have a complex
multi-layer subsystem / system integration testing scheme required for the
project. There are so many shops that like to pretend none of this exists, and
they can even manage to succeed doing that, but there's a lot of bad side
effects. They're not as effective long-term, often implode after rolling that
dice too many times, or will depend on the technical side to grind it out with
heroic measures.

------
edw519
Hey, don't blame (plan # actual) on programmers' poor estimating alone. There
are plenty of other reasons.

Here's are a couple of my typical instances:

[http://edweissman.com/it-takes-6-days-to-change-1-line-of-
co...](http://edweissman.com/it-takes-6-days-to-change-1-line-of-code)

[http://edweissman.com/dear-boss-for-a-
programmer-10-minutes-...](http://edweissman.com/dear-boss-for-a-
programmer-10-minutes-3-hours)

------
xyzzy123
Wait, so does this mean that if you can plan and execute a program of work
which will take longer than a week, you're suddenly an "architect"?

~~~
mcantor
Well, maybe. If you can put paint on a paintbrush and transfer it to a canvas,
are you suddenly a "painter", or just a guy with Cadmium Yellow smeared on his
shirt?

~~~
xyzzy123
If you're talking about art, you'd have to ask Jackson Pollock about that ;)

I'm not bagging on 'architects', I just think the article pulls its punches
when it says... "and for everything else, ask a grown-up". Well what if you
ARE the grown-up?

In a sense, what the table is saying is: "don't commit to estimates longer
than a few days". I think that is great advice if you can get away with it.

Understanding the problem and coming up with the detailed design is what
usually takes time. The problem is that this information is expensive to
produce. In fact it is usually the majority of the development effort.

Development tasks come in at varying levels of well-defined-ness:

* Imperative specification: Implementing a trivial, well specified feature, where all the edge cases have been specified. "Add a new field to form #37, store it in table 'blah', valid input is this regex...". Of course there is usually no problem with estimation in this case.

* Declarative specification: That is; the customer or stakeholder knows what they want, but you will have to do the design work. "We need I8N support in our webmail product. We need a dropdown in the compose window, and a language selector here and ...". Usually the edge cases in the specification are fuzzy and often it will turn out later that the customer didn't understand certain aspects of the problem themselves. Estimates will vary wildly depending on how much time is allowed to produce the estimate, and what approach towards a solution is envisaged initially. Most of the work is actually understanding the problem and producing a detailed design. It requires an intricate understanding of the existing code-base and the problem domain (in this case I18N). This how things really work in most of the industry. Not saying that's right though.

* Debugging: The pathological case. Fortunately, beyond triaging, most people don't expect estimates for this. When fixing really complex bugs (e.g. perf in a huge distributed system), sometimes the best you can do is produce a plan and demonstrate progress.

If the solution to difficult estimation problems was just "give it to an
architect to decompose the problem" then estimation wouldn't be hard. This
approach would work, if we assume the existence of some mythical architect who
can instantly decompose any problem into day or two sized chunks.
Unfortunately there is usually no mythical all knowing architect to whom the
problem can be punted and the team and PM have to work it out. Of course,
estimation has costs too...

Hey, and I know you're really busy right now, but could you get that to me by
Friday? ;)

------
donebizkit
The time translation is dead on. Just a caveat. In my last job I used to give
the actual time estimate and the PM was always frustrated because I was always
estimating more that my colleagues. I am a literal person, which always gets
me in trouble. So when I hear someone say I need 30 seconds I always reply
that the time it'll take you to go back to your desk is already more than 30
seconds. Anyways, when I started giving the coded* time estimates it made
everyone happy and I had more credibility with PMs.

------
finnw
Missing entry:

    
    
        6-8 weeks ==> Never
    

If you're lucky, the programmer is Jeff Atwood (but it will still take a
year.)

More likely, the task will never be finished, unless management intervenes by
splitting it into smaller tasks.

At that scale, you're probably overlooking whole features (as in, feature A
depends on feature B.) And feature B may be something you will need a
specialist for, like fraud prevention or database replication.

~~~
alexchamberlain
Isn't that your opportunity to become a specialist?

~~~
rabidsnail
Depends on the context. Doing so is risky and expensive, but if you're a
startup you eat risk for breakfast and can just cut back on sleep.

------
greenyoda
This article was posted (twice) a few months back:

<http://news.ycombinator.com/item?id=4116554>

<http://news.ycombinator.com/item?id=4110296>

~~~
sequoia
not to mention <http://news.ycombinator.com/item?id=4328660> where the author
posted the same article to another site.

my reaction, then and now:

"4 hours: This is probably the only realistic estimation. It is large enough
to have some margin for unexpected problems, while the task is still small
enough to grasp."

    
    
        1. Estimate everything in 4 hour increments
        2. 100% accurate estimates
        3. Pizza party

------
jiggy2011
Some of the stranger things I've come across when non technical people have
tried to estimate time-scales to develop something.

* This feature will not take long because <giant technology corp> has already developed something similar.

* This feature will not take long because it will not be used frequently (or because the 100s of edge cases will not be encountered regularly).

* This feature will not take long because it will only be one button click in the UI.

* This feature will not take long because it integrates with a lot of existing systems.

And of course:

* This feature will not take long because I need it tomorrow.

------
Zenst
Two things when doing esimates, the engineering muliplier factor and fully
understanding the task multiplier.

If you have somebody who knows the task well and knows exactly what do to then
the task muiltiplier is 1x, engineering multiplier is usualy always 3x, some
unwritten rule. If the person is not fully aware of what is needed to do the
task exactly but near enough then you increase the tast multiplier. Combining
the pair without any unit shifting for me works well. I'm sure others will
explain why the engineering factor is never 1x.

It is also worth noting that any engineers or programmers estimate time is for
the consumtion of you line manger and internal and not customer directly
presented. Reason being is that managers will either increase that more or
come back to you as to why it is so long.

Now manager will increase things as they will want to increase company profit
and what might be a 5 minute change for a programmer, could be something that
can be charged as a 50 hour change. There are situations were a 50 hour change
from a customers perspective is only a 5 minute change and it is the managers
role to adresss and educate were needed and juggle and balance tasks and costs
with others.

Saying all that if your a programmer and dealing directly with teh customer
with quotes, then you will learn your own time stretching approach multiplier
that works for you and your clients. Just remember egos can be costly if you
charge for 5 hours something that takes longer in the end, learn from it as we
all do, every now and then.

------
confluence
This is a humourous demonstration of the planning fallacy
(<http://en.wikipedia.org/wiki/Planning_fallacy>), which is a direct
derivation of the the anchoring bias
(<http://en.wikipedia.org/wiki/Anchoring>). This bias causes humans to be
unable to adjust conjunctive (multiplicative) probability sets down low enough
to accurately predict the total time to completion of complex tasks.

Basically - even though the actual chance of implementing any part of a
program is very high - the multiplied probabilities of all the parts working
together fall geometrically towards 0. Due to anchoring, humans don't adjust
down far enough which in turns leads them to underestimate the total time to
completion of various tasks.

------
nc17
This article can be summarized as follows:

Programmers tend to underestimate tasks.

Software estimation is an extremely complicated topic, this post barely
scratches the surface.

------
OSButler
What's also missing is the client point of view, where a feature gets
requested, the developer provides an estimate and then the feature gets
changed over and over again by the client during development, yet the client
is asking why it takes longer than originally estimated.

A little bit unrelated, but another fun one that happened to a friend recently
was the redesign of a website over to wordpress. Once it was done & ready to
be deployed the client mentioned that they don't have any servers with php
support available - he was the same contact who confirmed and approved all the
original specs, heh.

------
ErrantX
Everybody is bad at estimating tasks. When I ask project managers how long it
will take them to get the specification drafted "1 week" means at least two :)

I'm not being defensive, I agree with the OP, just think it extends to
everyone.

Specifically in programming there is a problem when working with suboptimal
teams. Many times as a freelancer I've worked for an "experienced project
manager". Don't get me wrong, these are charismatic and smart people who know
how to motivate and organise a team. But can't for the life of them write a
proper technical specification.

So obviously that means an unexpected drafting process (back and forth between
us) or I work on an incomplete spec (and all the delays that entails).

It works the other way too. I've still not been able to pin down the best way
to do design feedback with clients (if anyone has tips, please let me know:
tom@errant.me.uk). Currently they spec what they want and then we trade emails
and phone calls to make tweaks until it is ready.

When you work remotely this gets even harder - catching each other in phone
calls is difficult, you have to trade several emails just to organise it. And
usually that even gets scuppered by a last minute flake out. If you have a
good project manager at the other end that's not so much a problem of course.

Estimating time is hard, but I always overestimate by about a factor of two.
On the basis that when I make it under time it looks good, and the client
doesn't get disappointed. When contracting this is even harder because "2 days
work" isn't a completion estimate, so you have to say things like "It's a
couple of days work, and if I get it into my schedule I should have it done by
next Friday").

And then there is the inevitable; "oh yes, but we meant that as well..."

The bottom line; get. a. proper. _specification_. :) Saves most headaches.

~~~
grey-area
I approach this slightly differently when contracting in order to get a spec
everyone can agree on.

1\. I ask the client for a brief (an outline of what they want, not a detailed
spec, the general _what_ rather than how, when or why).

2\. I give them a spec which satisfies the brief, highlights any areas they
might not have thought of, and outlines exactly how the work will be done and
what it will entail (and what it won't), and how long it will take in days of
work (not days on the calendar), broken down into small subunits of several
days each.

3\. We sign off on the spec (with any revisions they want), agree on a
schedule (based on the time estimates with plenty of padding added for
feedback, approval stages etc), and I start work.

The padding for the schedule (perhaps 3 x work days) won't cost them extra,
and is there to cover the inevitable friction that working in groups produces,
but if you're contracting you can spend that time waiting for feedback doing
other work, so it comes at no cost to both parties. Probably the padding
increases as the size of the company you're working for does.

I've never received a spec from a client that I was completely happy with, so
it's easier to turn it around and accept a brief describing their goals in
general terms, then give them a detailed description of how, when and why I
would produce what they want. Asking them for the detailed specification, or
even accepting one from them without lots of discussion, usually leads to
problems as you're relying on the client to specify things they may not fully
understand, you're asking them to tell you exactly how to do all the work, and
by starting with their spec and mangling it or forcing lots of compromises,
you make them feel they're not getting what they want. Whereas turning this
around and giving them a spec lets you explain the cost/benefit of all
decisions up front, and still gives them room to add/remove things as they
wish as they approve the spec.

I do this even for design work as well as programming work, as there are a
surprising number of constraints which a client may not consider, but will
wish by the end of a project they had. All that said, most of my best ideas
come from clients half way through a project, so you can't expect things not
to remain fluid - that's just the nature of creation - as long as changes
_improve_ the end result and don't have knock-on effects I welcome them.

I'm not really convinced the article is correct in estimating 1 day as the
horizon over which most developers can't see - in my experience that's too
low, and it'd be more like several days, and as long as you split tasks up
when estimating, it's not hard to estimate the _actual hours worked_ \- far
harder is to estimate the friction introduced by bureaucracy and politics in
larger organisations. I suspect that's where most inaccuracies in scheduling
creep in.

------
kyt
I've seen the inverse of this, though. For example, I estimated it would take
me a couple days to do finish one part of a project, but I told the PM one
week. She in turn multiplied it by 3 when she actually turned in the project
schedule. So at the end I was given 3 weeks for an estimated 2 day task.

------
dccoolgai
That's why devs should scotty-factor their estimates.

~~~
jurre
<http://c2.com/cgi/wiki?ScottyFactor> for those like me that didn't know that
term :)

------
jstsch
The solution: break your task into smaller chunks (< 1 day). Then estimate for
the week, max. "At the end of the week, X will be done.". After then, scope
will be more clear for the tasks following...

PS: I've noticed that code gets estimated too low in general, but anything
involving manual (repetitious) work gets estimated way too high.

~~~
xyzzy123
I think you just invented agile ;)

Well OK, not all of it, but if you add iterative design that is the core idea.

------
svag
There is an interesting article in wikipedia [1] which summarizes some models
used to assess the time estimates.

[1]
[http://en.wikipedia.org/wiki/Software_development_effort_est...](http://en.wikipedia.org/wiki/Software_development_effort_estimation)

------
robocop
Using the same multipliers for everyone is bound to be sub-optimal, due to
Parkinson's law.

