ADAM SANDERSON: All right folks. This is Unreasonable Estimates and Improbable Goals. My name's Adam Sanderson. I'm a full stack developer at LiquidPlanner. I've been there for about six, nearly seven years, working on Rails, databases, like, front end, back end. You name it. If you want to, you can find me on GitHub. Twitter. These slides are gonna be on Speaker Deck. It's all under Adam Sanderson. That makes it easy. But more awkward, I write code, or I write about code on monkeyandcrow dot com. If you like the talks about, like, reading and learning about Rails, I'm actually writing a series called reading Rails. So go check that out if that's what you're in to. And hey, it's RailsConf. You probably are. So, like I said, I work for LiquidPlanner. We make online project management software. Probably the most interesting thing for you guys is that we do probabilistic scheduling, which is pretty awesome. So if that sounds kind of cool, like everyone else here, we're hiring. And I need somebody to come help me build new stuff. So really, if you're in Seattle, let me know. So, you can't really work on project management software without thinking about the work of work. Specifically, I'm talking about estimating projects, finding the hidden costs involved in those, and then dealing with deadlines. Sounds like fun, right? Sounds like life. All right. How hard would it be? I get asked this question all the time. People come up to me, and they say, hey Adam, how hard would it be? How hard would it be to change all of our buttons from red to blue? How hard would it be to implement a new, like, class of user? How hard would it be to implement email integration? What should I do? Clarify. Before I tell somebody how hard it would be - and, pro tip, they don't care how hard you gotta hit the keyboard. What they're actually asking is, how long is it gonna take you to get this done? Before you tell them, clarify. Make sure you know what they want. Make sure that what's in your head is what's in their head. Because a lot of times when people come to us, developers have a very specific vocabulary. Things that we think mean one thing mean a different thing to somebody in sales, or marketing, or QA or support. So make sure that you know what they mean when they say, hey, how hard would it be to integrate email integration? Does that mean sending emails out of our system? Does it mean receiving emails from someone else? Does that mean a plugin for like Outlook or Gmail? If you don't clarify up front, you could spend a lot of time wandering off into the woods, and when you come back with your amazing feature, they're gonna look at it and be like, what? What is this? And you'll have just wasted, like, an hour. A day. A week. Oh, that's gonna suck. So clarify. Next, clarify. Ah. Again. So. Look, you know what you're doing, now you gotta figure out why you're doing it. Ask them. Hey, why do you need to me to integrate email integration? Maybe they turn around and they say, well, look, we've been getting a lot of customers sending us screenshots and it'd be nice to just be able to email those into the system. Does a better, does a solution already exist? If it does, you might be able to point them towards that. And a bonus for you, now you don't have to do anything. Maybe they turn around and they say, yeah, I know that that exists. But it's kind of a pain to use. Well, now maybe you've found that there's a better approach to solving their problem. Maybe you just need to fix existing functionality. People come to us, all the time, with prescriptions for solutions to problems. It's really useful for us to take a step back, and before we say, yeah, I'm gonna do that, to say, wait, why do you need me to do that? Maybe you can help them come to a better solution. And, by doing this, you're gonna get a better idea of what you need to do. All right. Once you know the what and you know the why, it's time to start thinking about estimating how hard it's gonna be. How long it's gonna take you. I want you to think about the major pieces of work that you're gonna need to do. Imagine the project and, instead of thinking about it in their terms, in terms of the domain of the person asking you, think about it in terms of what you have to do. Is it gonna require a lot of database work? Well, think about the tables. Is it gonna require a lot of work in Rails? Think about your models, your views, your controllers. Is it gonna require a lot of front end work? Well, think about the different components on the screen. Break these large tasks down into smaller things, and write it down. You're gonna need to refer back to this later anyways. This is the stuff that you need to do in order to, like, service their request. Next, sometimes it could be overwhelming to get some of these asks from people. You'll find that they have so many, like, business rules that they want, they've got so many little details that they want to impart upon you. It can make it really hard for you to see the forest for the trees. Step back for a moment. Try and find unifying principles in what they're asking for. Is there some model that you can make, in your head, that explains what they're looking for? It doesn't have to be perfect. It's just gotta be enough so that you understand what direction to be going in. Again, write this stuff down. You'll need it later. All right. You've broken stuff down. You've grouped stuff back up. It's now in a stage where you can sort of wrap your head around it. Think about other things that you've done. Have you done anything like this before? One of the unique things about our profession is that we tend not to do the same thing twice, and if we do, we're kind of doing it wrong. So, if you can, think about similar things. But maybe you haven't. Turn and ask one of the other developers in your company. Maybe they've worked on this code before. Maybe they've dealt with this type of issue before. They can help you get a better estimate. And on top of that, if they're doing their job right, maybe they'll ask you what it is that you're trying to do, and they'll ask you why. This is awesome, because it turns you around and makes you be the person who is asking you for work. It's really helpful for clarifying what you've got to do. Now, there are dozens of different methodologies. Different approaches. Different sciences of estimation. Here's what I want you to do. Make a guess. That's it. I know. You could play planning poker. You could do all number of things. But, just make a guess. Here. I'm gonna make it flash. There. Isn't that awesome? Seriously. Look, an estimate's just an informed guess. A lot of times, we put way too much value on an estimate. It's OK for you to be wrong and it's OK for you to be uncertain. In fact, if you're not uncertain, you're probably wrong. I want you to quantify that uncertainty. Embrace it. Are there things that you're being asked to do that you don't know how they're gonna spa- like, turn out? Maybe, like, you've got to load a whole of data into the database and you're not sure if it's gonna handle that. Maybe you've got to make some, like, flippy clicky thing that's gonna be, like, really hard to implement in Internet Explorer 8. Do you know how that's gonna work? Maybe it will. Maybe it won't. Raise these things up. Let other people know. If they're asking you to do this work, say, you know, I'm not really sure about how this is gonna impact our database. I'm not really sure whether IE 8's gonna support this user interaction you're asking for. This is helpful, because it gives the other person a better understanding of what you need to be doing. Now, next, play a spread. Tell them a story. If everything goes well, I think that this might be done in a week. If I need to denormalize my database, if I need to do something really crazy to get this supported cross-browser, this could take me four weeks. Look, it's a lot easier for you to hit an estimate, a range, than it is for you to give them one hard number. So that's great for us. But it's also good for the person asking you to do the work. Because you're giving them a story about the future. You're telling them useful information about how this could play out. And if they've got that information, they can start making better, better use of that. They can plan better based on that. And it starts a better dialogue between you. But you're not done there. You've got to deal with this uncertainty. Nobody likes to get bad news. Nobody likes to find out that the project is doomed. But you know when they like to hear that? Never. OK. Do you know when they'll tolerate it? They'll tolerate it right at the very beginning. You know when they won't tolerate it? In the eleventh hour. Oh, man. Are you gonna be ever so happy when your fellow developer says, hey, guys, I know we're gonna ship, but I just checked the clicky flippy thing in IE-8, and it doesn't work. Wait, we're supposed to ship when? Nobody wants to find out that the uncertainty got left to the end. So do it first. It's really hard to do this, but deal with uncertainty up front. That way, when you find out that something's going to take a long time, you can communicate that back to people, and you guys can adjust your plans to accommodate that. I know. We always want to do the fun things first. I want to like, jump in and do the stuff that I know really well first, because I feel like I'm making progress. That's a great way to set yourself up for failure later. Now, doing that alone isn't enough. You remember that estimate? Change it. Change it continuously. As you learn new things, as you figure out the uncertain things, and as you make progress, circle back and tell anybody who depends on you how long this is gonna take. Give them your vision of the future. Give them your mental model of what the risks are. Give them the understanding that you have, right now, about what you think is gonna happen. Communicate often. All right. Let's talk about the Dark Arts of project management, for a moment. Look, you know what you're doing. You know why you're doing it. You've got an estimate and now. Oh. Shoot. We can get screwed, as developers. We think that we're all logical. That we're sane. Now. This ever happen to you? It happens to me all the time. Somebody comes up to me and they say, hey, Adam, how long's it gonna take? And I say, it's gonna take about three weeks. And they say, look, we need this done really quickly. Could you maybe do it in one? And I say. Well. Oh. How about two weeks? I thought that I was just being nice. I thought that I was just splitting the difference, right. Wrong. I just screwed myself. It's natural for people to haggle. But you don't win when people are estima- or bargaining over estimates. Look, you're estimate is your best understanding of what the future holds. What made it go from three weeks to two weeks? How did you suddenly manage to shave off a whole week of work in five seconds? Cause I want to know. I need to be able to do that later, so you come up and you tell me. No, look, you can't negotiate time. But you can negotiate features. And as you learn more about the project, you can re-estimate. Moral of this story, don't give people estimates that you think are gonna make them happy. Give them estimates that you think are true. If they keep badgering you about it, point it out. Say, hey, look, I know what you're doing here. I see what you're doing. Estimation bargaining. It's not gonna work. Not only is it not gonna work for me, it's not gonna work for you. If you give into this kind of thing, you're actually setting up not just yourself for trouble but your team. The people who rely on you. And, whether or not the person asking you to do the work knows it, you're setting them up for failure as well. Because they depend on that estimate that you just gave them. So, you know what you're doing. You know why you're doing it. You've got an estimate. You defended it. Maybe you shouldn't do it at all. There are hidden costs involved in everything. Like complexity costs. Look, some features that we build incur future, incur costs on all the future work that we do. For instance, if you build a new RESTful API, great idea. If you build a new, like, axis controls, you're just dropping in can-can. If you build, like, a new mo- native mobile client. Yeah. You're not done there. From now on, every new feature that you implement has to take those old features into account. So what you just did is you made it so that your future work, future work, is gonna hate past you. You're just incurring new costs for the future. So watch out for these cost-cutting concerns. they can really bite us sometimes. Now, there are ways to do this that are gonna cut down on those costs. You can never get rid of them entirely. But, if you want to, do the extra engineering up front, factor that into your original estimate. Let the people know that you're gonna need a little bit more time. What about operational costs? Look, are you introducing new moving parts? You're gonna build a new job queue. You're gonna throw resq and redis in place. They're awesome tech. But guess what? They're costly. How are you gonna test this in production server? How are you gonna monitor it? How are you gonna deploy this? How are you gonna make sure that it's running every time you spin up a new server? It's not necessarily hard. But it does take time. And once you've done it, it still takes time. And you know what? When resq goes down, who are they gonna call? They're gonna call you. You're the one that put it in place, right. So dealing with that is gonna take more time out of what you consider to be your budget for developing. Support costs. These are awesome. There are a lot of things that we can do as developers that are just really easy. We can knock out a feature in like ten minutes. The downside? Nobody understands how that feature works. So what if your users don't get it? Like, you built this awesome thing, and they've got no clue what it does. Who are they gonna talk to? Well, if you've got one, they're gonna talk to your support team. I hope your support team understands - your support team doesn't understand it. OK. Awesome. Your support team's now talking to you. And that takes time that you're gonna be not able to develop in. What if your business, as a whole, doesn't get it? Meetings. That's what. And you know what meetings mean? It's not just your time that's being used up then, it's the entire company. Everyone around that table? You're sinking more and more costs into this. So, again, you can combat some of this, but go back, update those estimates, to factor this in. What about opportunity costs? Slightly different thing. But think about this. You can really only do one thing at a time. So what's the highest priority thing for you to be doing right now? What's the highest priority thing for your team? For your business as a whole? Because, whatever you're doing now is excluding every other feature that you could be working on right now. Think about it. Prioritize all the things that you would like to be doing. All the things that you know you should be doing. Make sure that this is actually the most important thing. Not just the most immediate thing that you need to deal with. Look, I'm not saying don't do anything, but weigh the costs. Understand them. Recognize them. Everything that we do as developers costs us down the road. Choose which ones you're willing to pay. All right. More Dark Arts, cause I love these. This one's the most insidious. This one trips us up as developers, because we've got egos, and it's really easy to manipulate us. This happen to you? Somebody comes up to you, they say, hey, how long's it gonna take? And you say, I don't know, about a week? And they say, really? Oh, and they look so disappointed. And then they say, I thought you were smarter than that. Wow. That hurts. Then, it's like, kicking you when you're down. They say, oh, I'll go ask her. I'll go ask the intern. She seems pretty smart. Ah. Even worse. You know what happens next? I don't know about you. But me? I start begging to do the work. I'm like, you know what? Did I say a week? I meant maybe, like, three days. Whoa, stop going towards the intern. One day? I'll have it to you by noon. Fuck. Aw. Don't let your ego get you into trouble. Stand by those estimates. Really, the best thing that we can be as developers, in this case, is have a little humility. And if you see somebody trying to do this to you, call their bluff. Like, they're not really gonna go to the intern. Well, they might. And it might be a learning experience for everyone. But name this. Say, I know what you're doing there. It's not gonna work on me. Stand up for yourself. And if you can't, find a new job. All right. Deadlines. Like, I've got one coming up in eleven minutes. Deadlines come in all forms. They come in a spectrum. From soft deadlines to hard deadlines. Soft deadlines are things like goals. They're things we would like to achieve. For instance, we would like to ship this by the end of the week. We would like to get this out by, I don't know, this next conference. Hey, we're gonna try to get this out for the customer by Q1. Hard deadlines are things like, RailsConf. For me, anyways. Can you imagine, RubyCentral sending out an email. They say, hey guys, funny story. Adam didn't do his slides, so we're postponing RubyConf by, like, a week. Just change your reservations. Yeah. I'm not DHH, so I can't get away with that. It's a hard deadline. So when hard deadlines come up. Actually, when all deadlines come up, what do we do? You gotta deal with it. Ignoring it's not gonna work, and panicking also doesn't work. So, we've really got four options. The first two are ones that we as developers think that we really like, and the second two are ones that managers think that they really like. Nobody really likes any of these options, when you get down to it. But, if it's a soft deadline, if it's just a goal, you guys can ship late. You can miss. Maybe. It's probably not the end of the world. Don't do this all the time, cause you're gonna look like an idiot. But recognize. Weigh the balance, weigh the thingies that you've gotta weigh. I don't know. Yeah. This talk is about work. Not about how to give a good talk. Rad. So, yeah. Sometimes you can ship late. Of course, there are hard deadlines, right. There are things like RubyConf. And I can't miss this deadline. If I did, we would all be standing here and I would be stammering like I was. So what else can we do? Well, we can cut scope. We can cut features. Like, honestly, prioritize the things that you've gotta do. Figure out what you can get done by the deadline. Cut the rest. For instance, I illustrated like all of these slides, except for, I got about here and I ran out of time. So I cut my little illustration. One of the things that is scary about this, though, is that some of the things that get cut are the things that we, as developers, think are important. Performance. Testing. Correctness. All these things can get cut if you're not careful. So if you value that, make sure that it's put high in your priority. Make sure that you guard that against the deadline. OK. Another option. If you're not gonna get it done and you can't ship later and you can't cut features, well you can add more people, right? Well, you could go read the Mythical Man Month, but basically boils down to this. Unless you've got a project where everybody can work completely independently, you're gonna have to start talking to each other. Eh. It's kind of uncomfortable. So, I'm about to miss my deadline. They pull you in to work with me. Now you and I have to start talking. We've gotta make sure that we aren't gonna be stepping on each other's toes. We've got to keep each other appraised of the situation. We've gotta understand which direction we're both going in. That adds overhead. And if you're splitting up work between two people, it means that you're gonna start, like, depending on the other person to get things done. And if I'm waiting on you and I'm twiddling my thumbs, that's sort of wasted time. That's time that's not actually going towards getting the work out. So, adding more people sometimes works. But sometimes, it's just gonna make everything go more slowly. Oh, and if you do add more people, make sure they get along. Cause nothing is more awkward than running up against a deadline, working with somebody who you want to punch. Like, this is how sparks fly, right? You don't want to do this. All right. The final way that you can deal with a deadline. If you can't two people to do the work twice as fast, maybe you can make one person work twice as hard. Ah. This really sucks. And I'll tell you why. It works. It can. Honestly. But it's not sustainable. And I don't think any of us enjoy it. Look, think about this. You've got eight hours to work. You've got eight hours to sleep. And then you've got eight hours for your daily commute, for cleaning up after your dog, for cooking dinner, for spending time with your friends, your family, for reading seventeenth century poetry. Where's that overtime gonna come out of? I gotta hint for you. It's not coming out of work. Bummer. OK, your only two remaining options are sleep and what I would like to call life. So, if that time's coming out of sleep, you're gonna be tired. You're not gonna be very proficient. You're not gonna be thinking straight. We make the stupidest mistakes when we're up at 3 AM pounding on our keyboards. So quality takes a hit. Shoot. Well, OK. What about life? Use up a little bit of life to get this out the door. This, this is the path to burn out. To depression. Use it very sparingly. Use it wisely. Think to yourself, is this more important than cleaning up after my dog? Is this more important than spending time with my kids? Depends on how much you like your kids, right. Just be careful. That's all I can say. All right. Let's talk about one more of the Dark Arts. Deadline hardening. This is the magical thing. Whoops. I don't want to show this to you yet. I gotta tell you about it first. Because, here's what I love about this one. It happens to us all the time, and every time it does, we're like, totally surprised that it happened. We're like where? Where did that come from? And I'm like, what? Didn't this happen to you last week? Or yesterday? All right. Here's roughly how it goes. Somebody comes up to you and they're like, hey, let's try to release by the end of the month. And you're like, um, I don't think we can actually do that. But I'll try. OK, and you go back to your keyboard really quick, right. You know. Clock spins. Pages fly off the calendar. Eighties work montage. All of a sudden, manager comes back and they're like, hey, we need to release by the end of the month. And you're like, wait, what? Why? Why do we need to release by the end of the month? And they're like, we've got customers waiting on it now. It's like, what? Why, why did you promise that to them? And I'll tell you why. They heard you say that you were going to try to do it by the end of the month. Now, I know that what you said, in your head, was hey. Get out of here. I know that what you said was, leave me alone, I gotta code. I know that what you said was, I don't see you. But what they heard is, I'm on it. It's a bit of wishful thinking on their part, but it's true. Look, don't commit to making any deadlines that you don't think that you can meet. And saying that you'll try is committing. Look, people are less likely to turn a goal, a soft deadline, into a promise, a hard deadline, if they think it's risky. When do they think it's risky? They think it's risky when they know that there's uncertainty. They know it's risky when they know that the amount of work that you've got to do is large. And that you're likely to go over the deadline. So, communicate your status and risk often. Communicate uncertainty. If you take nothing else away from this, communicate. Make sure that other people understand what your view of the world is right now. Because if you don't, that's how you're gonna end up with unreasonable estimates and. The other thing in my title. I can't remember it. Awesome. That's my talk. You guys have any questions? Wait. Clap first.