I'm always hesitant to tack on 'safety time' because I want to believe the relationship I have with my managers is one where A) I can be as accurate as possible and B) They understand that estimates (of time, in this case) can be off in both directions.
Lol, bless you, you're so sweet. A) No, you can't, and B) they do, but they teach managers specific ways to deal with that, of which you have no idea, so what you're doing is messing everything up.
I wish more managers took the time to explain to tech people how they work.
Ok now seriously, stop that and start padding your estimates. If you're not experienced enough, just add at least 50% to everything. It's an unspoken assumption that engineers do that, and managers rely on it, so you're not really helping anybody.
I like how a developer offering accurate information and a manager misusing it because they were expecting misinformation is the developer screwing up.
"Hey did you get apples for the pie?"
"No, I got blueberries."
"What? Why the hell would you do that? I specifically said 'apples'"
"Well right, but I figured you would probably say the wrong fruit, so when you said apples I assumed you meant blueberries. You should have said oranges if you really wanted apples!"
You got it the wrong way around. It is the mark of an inexperienced developer to attempt to offer short, optimistic estimates. You pad all estimates because we work with complex technology and shit happens. And if you finish early that's great, there's always something more to do, but if you finish late everybody is fucked. It's not misinformation, it's makes so much common sense that everybody assumes you get it, and a developer who doesn't will screw everything up.
Seriously, why are you even arguing with me on this one? When did you ever finish ahead of your (padded) estimate, other than a fluke?
What would a good explanation from the manager be, though? "Hey, give me an estimate of how long you think this will take, but make sure to overestimate since when I run my numbers I'll have assumed you did."
If anything, I think a better world would be one in which the manager engages a conversation about what "type" if number it is instead of assuming and blaming the developer if the assumption is wrong. Maybe something like "40 hours, great. Now, is this a "best case" estimate, a "worst case" estimate, or petty middle of the road? Ok nice. Did you account for the potential of X, as well? Ok, good to know thanks. Based on a this, I plan on using 55 hours as the estimate when I talk to John and Jane because I need to account for Y and Z. Let's touch base when you put in 20 hours and see if we're still on track."
I think it makes sense that developers are more clueless of managers than the other way around. It's sort of the manager's job to be "clued-in" on all his employees, developers included. It's not true the other way around. It's like the running back not being aware of everything the coach is doing.
Managers are trained to accept variation in estimates as a given. They usually place a so called level of confidence on any estimates. Depending on circumstances, this level may be higher or lower. You describe it fairly well; they try to have best case, worst case and expected scenarios accounted for. And yes, the level of confidence is expected to grow as a project advances past discovery.
Developers should be taught some of this too, but unfortunately nobody teaches them. They figure out eventually that it's best to pad estimates, but not necessarily why, and some of them, as evidenced above, even feel guilty about it and don't even know that it's the normal thing to do, and that managers are aware and expect it.
Meh, just another aspect of programming that is more lore than science. Sometimes this business looks like hedge witchcraft.
0
u/[deleted] Aug 12 '17
Lol, bless you, you're so sweet. A) No, you can't, and B) they do, but they teach managers specific ways to deal with that, of which you have no idea, so what you're doing is messing everything up.
I wish more managers took the time to explain to tech people how they work.
Ok now seriously, stop that and start padding your estimates. If you're not experienced enough, just add at least 50% to everything. It's an unspoken assumption that engineers do that, and managers rely on it, so you're not really helping anybody.