Programmer Time Translation Table
coding.abel.nu
coding.abel.nu
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.
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-...
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? ;)
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.
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* 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.
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.
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.
Programmers tend to underestimate tasks.
Software estimation is an extremely complicated topic, this post barely scratches the surface.
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.
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.
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.
PS: I've noticed that code gets estimated too low in general, but anything involving manual (repetitious) work gets estimated way too high.
Well OK, not all of it, but if you add iterative design that is the core idea.
[1] http://en.wikipedia.org/wiki/Software_development_effort_est...