No ETAs

People often ask me about ETAs. When will the feature they’re waiting for ship? If you’re a software developer, they probably ask you too.

I totally get it! Though I write an app, I’m mostly a user of apps, and I too want to know when the features I’m waiting for will ship.

The Problem

But here’s the thing: ETAs are very hard to estimate with any amount of accuracy. Even if you plan well.

There are just too many variables. You have some very rough idea of the work to do, and how much time it ought to take, yes. To start with: those ideas are wrong.

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. (For instance: iOS 13.2 just came out today. How is it different? Does it affect the app? Every OS release is a moment of anxiety for developers.)

You don’t know if you’ll need to do some serious, time-consuming refactoring or rearchitecting. You don’t know if the person working on the feature might get pulled away for some reason (vacation, emergency, reassignment, etc.).

You don’t know if the fallout from some other feature in progress will require more time, which ends up pushing back this feature. You don’t know if some other feature or bug fix will suddenly get a higher priority based on any number of good reasons.

You don’t know if your testers will be pulled away to work on something else. You don’t know if your tools will be updated in a way that affects productivity. (Hopefully for the better! Though, if there’s a learning curve, maybe it will hurt productivity at first.)

There’s all that and plenty more — and none of the above are extraordinary conditions. They’re all quite normal. So any ETA will almost surely be quite wrong. Even if you take all of the above into account.

On Not Setting Expectations

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. Not everybody. But some people take ETA to mean “I promise to ship that day or damn close to it.”

So the better thing to do is plan which features go into which releases, and have a date for internal use for just the next release — and refrain from making public ETAs.

Even if you the software developer think you can make accurate ETAs — and maybe you did, once or twice — you’re not going to be that lucky most of the time.

PS This is all just to say that app-making is nothing like building a house. It’s more like building the first house ever in the history of houses, with a pile of rusty nails and your bare hands, in a non-stop tornado. It’s different every time, and it’s astonishingly complex, non-linear, and unpredictable. We all do our best to mitigate this, to make it more regular, but the industry just hasn’t gotten very far with that yet. The only reason anything ever ships is because people just keep working until it’s ready.

Update 30 Oct. 2019: See the follow-up, which explains that I’m not talking about all ETAs.