Las Vegas 2022

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

Fun, thought-provoking, emotionally resonating talks presented by members of the DevOps community.


Hosted by Topo Pal and Jason Cox.


Presented by Sleuth

DB

Don Brown

CTO/Co-founder, Sleuth

Transcript

00:00:00

<silence>

00:00:10

And now for something completely different, anyone's parents or partners, did you ever have somebody make you read these books from the 1990s minute from Juarez Woman, from Venus Hands, anyone? Yep. 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

00:01:03

Managers. Picture this, you have a project you need to get done. You set your best developer down and you say, how hard is this gonna be? How long is it gonna take? Your developer's gonna 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 uh, vernacular of 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. It's 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 it 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. <laugh>.

00:02:00

So my pro tip for you as a manager, ask the next question and say, awesome. It's trivial. Now. How long is it gonna take? Don't assume, as they say, you make an asset 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 row is gonna 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 in a turning 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? 'cause sometimes close is good enough. And uh, what's it Hand grenades and horseshoes. Is there a third? I always forget if there's a third. Nuclear weapons. Nuclear weapons. Jesus. That's <laugh>. That that took a whole different turn. Yes. Moving right along.

00:03:29

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

00:03:44

And what they mean is that, uh, if you, let's take cryptography. It is infeasible for my phone to crack any encryption, but it could happen. You get the resources at it, it's not gonna 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 some things 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 none known unknowns. The whole point here is in a non-trivial problem is 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 <laugh>. 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? <laugh>? Alright. 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 wanna read his blog posts on understanding feasibility, it's.