|
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
|
|
|
|
|
Cool thanks! I'll look into it.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Wordle 534 6/6
⬛⬛⬛🟨🟨
🟨🟨⬛⬛⬛
⬛🟩⬛🟩🟩
🟩🟩⬛🟩🟩
🟩🟩⬛🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 534 5/6
⬜⬜⬜🟩⬜
⬜🟩⬜🟩⬜
⬜🟩⬜🟩⬜
🟩🟩⬜🟩🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 534 5/6
⬜⬜⬜⬜🟨
⬜⬜🟨⬜🟨
⬜🟨⬜⬜🟨
⬜🟩🟨🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 534 6/6
⬜⬜🟨⬜🟨
🟨🟩⬜🟩⬜
⬜🟩🟨🟩⬜
🟩🟩⬜🟩🟩
🟩🟩⬜🟩🟩
🟩🟩🟩🟩🟩
Yeah ... indeed ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Wordle 534 4/6
⬜⬜⬜⬜🟨
🟨🟩⬜⬜⬜
⬜⬜⬜🟨⬜
🟩🟩🟩🟩🟩
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
⬜⬜⬜🟨🟨
🟨🟨⬜🟨🟨
🟩🟩⬜🟩🟩
🟩🟩⬜🟩🟩
🟩🟩🟩🟩🟩
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 534 5/6
🟨⬛⬛⬛⬛
⬛🟩⬛🟨⬛
⬛🟩🟨🟩⬛
🟩🟩⬛🟩🟩
🟩🟩🟩🟩🟩
Close to 4
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Wordle 534 6/6
⬜⬜⬜🟨⬜
⬜⬜⬜⬜🟨
⬜⬜🟨⬜⬜
⬜🟨⬜🟨⬜
⬜🟩🟨🟩⬜
🟩🟩🟩🟩🟩
Hard one
|
|
|
|
|
Wordle 534 4/6*
⬜⬜🟨⬜⬜
⬜🟨⬜⬜⬜
⬜⬜🟨🟩⬜
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
