Time Estimates

[Lost User]

And it's pretty hard to estimate the amount of time that one is going to be hanging out in the CP Lounge from one day to the next.

Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Please stand in front of my pistol, smile and wait for the flash - JSOP 2012

[lewax00]

We have estimates of sorts, but they're more relative to other tasks in the current sprint, not actual time estimates. But in general I have to agree, estimates are a waste of time. Mostly because I still haven't figured out how time works. I can barely separate today from yesterday :doh:

[Clifford Nelson]

Yeah. Whenever anybody asks me for a time estimate I cringe, and I have been doing this for quite a while. Little stuff you can estimate pretty well, but then trying to estimate they number of little things that need to be done can be difficult. From what I have heard, when programmers estimate, they tend to double it, and quite often that is right. What happens is management they halves it.

[Chris Meech]

I do a lot of production support and often get asked, "How long is it going to take to fix this problem?". To which I reply, "What do you want me to do? Waste time figuring out long it will take to fix or would you rather me just figure out why it is broke and then fix it?". :)

Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra] posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]

[Marc Clifton]

Shelby Robertson wrote:

Most managers expressed one or more of these views:

I would really like to meet (and work for) those managers. Come on. I have NEVER worked for a manager that realized that estimating software tasks are inherently unreliable, or the rest of those points. There are two categories of tasks: have to do, and would be nice to do. If you want to control time, then manage competently (aye, there's the rub) the "have to do" tasks by HOW they are done. Prioritize the "nice to do" tasks so you get the most bang for the buck, which yes, does involve a WAG at the estimate. I've recently seen one developer go off on some obscure tangent of technology (that only he knew about) to write what sounded like little more than a parser. What's insane is that his manager didn't discuss what the problem was and his recommended approach for solving it. Nor did the developer talk to the rest of the team. It was several weeks before we discovered this "waste of time", and by then it was too late. Management is not about estimation and pretty PowerPoint slides that they use to BS their management with. The worst scenario (and I've worked in many) is that a company doesn't fully grasp the investment needed (time and $) required, yet they have this idea that because they have some smart people it should be cheap. Ultimately, it's a lack of communication between management and developers, and quite frankly, I think we developers fail in that communication quite a bit! Marc

My Blog
Computational Types in C# and F#

[R Giskard Reventlov]

I would broadly agree with this. Rough estimates of when I'd like to get something off my pile are okay but anything else is just nonsense. Non-technical project managers use estimates like cudgels to beat developers with - very, very unproductive. Sure, I can tell you roughly how long a job might take under perfect conditions but when was the last time you worked under perfect conditions? Never, would be my guess.

"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me

[AspDotNetDev]

Any work sufficiently interesting will be very hard to estimate time for. It's a sad day when you only work on things with no novelty or variability. Sure, I can produce an estimate, but the actual work may vary from that estimate by 300%.

Thou mewling ill-breeding pignut!

[Nagy Vilmos]

Intelligent discourse in the Lounge? How dare you! :thumbsup:

---

Panic, Chaos, Destruction. My work here is done. Drink. Get drunk. Fall over - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett

[jschell]

Clifford Nelson wrote:

From what I have heard, when programmers estimate, they tend to double it, and quite often that is right

From what I have seen programmers tend to be optimistic. Even some who think they are pessimistic. I feel that my pessimism has gotten better so my estimates are often sufficient. I strive to insure that they will be sufficient (bigger).

Clifford Nelson wrote:

What happens is management they halves it.

My estimates are what I target regardless of managements preferences. If they want it in less time then they need to reduce features.

[jschell]

Marc Clifton wrote:

Management is not about estimation and pretty PowerPoint slides that they use to BS their management with.

Most management cannot differentiate between managing tasks and managing projects. And I only say most because I hope that one such exists. Managing tasks is the process of defining, estimating and tracking actual parts of some delivrable. Managing a project is the process of tracking delivery expections and fitting the task planning into that. Trying to managing them as one is very likely to represent the difference is not understood. One uses task management and the prunning of it to better fit project expectations.

[Shelby Robertson]

jschell wrote:

From what I have seen programmers tend to be optimistic. Even some who think they are pessimistic.

I fall into that category too often.

CPallini wrote:

You cannot argue with agile people so just take the extreme approach and shoot him. :Smile:

[Keith Rule]

I worked in a group where program managers were held to within 5% of their project estimates. Corporate spent lots of money on consultants and tools. We spent several years being micromanaged daily by having to spend an hour or so a day updating our status into the tools. The result was the program managers could watch the forecasts (we called them wiggle charts) get larger day by day. So they knew exactly when they had exceeded their 5% margin of error. After the first set of program managers moved on because of missing their targets, the next set of program managers came up with a clever solution. They institutionalized sandbagging. The result was that nobody got fired, but we couldn't actually do anything because the estimated cost of any project was astronomical. The result was that no project appeared to make financial sense - clearly that was wrong too. Now we use scrum. Though it has issues too (like not begin able to accurately estimate end dates), but from an engineering point of view it's much better than most other processes that we've tried and discarded.

Keith Rule

[Brady Kelly]

I agree that micro-estimations are a liability, but I don;t get much work at all without an upfront estimation, and I often lose there, so I'm moving toward a staggered delivery with an estimation for each phase, which is a step back toward micro-estimations.

[Fran Porretto]

A rational management will understand a fundamental rule that military analysts get drummed into their heads on Day One at the War College:

The map is not the terrain.

A plan, with attached estimates of time and cost to completion, is a map; the actual enterprise of:

• Solidifying the requirements;
• Gathering all the relevant specifications for the inputs and the outputs;
• Designing the solution;
• Coding the solution and performing alpha-testing;
• Composing a beta-test procedure and contriving to get it executed by competent beta-testers;
• Coping with the screams of outraged customers to the effect that "That's not what we want;"

...is the terrain -- and a harsh, irregular, rock-strewn land it is. However, rational managements are about as rare as sensible liberals.

Possibly the best approach to the production of an engineer's estimate goes as follows:

1. Take a SWAG at it.
2. Double the numerical figure in your SWAG.
3. Whatever the time unit in your SWAG (i.e., hours, days, weeks. months, years), replace it with the next higher one.

Thus, if your SWAG is "two weeks," publish an estimate of four months.

Why? Simply: That won't be the final schedule, and the final schedule is what really matters. The procedure above attempts to account for all the following:

• Changes in requirements.
• Management's inevitable attempt to bargain you down.
• Engineer's optimism.
• Distractions, diversions, and deflections.
• Delays in the acquisition of necessary items (e.g., file formats and test data).
• Unavoidable "learning experiences" ("What do you mean, you don't know RPG-II? Everyone knows RPG-II!")
• Everything else.

I've been using the above procedure for about thirty years, and it's served me well...because it's based on realities we'd like to wish away, but can't:

• Requirements will change.
• Management will meddle.
• We all think we're faster, smarter, and more accurate than we really are.
• There are always other things that will demand our attention.
• Nothing is ever ready when those who've promised it to you said it will be.
• So you think you know how to code a B*-tree from scratch, eh, hero? Think again!
• Murphy never sleeps.

In my experience both as an engineer and a supervisor, a competent engineer's SWAG is within 25% of exactly accurate ne

[agolddog]

Huge lump-of-salt caveat: I by no means claim to be an expert in agile work; just some things I've observed at various shops which claim to be "agile". We've been discussing this lately. Our boss apparently doesn't get that "agile" is an adjective for the word "development". His notion is that, once the items in a sprint are defined, they must always be completed, no matter what else (i.e., other time sucks like interviewing, prodution bugs, etc) come up. Of course, there can't be a space in the sprint planning for things like upcoming interviews. What I've discovered is that there really are only three categories of estimates: trivial (a few minutes/hours), a day or two, or "a long time". Trying to pin down anything more than a day or two is a futile exercise. For any system of that level of complexity, we can't possibly expect the business people to have thought through every possible path. Thus, there's no way that we can expect to have a complete set of requirements. To me, that's one of the strengths of agile; we have a pretty good idea of the direction we're going, and as we see it in action a little bit, we refine those requirements. But, allowing the development process to be agile means, by definition, we can't give accurate big-picture estimates. With respect to some of the other posts about management, it occurs to me that there are really only two things management needs to get right: hire competent people, and put them in a position to succeed. What does it mean to put people in a position to succeed? Pretty much analysis of the skills required to solve the problem at hand. It is not, "stick resource A on problem B and see how it goes," but rather, "problem B requires skill set X, Y, Z: find a resource with those skills." So, not a trivial problem to solve, but my experience is that most managers don't go to even that level of analysis. Of course, criticality enters into the equation. If resource A doesn't have skills X, Y, Z, and this is a high-priority, production problem, A is being put in a position to fail. If problem B is lower-priority, and A is given time to learn those skills, then A is being put in a position to succeed. But, fundamentally, it's the same problem: put your people in a position to succeed, and they will; put hem in a position to fail, and they will.

[BrainiacV]

That pretty much sums up what I've been saying all along. But quibbles are that given the right person (me), software estimates can be fairly good. I was always stuck doing estimates and hated every minute of it. Anything I estimated got bricked into a Microsoft Project plan and our noses were held to it. I can't quite articulate how I did it, aside from just understanding the tasks and being able to imagine the volume of code it would take to create it. But that said, management never knew how to use the estimates other than to punish you if they thought you weren't keeping to them. And worse, they would then take a dependent string of tasks and they would try rearrange them to get things done faster. Again and again, I had to tell them they couldn't do that or it would all fall apart. But in reality they never wanted estimates. They would just pluck a date out of the air and pronounce it as the end date. The task list stayed the same (or got bigger) even when they would decide to move the schedule up. That was one place. At another, you'd create the estimates to figure out the project costs for the quote to the client. Well reality never means anything to the salesmen and they'd take our figure and chop it down to whatever they thought would undercut the competition to get the sale. You can argue the hardware has fixed costs and construction estimates are honored because you can see the work getting done, but the software was invisible. The cost would always remain the same, but we won't be able to bill for it. We used to joke we'd make it up in volume. The (un)amusing part would be when they thought they'd sell a duplicate of the system and try to make the money up then. But invariably the client would argue the system was already done and they'd want to pay only for the hardware, the software they expected to get for free. My experience is basically estimates don't matter. Whatever you come up with will be ignored or met with extreme skepticism as to the length (it should be shorter) and never used for any practical purpose.

Psychosis at 10 Film at 11 Those who do not remember the past, are doomed to repeat it. Those who do not remember the past, cannot build upon it.

[snowman53]

An important element in this is the collection of actual time required. Once you/your company has collected a history of MHR's per line of code (or similar metric) you will have a decent method of predicting the schedule/cost of a new project. In the aerospace industry one of the companies I worked for based the estimates on lbs of airframe weight that were new and changed design. They had a thirty year history that was within +/- 20% for estimating new projects. We used the historical record as much to defend our estimates against arbitrary cuts in budget as we did to make initial estimates.

[Member_5893260]

Interestingly, the "upgrade the unit and multiply by two" approach was also adopted by IBM at an early stage. I've found that in general (unless you get really lucky, which can happen) it's a fairly representative method of working it out.

[Lost User]

Yep. If you never estimate or measure, you will never be late or over budget. Just keep telling them: "soon"; while asking for more time / money / resources.

[jschell]

Fran Porretto wrote:

A rational management will understand...

In the current software industry I would expect that at best a knowledgeable and rational management will understand nothing except that they shouldn't rely on software project plans. The irrational ones assume that the project plan can be done in less time often with nothing more than throwing marketing terms around.