A bad estimating technique. A manager asks a developer for an estimate. When the developer answers, the manager says "No, that's too high, give me a ''better'' estimate." This repeats until the developer provides whatever estimate the manager had in mind at the beginning of the process.

This pattern is described in DeathMarch, but is familiar to most developers.

It is easy to blame this on the manager, but the developer has some responsibility as well. Just say no.

'''Concur.''' As a professional I am responsible for giving accurate estimates. Part of the estimation process is to identify what my level of certainty is on the quoted number. If I am asked for a time estimate on delivering "Hello, World" I can say with absolute certainty -- 100% -- that it will be delivered in 30 seconds. If I am asked about a motion coordinator for eight simultaneous operations on a machine control I have to add some more fuzz.

One thing I can not do under any circumstances is to allow a client to dictate the delivery schedule of a product or component. Fast, cheap, good -- pick any two. If you want it at that time you have to give up these features and I am only 85% certain that it will be ready by then anyway. If you are willing to wait another two weeks then I can deliver the whole shebang and am 98% certain that it will be ready. Up to you, pal. -- MartySchrader

''Fast, cheap, good -- pick any two. I get to pick one, you get to pick the other. My choice is "good".''

Oh, by the way -- this can be short circuited by applying CountTheHands.
----
Thirty Seconds for "Hello, World"? Might be as long as two or three minutes depending on your environment, if you don't have an editor running, run compilers from command line. If it is in a GUI environment, it might take more like 5 minutes if you have to CopyAndPaste a framework. Not to slam you, but just to show the danger of pulling numbers out of the air. They are almost always too optimistic.

''This is not a number pulled out of the air. On almost any system I have used over the last thirty years I could produce "Hello, World" in thirty seconds after I had become proficient with the box. I can certainly do it now. Can't you?!? -- MartySchrader''

In the complex where I work it could easily take 10 minutes to walk back to my desk from the conference room where the meeting was held. If you say, "30 seconds," they will assume you mean they will ''have it'' in 30 seconds. Is your manager's desk less than 30 seconds from yours? By the way, does that 30 seconds include the documentation?

''Prints out a copy of "hello world" on the screen.'' Took me less than five seconds. :) ''Let's see, press EditText, wait for page, locate spot where to reply, write text, Save, check result. Takes me a minute, at least!''

"Can't keep to the schedule? You're all fired!" said The Donald.
----
'''Policy:''' I never change the estimate unless the assumptions on which the estimate is based are changed. It doesn't matter who or how many times or how hard anyone says that it's a bad estimate. If they have a "better" estimate, then they are free to use it. -- JeffGrigg

Completely, totally, '''concur''' with this policy. I am the expert, dammit!! Why did you even bother ''asking'' me for an extimate if you aren't going to listen to my expertise speaking?!? What the heck?? -- MartySchrader
----
See: NegotiateEstimates, GiveMeEstimatesNow, EstimationWoes, NegotiatingWithManagers

CategoryAntiPattern