Subscribe
Share
Share
Embed
Today, Jason Fried and David Heinemeier Hansson, the co-founders of 37signals, discuss their chapter in Rework on why estimating is not the road to completing projects and what has helped them get things done in their business for over twenty years.
Show Notes
"Getting out of estimates and getting into appetites and budgets is the single most important thing that we have instituted," - David Heinemeier Hansson
Today, Jason Fried and David Heinemeier Hansson, the co-founders of 37signals, discuss their chapter in Rework on why estimating is not the road to completing projects and what has helped them get things done in their business for over twenty years.
Show Notes:
[00:42] - David shares why it's time to accept that we're awful at estimating.
[03:27] - Why estimating is 'an amazing example of the human optimism to overcome its own fundamental flaws in a way that's just wholesomely unrealistic.'
[05:49] - Jason asks how much you are willing to spend (or lose) in gambling (and software development projects).
[08:13] - The worst situation to be in for rational decision-making.
[09:00] - Why it's vital to stick to your limits.
[10:29] - "Getting out of estimates and getting into appetites and budgets is the single most important thing that we have instituted as a barrier for our software development process over all these years."
[12:47] - In software development, no one—from the owner of the company to the end user—gets everything they want; staying within your parameters is about trading concessions.
[14:15] - You need to keep the engine moving because software development is like baking bread on an industrial scale.
[16:19] - You produce what you practice.
[16:57] - You don't cut corners or quality, you cut scope, and if you can't, you scrap the project.
[18:15] - Losing the right things prevents you from missing out on other opportunities.
[19:48] - Forecasting the next ten years, six weeks at a time.
[20:33] - Shortening planning cycles improves your ability to determine your next steps with more accurate information.
[21:15] - 'We're making a ton of progress with a small team with a product that's been around for 18 years - so it works!'
[23:21] - Why keep doing things that don't work?
Creators & Guests
Guest
What is Rework?
A podcast by 37signals about the better way to work and run your business. Hosted by Kimberly Rhodes, the Rework podcast features the co-founders of 37signals (the makers of Basecamp and Hey), Jason Fried and David Heinemeier Hansson sharing their unique perspective on business and entrepreneurship.
Kimberly (00:00):
Welcome to Rework a podcast by 37signals about the better way to work and run your business. I'm your host, Kimberly Rhodes. It's been said many times before on this podcast that as a company 37signals works in six week cycles. Each team plans what they're going to accomplish over the course of just six weeks and with the final cycle of the year upon us, I thought it made sense to dive into a chapter of the book Rework called "Your Estimates Suck." To talk about it, I'm joined by the co-founders of 37signals and the authors of Rework, Jason Fried and David Heinermeier Hansson. Guys, I assume when you say your estimates suck, that's not just when it comes to software development, but across the board in business. True?
Jason (00:40):
David, you wanna take this one? I know this is sort of your...
(00:42):
David Yeah, I think it's just been proven over and over again that humans are terrible at estimating anything complicated that involves novel attempts at problem solving. If you know exactly what you're gonna do, it's somewhat easier, but I'd actually say even then it's hard. I mean, construction is a great example. We've been building houses for a very long time and yet still, somehow it's quite difficult to hit an estimate unless you're building a cookie cutter thing that you've done exactly the same thing five times before or 10 times before, then your estimates might be closer. But if you're trying to do anything novel at all, anything that involves new problem solving, you just gotta accept the fact that we are awful at estimating. And the way I remember this from the early days of the company is really funny because I remember trying really hard to get better at estimating that, you know what the problem with estimates were just that we weren't trying hard enough that we didn't have the right scheme of doing it.
(01:42):
If we just broke tasks down better and, and were more specific in our estimation, or maybe if we applied a a more generous margin, we timed 1.2 or 1.5 or one point or two to our estimates, it would come out just right. And we actually did that in the early days of even creating Basecamp because when we were creating Basecamp, I had 10 hours a week and I remember thinking, do you know what? We gotta really make those 10 hours count. So if we want the different things, we should have a good idea of how long it's gonna take. And again, and again and again and again and again, we just learned the lesson, it is impossible. You might be able to accurately estimate one part of the piece you're trying to solve, but then you forget about the five you hadn't thought of yet that you run into.
(02:25):
You realize, Ooh, we're gonna need that, aren't we? Because it's novel, because it's new because you're solving a fresh problem that hasn't been solved before. You just can't get it all there. You can't design it all up front. And I think that sense of, um, just frustration that why can't we crack this nut eventually led to our breakthrough? Why are we trying to solve this problem that we have shown absolutely no capacity in human history of being able to solve? Are we really gonna be the first ones that solve the problem of estimation? Especially in software where even when we got started, there was a 40 year history of establishing that the sort of industry was basically a long series of large projects that got canceled because they ran overtime at budget. So this idea that here are we starting out in software and like, yeah, we're not that good at it now, but if we just practice real hard, we will crack it in a way that no one has ever cracked before, which is delusional.
(03:27):
And what I found so funny about that at the time was reading a lot of this, um, software methodology thinking and how to estimate and how to break things out. Everyone was trying. Literally no one had it cracked, but everyone was like, no, no, no, we got it. Like we just need a little tweak on the methodology and then for the next project we're gonna nail it. And of course they didn't. Right? It's an amazing example of the human optimism to overcome its own fundamental flaws in a way that's just wholely unrealistic, never gonna happen. And that's why we finally gave up and canned the estimates. And these days we just don't estimate. Not in any precise sense, not in any binding sense. What we do instead is we, we work with budgets, which is also actually funny because this chapter of Rework is one of the few chapters where the fundamentals really move forward. In 2010, we did not have the, the specific nailing of how we were gonna do it. That came with Shape Up. Um, our, our software methodology that we refined, we were refining over these years and we were trying to figure it out. Um, but it really didn't get crystallized until we had experimented a thousand different ways and ended up with this six week cycle, uh, setup that we've now run for quite a few years. And we document it in in Shape Up. That's at uh, basecamp.com/shapeup. So yeah.
Kimberly (04:48):
Okay. So you said we don't use estimates. Instead what do we do?
David (04:52):
We use budgets or we use appetites as we call it, in Shape Up, where we say, do you know what? We have a rough idea here that a version of the problem we're trying to solve a solution to the problem we're trying to solve can be done in this amount of time. Do you know what, there's three weeks here for us to solve this project and we're not specifying specifically what the project is. It gets this rough sketch outline of what the problem is and how we want to go about tackling it, but this specific scope, like what the screen should be or how we implement it or even whether we implement all of it or not, is left open in such a way that we can deliver something, not just something, something good in the amount of time for the appetite, which is just flipping it on its head. Don't tell someone or don't ask someone. How long is it gonna take to get exactly this? Say you have three weeks to make a great version of that.
Jason (05:49):
Yeah. One way to think about it is, um, let's say you're going to Vegas and you're gonna go gamble. The smart way to do this is to say, I'm willing to lose $500. Like that is it. I'm gonna bring 500 bucks with me and if I lose 500 bucks, I'm out. Versus saying how, like what's your estimate of how much you're gonna lose? Hmm. Well, I don't know. And so you don't have a limit and you just keep losing and losing and losing and losing and losing and then you try to make it back so you double down. And this is how software pro projects work too. It keeps going and going and going and now you've got so much built up that you, you can't give up now because it'd be a huge waste of time. And the whole thing, the sunk cost up.
(06:26):
So it's like, I've got 500 bucks, I'm gonna spend 500 bucks on myself and have entertainment this weekend. I might lose it all. That's how much I'm willing to lose or willing to spend. I shouldn't even say lose because you're spending it on entertainment. If you go to a restaurant and you get dinner and it costs you $85, you don't say, I lost $85. You say I spent $85 on food. And if you go gamble, you spent whatever, 500, whatever you spent on that, that's how we look at it. And so what are we willing to spend on this problem and different problems get different or have different appetites. Some small little thing is not worth spending six weeks on some big thing might be worth spending six weeks on. This thing might be worth spending a week and a half on. That's all we're willing to spend on it. So that's how we, we think about it and hopefully that sort of metaphor helps people think about how they could plan their software development projects is what are you willing to spend on this feature? What's it worth to you?
David (07:24):
I love that. And related to that, there's also the metaphor of the stop loss. If you're in the stock market and you're like, do you know what if this stock, I I bought it, uh, what a hundred, if it goes down to 80, I'm out, I'm done. I'm willing to spend 20 bucks on, its on its way down, but then I'm out. Gives you a sense of discipline where you don't end up in this like, shit, I gotta make it back. Which is, as Jason says, just as common in software development as it is in gambling of all kinds. It is so common that someone will reach the end of their estimate and they'll go like, no, no, no, we're 90% done. We're 90% done. We just need the last 10%. Yeah, except there's another 90% worth of effort in those last 10%. And you're gonna end up keep chasing those and you're gonna feel worse and worse about it just like a gambler would trying to win back what they lost at the table, right?
(08:13):
Like you just start feeling worse and worse, but you feel like you cannot give up now. And that is absolutely the worst position possible to be in if you're trying to make rational logical decisions about how to spend your resources, is to be in this state of like, I gotta dig myself out of this hole. Well, do you know what the first move stop digging, stop digging. So this stop loss is actually something we end up hitting occasionally at, um, at 37signals as well. Occasionally we'll have a thing where we'll hit the stop loss and we just go like, well, we gave it four weeks and it's not, it's not gonna be there. We're not that close to it either. And okay, that was, that was an, an investment in part in our discipline to be able to stick with this, right? Because that's the other thing.
(09:00):
If you have a software methodology like this and you're broadcasting to the entire team that you know what, the limits aren't actually the limits, eh, we can just like, eh, we can just keep pushing and if there's something sort of falls out of it, we'll just give it another cycle. We'll just give it another six weeks. No one's gonna believe that these limits are actually the limits and then it all just sort of falls apart. So you have to have the intellectual honesty to stick to your guns on this and just say like, you know what? This is what we're willing to lose. And when when that's out, we close the position up, we may return to it. And I mean just to illustrate how hard this is, is the number of times, I mean we've been running this operating system for how we developed for quite a long time.
(09:43):
Rework came out in 2010, I think Shape Up really started taking its recognizable final form and how we used it maybe a few years after that. So we've been running that methodology for a good 10 years. But even so, um, just a few months ago we, we had a, a project I think we might even have talked about on the podcast before with this my side project that Jason even demoed. Um, we showed it to customers before it was ready to ship and as us, we felt, we hung ourself up on the expectations that like it's gotta go out right? And we just, we blew through our stop loss and then we said another stop loss and we blew through that too, right? This is the thing, these estimates and the revised estimates, if you revise your estimates once, you're gonna be pretty damn sure you're gonna revise it twice, three times, four times, five times, right?
(10:29):
It becomes this never ending screw. And it's very rare that even if you end up making the final set of estimates that you're gonna feel good about it, that this was a good use of time. So I'd actually go as far as to say that flipping it on its head, getting out of estimates and getting into appetites and budgets is the single most important thing that we have instituted as a barrier for our software development process over all these years. I cannot point to another single fact that really is as influential in keeping us on the narrow track of shipping good software that doesn't grow too large. And for us not to get into these mega projects that swallow all your motivation and spirit. Because this is of course the other thing, right? Like if once you've been working on something that that feels overdue and feels late, um, you're just so inclined to end up in a death march.
(11:17):
Like the software industry is renowned for its endless death marches and some branches of the software industry. It's even worse. Like in game development is on someone just be churning they're working 12, 14 hour days for weeks or months on end all because someone missed some estimates. And I think that's the other part of it. What does that mean to miss some estimates? What it means in a lot of companies is you did a poor job. That was your estimate. That was the thing you said, you said it was gonna take four weeks, we're at four weeks. Where's the thing? And you're like, uh, I don't know, I didn't uh, what? It's that you, that's the creative process. No one has the capacity to be able to estimate accurately at four or six weeks. That is just not within our human powers. Yes, we take it on as a human burden to feel embarrassed by the fact that we couldn't hit our estimates to feel ashamed that we didn't hit our estimates and then feel like we have to double down on it. And that whole cycle, especially as it goes between an individual contributor, a programmer, a designer and their manager, it's just like everything that's awful about software development, like half of it lives in that scope on the estimate um, front.
Kimberly (12:30):
So this kind of sounds opposite of what I assume a lot of people are doing. They're setting like this is what we wanna have accomplished and then trying to figure out how long that will take. But we're taking features sometimes out in order to meet a date or meet a how long we're willing to work on it.
David (12:47):
I think this works really well when you have the humility to accept that you're not gonna get everything you want. That's just like who gets everything they want? No one gets everything think they want in, in software development, the customer doesn't get everything they want. The programmer doesn't get everything they want. The owner of the company making the software doesn't get everything they want. Accept that fact. Accept the fact that like you know what? You have all these wishes, you have these inspirations, things you'd wish to be true and software you wish that exists and then you start building it and you learn something. You learn this takes longer than you thought. I was gonna say that this takes shorter than you thought. That's a rare one. It's usually it takes longer than you thought and then you realize, you know what, I gotta give something up.
(13:30):
I gotta trade here, I gotta trade. We like to call it trading concessions. I gotta trade the fact that like I cannot make it all happen within the three weeks. You outlined all your hopes and dreams here, but we're gonna have to take a knife and we're gonna cut to it. So there has to be that level of trust between the people working on it and the people asking for it, that we will come up with something good. It won't be perfect, it won't be great, it won't be everything you wanted. But if we can consistently ship good things inside these time boxes we call appetites or budgets, you know what? That's a really repeatable process that's gonna increase the trust between us. We work in these six week cycle and Jason, I mean I'd be surprised if you felt otherwise virtually all the cycles this year.
(14:15):
I look back on it at the end of the cycle and I go hot damn. We built a lot of stuff. We really made the products significantly better. Both of them at once. Both Hey and Basecamp. Wow, they got better. Even if you look into it and you look at each individual product and you go like, do you know what? They all left something on the table. They all left something. They all, there's all always, whenever we finish a a cycle work on a project, there's always to-dos left. There's always like five things, Hey here's the things we could have worked with, but you know what? It doesn't matter the grand picture that we are machine to create software and the continuity of that machine is super duper important. I remember reading about these, um, how you bake bread at an industrial scale, like uh, thousands of pieces of bread, right?
(15:06):
And the most important thing for that oven is to keep it going. It literally takes weeks to get it going and get it started again. And I feel like software development has a lot of those qualities to it. You need to keep the engine moving and you need to move things off the conveyor belt if they're blocking it. And then you need to put something on there. It's just that you get this cadence and you get this rhythm that you are shipping stuff. Nothing will clog down the momentum and motivation of a software development team as not being able to ship and nothing will prevent you from shipping, like having projects that continuously get pushed out because you wanna have all your hopes and dreams happen inside of them. And you said the the estimates were gonna happen and of course they were wrong. So now we end up like we're on month three or month six on something that we thought was gonna take two months and the whole thing has just cooled down. You've lost your capacity to ship, you've lost your capacity to to move over and do something else, which is just super duper dangerous. Do not shut down the oven, keep the oven going. There's no single piece of bread that's worth shutting down the whole oven for. There's no single feature in a product like hey or base chem that's worth backlogging everything else for move it off the table.
Jason (16:19):
Another way to think about that is that you're always practicing something and if you practice being late over and over and over and over, you're gonna get good at being late and that's how you're gonna work. Uh, if you get good at shipping, which is what we are good at, you ship and that doesn't mean cutting corners or anything like that. You know you have to ship really good stuff, but you're gonna practice something. I think what ends up happening is as companies are always late or perpetually late or keep putting more time after bad time or whatever, that's just what you keep doing cuz that's all you know how to do and you actually unfortunately get really damn good at it. That's sort of the problem.
David (16:57):
We are what we keep doing. And I think that that's, that's just the, the, the factor of it, right? That you have to get into doing the shipping thing And it's, I mean it's funny when I compare it to lots of other people who work in software and our shipping ratio is incredibly high, but everything we ship has compromises in it and part of that compromise just comes from like, do you know what? We're gonna ship something good, not gonna be perfect, that's gonna have it all. But as Jason said, it's also important to not hear this and think the thing, well just shipping that's the most important thing. Therefore cut quality, cut, um, quality control just like whatever. Just push it out there at all costs. Absolutely not. The thing you cut is scope and if you have to cut too much scope, you cut the project, you don't do the do the project. I mean again, as I say, even though we ship a lot, we've also canceled quite a few projects as a ratio of the number of projects shipped. It's a small ratio but it's important that it's there. It's part of keeping the system integral.
Kimberly (18:00):
I think it's interesting that your philosophy is cut the scope and not just put in more hours. Cause I think that's probably where a lot of businesses are coming from is just the cram, like cram for the test to make sure that it gets done by a certain date. But that's clearly what you guys are not doing.
Jason (18:15):
You know what that is is that you're gonna, again, just like you're always practicing something, you're always losing something too. And I think the way we look at it is if we keep pouring more time into this thing, we're losing other opportunities to do a bunch of other things and you're better off losing just that one thing and getting to a bunch of other things than getting stuck behind this one thing that probably wasn't worth it in the first place. So, you know, you just have to choose your losses.
David (18:39):
It's such a negative feedback cycle too because if you end up continuously shipping late, you create more uncertainty in the people who are deciding what we should work on because they have to get everything in now because they're not gonna have another shot at this perhaps for a very long time cuz you're gonna go off de wilderness and who the hell knows when you'll be back. We put a premium on the fact that every six weeks we get to decide again and we make new decisions at those six weeks. And the fact that we continue to get that opportunity to change our mind is what gives us the confidence to sit on our damn hands while the cycle is running, while the oven is bacon. We won't constantly be peeking inside. Ooh, is it hard enough or is it swollen? No, keep the damn oven shut six weeks, enjoy the bread.
Kimberly (19:31):
Okay, so on that same note since we're talking about these six week cycles, tell me about forecasting. I know that a lot of companies are planning like a year in advance or two years in advance. We're talking about just six, six weeks. How does that help with estimates and appetites and all of that?
Jason (19:48):
I would say that we, we plan 10 years, six weeks at a time. everyone plans something so you can plan 10 years, one at a time basically over the next 10 years or you can get there gradually as you go. And so we're just, we're coming up for air constantly and looking around and deciding where to go next. And we're not like whip lashing, it's not like we're, I think people assume that if you, if you do it this way, you have no idea what you're doing. That's not the case at all. We have a a direction roughly that we're headed and then we course correct all the time. We open our, we leave ourselves open to to, to changing directions if we need to. We leave ourselves open to taking three steps the left instead of one or whatever it might be, right? You can make these adjustments as you go.
(20:33):
But um, this gets back to something David was saying is that since we're all bad estimators in general, how can we possibly know or we want to even be in five years or where we want to go in five years. The best information you have is the, the information that's the most current information. Like I know more about what's gonna happen today than I do next week, obviously don't we all, I mean probably like we have in front of us what's in front of us, what we can probably look at that and make an assumption about where we're at. So by, by shortening these these sort of planning moments or times or or periods of time, you just have more accurate information on which to make your decisions about where you wanna go next. Like why wouldn't you do that? It just baffles the mind.
(21:15):
Now our boggles mind of course again we're not building airplanes here or we're not building, you know, medical systems where people are gonna die. All the stuff that people always come up with these examples like we're making software and um, we can make choices along the way and this is a malleable thing and we don't need to ship anything physical. So you must take advantage of that situation and our approach takes full advantage of the fact that we just don't know, but we'll find out as we go and then we'll make calls as we go and the product, you know, like the results are there, we're shipping great things within every six week cycle. The products are getting better all the time, both Basecamp and Hey and uh, we rarely miss, sometimes we do but we rarely, rarely miss things and we rarely have to throw them out and we're making a ton of progress with a small team.
(22:02):
This works really, really well and we've been around for 23 years as a company. It's gonna been around for 18 years as a product. Hey's going on the next few years or it's been on a couple years so far and going forward of course, so like it works, it works really, really well for us. And if you talk to other people who've come from other companies, so we hire people, they come from other companies, they're shocked by the amount of stuff that we actually are able to get done in a reasonable bond on time without, you know, driving everyone into the ground. And it's because the way we do it.
David (22:30):
And I think a lot of that comes to just compare, are you happy with the way you're shipping software? Are you hitting your roadmap that you planned two years ago to the dot and all everyone is just cheering and everything is shipped fine. Keep your process. I mean that's wonderful. Congratulations. I think you should be written up for just an amazing outcome. That is not something that is generally seen in this industry, but if you are curious to have a process that feels like it's cutting with the grain of human nature, that's what shape up is. That is what giving up on estimates is that sometimes we just have to accept our fallacies as humans, the things we're good at that fall, right? To what we can do really well. Um, getting something good done within a, a finite space within constraints. You humans pretty good at that.
(23:21):
You can drop a lot of people into that kind of box and say you have three weeks to do something good. And at the end of that three weeks they'll be like, ah, I'm almost done. I'm almost done. But they'll have something done versus if you say like, Hey build this exact box to these specifications and by the way, here's like 50 unknowns. How long is it gonna take? Yeah, the history of the human race and certainly of software development is like, they will fail. Why would you sign up for that? Don't keep doing things that don't work? That is like fundamental insight of progress, right? Just stop doing the shit that's broken that does not work, that's producing the bad results and try something else.
Kimberly (23:58):
I love that. Well I think we should wrap it up there. That's perfect. Rework is a production of 37signals. You can find show notes and transcripts on our website at 37signals.com/podcast. You can also find us on Twitter @reworkpodcast. And in case you haven't yet checked it out, you can learn more about the 37signals, programmers and ops team, what they're up to at their new technical blog. You can find that at dev.37signals.com.