Hacker News new | past | comments | ask | show | jobs | submit login

I've always felt the problem is that we're trying to estimate something unestimatable. My thought's always been that if the management needs of the company are that developer time should be quantifiable and that projects should have a direct ROI, then the most sense would be to only chase ROI in small projects of little risk, and leave business growth to big projects with lots of ambiguity and lots of risk. This is the same for any kind of business venture; why should writing software be any different?

In other words, if your process involves predicting time needed to complete a project, you've already failed.




My father-in-law is a project manager for a gigantic construction company, so it was interesting talking about estimation for him. Estimates are much more predicatble in his field, even when working on multi-million dollar projects with timelines that span several years.

The difference was that in construction, the same subprojects have to be done over and over again, so subcontractors can easily be given and held to realistic deadlines, and your only bloat comes from the usual hiccups. On the other hand software engineers _by definition_ estimate things they've never built before. If they've already built it, they can just port it over and start working on something new.

Combine that with everyone's tendency to underestimate, inability to determine unknown unknowns, and the usual hiccups, and we're left with the usual refrain: accurate software estimation is basically impossible.


The interesting thing is that in software engineering the cost of additional sub components is zero. Copying bytes is effectively free, so we gain no useful information on how much it costs to build a widget.


2 observations from my experience:

1 - You can fix the time or the scope of the project, but not both. I can say, "I will deliver project X in 4 months" but you have to be willing to let me toss out scope, and the earlier the better. This does work. Just like I can say, "I will promise to deliver all the scope in project X, I just can't promise how long it will take." Agile helps break this into smaller chunks, and allows you to get more visibility into what's realistic more quickly. I've seen too many waterfall projects slip by 3-6 months at a time only when the final deadline approaches.

2 - I've seen more projects slip because of "Unplanned work" and "Missed Dependencies" than due to "Misestimated work". It's either scope creep, or "I didn't realize we needed to test integration" or "Person X didn't give me what I needed." The only counter-examples I've seen are when engineers aren't consulted in the estimates.


I would certainly agree on both of these assertions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: