Programmer Time Translation Table(coding.abel.nu)
coding.abel.nu
Programmer Time Translation Table
http://coding.abel.nu/2012/06/programmer-time-translation-table/
31 comments
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/dear-boss-for-a-programmer-10-minutes-...
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/dear-boss-for-a-programmer-10-minutes-...
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"?
Yeah I hate that point too. I think a better solution would be to sit down with a co-worker and talk it through, rather than having to ask some god-like "architect" who knows everything about a system.
Agreed. At times though, I WISH there were a god-like architect around to chew all my food for me...
I'm an 'architect'. According to my job title. I just program, man. It's not even complicated stuff. But bare competence is apparently beyond the pale for the majority of people.
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?
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? ;)
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? ;)
That's a tricky one. On the one hand I'd say just a guy with paint on his shirt, but the fact that you know what Cadmium Yellow is definitely qualifies you as a painter!
I'm sick of this whole dichotomy of "architects" vs "programmers". It makes it seem like the "architects" are the brains behind the system and the "programmers" are just code monkeys. I'd hate to work in an organization where that was the case. I expect even junior developers to try to have a holistic understanding of the system, even if they might need some guidance from more experienced folks.
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.
Missing entry:
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.
6-8 weeks ==> Never
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.
Isn't that your opportunity to become a specialist?
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.
This article was posted (twice) a few months back:
http://news.ycombinator.com/item?id=4116554
http://news.ycombinator.com/item?id=4110296
http://news.ycombinator.com/item?id=4116554
http://news.ycombinator.com/item?id=4110296
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."
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 partySome 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.
* 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.
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.
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.
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.
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.
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.
Programmers tend to underestimate tasks.
Software estimation is an extremely complicated topic, this post barely scratches the surface.
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.
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.
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: [email protected]). 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.
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: [email protected]). 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.
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.
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.
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.
That's why devs should scotty-factor their estimates.
http://c2.com/cgi/wiki?ScottyFactor for those like me that didn't know that term :)
[deleted]
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.
PS: I've noticed that code gets estimated too low in general, but anything involving manual (repetitious) work gets estimated way too high.
I think you just invented agile ;)
Well OK, not all of it, but if you add iterative design that is the core idea.
Well OK, not all of it, but if you add iterative design that is the core idea.
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...
[1] http://en.wikipedia.org/wiki/Software_development_effort_est...
Using the same multipliers for everyone is bound to be sub-optimal, due to Parkinson's law.
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.