Slashdot Mirror
Overconfidence: Why You Suck At Making Development Time Estimates
Dan Milstein from Hut 8 Labs has written a lengthy post about why software developers often struggle to estimate the time required to implement their projects. Drawing on lessons from a book called Thinking Fast and Slow by Dan Kahneman, he explains how overconfidence frequently leads to underestimations of a project's complexity. Unfortunately, the nature of overconfidence makes it tough to compensate. Quoting:
"Specifically, in many, many situations, the following three things hold true: 1- 'Expert' predictions about some future event are so completely unreliable as to be basically meaningless 2- Nonetheless, the experts in question are extremely confident about the accuracy of their predictions. 3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel. The last one is truly remarkable: even if experts try to honestly face evidence of their own past failures, even if they deeply understand this flaw in human cognition they will still feel a deep sense of confidence in the accuracy of their predictions. As Kahneman explains it, after telling an amazing story about his own failing on this front: 'The confidence you will experience in your future judgments will not be diminished by what you just read, even if you believe every word.'"
'nuff said.
We've all been under pressure to give our "best" estimates and then some.
Give a realistic estimate? Off to India!
1- 'Expert' predictions about some future event are so completely unreliable as to be basically meaningless.
2- Nonetheless, the experts in question are extremely confident about the accuracy of their predictions.
3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel.
There's problems with the dev machines and environments, changing specs (including specs which are just stupid and need changing by someone with some sort of clue, rather than an overpaid 'analyst' who's just cutting and pasting stuff they don't understand from other people's documents), unforeseen problems during development, resourcing difficulties - all for a fuckwit of a manager with no technical experience who just wants a number they can enter into an email.
I found that if I multiply by Pi my estimated time I'm usually right on target !
I'm not an expert in these manners, but I think you're supposed to post an APK troll as the first post.
Points 2 and 3 don't seem to apply to me. I know I suck at doing development estimates. When asked for one, I've never been particularly confident about any estimate I give having a good chance of being accurate. I want to estimate conservatively, but project schedules don't allow for that.
File under 'M' for 'Manic ranting'
Predictions on the time it takes for me to do something can be off, but not by much. Most good predictions have contingency plans, etc...
In my experience, the biggest variability in estimates is the reliance on external dependencies. If I were the only person needed to work on something and I estimated 40 hrs of work, I would probably get it done in 30-45 hrs. But when that works requires someone else to do something at a critical point, even if it only takes 1 hr, the ability to acquire that resource in a timely manner ALWAYS messes with the time. Instead, the 30-45 hrs turns into 40-60 hrs. Amazingly, the "wait time" makes my time spent worse as well. I have to go through "ramp up" time again.
You can even schedule out that you will have the person for 1 hr a whole week ahead of time. But I have found it rare that you are able to acquire that resource remotely close to the time you scheduled.
Well, I at least have my wife trained to treat my time estimates as "no sooner than", and I don't have any trouble sticking to those commitments. Can't be that much harder to train your boss to have the same expectations.
Anyway, isn't most of Agile centered around coming up with time estimates formed from a consensus of team members who know you well?
Always tripple all estimates. That way you always look like a miracle worker.
If I were God, wouldn't I protect my churches from acts of me?
If you think it will take an hour, say it will that three, then when it takes two you're a genius for getting it done so fast.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
From the story, "[they] were instructed to lift a long log from the ground and haul it to a wall about six feet high. There, they were told that the entire group had to get to the other side of the wall without the log touching either the ground or the wall, and without anyone touching the wall. If any of these things happened, they were to acknowledge it and start again."
Sure seems like it would have been easier to just carry the log around the wall rather than over the top.
It took me a few years for me to discipline myself to including testing and bug fixes in any estimate I made to managers. When ever I would say, "I'll finish coding by X," they would always assume that it would be in release condition by then.
The Moore-Murphy Law: The number of things that will go wrong will double every 2 years.
I often find another problem is management's refusal to accept the estimate of the developer. I am usually pretty good at estimation. Here is what usually transpires for me:
Manager: "How long will it take you?"
Developer: "2 months."
Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"
Developer: "2 months."
Manager: "You don't have 2 months. You only have 1 month. Redo your estimate. How long now?"
At this point I feel like saying:
Developer: "Why are you asking for my input? Just write down 1 month. And do you want me to tell you I will be 1 month late right now or in 1 month from now?"
That it'll take 2x-3x longer than it takes in my head. If there are no spec changes (i can dream, right?) or other surprises, maybe put that down to 1.5x.
When given a project, I'm sure most people will have a macro-level architecture thought up within minutes. It all seems so easy at that point! If you're lucky you get to spend a little more time in thought before being asked for a time estimate. If you're unlucky, well... in those cases I just multiply by 3. Underpromise, overdeliver and all that.
There are much more simple ways to explain this..
1. There is often no incentive to deliver an accurate projection. If the job will take 12 months, you say it will take 12 months, and your competitor says six months, guess who is going to get the bid. When the six month date rolls around, the project will be extend to 12 months anyway because there is already a lot of time and money invested. Lying works. Welcome to the bid process, and sales in general.
2. Humans are bad understanding complex, non-linear relationships. Software development is just about the definition of complex and nonlinear.
3. There is already and expectation of cost and time overruns in development projects. Most people are shocked and surprised when a project is delivered on time.
My team seems to do ok on the estimates. Then we get beaten into 1/2 that by management. Then in the end it takes twice as long as management expected. So the original estimate was good.
So we would be fine if only management did not try and squeeze it.
Management never accepts the "debug", "refactor" and "new feature" timelines, those are generally considered as "not needed". It just supposed to work perfectly and on the timeline they negotiated before consulting the people who would actually deliver it.
*sigh*
Blah, blah, blah. Bad estimates.
Blah, blah, blah. Oh noes! Waterfall!
Blah, blah, blah. Fixed by Agile!
I think they finally blocked the APK posts with a HOSTS file.
But it's not really that hard to predict estimates where predictable and predict a reasonable time to determine if an area is predictable.
The RUP methodology is excellent for this.
1) You gather the feature set and identify the risk vs non risk portions of a project.
a) New technology.
b) Relying on develop of technology which doesn't even exist yet.
c) Performance.
2) You work on the risky items first. You do not start on the non-risk portions until the risks are mitigated.
3) Work in a time-boxed fashion. The time box can be 3 weeks or 5 weeks but deliver a working build each release. Note which features are not on track and drop them, adjust estimates, or even cancel the project.
And there is also baselining your coders. Over time, some will consistently be over cautious, under cautious, or on target. And by a consistent amount.
Let me put it this way...
How long would it take you to develop a sorting algorithm for a screen element?
How long would it take you to develop an import mechanism?
OTH, how long would it take to integrate your web site with an app using a new poorly documented library delivered last year?
I agree with the author that some things can't be estimated. But many things can.
The biggest problems I've seen are
1) Business decides the delivery date, features, and sometimes even the budget without consulting IT.
2) If a couple 70 hour weeks work to deliver in a crunch then always working 70 hours must be even better, right?
3) Business firing anyone that says a project is risky ("not drinking the koolaid").
4) This is a funny one.. They come and say, "How long will this take" and one person says 4 weeks and the other person says 2 weeks. So they consistently give it to the person who said 2 weeks. And then it takes them 4 weeks (sometimes longer).
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
It's easy to manage time if you keep this simple law in mind:
The first 90% of the work will take up the first 90% of time, and the remaining 10% will take up the other 90% of time.
Then I'll estimate time to design, implementation, testing, debugging, and release of a product.
How about people just stop with this ridiculous nonsense notion that it's even possible to estimate this kind of thing to +/- 1000%?
La Forge: The Captain wants this spectrographic analysis done by 1300 hours.
Scotty: Starfleet captains are like children. They want everything right now and they want it their way.
But the secret is to give them only what they need, not what they want.
La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
Scotty: How long will it really take?
La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
- TNG 6x04
Use a OUIJA board, or, do some decent project management planning and know thy tasks, thy players and thy resources at your disposal.
For the most part, double your estimates and then adjust where it gets too costly and you know your players can perform fast than expected.
Lt. Commander Geordi La Forge: Look, Mr. Scott, I'd love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.
[La Forge goes back to work; Scotty follows slowly]
Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.
Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I'd have this analysis done in an hour.
Scotty: How long will it really take?
Lt. Commander Geordi La Forge: An hour!
Scotty: Oh, you didn't tell him how long it would *really* take, did ya?
Lt. Commander Geordi La Forge: Well, of course I did.
Scotty: Oh, laddie. You've got a lot to learn if you want people to think of you as a miracle worker.
It also helps you plan time for unforeseen setbacks.
Profitabily is 12 to 18 months out. Thats when the hockey stick curves up.
It was that way 3 months ago. It will be that way in 3 months.
I hate making estimates. I'm always, ALWAYS wrong. I always know I'm GOING to be wrong.
I've been trying to fix this for 12 years. I thought it was just inexperience talking, but I'm a grown-up programmer now. 'Senior', by some estimates. And yet I still have a hard time estimating the time of getting things up and running. I write one thing, and four things that I couldn't have anticipated crop up. This is particularly true in my industry (video games) where you're often working with an engine that's a few years old, and other people are in the middle of working on it, and specs are changing under everyone all the time. Things that look straightforward end up taking bad detours through networking components that nobody else understands because that part was written years ago and those programmers aren't around anymore.
Man, this story makes me feel a lot better about myself.
Real time expectation = ideal expectation times three
x1 = time you need to do the job if nothing goes wrong
x2 = when you find something unexpected and search for a solution
x3 = implementing the fix/workaround/rollback or whatever you decided to do in the end
I call this experience.
First post!
I don't know what the article is talking about, my time estimates are perfect.
I started to get offended at this broad generalization that experts can't make accurate estimates. And then I realized that no where in the summary does it say anything as to the absolute value of anything. It uses phrases like "extremely accurate" or "extremely confident". If someone takes a 1,000 hour project, and predicts it will take 1002 hours +/- 1 hour, is that a failure? Or does the OP mean the expert says 1,000 hour project is predicted to take 10 hours +/-1 hour is a failure. What is this confidence? Is this 99.99%? Is this 51%? An adverb and a verb without a point of reference is useless. But man, does it sure sound good!
Hofstadter's Law:
It always takes longer than you expect, even when you take into account Hofstadter's Law.
In my previous life as a software architect for a small rural software development shop, I would try to give estimates and my bosses (all salesmen) would come back with, "I can't sell the client that!" Then when I missed the deadline or had to work weekends they were quick to blame me for giving an unrealistic deadline. My favorite line was always, "Give me an estimate, I won't hold you to it." Yeah. freakin. right.
Even better is when I would attempt to show them what other SUCCESSFUL development shops were doing. They would then give the excuse, "That's because their developers just sit and do nothing all day. Big shops have money to blow." Wrong. Big shops grow big because they know what they are doing. Eventually when they figured out my patience had run out, they dismissed this constructed advice as me just dissing the company.
I'm not sure why I stuck around with them for so long. I guess it was a sense of loyalty. Yet they tried destroying my marriage with their unrealistic estimates (and contracts that allowed clients to call me at home when-freakin-ever they freakin wanted. Guess as long as it didn't bother them or their time with their family, who cares, right?) Perhaps I just had a form of "stockholm syndrome".
People estimate based on how much time they think it -should- take, but you almost never estimate:
1. External factors which grow time
2. Feature/function clarification takes time
3. Outside resource turnaround takes time
4. QA may never be satisfied
5. We're moral and WE make a lot of mistakes along the way
6. Most likely, you don't know all the caveats of developing the piece of work until AFTER the development is over
7. General personal time spent elsewhere (meetings, consulting with co-workers)
Sadly, the best estimate for completion ends up being 1.5-2x longer than my original gut check, so as long as you pad out your estimates, you should be fine.
Bye!
The so called 'experts' are just as much experts at estimating requirements and timing as they are 'expert architects'.
Here is a thread where I argue that J2EE is a crutch given to people labelled as 'architects', turning them into typists while removing any real architectural thought from their activities. If you read through the thread you'll see some AC objecting to that notion and he does not realise that he is arguing my points there when he talks about architects.
He is mistaking what 'enterprise' means, he believes it has to do with some technology, with some instrument, a tool or a set of tools. He does not realise that 'enterprise' really means an approach, a process, set of processes and standards that a company forces itself to adhere to, be it in implementation details or documentation process (all of which are important of-course), but enterprise does not mean just some solution provided by some vendor even if it has the word "enterprise" in its name!
So with that in mind, realise that what we actually have for architects are most of the time not architects at all, they are copy pastors, they are typists, they are managers probably, but they are not actually designers.
Those are the same people that would be considered 'experts', who managers turn to for time estimates. I don't remember myself underestimating projects at all or overestimating by more than a factor of 2, because I have the entire process of what it takes to build a project in mind and I break it down into all the little pieces, put a number that comes from past experience in front of that little piece, then the numbers are added up and there is some adjustment based on the team, the people that are going to be working on this.
AFAIC overestimating is not as a big problem as underestimating but if you are bidding on a job, then it does present a challenge. In case of bidding you are actually not truly estimating a project, you are just trying to get it before the other guys get it, and I think that's where the real problem comes in. Managing client expectations is a serious matter, you better be able to do that and I think the more you way overestimate or way underestimate the less likely the clients are to trust you in the future, so be true to yourself.
But again, how can somebody be true to themselves, when they don't even understand themselves what it is they are doing in the first place?
You can't handle the truth.
Back when Joel spent time on writing, Joel Spolsky of Joel on software had an interesting method for doing time estimates. His point was to go into a deep level of detail. Instead of handwavy "code the GUI" the only way to really get anything remotely close to a real time is to estimate everything down to at least half day, if not lower granularity. It's not the "oh you feel the time better" as much as to think of EVERYthing you need. If you go to a lower level, you may remember that dialog box that you didn't think of at the 25,000 foot level.
It would be interesting to see if anyone ever used it to improve their estimates. Even he "disavows" it now, preferring the method in his software tool. But I like the "the world is a big place, are you sure you're thinking of everything" that the older method pushed you to.
APK was arrested last night for disturbing the public and public indecency. Basically, his meds weren't adjusted (yeah, you probably noticed) and police officers don't like it when you masturbate in public, run around naked, and hurl your shit at them.
Something my boss has us do when we estimating projects. She has a certainty factor that we set for each task, simple terms, which equate to a percentage in her calculations. The higher our certainty, the less risk that the task is underestimated. The lower the certainty, the larger the margin that the estimate needs to be factored.
Makes a huge difference in ballparking our estimates.
As per my blog post a couple of years ago at http://use-cases.org/2011/06/04/getting-good-estimates/ [use-cases.org] and http://use-cases.org/2011/06/22/updates-on-getting-good-estimates/ [use-cases.org]
Most good estimates have a range - and not a number, or a number with a confidence (both are interchangeable).
If an engineer says it will take two weeks - I push for a range or a confidence. If the range is weird (2-8 weeks), I push for the engineer to tighten their estimate through discussing or raising and discovering the unknowns or the risks that they are aware off. That sort of estimate would usually end up around 3-5 weeks which is a reasonable margin - and a lot better than than underestimating by 50%.
Same with estimates that are too narrow. "2 weeks +/- day". That implies a full level of understanding, no risk and no dependencies. Almost never happens. Work through the same risks/unknowns and the estimates usually become really bad - typically at least double of the "high confidence" estimate - similar to TFA.
There is a lot of reasonably applicable theory behind this (confidence intervals, cone of uncertainty, etc). But we don't necessary focus on mastery of our art...
3 days for bitching, pissing and moaning.
3 days for dicking around on the interwebz
1 day lunch overages.
2 days for "zoning out"
3 days for witty banter.
This sig is not paradoxical or ironic.
This is why in scientific disciplines we look at predictions from models (or theories or whatever), rather than predictions from people.
So I guess if you want to make predictions about how long it takes to write a piece of software, you use the prediction of a model that has proved to be pretty good at predicting how long it takes to write other software.
Suit: "How long do you estimate development will take on this project?"
You: "My best estimate is 2 years, 3 months, as long as specs don't change."
Suit: "But the customer would like the product in a year"
Bean counter: We'll need 6 months to determine the task flow".
You: Then you'll need to add six months to the scehdule."
Suit: Okay, it's settled. We'll start tommorrow, the accountants will take the first six months to determine the charge numbers, and the programmers will have the job finished six months later.
Two days later.....
Suit drops by....p> Suit: "Hey, I just got off the line with the customer, and they changed all the specs. Don't worry though, I told them there wouln'd be any impact on the schedule. Oh, by the way, the accountants say they need another month. But I every confidence in you.
a year and a day later.........
Annoyed suits and accountants sitting around the meeting table...
Suit: Okay, now what the hell is the problem here?
You: We only had five months to complete the task, and specs and accounting time were all changed..
Suit interrupts: You told us you could have it finished, you aren't going to make it very far here - we need better estimates on your part!"
You: Sigh... Well, I think if we work everyone double shifts, we can get it out the door in anotther two months"
Bean Counter: We'll need a month to redistrubute gharges and funds."
You: "Wait! umm.."
Suit interrupting: Okay, that settles it. A month and a half out the door, just like you promised. And don't let me down, again. Just what to you programmers do with all your time anyway?
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
During my last project, one component was estimated (by others) at 2 man months, and it ended up taking 6 full time developers a year to implement. The estimates were absolutely horrible. As much as it was the fault of the original estimate, management constantly rode the development team to get it done asap, which probably in the end did more harm than good.
Bye!
I give perfect estimates, every time. It's the honest truth.
Then the project manager(s) squeal like stuck pigs when they see them and force me to cut them down to what they think is reasonable.
That's why your software is late and buggy.
If you've ever had to deal with ExpressionEngine and it's complete ass-backward "parsing order" crap, you know that giving good estimates is impossibru!
When my customer comes to me and asks me to provide an estimate for a job, if I give them a conservative estimate, some of them may think that I am milking them with the extra hours. Specially if they get a competing estimate from an overly aggressive Indian company who is eager to sign the contract but has no clue on how to deliver.
I usually do not fret too much about customer feelings in a case like this. But during slow times I have little choice. Bottom line is, most of us would love to provide conservative estimates, but often times it is not as simple as that.
There is another reason time estimates are bad -- they are often required to be bad to satisfy management. In my 25 years of experience I've often come up with reasonably accurate time estimates. These are invariably too long for management to accept. Therefore, management often picks someone else (with a lower estimate) to lead the project, and then the project comes in late, usually around my original estimate. I've also found that explaining why my estimates are so high does not help. If I set aside project time for investigation, research, and other non-specific tasks that my experience tells me is necessary, it doesn't make a very good story. Most management will go for the happy story, and then deal with the repercussions.
At my giant corporate place of employment, developers are pressured into giving optimistically conservative estimates. They are called estimates and everyone plainly knows that they are estimates of unknown quantities. These estimates are entered into Microsoft Project and the dates are manipulated to fit whatever deadline has been set. That Project file is then sent upwards into the management cloud from which threats and curses come back down when the dates aren't met. The reality that no one talks about is that there is no such thing as an estimate here - only commitments and deadlines. But they pay me, so I will be back tomorrow.
... to be developed for them in 3 months. I estimated 10 months. So they decided to look around for another developer. A couple years later they came back and asked if I could do it in 6 months. I told them it would take 12 months, now.
now we need to go OSS in diesel cars
You can have confidence in your estimates and still be aware that that confidence is misplaced. One of the common things I keep saying to my manager is "Yes, I'm pretty sure we can finish this in 3 weeks. But I want to schedule it for 6 because always, always we spend half our time getting pulled off onto other things and I want to account for that now before we get in a bind.". I have confidence in my estimates, but I also have confidence in the statistical evidence of how reality varies from my estimates and I'm not prepared to ignore the latter.
As others have said, I also end up in arguments where people "up the chain" have already decided when they want something delivered and are pressuring me to make my estimates conform to the schedule they've already set. I don't consider this a problem with my estimates or my planning/scheduling, because I have no input into this or ability to control it. The problem lies with the people who're making promises without making sure those promises can be made good on, who then expect someone else to pull their chestnuts out of the fire. I can't do anything about that, because I can't order them to ask for estimates before setting delivery dates.
The agile software methodology was created in large part to address this problem (and the related problem of budgeting) and it works by saying, "we're only going to estimate what we can do in the next month."
You may have to evaluate a library or a technology to see if it's suitable, you might have to come up to speed on something, and you will often be waiting on another component to complete.
The biggest issue, though, is that clients don't know what they want until they see it. So if I take vague requirements X, Y and Z and generate X', Y' and Z', the client might decide he really wanted A, B and C. How can I possibly estimate that? And any client who promises he won't change his mind is lying.
The only reason people deliver even close to the estimated date is because they will throw in massive numbers of hours trying to meet these arbitrary deadlines, or cut corners or whatever.
My estimates suck because:
Project leader: Ok, so we need to know how long it will take for you to do X
Me: I'm not sure, that's an entirely new API, proprietary to the vendor, there's almost no documentation and their website has a support forum filled with questions and basically no replys to any of them.
Project leader: Well, we need a number.
Me: Why?
Project leader: I have to fill in this box here... see?
Me: Ok fine, 800 hrs
Project leader: Now hold on a minute, this wont take 800hrs
Me: It could, I have no idea. It's already taken the majority of at least one hour and I don't even know what language it's in.
Project leader: Fine, I'll put down 800hrs, but you're the one that's going to look silly.
POST PROJECT REVIEW ....
Project leader: I can see here your original estimate was 800hrs, and your actual billed time was 1265hrs. What causes led to you missing your estimate, and how can we avoid those in the future.
Me: Don't make estimates.
Project leader: Come on now, I need a real answer.
Me: Why?
Project leader: I have to fill in this box here... see?
Me:
Anyone who calls themselves an expert isn't qualified to call themselves an expert.
And that's double the time you THINK it will take to complete.
It almost NEVER manages to get within time, but it never seems to take more than double (unless it turns up as a doomed project very early on and you can SEE it won't finish anywhere near the time.
I.e. you forget about commenting the code, or the tests take longer to collect all together, or some bit of new language feature *reads* like it'll do X, but it really does Y instead, or the X isn't really what it was meant to do, so is harder to implement than you thought.
This works up to one-man-month (or so) work.
Ice melting in the Arctic? Going FASTER than predicted.
Drought counts and length? Getting worse FASTER than predicted.
CO2 increases? Getting worse FASTER than thought.
The reason why #3 is true is because the moderated and generally-agreed results (which are necessarily going to be conservative) have been over-conservative when measured up to reality.
Hansen's 1988 paper so often touted by deniers as "heinously wrong, tenfold error!" was actually pretty damn close in its 30 year prediction. A sensitivity of 3.2C per doubling would have been spot on, but Hansen's model predicted a 3.4C per doubling figure.
Been doing it for many years, too
Estimates seem to be driven mostly by the following forces:
Non-Tech Problem Space
In the worst case, this is the equivalent of walking up to a student and asking how long it will take them to solve a problem in both a subject he/she hasn't studied yet, and in a problem with no similarity to those at hand. Any notion of accuracy gets thrown out the window under these conditions.
Tech Problem Space
What tech is needed? And how long will it take to acquire proficiency in this tech? Since tech is a road well traveled by others, this makes the estimation of the learning curve and the tech application easier.
I think the answer lies in patience, instead of demanding estimates that can be produced in the next hour. In many cases, the problem needs to be inspected and possibly specified further to come up with anything approaching accuracy. I have to wonder if this is something that is understood and being communicated effectively to non-engineers and those on the client side. Nevertheless, if businesses chooses to subjugate informed, honest estimates to salesmanship, then none of this matters anyway.
We did that in the college research game. A prototype was already done before we applied for a grant. We used the money to perfect the old project and start a new secret project. Nothing succeeds like existing success.
Think about it.
Time is, for all practical purposes, linear. Your task will take a specific quantity of time to complete. You don't know that quantity of time in advance, because you don't control all factors, so you're guessing.
Now, what is the environment of your guess? You are trying to pick out a specific point in the future at which your task will be done.
Balance that against the infinite number of points of time in the unbounded future in which your task could actually be completed in.
1 estimated point against an infinite number of possible points. That's your odds of picking the CORRECT point in the future. 1 divided by infinity. Although it's not necessarily mathematically correct, it's a useful convention to reduce that expression to "0". And that is your precise odds of estimating the completion time correctly. Zero.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Here's how you do it: You split your development task up into small parts that should take 1 to 5 days. For each task, you write down your best estimate. Now of course you know you are bad at making good estimates, but that doesn't matter: You do the first part, then write down what you estimated, and when you actually finished. From that you extrapolate when you will finish - if you estimated two days and it took three, you estimate that the whole task will take 50% longer than estimated. After the second part is finished, you get an improved estimate, and so on.
I know, insert prelim apology for sounding "arrogant" etc. Then let's thrash out a theory.
"I've been trying to fix this for 12 years." When something takes 12 years to get better at, there's hidden factors at play.
Suppose you try a thought experiment. Imagine one of your recent projects. So you get to the stage of the "estimate" (really some kind of pre-pre-pre estimate!) and imagine what you were thinking when you worked it out.
Then try to pin down at least a couple of the "oh my gawd" moments when the whole thing exploded. Clarify a little why that particular moment didn't work.
So as part of the thought experiment, the next time you get a project, make THREE estimates. (Feel free to add a couple of bonus ones). The first is private and not told to anyone. *Because you just throw an "insane" chunk of time on top of it*. Go wild! Three month project? Whee! Let's pretend it takes two years! And lo and behold, it came in at 10 months. Yay! You were "under your estimate!" That's your first private estimate - throwing so much time that it's designed to *not go over, with NO penalties*.
So then the second one should perhaps also be private - the one that made you *think* (wish?) it was three months. But that one will be too short, for all the reasons you said you've struggled in 12 years.
Then your third one is to build in contingencies for "nightmares" - "I don't know what it is yet but something awful will go wrong here."
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Break the problem down into parts. Carefully consider contingencies. Get creative - sleep on it. Think about it in the shower. What bullshit will crop up as I work on this project?
Using all your experience as to how long similar components took to implement in the past, plus how much longer it would have taken if worst case nuclear godzilla attack had occurred, compute time estimates for each component.
Add all the time estimates together.
Multiply by the Planck constant in Joule seconds / (pi^3 / e^2) * 10^34... approximately 1.58. It has something to do with brane theory and the double slit experiment. Trust me.
Hofstadter's law: It always takes longer than you expect, even when you take into account Hofstadter's Law. — Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid
Thankfully I'm a pessimist and a detailed oriented person. Most of my estimates are beyond the actual delivery date. This has two side effects: 1. It makes me look like an over achiever. 2. It means I'm not rushing to finish and cutting corners = quality output.
"The hardest part of solving a problem is understanding it" - ?
The reason its hard to estimate development time is because programming involves design, design is a creative task.
Nobody can predict how long it takes to be creative, its a universal unknown. Creative workers (such as graphic artists) often estimate the design phase by giving themselves a hard limit and then just choosing the best idea they could come up with.
Most programmers dont even acknowledge their work is a creative expression, so they are bad at estimating what a reasonable "hard limit" might be. But even so, im not sure the same method of 'choosing the best idea within a given time limit' is suitable to programming. Some things just have to meet certain objective benchmarks or there is no point continuing.
Best idea i can come up with is to allocate your self "design time" first, which wont be long enough. Then you should be able to get a reasonable estimate of implementation time.
For the first 40 years on the job my time estimates sucked. Now that I'm retired I'm accurate as hell.
Because by the time anyone who could come up with accurate estimate is asked for their opinion, the product has already been sold and the contracts signed.
Prioritise the order of development and get on with it. It'll be done when it's done, you'll get paid or you won't. Wasting time producing imaginary numbers has never fulfilled a contract, ever.
If you were blocking sigs, you wouldn't have to read this.
But it takes time.
Use historical data and use that to weight the estimate you came up with.
Keep doing it and eventually your estimates will start to approach reality - as others have said though - management is usually unhappy with accurate estimates.
I suspect that's the reason for the demise of formal project management tools in the industry, particularly the ones that allowed you to log the reason for plan changes and stored history.
Very embarrassing when the dev turns up at the witch hunt meeting at the end and shows that 90% of the delay is due to management failures. (Changing plans, delays purchasing essential resources etc).
While this is correct, I suspect the real problem is that most managers can't.
APK was arrested last night for disturbing the public and public indecency. Basically, his meds weren't adjusted (yeah, you probably noticed) and police officers don't like it when you masturbate in public, run around naked, and hurl your shit at them.
Well, there go about half the people on the Internet.
Start by prototyping before the project is funded. This helps the business parties see what is possible and also gives the developers a much better understanding of functional requirements than any document ever could. Do UX testing sessions (test using your best developers - they find cool hacks, and business people, and anyone). Evolve the prototype, if even over a couple of weeks (I'm pretty good at rapid prototyping, two weeks is usually enough for 2-3 revisions resulting in a reasonably functional prototype for 5-10 screens). Prototyping and UX testing take experience, try them on a pilot project. Note, estimating hasn't begun yet. But do these things first, it's very important.
Then, once funded, start estimating. If the project is large (>1 person year), break it into logical functional components with a goal of at most 1 person year of "high" level estimated time (better estimates come next). Treat each of the functional components as a separate project. Large projects fail a lot, small projects are surprisingly successful (I don't have the article links handy at the moment, my anecdotal experience supports this as well).
Then, for each logical component, estimate. Estimating sucks, but I have seen the value in it, as has management where I work. It means sitting in a meeting room for multiple days per component. You will need at least one business representative, the development team, and a DBA, at minimum. Use the prototype to explore the functionality and system requirements. Start namespace/class definitions (helps a lot to categorize/define functionality boundaries). For each namespace/class, estimate the number and complexity of methods. Same for database stuff. Again, the prototype is a useful tool (never DB connected, generate data manually, Excel is a great code generator for such purposes).
Then put some time estimates on all of the tasks (think of it is as backlog, but for the project, not a sprint).
Continue estimating for each functional component (don't forget integration time between components, I pad these, it's always harder than you expect).
If you can't do this level of estimating then you do not understand software at a level required to make the project a success.
Then decide if the project should move forward. I've been involved in two hard estimating efforts (2-3 weeks each, huge projects, one that wasn't considered that big until we did detailed estimation) that resulted in management deciding against moving forward, it was obvious to us that this would be the result given the results of the estimation. Millions of dollars probably saved, large projects fail a lot.
As for daily work, we do two-week sprints, spending the first Monday doing nothing but backlog grooming (the crappiest day, but again, valuable). We strive to breakdown tasks to less than 8 hours, with 2-4 hours being the target (.5 hour tasks as very common, such as create Widget.Cache and Widget.Cache.Test projects). The sprint tasks are sacrosanct, they are the focus. If production support rears it head remove sprint tasks. We only schedule 50 hours of work time per 2 week sprint.
We do UX testing at the end of each sprint, enables us to be reactive to the results during the next sprint.
Yes, we are targeting agile methods and I'm not sure if they would scale too far. But, if a project is broken into functional components I don't see why it wouldn't scale, a large team would simply be composed of several smaller teams. Remember integration! It's usually a big part of the 20% of my 80/20 rule (where 80% of development takes 20% of the time, and the remaining 20% takes 80% of the time). Enhancement/support situations are something we haven't worked with much yet.
When starting a project, focus on "project killers" first. This includes things that are unknown, known to be hard or particularly complicated, or external integrations. Project killers are the things most likely to kill a project or directly impact the delivery date/budget.
BlameBillCosby.com
I too partially suck at estimates. Aside from the "unknown unknowns" which you can budget for but never predict I have found several rules of thumb have got my estimates from "fairyland guesses" to "accurate with withing a factor of 2". These are:
Thanks to all the other posters for their lists and suggestions. Time estimates are much much harder than development.
I'm never actually confident of my schedule or anything else I've given to my boss. But my boss requires me to pretend that I'm confident.
Sure! India CAN get it done...but do you actually want it to be done right?
You don't estimate completion dates. The biggest single failure in Project Management is the concept of estimation of completion dates, the work will be finished when it's finished and that is all there is to it. Personally I'm not handing over software that I don't think it 100% ready to go and tested, if that takes me 2 weeks long then the "work estimate" then it does and I don't care. Completion Estimates lead to shitty software, missing features and bug lists. You need to take the time you need to make sure the software is polished and ready to go in a professional setting, if your project manager bitches and complains then go above them. If marketing wants to be keen and set a date with you not being ready then tell them to write the software. The point is take control and take the time to do the job right, The first time you'll hear lip, the second time you'll hear lip but by the third and x time people will let you be and let you produce excellent work. Nothing will kill a company or a product faster then crappy, bad feature and bug filled software or in other terms Project Manager and Marketing managed software releases.
If your a good programmer your a good programmer and it doesn't mean that you can do the impossible.
Our team follows Joel Spolski's approach. We scope tightly, we do enough design that we can list all the tasks we need to accomplish. We estimate tasks to a 2-day limit; if the estimate for a task is more than that we do a little more design and re-estimate.
We end up with a list of tasks for a project as long as your arm. We start working on them and tick them off as we go. The designer keeps an eye on things and she is ready to change or enhance the design as things come up.
Overall our actuals are within 20% of our estimates, which is fine for us. Sometimes we go over, and sometimes we come in under. When we get a new project manager they can't believe how tight we come in overall.
If there is a scope change, we re-estimate it. We can't control scope changes, but we don't count them under our initial project estimate, that wouldn't be fair or reasonable. We've trained our management to accept that.
Freshly graduated programmers seem to have a problem with this, I think mostly because they've never worked on a really large project before. I think a lot of them procrastinate on assignments, too. At least if what I saw in college was any indication. If a programmer hasn't worked with a single project for more than six months, they may not have noticed this effect either. If you've been playing contractor musical-chairs, it's easy enough to be in a situation where you haven't.
Employers really should set out to retain engineers for at least several years. You see huge productivity gains as you become familiar with the business and the code base. Burning through people seems to be a good way to stay in a perpetual no-release cycle. Which I suppose some managers might view as beneficial...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
They just take as much time as the work itself.
People don't realize that engineering and software development always involves doing something new and dealing with unpredictable problems. The things that can be estimated are the trivial part of the project, and they do not actually take any significant time, we just fudge that time to stuff the "creative" and "unpredictable" things in there. In reality it's all bullshit, and any relationship between estimated and actual development time is a coincidence.
Contrary to the popular belief, there indeed is no God.
are the ones most likely to experience it.
It's really a lot easier to deal with this stuff if you know rigorous ways of thinking and the very basis of this is knowing the difference between knowledge and belief AKA the Socratic method. Certitude is not knowledge and shouldn't be treated so.
brandelf -t FreeBSD
I agree. Fortunately for me at least, I happen to be in the happy world where management supports us in realistic timelines and realistic scoping.
Spanning almost seven years now and well over a hundred assorted projects we have been overdue on projects two times total. One of those was during the exceptional case of a co-worker getting in a car accident and breaking 13 ribs, the other was an exceptional case where very serious external forces caused the design to shift mid-development. In no case has it been due to poor estimation.
We have come to learn the development cycle for our small teams:
When I hear about other groups hitting 60% or later in their development cycles and still not getting feature complete, I pity them. They have made the mistakes the original article warned about, and were probably driven to that madness by the poor management you mention.
//TODO: Think of witty sig statement
Seriously, I told my manager not that long ago that I had no idea how long something would take me.(The real answer) He started trying to get me to "confess" to a estimate and when that didn't work he had 2 other SE's play estimation poker to get an estimate that he wanted. Actually when I do give an estimate I give myself a large amount of padding for all the interruptions I'm going to have.(They're going to happen.) Lets just say my manager would prefer me to lie and give the estimate if I had no interruptions.(Which let's be honest, never happens.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
I've seen many good explanations for why estimating software is so difficult. But my favorite explanation points out the fact that when we write software, most of what we write is not like anything we've written before.
Engineers in other fields don't run into this as much. Building a new house is very much like building any other house, so they've got a pretty good idea of how long it takes to build a house like that. And even then, building houses typically takes longer and costs more than the estimates.
Software sucks. Open Source sucks less.
I would love to see an experiment. Take two groups and give them the same job. Group one would be based on a typical American corporate structure with a Boss, Scheduler, budget person, middle management, supervisor, and finally people doing the work.
The other group would have the same number of people but only those that work. No schedule or budget just work until it's done. I wonder what the results would be?
I love Jesus, except for his foreign policy.
The post stated:
3- And, best of all: absolutely nothing seems to be able to diminish the confidence that experts feel. The last one is truly remarkable: even if experts try to honestly face evidence of their own past failures, even if they deeply understand this flaw in human cognition they will still feel a deep sense of confidence in the accuracy of their predictions.
A better way to put this is people who do not feel such overconfidence will not be recognized as "experts" by anyone. This is a social problem, not a personal one. Human beings more readily believe confidence than veracity. This why there are so many confident idiots around.
This should be obvious to anyone who has dealt substantially with other people at any time in his or her life. Confidence makes one an expert -- more than documents or proof or the ability to obtain, compile, and present convincing evidence.
All data is speech. All speech is Free.
Predicting a civil engineering project, like a bridge, is easy.....
I'm going to stop you there, because civil engineering projects are NOTORIOUS for going over budget. You might have heard of projects like the big dig. Less well know, is that going over budget in less spectacular ways is apparently a fairly common occurrence. I was looking around for a report to link for you that I read awhile back talking about why civil construction projects so frequently go over budget, but alas, I cannot locate it.
Alas!
HA! I just wasted some of your bandwidth with a frivolous sig!
One huge contributor, in my experience, is the following.
A manager (could be a project manager, same difference) asks for a time estimate. With no preparation by the programmer. And they want that estimate immediately!
Now the only reasonable way to interpret this situation is that they want a ballpark estimate. One that has very large uncertainties, on the order of +/- 100-300%. There's no functional decomposition going on here, not really. Usually the technical guy doesn't add an automatic fudge factor to account for contingencies. Rarely is a realistic % availability calculation done either; the tech resource is assuming that Days = Standard 8 hours Days Working the Project.
Such a preliminary estimate should be used as a first draft to evaluate whether the organization even wants to go ahead with the project. If the Go/No Go decision is made, then a proper project estimation (with all the overhead that implies) can be done.
However how often is this sequence actually followed? Many times the manager shortcuts directly to the end. Project is assumed to start immediately, that SWAG estimate is codified as the actual deliverable timeline, promises are made to customers (geez, often the promises were made BEFORE the conversation with the tech even started), and the confidence intervals are never established.
You want to know how come the estimates are so bad? Start here.
Exactly. If someone asks me for an impossible prediction, I will give them what they asked for with unyielding confidence. When faced with the inaccuracy of my prediction, I will continue, with confidence, in giving equally inaccurate predictions in the future.
My real algorithm is as follows:
Is it fun/interesting to do? If yes, feel the room and give an estimate that will keep the project from being killed. Else, give a long enough estimate that can withstand cross examination that hopefully will kill the project. Regardless of what I answer, management will cross examine my estimate using their own equally inaccurate measurements and assessments, if I deliver with anything less than absolute confidence I will be smashed. You see, the bullshit is layered upon the bullshit, then convoluted by management bullshit, into spectral bullshit that makes for a great power-point.
If you want an accurate assessment of how long something that has never been done will take, you're asking for the impossible. If you want an accurate assessment of how long something that has been done before many, many times will take, either a) you're not in technology in the US, we don't do "competition" here, or b) I'll tell you 75 years because I really don't want to do that anyway.
If you ask any experienced software developer about estimating when the project will be finally completed you will get a blank stare --- for the simple reason that there are always higher mountain to climb, more features to add, more bugs to be squashed, more optimizations to be made, and so on ...
I do not do time estimation --- I do the reverse
I set out a limit on time before I even begin a project
Within that time span I partitioned it into "exploration", "research", "coding", "debugging", "finishing touch" --- and I can terminate the entire project when any part of the partition takes too long, or produce too few result, or both
That's the way I've been using since the late 1970's --- it might not be the best way, but that's my way of accomplishing my projects --- or abandon it before it dragged out way too long
Muchas Gracias, Señor Edward Snowden !
Causes: lack of consideration for design by the client (resulting in heaps of "minor" changes - death by a thousand cuts), lack or thorough analysis of the problem (no one wants to pay for proper analysis before starting work or even doing the project budget), lack of allowance for scheduling problems, etc.
Solution? Take your initial time estimate and multiply by 2-3x, to allow for the unforeseen.
Is a rule of thumb I have used for years and has served me well. And when you do come in UNDER budget and ahead of time (i.e., only taking 1.5-2x your initial time estimate), you look a lot better than coming in at 2x the cost and taking 1.5-2x as long as promised.
In other words: under-promise and over-deliver. Too many development/IT/sales types over-promise and under-deliver (possibly to win a sale), but it just pisses people off when the project the business is depending/wait on is late, and possibly drives repeat business away.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
Today I told the project manager for my current contract that my code would be ready for testing on Thursday. I had a sinking feeling the instant the words left my mouth, and now I know why...
We don't have a state-run media we have a media-run state.
A.L.C.O.R.
After Last Change Of Requirements...
Manager: "We need an application that does X,Y, and Z. When can you have it done?"
Developer: "Well, can you tell me more?"
Manager: "No, time I have a manager's meeting in 5 minutes. Just give a pall park."
Developer:" Ok, umm 3 weeks."
Manager: "THAT LONG?"
Developer: "OK, 2 weeks? Maybe less?"
Manager: "OK"
Later, in the manager's meeting.
Manager:"My developer says he can get it done in less than 5 days."
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Aint that the truth.
I remember incidents where I have said "4 weeks if NOTHING goes wrong and I am not disturbed for any reason." Translated into "4 weeks and I'll put my developers left gonad on it"
Since then, all my quotes for time have been in writing. Nothing like Email for controlling the dialog.
A sig is placed here
To display how futile
English Haiku is
management/sales: how fast can we get this done?
dev: low 3 weeks, mid 5 weeks, high 9 weeks
management/sales:Great! I was hoping you would say around 2 weeks, because this product is being launched next week, so if we push it, we should be able to get it out the door by tomorrow approval!
5 days later: But you promised!!! Now I'm on the hook for a demo to the VP of International Sales and Marketing!!!
You clearly did not read the article. You are saying that it is possible to make good estimates by using the methods you spelled out. The article is saying that it is not possible to make estimates, and that the solution is to not make estimates at all, but to follow Agile software development.
http://coding.abel.nu/2012/06/programmer-time-translation-table/
4 hours is about the sweet spot.
In seriousness, there are many ways of improving estimates (reviewing past similar projects - you kept metrics right?), appropriate granularity of features and estimates of these features, confidence factors appropriate to the complexity/unknowns of the task (write a CRUD GUI screen? high confidence. Write a new algorithm to combine multiple videos into a 3-d pannable single video? Low confidence), etc. You need to be refining and grooming these estimates weekly as data changes, so at least you fail early.
"how long will it take to cure this patient? He has some pains in his torso so he could need angioplasty. Or it could be that he was stabbed by a knife. Maybe he was shot. We also will probably want to cure anything else that we find wrong with him. How long should all that take and I need a precise estimate?..."
[Ctrl + F] "Planning Fallacy" --> Phrase not found
Oh you.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.344
"Specifically, if it is accepted that algorithmic complexity is an appropriate definition of the complexity of a programming project, then claims of purely objective estimation of project complexity, development time, and programmer productivity are necessarily incorrect"
I am Jack's writable stack pointer.
Customer
1. We want this functionality.
After 1 month
2. We scare user type in wrong,please filter to sure user don't key in wrongly.
Tester
1. This is basic validation, why you don't put. There aren't basic validation. Business Rule can change everytime.
E.g
Country Currency Field
1. Country a don't want comma.
2. Country b have comma.
Customer..
We provide basic information.. You consultant should have imagine...
Imagine is abstract and cannot be calculate time.
Software development is special in that we never do the same thing twice.
An engineer estimating how long it takes to build a bridge will take a look at all the other bridges of about the same size, and add some time for differences. The differences might be 25% of the end estimate, but the rest is known to have taken a certain amount of time every time.
If a developer needs to do the same thing again, he will either copy the code (couple of minutes), or refactor the code to make it reusable (assuming that he hasn't already done so, in which case he wouldn't do it twice).
Now try asking an engineer for an estimate for something he hasn't done before. A fusion reactor, perhaps. Nope, sorry, we havn't built any working fusion reactors before, so you can't add 25% to how long it took the last time. No copying an existing function.
How far do you think he will be off? 25 years? 50 years?
5 days later: But you promised!!! Now I'm on the hook for a demo to the VP of International Sales and Marketing!!!
Powerpoint! Those bastards don't know the difference. Just show some slides...
Projects that are simple at a high level can consist of several parts and each of those parts might require many small tasks and each small task may require other tasks. Yak Shaving It's like playing a quest in World of Warcraft.
Feedback is the thing. I learned that my estimate and the real time I spent have a factor 1.4 between them. Knowing that, I estimate the work, multiply by 1.4 and report that to my manager.
I am never far of my estimate now.
In software development, if you want a second instance of some program or piece of software, you don't need to 'rewrite' it, you just copy it (or relink it, etc).
This means that every bit of code that you write, you are writing for the first time.
Clever developers will re-use code they have written in the past as much as possible, but all this does is reduce the overall time, which can actually cause estimates to go even further wrong because the "unknown code written from scratch" now constitutes a larger percentage of the overall development effort.
I don't suffer from overconfidence. My estimates are wrong because people never know what they want and keep moving the goal posts, and priorities change at a whim and I keep getting pulled off.
The difference between building software and a bridge: once you start on the bridge, you can't change everything.
After reading the comments, it appears that most dont know how to estimate.
If you are giving a time estimate in days/weeks/months/years Stop! That is wrong!
Always give the estimate in hours of work. The reason multiplying by pi works is that to management 1 day == 8 hours and 8*3 == 24 hours or 1 day.
I have found that when developers, Admins, and other technical people are asked to give the estimate in hours, you normally get a good estimate. Asking for the number of hours causes them to stop and think about the answer on a more granular level.
To top it off you can play with management when using hours. A work week is not 40 hours, it is 37.5 when you deduct federally mandated breaks and lunch. A year for one employee is 1,950 hours. If the employee has holidays and 2 weeks vacation it drops it down to 1837.5 hours. You can even go in and say things like the first hour of the day and the last hour of the day are non-productive hours due to time to spin up/read email/spin down/ etc and you can deduct another 10 hours a week for that making a work week 27.5 hours of working time or 1317.5 hours a year. Then start deducting weekly meetings, project meetings, etc. I bet when all is done you are looking at less than 10 hours a week of actual time coding. (Therefore your estimate of 3 days was right because that is 18 hours and it has taken 2 weeks to get the 18 hours in ;) )
When I am asked for a timescale to develop a solution, and get a snide or sarcastic comment about how poor my team's previous estimates have been, I first point out that our responses are estimates, then I ask for a feature list of the solution we are being asked to develop. The estimate is then broken down into phases for each section of the solution. The project manager gets stressed because he asked a "simple" question and is getting obstruction and complexity in return, but over the course of the project, that approach gives the PM better oversight of the schedule.
It also means that if I break it down, 120 hours for a, 240 hours for b, 180 hours for c, 60 hours for d, and 300 hours for e, so 900 hours for the project, +/-10%, with each section itself broken down with sub-milestones, and the client + PM agree to 600 hours, my first question afterward is to ask what elements we need to cut. As everything is verbal with email follow-up, we have instant communication and a paper trail so that if we are over my estimate for milestones early in the project I can adjust things and we can communicate more easily.
My estimation process does involve an element of "think of a number and double it", but I am usually pretty accurate with that process.
Even if we could predict development/release times with 100% accuracy, the damn customer always changes things up at least once. And it's usually when you're 80% of the way through the project....
"It's not the known things that get you, or the known unknowns, it's the unknown unknowns." -- heavily paraphrased from Donald Rumsfeld
Just a little wisdom from a related field...although many days it feels like they're the same thing...
To a certain extent, the problem is that I don't get asked to solve the same problems that I used to. When I'm asked to write something new...it's NEW. How long will it take? Well, it's hard to say. I haven't worked with this engine before and this gameplay mode is different from the last game I was on, etc.
I'm lucky that my job isn't really repetitive, but it also means that I lack a basis for making estimates. Over 12 years I've worked with the same engine for 2 games twice. My first game was a custom engine. The game I'm working on now is with a legacy engine that we've been patching up for years and years. The problems are never really the same, even when the specification is similar. The context changes the problem being solved.
I actually do make fairly wide estimates now, with an 'ideal' and 'worst case', but the shifting nature of the work means that sometimes even straight-forward things aren't.
When it gets down to bugfixing and refinement, I'm much better at estimates because I understand the context of the issue at hand.
I suppose that's the REAL issue in the end: it's very difficult to understand your context before you start trying to solve the problem. Until you've built the system and now have the time to iterate on it, it's all unexplored ground, and that's surprising and time consuming.
This is 100% accurate, Guaranteed.
1) Make best estimate.
2) Multiply by 10.
Done and done right.
When reporting (simple reporting) we estimated 1 hour per input file, one hour per output file, and one hour overhead. This was OLD big iron, but it worked.
Our DB scripting language was proprietary, but worked pretty well. And with very few exceptions, the formula for figuring out how long it would take to code a report was pretty good, too.
NOW, RUN TIMES---that's a different matter.
I had one canned report that we only ran annually because it took a MINIMUM of 40 hours of processing time. We didn't write the thing, the AP/AR software vendor did. Since we had a nightly downtime it actually had a break point so the system could cycle. Well, I had this manager who wanted me to run it NOW and give him the results in an HOUR! I told him that was impossible and tried to explain why.....he got ANGRY and said I had an hour to get it to him or he would have security escort me from the building. I went to my manager who tried to smooth it down, but he got threatened with HIS job. Good news is, EVERY canned report saved at least 20 run histories, not the data, but a file that showed how the run went with processing times, CPU utilization, etc. For the 40 hours the report ran, it took up 20% of our utilization. It's why we only ran it 1 weekend a year. We ran it. listened to him bitch about the time But, at least he knew we COULDN'T change it---actually my boss's boss talked to HIS boss after seeing the copies of the run logs and asking him not to threaten to fire the IT people. Then we printed it. It took 4 boxes of greenbar. NORMALLY, it would have been saved to something that could be viewed and searched--but when it's "mission critical" and they need it 40 hours faster than possible--it is SO nice to deliver 150lbs of paper to the guy using a moving dolley.
The shop where I worked had the same overconfidence problem. Project leaders would pull numbers out of a hat, or someplace else, and of course they would fall short. I was in QA. They would chop testing time to meet deadlines, and that's why sometimes we'd release an unusably buggy product to clients. IMHO, the only credible way to do it is for someone not personally involved in the development phase to rank it as "large," medium" or "small" and apply historical average times for that category to come up with an estimate.
From Taleb's "Black Swan" which I believe Kahneman was quoting in FT&S, the more information you have the more confident you will feel about your estimate, even though your estimate will not improve with additional information.
Taleb makes the distinction that some areas have no black swans (totally unforseen / unforseeable events). He calls this 'mediocristan'. There is much less of an expert problem in this area. Then there are areas where there's the possibility of a black swan. He dubs this 'extremistan'. Expert predictions are much more likely to go awry because, well, something unforseen has happened. In either case, the more information we have, the more confident we will be of our predictions but we are not sensitive to when things shade from mediocristan to extremistan.
... the pi factor.
Make estimate and Multiply by pi.
Privacy is terrorism.
Three words: The Mythical Man-Month. http://www.softpanorama.org/Bookshelf/Classic/tmmm.shtml
You cannot estimate the time you need to debug.
Casteism
Estimating method:
Take what you think you can do on your best day.
Then double that number.
Then move to the next larger time unit.
2 days becomes 4 weeks.
I'm actually very good at estimating how long a software project will take me. But if I told you the truth, you'd tell me not to do it because it's too expensive. That's not to say I'm a selfish liar. You also don't realize the benefit you'll get from this properly working software. Trust me, it truly will be well worth the cost (yes, even the real cost that I don't tell you about). And no, I'm not being sarcastic. I think most of us experienced software developers know this. Some of us don't admit it even to ourselves, but it's true. We know if the software will benefit you. We know if we can do it or not. And we know how long it will take. If it's not a net benefit, we know that and we'll talk you off that ledge. If it is, we'll say whatever it takes to help you take that leap.
Steve McConnell's Software Estimation: Demystifying the Black Art is the last, best word on this topic.
Basically, somewhere in the chain is usually an incompetent manager or product development person who will shut you down if you give honest development estimates for a good, bug free release, and encourage you to lie. This has the effect of training, the first couple of warnings you get over giving realistic estimates, which are overruled anyway, and you turn into Gale Boetticher on Breaking Bad giving his scary drug lord boss estimates on how long it will take him to exactly duplicate Walter White's Meth formula.
Gale Boetticher: l suppose if we had......at least a few more cooks together.
Gustavo Fring: You don't think you're ready now?
Gale Boetticher: Well, l mean......he is such a.... A master.
Gale Boetticher: There's always more for me to learn. But l'm thinking that if we had......say......one or two more cooks.
Gustavo Fring: [Icy Silence, the temperature in the room drops 10 degrees]
Gale Boetticher: One more......l guess would do it. l suppose.
Gustavo Fring: l believe in you, Gale.
On the other hand, at least things worked out really well for Gale, eh?
"MIT betrayed all of its basic principles."
I'm not sure if you are making a joke or saying how you work. But, as a developer if I, or any of my subordinates, did that we would be doing our business a great disservice.
One way of being a professional is telling people "no" and sticking to your estimates. There is a great book that I think everyone in a software company should read called: The Clean Coder: A Code of Conduct for Professional Programmers. This book has great examples of why you should agree to an estimate and NOT say "I'll try" when asked to do something unrealistic. When you say “you'll try,” that implies that you are going to work harder; something that you apparently weren't doing before.
A quote from the book:
When your manager tells you that the login page has to be ready by tomorrow,
he is pursuing and defending one of his objectives. He’s doing his job. If you
know full well that getting the login page done by tomorrow is impossible, then
you are not doing your job if you say “OK, I’ll try.” The only way to do your job,
at that point, is to say “No, that’s impossible.”
do it the microsoft way (as i've heard anyway) which is at the end of every day, there must be a compiled and running version available to be shipped if necessary, even if not every feature is implemented.
Star Trek transporters are just 3d printers.
My Chief Developer had a saying called the 4/2 Method. Whatever the projections it will take 4 times as long to get it done and will cost twice as much as one thought.
But be careful not to say, "No, that's impossible," unless it's impossible. More often it's, "Well we could do that, but it will mean sacrificing features X and Y and it will cost an extra $Z."
Manager: "So, Johnson, how's the flight control software for the SLS coming along?"
Johnson: "Well, sir, it was properly coded AND debugged, but the finishing touches were taking longer than the prediction I had in mind before I started any of this, so I scrubbed it from the repository."
Manager: "We need an application that does X,Y, and Z. When can you have it done?" Developer: "Well, can you tell me more?" Manager: "No, time I have a manager's meeting in 5 minutes. Just give a pall park." Developer:" Ok, umm 3 weeks." Manager: "THAT LONG?" Developer: "OK, 2 weeks? Maybe less?" Manager: "OK"
Later, in the manager's meeting.
Manager:"My developer says he can get it done in less than 5 days."
The fault lays squarely on the developer. You got to stick to your guns with your ballpark or negotiate with the caveat of greater risks of failure as the estimated time is decreased (w/o ever decreasing it substantially.)
me: Oh that's easy, I figure about two days of coding, plus a few days of testing. So a week if everything goes right, maybe two weeks if I run into a snag.
my manager: So, it'll really take four weeks, especially with meetings and interruptions. But since you also have X, Y, and Z to work on, let's call it 8 weeks. I'll add 3 weeks, that will give me negotiating room in the planning meeting. Tell you what, I'll call it 12 weeks, with a stretch goal of 10 weeks to hit the June release, otherwise it will go into the August release. If we go past June you'll be covering vacations for others anyway. But we better not miss the August release, that's a hard commit!
me: Sure I can commit to that.
- Trying to remember what method is best to use in some newfangled language I’m using. - Thinking I’m programming back in high school where programs were faster, more efficient, and not 10 clicks and menus to do everything. Now everything is just slow and clunky it seems.