Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree with you but like others have said, they want a date they can sell to and in the end it will be your fault.

It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much.

I read something once that has stuck with me. "We can never give more than a vague guess because we are literally building something that doesn't exist and has never been built before."

* I do find it annoying that the sales teams generally drive this. I wonder how they would feel about a response of "We'll get you an estimate of when it will be available as soon as you get us an estimate of when this feature will generate the $1M of revenue to cover the costs of building it. Also, please give us a list of customers that are likely to buy it and your expected contract date so we can track it along with development."



> It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much.

There's definitely a correspondence here, but it's a bit indirect.

Government and even private contracts are often knowingly lowballed to secure the deal. Rules like "must choose lowest bid" reward entering an unrealistic bid and then inflating costs after work is going. Or, if overruns come with sufficient penalties, doing work at a loss and then charging a fortune to support a fragile and proprietary result.

In the metaphor to non-contracted software, developers generally don't correspond to the contractors but to the government. Sometimes blown estimates are simply errors, but other times somebody wanted to secure customers, so they pitched an unrealistic scope and arranged to make the inaccuracy land on the programmers. Where the government ends up with late delivery or runaway costs, programmers end up working crunch time or sacrificing quality. And where the government ends up locked into paying for support, programmers end up locked into maintaining rushed, tech-debt-riddled work.

(As for pushing sales for revenue and contract estimates, do it! Some of the most productive teams I've been part of have been ones where sales applied this pressure, but also responded well to the reverse version and kept everyone informed.)




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

Search: