No ETAs
You don’t know what you forgot to take into account, or what pieces you underestimated or overestimated. You never know what weird bugs will trip you up.
You don’t know what OS release between now and then will make you spend extra time on something.
[…]
The problem with stating an ETA then, is that it sets up expectations. When you don’t meet them — and you won’t, most of the time — people sometimes get upset.
[…]
The only reason anything ever ships is because people just keep working until it’s ready.
I support and endorse this position. It’s how we’ve done it for close to thirty years.
Great post. If someone asks me for a feature, I tell them the version it’ll be in, not when that version will be out. That’s easier for us to control.
Even this can be difficult because sometimes there’s an unexpected blocker that makes it impossible to implement a feature that seemed doable.
Absolutely agree. The most I will ever say is “it is done for the next version” (ie, I have actually implemented, it is actually running on my Mac, and so it will be part of the next release).
Old man Matt has had too many features postponed or killed by schedules, or management, or politics, or bugs to promise anything to anyone.
3 Comments RSS · Twitter
I guess the insinuation here is that Apple states an ETA for their software, so they're forced to deliver it full of bugs to meet the ship date?
Ben G: No, Brent specifically notes it’s about people always asking him for an ETA for such-and-such a feature in NNW (currently, feed sync service X, Y, and Z!) or an Omni product. The post just happened to roughly coincide with Apple’s worst strict-annual-fall-releases OS versions in some time, so it’s very easy for us to assume that was his context (though certainly some of the reasons against ETAs for features also apply to hard deadlines for releases).
