|
I don't buy it. Franklin, you're just advenTuring...
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
You are a Feynman. Were you Born this way?
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
I tend to underestimate myself. Barring the occasional snafu, my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that.
People consistently tell me I'm fast, maybe in part because of the above, but I even get it here at codeproject sometimes, and other programming venues I haunt. I'd be foolish not to acknowledge it, even if it feels awkward doing so.
Realistically, even if I don't change how I estimate to my clients, I'd like to be able to more accurately assess myself. Confidence plays a part, and I get imposter syndrome a lot. Sometimes I'm confident, because intellectually I know I'm in my element, but over all I tend to magnify my own shortcomings and short sell myself in terms of what I can deliver.
How the heck do you do it? It's far from the worst thing in the world, being underestimated, even by myself. It has advantages, like me not going over my estimates. Still at the same time it would be nice if I knew what a project was actually going to cost me to deliver.
To err is human. Fortune favors the monsters.
|
|
|
|
|
honey the codewitch wrote: How the heck do you do it?
It is all about risk estimation and failure acceptation.
In my experience, things tend to turn better out than planned or expected in most of the cases, whatever you do, so I think your underestimation is not that uncommon. Even if from times to times, it need that extra strength (read a couple of sleepless nights) to bring it on the right track again, it works. And in very rare occasion, it fails - and coping with failure is something one needs to learn.
So simply shift the cursor slowly to the risky side until you feel you touched the red lines a couple of time, and then shift it in the other direction again to enable you a buffer.
Maybe a hint : As someone having to rely a lot on estimates of other people to plan my own work, here's how I like it:
1. Very Late is a no go, so do not overestimate your speed. I do not work with people who blow my schedule more than once - unless they have a very good justification, I mean, sh*t happens.
2. Slightly late is my level of expectation -> My assumption is that people need about 20% more time than they announce, and this proved quite solid in my experience, even if that seems a lot.
3. Slightly early is good.
4. Very early gives an ambivalent feeling : I of course enjoy having my requested stuff done on time, but it looks like you are not mastering your businnes and do estimatiton based on wind direction, or that it was a mistake to give it out if it was so easy to do. Plus I could have planned more for that sprint/order, so overall, it does not give a good confidence about scheduling, even if quality is good.
So until you have found your cursor position, do not deliver too early even if your work is done - it does not give as good an image as you may think.
|
|
|
|
|
|
I try not to deliver really early. If it turns out a task I thought was complex is relatively easy, sit on the deliverables and deliver just slightly early. Your client will still be happy, but won't have expectations set for the future. They'll think you're really good at estimating, which will reinforce their opinions of you. In part it comes down to how you charge, too. If you're calculating charge by the (estimated) hour and you deliver in half the time, the client will feel they've been fleeced. Of course you can reduce the fee and, since they were prepared to pay the original, again they'll be really happy that it's worked out cheaper.
If you've completed something in a fraction of the time you thought, use that time for (a) another client or (b) some time off. If you're feeling uncomfortable about doing that, use the time to do additional testing, or improve the code, or make it more generic / configurable, or faster. i.e. give an (even) better quality deliverable. Or, if it's giving you angst, spend the time reviewing the original estimate and figure out where you went wrong. Document why and how the estimate drifted (in the good direction) and after a while review all that evidence to find out what the trends and common features are, and use that to revise your estimating.
FWIW, I read some of your coding adventures here and am astonished at the rapidity and volume of your output. That's maybe partly because your field is very different to mine and I wouldn't have a clue where to start, but it's clear you're in the premier league technically and an exceptional developer. I think you'd be shocked at the capabilities (or lack of) in the average bum-on-seat coder. As in, "send teh codez plz". 
|
|
|
|
|
DerekT-P wrote: you're in the premier league technically and an exceptional developer
Well, do not forget about the witchcraft - it helps to be able to incant bugfree code or summon a debugger daemon.
|
|
|
|
|
Rage wrote: incant bugfree code or summon a debugger daemon.
The Rite of AshkEnte is very useful for post-mortem analysis. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I always overestimate and my team has adjusted. For example, last Monday afternoon I was asked when I could have some changes done. I said, 'by the end of the week'. The followup meeting was promptly scheduled for Thursday morning. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
So you work 4 days a week
|
|
|
|
|
I'm really no good at estimating. I have told people to add six months to any estimate I give. This is based on the two times I needed six months more than I had estimated. 
When I was hired at my current job, I had a manager with the motto, "under promise and over deliver", and I try to go with that.
But now I have a boss who always insists on giving the rosiest of rosy ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif) estimates to others. He never wants to be the bearer of bad news. Which continually leads to upset clients when we repeatedly need more time due to circumstances.
RantMode=On
The most recent case was just concluded. At the beginning of November, one of our upstream sources deployed a breaking change without telling anyone. Ideally, they would have told us they had a breaking change in UAT and we should have been able to update our ETL accordingly and been ready to deploy at the same time. But that didn't happen. Can we push back and tell them to revert the change? No. We have to fix our ETL (of course, we'd have to anyway).
So my boss asked how long the fix would take -- I estimated a day, it's not a big change. Baaahhht, nooooo... our DEV account didn't have access to their UAT system, so there was no way I could make the changes and test them (this is SSIS). How long did getting access to their UAT Take? Three weeks of course. So then I made and tested the changes in DEV (in a day) and checked it in. And the change got deployed to our UAT system... Now I had told them to check the access of our UAT account when we had found out that DEV didn't have access... But, no, they didn't bother to check and of course our UAT account didn't have access to their UAT system either. So we were looking at another three weeks before we got access and could test, but that would put us in the year-end freeze and we couldn't deploy then -- which would mean mid-January at the earliest; two-and-a-half months after the outage had begun. It was decided to skip UAT, so the fix was deployed to PROD last week. And all's well.
|
|
|
|
|
Quote: (this is SSIS)
Ouch!
There is only one Vera Farmiga and Salma Hayek is her prophet!
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
I just say what I going to deliver by the end of the week, and I do. Each and every week. No "in 2 weeks", etc.
And if one can't deliver a tangible every week (be it a spec, form, report, whatever), you're probably heading for trouble.
An "emergency fix" is another matter; they get done right then and there; usually in a few minutes.
Keep them interested by delivering often ... that's all there is to it.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Gerry Schmitz wrote: Keep them interested by delivering often ...
I never thought of it that way, but you're right.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Must be nice.
|
|
|
|
|
honey the codewitch wrote: my estimates run conservative - very, to the point where clients expect if I say a day, I'll have it in an hour. If I need a week, it means a day or maybe a day and a half. It's like that.
Are they taking your estimates to be that or do they take it to be a commitment of a delivery date?
Not sure I have seen non-developers ever understand estimates. And even some developers don't get it. So I just always over estimate now.
|
|
|
|
|
Typically I have a lot of control over delivery milestones since I am the primary developer on any project I've worked on over the past few years. Those are affected by my estimates, but they are not my estimates themselves. My estimates are usually on a task by task basis.
I work with some engineers who liaison between the end clients and me in my current setup.
If I was dealing with the clients directly they wouldn't be getting such granular information from me.
To err is human. Fortune favors the monsters.
|
|
|
|
|
My experience has been that over-estimation beats under-estimation every time (duh). I'm pretty good at estimating work on my own code. Unfortunately more than half of my job is supporting products written by others, and estimating work there is difficult.
The most practical skill I've developed over my career is managing disparate tasks efficiently. Some short tasks I do immediately so that they're not taking any of my attention. If part of a long task is difficult or requires concentration, I'll ignore everything else until I get to a good stopping point. If a lot of items have accumulated in the meantime, I'll knock all of them out just to rid myself of the distraction.
While this approach works for me, obviously YMMV.
Software Zen: delete this;
|
|
|
|
|
Ditto
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Delivering early to a client/employer will eventually come back and bite you, as you have found. They then set timeframes that you cannot possibly meet, they get shorter and shorter because every time you meet a short deadline they will continue to shrink them.
I would hold back on delivery to a time closer to the deadline. What I never did was shorten my estimation of the time it would take to deliver.
Estimation:
Break down to the smallest buildable blocks
Estimate the hours for each block
Add the hours - double it and double it again.
If billing then add the time for the estimation.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
The way Scotty puts it, always give yourself a wide berth. If you deliver before, okie dokie, but if you need more time...well that's why we give ourselves 4 times as much time.
And it's ok to request even more time (if you have several projects, nobody can expect miracles)
|
|
|
|
|
You obviously are not subject to the Dunning Kruger Effect. Those people overestimate their capabilities because they don't have the ability to accurately estimate what they don't know. Competent people know what they don't know, so underestimate accordingly.
Bond
Keep all things as simple as possible, but no simpler. -said someone, somewhere
|
|
|
|
|
The only way you can accurately provide software estimates is by using standard Software Engineering practices such as Function Point Analysis.
Function Point Analysis relies on the use of a metric system in which every project you complete, you then record the metrics that were apparent in the endeavor.
Over time you will generate metrics for small, medium, large, and huge projects that can then be used as comparative standards to measure anew project accurately.
Function Point Analysis is well described in the Bible of Software Development, Stephen McConnell's, "Rapid Application Development (1996). However, there are more modern ways to perform this task, which have been developed in The Royal Netherlands.
I have used the original techniques myself with great accuracy.
Unfortunately, most technical managers and clients aren't very understanding about Software Engineering as most of these people are just idiots.
But you will get those people who will be very appreciative of your increasing accuracy...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I'm fairly good at estimating whole projects for some reason. It's the individual tasks where I overestimate how long they will take.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Function Point Analysis is based on the individual tasks, so it will be able to help you...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
