Lightning Talk: Manager's guide to developer estimates (abridged)

And now for something completely different.

Anyone's parents or partners ever make you read these books from the 1990s: Men Are from Mars, Women Are from Venus? Hands, anyone? Yeah. The Five Love Languages, anyone? Yes. The rest of you are thinking, what the hell does this have to do with developer estimates?

Well, I'll tell you. It's two groups of people that want to do the same thing, but speaking in different languages. And so let me be your guide to speaking developer.

But before I start, how many of you would consider yourself a manager here? I just need to know approximate. Okay, quite a bit. Developers? I see-ish. Okay, so a good amount managers. This is for you. Developers, keep me honest.

Managers, picture this: you have a project you need to get done. You sit your best developer down and you say, how hard is this going to be? How long is it going to take? Your developer is going to say a few words that you might not understand. So let me translate for you.

The first word: trivial. Yeah, you know what I'm talking about. You know where I'm going.

This word, in the vernacular of The Princess Bride, doesn't mean what you think it means. To a manager, they hear a couple hours. You know what, I'll give you a couple days. This trivial? No problem. Yeah, that's not what a developer means. What they mean is, I can map it out in my head.

Now it may take a minute. It may take an hour. It may take a day. It may take an entire lifetime. Developer doesn't know. Developer doesn't care. All they know: they figured it out. Excellent.

So my pro tip for you as a manager: ask the next question and say, awesome, it's trivial. Now, how long is it going to take? Don't assume. As they say, you make an ass out of you and me. This applies here. Ask that next question.

Impossible. Now, the definition of impossible starts with this man, Alan Turing. He hypothesized a device that had infinite capabilities to solve any computable problem.

This is the part of the talk where I was going to pull out my phone, but I'm out of hands. So imagine I'm waving a sweet flip phone in front of you and making the point that this device, given enough time and a Turing-complete language, can compute any possible problem.

When a developer says something is impossible, what they mean is, given every possible computer in the world, you would never solve this problem. But do not despair. What a developer doesn't often know or even think about is there's a lot of value in getting close.

Amazon doesn't know what book you would love to read next, but it can make some educated guesses. It would get pretty close.

So for a manager, I would say always ask: okay, it's impossible, but can I get close? Because sometimes close is good enough in, what's it, hand grenades and horseshoes? Is there a third? I always forget if there's a third. Nuclear weapons? Jesus. That took a whole different turn. Yes. Moving right along.

Infeasible. If your developer says this, you might think, well, isn't that impossible? And from a practical sense, you would be absolutely correct. But a developer always, of course, doesn't want to be correct. They want to be technically correct.

And what they mean is that if you, let's take cryptography, it is infeasible for my phone to crack any encryption, but it could happen. You could throw resources at it. It's not going to happen. So when they say infeasible, you're hearing impossible, and you should still think that. Don't listen to them. Yes, they're technically correct, but you know, you have to let something just go in one ear and out the other.

Non-trivial. This is the opposite of trivial. Again, there is zero time component here. All the developer means is, I do not know how to solve that problem.

I am reminded of my good friend Donald Rumsfeld, who said, there are known unknowns and unknown unknowns. The whole point here is, in a non-trivial problem, there are unknowns and the developer needs to work through it.

The non-trivial problem, given investigation, could become trivial. It could also become impossible or anywhere in between. So therefore, my recommendation for you as a manager is, when you hear that, give them time to investigate and see where it goes. Cross your fingers it becomes a trivial problem. And then, of course, you need to estimate. You remember the stuff in the slides before, right? All right.

This, I fully admit, I stole from a friend of mine, Charles Miller. He is the first architect at Atlassian, pictured here back in the early days. If you want to read his blog post on understanding feasibility, it's...

[Transcript ends abruptly in the source VTT.]