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

Where I work, we deliver on time. Customers schedule upgrades many months in advance, and in series or sync with other upgrades. They are on maintenance contracts to get the latest version.

If we deliver a broken product, than that is a failure to cut scope adequately. Do that once or twice and suffer through the consequences and you will learn not to let it happen again.




Moving a feature into the next release cycle is equivalent to extending the deadline for that feature. You're right, though -- management does seem to have a strong preference for one terminology over the other.


That’s true, but if the product is big enough, with enough varying constituencies, then delivering something to a large chunk of those people on time is a lot better than delivering nothing to everybody on time.


I think there is a lot of "it depends" in here. If deployment is zero friction to the customer then maybe this applies. If deployment by customer is disrupting then forcing them to go through multiple release cycles due to bugs or lack of required features can be worse for them.

I just lived with a half-broken product for a year rather than deploy the more final full featured but less stable version multiple times from a vendor due to such deployment difficulty. I want quality and completeness over speed in that case.




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

Search: