Talks
Unreasonable Estimates and Improbable Goals
Summarized using AI
Unreasonable Estimates and Improbable Goals
by Adam SandersonIn the video titled "Unreasonable Estimates and Improbable Goals," Adam Sanderson, a full stack Rails developer at LiquidPlanner, discusses the critical aspects of project estimation and the challenges developers face when asked about the difficulty of a task. He highlights the importance of accurately understanding project requirements, considering hidden costs, and managing constraints effectively.
Key Points Covered:
- Clarification of Requirements: Sanderson emphasizes that developers often get vague inquiries like "How hard would it be to..." and suggests clarifying what the requester truly means, ensuring both parties share the same understanding.
- Understanding the Project's Why: It's important to ask why a feature is needed, as it could lead to alternative solutions and saving development time.
- Estimating Effort: Sanderson encourages developers to break down tasks, recalling experiences with similar issues, and making informed guesses about time and complexity, acknowledging that estimates should allow for uncertainty.
- Communicating Uncertainty: He advises developers to communicate any uncertainties at the outset, to avoid unpleasant surprises later in the project timeline.
- The Dark Arts of Project Management: Sanderson warns against common pitfalls, such as estimation bargaining and ego manipulation. Developers should stick to their estimates, as reducing them under pressure can lead to unrealistic outcomes.
- Managing Hidden Costs: Features sometimes impose future complexities that require additional considerations. Sanderson highlights types of hidden costs including operational, support, and opportunity costs, suggesting that developers factor these into their estimates.
- Prioritization and Deadlines: He discusses the necessity of recognizing soft versus hard deadlines and how developers should handle them appropriately, whether it be cutting scope, adding resources, or finding alternatives when a deadline cannot be met. Sanderson asserts that communication is key throughout this process to prevent misunderstandings and ensure successful outcomes.
In conclusion, the takeaway from Sanderson's presentation is the need for clear communication, thorough understanding, and realistic estimation in project management, which can translate to better project outcomes and less frustration for developers and teams alike.
00:00:16.800
All right folks, this is Unreasonable Estimates and Improbable Goals. My name is Adam Sanderson, and I'm a full-stack developer at LiquidPlanner. I've been there for about six, almost seven years, working on Rails and databases—front end, back end, you name it. If you want to, you can find me on GitHub or Twitter. These slides are going to be on Speaker Deck under Adam Sanderson, so that makes it easy.
00:00:22.320
A bit more awkwardly, I write code or I write about code on MonkeyCrow.com. If you like talks about reading and learning about Rails, I'm writing a series called Reading Rails, so go check that out if that's what you're into. And hey, it's RailsConf; you probably are.
00:00:28.640
As I mentioned, 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. 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.
00:00:39.520
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? That sounds like life. All right, how hard would it be? I get asked this question all the time; people come up to me and say, 'Hey Adam, how hard would it be to change all of our buttons from red to blue? How hard would it be to implement a new class of user? How hard would it be to implement email integration?'
00:01:00.320
What should I do? Clarify. Before I tell somebody how hard it would be, and pro tip: they don't care how hard you think it is. What they're actually asking is how long is it going to take you to get this done. Before you tell them, clarify. Make sure you know what they want. Ensure that what's in your head is what's in their head, because a lot of times when people come to us, they have a very specific vocabulary, and the things we think mean one thing may mean something different to someone in sales, marketing, QA, or support.
00:01:19.200
So make sure that you know what they mean when they say, 'Hey, how hard would it be to implement email integration?' Does that mean sending emails out of our system? Does it mean receiving emails from someone else? Does it mean a plug-in for Outlook or Gmail? If you don't clarify upfront, you could spend a lot of time wandering off into the woods. When you come back with your amazing feature, they're going to look at it and be like, 'What is this?' You'll have just wasted an hour, a day, a week; oh, that's going to suck.
00:01:43.440
So, clarify. Look, you know what you're doing. Now you've got to figure out why you're doing it. Ask them, 'Hey, why do you need me to implement email integration?' Maybe they turn around and say, 'Well, we've been getting a lot of customer screenshots, and it'd be nice to just be able to email those into the system.' Does a better 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.
00:02:01.199
Maybe they turn around and say, 'Yeah, I know that exists, but it's kind of a pain to use.' Well, now maybe you've found out 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 going to do that,' to say, 'Wait, why do you need me to do that?' Maybe you can help them come to a better solution.
00:02:20.560
By doing this, you're going to 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 going to be, how long it's going to take you. I want you to think about the major pieces of work that you're going to 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.
00:02:40.400
Is it going to require a lot of database work? Think about the tables. Is it going to require a lot of work in Rails? Think about your models, your views, your controllers. Is it going to 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 them down. You're going to need to refer back to this later anyways. This is what you need to do in order to service their request.
00:03:02.000
Next, sometimes it can be overwhelming to get some of these asks from people. You'll find that they have so many business rules and details they want to impart; it can make it really hard for you to see the forest for the trees. Step back for a moment, and try to 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 just has to be enough for you to understand what direction to be going in. Again, write this stuff down; you'll need it later.
00:03:22.000
All right, you've broken stuff down, you've grouped stuff back up; it's now at 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 things twice, and if we do, we're probably doing it wrong. If you can think about similar things, even if you haven't, turn and ask one of the other developers in your company. Maybe they've worked on this code before, or maybe they've dealt with this type of issue before.
00:03:44.400
They can help you get a better estimate. 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 why. This is awesome because it turns you around and makes you be the person who is asking for work. It's really helpful for clarifying what you need to do now. There are dozens of different methodologies and approaches to estimation, but here's what I want you to do: make a guess. That's it.
00:04:03.200
I know you could play planning poker; you could do all number of things, but just make a guess. Here, I'm going to make it flashy—there, isn't that awesome? Seriously, look, an estimate is just an informed guess. A lot of times, we put way too much value on an estimate. It's okay for you to be wrong, and it's okay 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.
00:04:22.800
Are there things that you're being asked to do that you don't know how they're going to turn out? Maybe you have to load a whole lot of data into the database, so you're not sure if it's going to handle that. Maybe you've got to make some flippy clicky thing that's going to be hard to implement in Internet Explorer 8. Do you know how that's going to 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 going to impact our database.'
00:04:47.200
Say, 'I'm not really sure whether IE8 is going to 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, or if I need to do something really crazy to get this supported cross-browser, this could take me four weeks.
00:05:04.800
Look, it's a lot easier for you to hit an estimated range than it is for you to give them one hard number. 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. If they've got that information, they can start making better use of that. They can plan better based on that, and it starts a better dialogue between you.
00:05:21.360
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. Okay, 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 11th hour.
00:05:33.840
Oh man, are you going to be ever so happy when your fellow developer says, 'Hey guys, I know we're going to ship, but I just checked the clicky flippy thing in IE8, 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 is going to take a long time, you can communicate that back to people, and you guys can adjust your plans to accommodate that.
00:06:02.960
I know we always want to do the fun things first. I want to jump in and do the things 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; 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 going to take.
00:06:22.720
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 going to 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 cute, we can get screwed as developers.
00:06:43.400
We think that we're logical and sane. Now, has this ever happened to you? It happens to me all the time. Somebody comes up to me and says, 'Hey Adam, how long is it going to take?' I say it's going to take about three weeks. They say, 'Look, we need this done really quickly. Could you maybe do it in one?' I say, 'Um, well, oh, uh, how about two weeks?'
00:07:01.760
I thought I was just being nice; I thought I was splitting the difference, right? Wrong. I just screwed myself. It's natural for people to haggle, but you don't win when people are estimating or bargaining over estimates. Look, your 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? Because I want to know.
00:07:20.160
So, you come up and tell me no; look, you can't negotiate time, but you can negotiate features. As you learn more about the project, you can re-estimate more or less. Don't give people estimates that you think are going to 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.'
00:07:39.360
I see what you're doing: estimation bargaining. It's not going to work. Not only is it not going to work for me; it's not going to work for you. If you give into this kind of thing, you're actually setting not just yourself up for trouble, but your team, the people who rely on you. 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.
00:07:58.560
So, you know what you're doing—you know why you're doing it. You've got an estimate; you've defended it. Awesome! 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 costs on all the future work that we do.
00:08:17.440
For instance, if you build a new RESTful API, great idea. If you build new access controls or drop in CanCan, or if you build a new 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 self is going to hate your past self.
00:08:33.680
You're just incurring new costs for the future. So watch out for these cross-cutting concerns; they can really bite us sometimes. Now, there are ways to do this that are going to cut down on those costs; you can never get rid of them entirely, but if you want to do the extra engineering upfront, factor that into your original estimate. Let the people know that you're going to need a little more time.
00:08:55.360
What about operational costs? Look, are you introducing new moving parts? Are you going to build a new job queue? Are you going to throw Rescue and Redis in place? They're awesome tech, but guess what? They're costly. How are you going to test this in production? How are you going to monitor it? How are you going to deploy this? How are you going to make sure that it's running every time you spin up a new server?
00:09:14.080
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 Rescue goes down, who are they going to call? They're going to call you; you're the one that put it in place, right? So dealing with that is going to take more time out of what you consider to be your budget for development. Support costs—these are important.
00:09:35.920
There are a lot of things that we can do as developers that are 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? You've built this awesome thing, and they've got no clue what it does. Who are they going to talk to? Well, if you've got one, they're going to talk to your support team. I hope your support team understands; if they don't, awesome, your support team is now talking to you.
00:09:51.040
And that takes time that you're not going to be able to use for development. What if your business as a whole doesn't get it? Well, that means meetings, and you know what meetings mean: it's not just your time that's being used up. Then it's your entire company—everyone around that table. You're sinking more and more costs into this.
00:10:09.440
So again, you can combat some of this, but go back and update those estimates to factor this in. What about opportunity costs? A 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 or your business as a whole? Because whatever you're doing now is excluding every other feature that you could be working on.
00:10:23.680
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.
00:10:45.080
All right, more dark arts, because 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 happened to you; somebody comes up to you and says, 'Hey, how long is it going to take?' You say, 'I don't know, about a week.' And they say, 'Really?' Oh, they look so disappointed. Then they say, 'I thought you were smarter than that.'
00:11:03.080
Oh, that hurts. It's like kicking you when you're down. They say, 'Oh, I'll go ask Carl. Go ask the intern; she seems pretty smart.' Even worse! You know what happens next. I don't know about you, but 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.
00:11:23.680
Oh, don't let your ego get you into trouble. Stand by those estimates. Really, the best thing we can be as developers in this case is to have a little humility. If you see somebody trying to do this to you, call their bluff. Look, they're not going to really 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 going to work on me.'
00:11:41.920
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 for the next conference.
00:12:00.560
Hey, we're going to try to get this out for the customer by Q1. Hard deadlines are things like RailsConf for me anyways. Can you imagine Ruby Central sending out an email saying, 'Hey guys, funny story; Adam didn't do his slides, so I'm postponing RubyConf by a week. Just change your reservations.' Yeah, I'm not DHH, so I can't get away with that. It's a hard deadline.
00:12:19.440
So when hard deadlines come up, actually, when all deadlines come up, what do we do? You've got to deal with it. Ignoring it isn't going to 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 they really like. Nobody really likes any of these options when you get down to it.
00:12:30.640
But if it's a soft deadline, if it's just a goal, you guys can ship late; you can miss it. Maybe it's not the end of the world. Don't do this all the time because you're going to look like an idiot, but recognize and weigh the balance of the things that you have to deal with. I don't know. This talk is about work, not about how to give a good talk.
00:12:54.960
So, yeah, sometimes you can ship late. Of course, there are hard deadlines—things like RubyConf. 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. Honestly, prioritize the things that you've got to do.
00:13:05.680
Figure out what you can get done by the deadline and cut the rest. For instance, I illustrated 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 aren't the things that we as developers think are important. Performance testing, correctness—all these things can get cut if you're not careful.
00:13:24.960
So if you value that, make sure that it's put high on your priority list. Make sure that you guard against the deadline. Another option: you're not going to get it done, you can't ship late, and you can't cut features. Well, you can add more people, right? Well, you could go read 'The Mythical Man Month', but basically it boils down to this.
00:13:49.440
Unless you've got a project where everybody can work completely independently, you're going to have to start talking to each other. 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 got to make sure that we aren't going to be stepping on each other's toes. We've got to keep each other appraised of the situation; we've got to understand which direction we're both going in.
00:14:11.680
That adds overhead, and if you're splitting up work between two people, then it means you're going to start depending on the other person to get things done. If I'm waiting on you, and I'm twiddling my thumbs, that's 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 going to make everything go more slowly.
00:14:31.680
Oh, and if you do add more people, make sure they get along, because nothing is more awkward than running up against a deadline working with somebody you want to punch. Like, this is how sparks fly; you don't want to do this. All right, the final way that you can deal with a deadline: if you can't get two people to do the work twice as fast, maybe you can make one person work twice as hard.
00:14:45.760
Oh, this really sucks, and I'll tell you why. It can honestly work, 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, 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 and family, for reading 17th century poetry.
00:15:08.800
Where's that overtime going to come out of? I've got a hint for you—it's not coming out of work. Bummer! Okay, your only two remaining options are sleep and what I would like to call life. If that time is coming out of sleep, you're going to be tired; you're not going to be very proficient. You're not going to be thinking straight; we make the stupidest mistakes when we're up at 3 a.m. pounding on our keyboards.
00:15:29.760
So, quality takes a hit. Shoot! Well, okay, what about life? Use up a little bit of life to get this out the door. This is the path to burnout, 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? It depends on how much you like your kids, right?
00:15:46.320
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. Oops, I don't want to show this to you yet; I got to tell you about it first. Because here's what I love about this: it happens to us all the time, and every time it does, we're totally surprised that it happened. We're like, 'Where did that come from?'
00:16:06.960
And I'm like, 'Didn't this happen to you last week or yesterday?' All right, here's roughly how it goes: somebody comes up to you and says, '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.' Okay, you go back to your keyboard really quickly, right?
00:16:27.840
You know the clock spins, pages fly off the calendar, 80s work montage. All of a sudden, a 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 do we need to release by the end of the month?' And they're like, 'We've got customers waiting on it now.' You say, 'What? Why did you promise that to them?'
00:16:48.800
And I'll tell you why: they heard you say that you're 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,' or 'Leave me alone; I've got to code.' 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 you can meet, and saying that you'll try is committing.
00:17:09.280
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.
00:17:28.920
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 going to end up with unreasonable estimates and the other thing in my title, which I can't remember. Awesome! That's my talk. You guys have any questions? Wait, clap first!
Explore all talks recorded at RailsConf 2014
+129