Evaluating ones abilities.
-
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". :laugh:
Telegraph marker posts ... nothing to do with IT Phasmid email discussion group ... also nothing to do with IT Beekeeping and honey site ... still nothing to do with IT
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.
-
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](https://wiki.lspace.org/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 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.
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"
-
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.
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. :sigh: 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: 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=OnThe 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... :sigh: 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. -
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.
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
-
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.
-
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. :sigh: 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: 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=OnThe 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... :sigh: 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
Must be nice. :sigh:
-
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:
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.
-
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.
-
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.
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; -
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; -
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.
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
-
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 :laugh:
-
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.
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
-
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.
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)
-
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.
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
-
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.
-
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
-
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.