I would estimate

funny wallpaper » I would estimate

funny wallpaper » I would estimate — Mon, 01 Sep 2008 09:17:22 GMT

PingBack from http://housesfunnywallpaper.cn/?p=3385

re: I would estimate

dejan Fajfar — Mon, 01 Sep 2008 13:54:43 GMT

Happens to me every two weeks when we have those sort of meeting.

re: I would estimate

kjopc — Mon, 01 Sep 2008 19:17:25 GMT

When it comes to estimates, management actually *wants* you to lie to them.

When managers insist that the project can't take as long as estimated, managers effectively pressure devs to tell them it can be done in *less* time. The dev reluctantly plays along, knowing the reduced estimate is inaccurate.

Ken

re: I would estimate

ACM — Tue, 02 Sep 2008 00:28:22 GMT

I find most devs grossly underestimate the time. They focus on the two or three interesting or challenging subtasks and forget all the other bits that go into building production code (UI polish, unit tests, documentation, etc.).

I used to do this, too. Now I spend more time thinking about all of the tasks necessary to get to the finish line. My estimates have become very accurate--a fact that was greatly appreciated by my managers at previous jobs.

But at Microsoft, it's not that my managers don't believe my estimates, they simply refuse to accept them.

A deal was made to ship code to a partner. The negotiated date allows four weeks of development time (to "code complete"). My most optimistic estimate is a shade over five weeks, even after I get agreement to cut every last non-essential feature. The spec won't even be 100% done before the code complete. Result? I get branded as "pessimistic", "cynical", and "uncooperative", and I'm told to treat the project as a "stretch goal".

So, I crank away, work extra hours, take a few shortcuts, annoy others by ignoring their email, and get 85% done by the deadline. The deadline gets renegotiated with the partner (who wasn't going to be ready anyway), the implementation is now hog-tied by some of the shortcuts (which will cost us in V2), and my review says that I missed my stretch goal.

Nobody remembers or cares that my estimate was right on the nose. Predictability is not valued in my corner of the company.

Then there's the problem of there being far too many unknowns to estimate. I was on a group of top-notch client coders. We were then given a server project in maintenance mode, and asked to estimate how long it would take to make some changes. (Again the estimate was meaningless, the date was already determined.) None of us had any experience with IIS, SQL Server, ASP.net, C#, JavaScript, or the existing code base. The first task on the schedule is: learn all those technologies. How do you estimate that task?

re: I would estimate

mfp — Tue, 02 Sep 2008 11:28:42 GMT

Here is another blog post on how to reach consensus on what a realistic estimate is:

http://blogs.msdn.com/mfp/archive/2008/01/18/late-night-discussion-on-software-development-2-estimation.aspx

re: I would estimate

Rajesh Mishra (Microsoft) — Thu, 22 Jan 2009 03:14:49 GMT

what i found that works well in estimating is to break all tasks that will go into the effort of building that piece of the feature such as specing, socializing the spec, factoring testable design, unit testing, integration with other components - w/o all of this and likes your are really estimating just the 30% of effort!!