Vox

Leitura de 32 min

Your Estimates Suck

Summary

The episode explores the fundamental human inability to accurately estimate complex, novel work, particularly in software development. The hosts discuss how 37signals moved away from traditional estimation practices after years of frustration and failure, recognizing that the industry has a 40-year history of projects failing due to time and budget overruns.

Instead of estimates, the company now uses “appetites” or budgets—setting a fixed amount of time (like three or six weeks) they are willing to “spend” on solving a problem. This approach is framed using metaphors like gambling with a set loss limit or a stock market stop-loss. The key is to decide what you’re willing to invest upfront, then work within that constraint, cutting scope if necessary, rather than trying to predict how long a perfect solution will take.

The discussion highlights the importance of discipline and intellectual honesty in sticking to these time boxes. The hosts explain that occasionally projects hit their “stop loss” and are canceled, which is crucial for maintaining the integrity of the system. This methodology, documented in their book Shape Up, creates a repeatable cadence of shipping good (though not perfect) software every six weeks, which builds trust and maintains team momentum far better than endless death marches chasing unrealistic estimates.

They contrast this with the common industry pattern of revising estimates upward, which creates a negative cycle of shame, overwork, and delayed shipping. The episode concludes by framing their approach as “planning 10 years, six weeks at a time,” allowing for constant course correction based on the most current information and aligning with human strengths of working creatively within constraints.

Recommendations

Books

  • Rework — The book by Jason Fried and David Heinemeier Hanson that contains the chapter “Your Estimates Suck,” which this episode discusses.
  • Shape Up — Referenced as the methodology where 37signals refined their approach to using budgets and appetites instead of estimates. It’s documented at basecamp.com/shapeup.

Tools

  • Basecamp — One of 37signals’ products, mentioned as having been improved through their six-week cycle process.
  • HEY — 37signals’ email product, also mentioned as being consistently improved through their shipping cycle methodology.

Websites

  • dev.37signals.com — Their new technical blog where you can learn more about what the 37signals programmers and ops team are up to.

Topic Timeline

  • 00:00:00 — Introduction to the problem of estimation — Host Kimberly Rhodes introduces the episode’s topic from the book Rework: “Your Estimates Suck.” She is joined by co-founders Jason Freed and David Heinemeyer-Hansen. David immediately states that humans are terrible at estimating anything complicated involving novel problem-solving, using construction as an example where only cookie-cutter projects are predictable.
  • 00:01:24 — The delusion of cracking the estimation nut — Jason recounts the early days of the company, where they tried various schemes to improve estimates—breaking tasks down better, applying margins—but consistently failed. He describes the realization as delusional: thinking they could solve a problem that the entire software industry, with its 40-year history of failed projects, had never cracked. This frustration led to their breakthrough.
  • 00:03:57 — The shift from estimates to budgets and appetites — The hosts explain they gave up on precise, binding estimates. Instead, they now work with budgets or “appetites,” a concept refined in their methodology Shape Up. They decide how much time (e.g., three weeks) they are willing to spend on a problem, not how long a specific solution will take. This flips the question from “How long will this take?” to “What can we do well in this time?”
  • 00:05:51 — The gambling and stop-loss metaphors — Jason uses a gambling metaphor: going to Vegas with a fixed $500 you’re willing to lose (spend) is smarter than trying to estimate losses. David adds the stock market “stop loss” concept. In software, this means having the discipline to stop a project when the budget is spent, avoiding the sunk cost fallacy of doubling down to ‘make it back,’ which leads to death marches.
  • 00:09:38 — The necessity of discipline and intellectual honesty — David admits that even with a decade of practice, they sometimes blow through stop losses, as with a recent side project. He emphasizes that if limits aren’t real, the whole system falls apart. Sticking to budgets is the single most important barrier in their process, preventing mega-projects that swallow motivation and spirit.
  • 00:12:50 — Cutting scope, not quality, and trading concessions — Kimberly notes this approach is the opposite of trying to accomplish everything by a date. The hosts explain it requires humility and trust. You won’t get everything you want; you must “trade concessions” and cut scope within the time box. What you ship is good, not perfect, but shipping consistently within budgets builds trust and is a repeatable process.
  • 00:16:48 — Practicing shipping versus practicing being late — Jason argues that companies practice what they keep doing. If you’re always late, you get good at being late. 37signals practices shipping. They ship a high ratio of projects, but everything has compromises—they cut scope, not quality. If too much scope must be cut, they cancel the project, which is vital for keeping the system integral.
  • 00:19:34 — Planning 10 years, six weeks at a time — When asked about long-term forecasting, Jason says they plan “10 years, six weeks at a time.” They have a rough direction but course-correct constantly. Since humans are bad estimators, the best information is the most current. Short planning cycles allow for adjustments based on fresh data, taking full advantage of software’s malleability.
  • 00:22:24 — Results and invitation to try a different process — The hosts point to their 23-year company history and consistent shipping as proof the system works. New hires are shocked by how much gets done without burnout. David concludes: if your current process works perfectly, keep it. But if you want a process that cuts with the grain of human nature—working well within constraints—then Shape Up and giving up estimates is the answer.

Episode Info

  • Podcast: REWORK
  • Author: 37signals
  • Category: Business Business Management
  • Published: 2022-12-07T09:00:00Z
  • Duration: 00:24:19

References

Podcast Info

Transcript

[00:00:00] Welcome to Rework, a podcast by 37signals about the better way to work and run your business.

[00:00:04] I’m your host, Kimberly Rhodes. It’s been said many times before on this podcast that as a

[00:00:10] company, 37signals works in six-week cycles. Each team plans what they’re going to accomplish over

[00:00:15] the course of just six weeks. And with the final cycle of the year upon us, I thought it made sense

[00:00:19] to dive into a chapter of the book Rework called Your Estimates Suck. To talk about it, I’m joined

[00:00:25] by the co-founders of 37signals and the authors of Rework, Jason Freed and David Heinemeyer-Hansen.

[00:00:31] Guys, I assume when you say your estimates suck, that’s not just when it comes to software

[00:00:34] development, but across the board in business. True? Yeah, David, you want to take this one?

[00:00:41] I know this is for a year. Yeah, I think it’s just been proven over and over again that humans

[00:00:45] are terrible at estimating anything complicated that involves novel attempts at problem solving.

[00:00:52] If you know exactly what you’re going to do,

[00:00:54] it’s somewhat easier, but I’d actually say even then it’s hard. I mean, construction is a great

[00:00:59] example. We’ve been building houses for a very long time, and yet still somehow it’s quite difficult

[00:01:05] to hit an estimate unless you’re building a cookie cutter thing that you’ve done exactly the same

[00:01:11] thing five times before or 10 times before. Then your estimates might be closer. But if you’re

[00:01:16] trying to do anything novel at all, anything that involves new problem solving, you just got to

[00:01:22] accept the fact that we are all in this together. We’re all in this together. We’re all in this together.

[00:01:24] And the way I remember this from the early days of the company is really funny because I remember

[00:01:31] trying really hard to get better at estimating that. Do you know what the problem with estimates

[00:01:36] were just that we weren’t trying hard enough, that we didn’t have the right scheme of doing it.

[00:01:41] If we just broke tasks down better and were more specific in our estimation, or maybe if we applied

[00:01:48] a more generous margin, we time one point two or one point five or one point or two,

[00:01:54] to our estimates, they would come out just right. And we actually did that in the early days of

[00:01:58] even creating Basecamp. Because when we were creating Basecamp, I had 10 hours a week.

[00:02:03] And I remember thinking, you know what, we got to really make those 10 hours count.

[00:02:07] So if we want the different things, we should have a good idea of how long it’s going to take.

[00:02:11] And again, and again, and again, and again, and again, we just learned the lesson,

[00:02:15] it is impossible. You might be able to accurately estimate one part of the piece you’re trying to

[00:02:20] solve, but then you forget about the five you hadn’t thought of yet, that you run into,

[00:02:25] you realize, oh, we’re going to need that, aren’t we? Because it’s novel, because it’s new,

[00:02:29] because you’re solving a fresh problem that hasn’t been solved before. You just can’t get

[00:02:34] it all there. You can’t design it all up front. And I think that sense of just frustration,

[00:02:42] that why can’t we crack this nut eventually led to our breakthrough? Why are we trying to solve

[00:02:48] this problem that we have shown absolutely no capacity?

[00:02:50] In human history of being able to solve, are we really going to be the first ones that solve the

[00:02:57] problem of estimation, especially in software, where even when we got started, there was a 40

[00:03:03] year history of establishing that the sort of industry was basically a long series of large

[00:03:11] projects that got canceled because they ran over time and budget. So this idea that here are we

[00:03:17] starting out in software and like, yeah, we’re not that good at it now, but if we

[00:03:20] just practice real hard, we will crack it in a way that no one has ever cracked before,

[00:03:25] which is delusional. And what I found so funny about that at the time was reading a lot of this

[00:03:30] software methodology thinking and how to estimate and how to break things out.

[00:03:34] Everyone was trying. Literally no one had it cracked, but everyone was like, no, no, no,

[00:03:39] we got it. Like, we just need a little tweak on the methodology. And then for the next project,

[00:03:43] we’re going to nail it. And of course they didn’t. It’s an amazing example of the human

[00:03:48] optimism to overcome.

[00:03:50] We’ve gone fundamental flaws in a way that’s just holistically unrealistic, never going to happen.

[00:03:57] And that’s why we finally gave up and canned the estimates. And these days we just don’t estimate

[00:04:03] not in any precise sense, not in any binding sense. What we do instead is we work with budgets,

[00:04:09] which is also actually funny because this chapter of rework is one of the few chapters where the

[00:04:15] fundamentals really move forward. In 2010, we did not have the

[00:04:19] the specific

[00:04:20] nailing of how we were going to do it that came with shape up um our software methodology that

[00:04:27] we refined we were refining over these years and we’re trying to figure it out um but it really

[00:04:32] didn’t get crystallized until we had experimented a thousand different ways and ended up with this

[00:04:38] six-week cycle uh setup that we’ve now run for quite a few years and we documented in shape up

[00:04:43] that’s at basecamp.com slash shape up so yeah okay so you said we don’t use estimates instead

[00:04:50] what do we do we use budgets or we use appetites as we call it in shape up where we say do you

[00:04:57] know what we have a rough idea here that a version of the problem we’re trying to solve

[00:05:03] a solution to the problem we’re trying to solve can be done in this amount of time do you know

[00:05:07] what there’s three weeks here for us to solve this project and we’re not

[00:05:13] specifying specifically what the project is it gets this rough sketch outline of what the

[00:05:19] problem is and how we want to go about tackling it but this specific scope like what the screen

[00:05:24] should be or how we implement it or even whether we implement all of it or not is left open in such

[00:05:29] a way that we can deliver something not just something something good in the amount of time

[00:05:35] for the appetite which is just flipping it on its head don’t tell someone or don’t ask someone how

[00:05:41] long is it going to take to get exactly this say

[00:05:43] you have three weeks to make a great version of that yeah one way to think about it is um

[00:05:51] let’s say you’re going to vegas and you’re going to go gamble the smart way to do this is to say

[00:05:55] i am willing to lose five hundred dollars like that is it i’m going to bring 500 bucks with me

[00:06:00] and if i lose 500 bucks i’m out versus saying how like what’s your estimate of how much you’re

[00:06:05] going to lose hmm well i don’t know and so you don’t have a limit and you just keep losing and

[00:06:11] losing and losing and losing and losing and losing and losing and losing and losing and losing and

[00:06:13] you try to make it back so you double down and this is how software projects work too

[00:06:18] it keeps going and going and going and now you’ve got so much built up that you you can’t give up

[00:06:23] now because it’d be a huge waste of time and the whole thing the sun cost up so it’s like i’ve got

[00:06:27] 500 bucks i’m going to spend 500 bucks on myself and have entertainment this weekend i might lose

[00:06:32] it all that’s how much i’m willing to lose or willing to spend i shouldn’t even say lose

[00:06:37] because you’re spending it on entertainment if you go to a restaurant and you get dinner

[00:06:42] you’re going to lose a lot of money and you’re going to lose a lot of money and you’re going to

[00:06:43] 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

[00:06:51] spent whatever 500 whatever you spent on that that’s how we look at it and so what are we

[00:06:58] willing to spend on this problem and different problems get different or have different appetites

[00:07:04] some small little thing is not worth spending six weeks on some big thing might be worth spending

[00:07:09] six weeks on this thing might be worth spending a week and a half on that’s all we’re willing to

[00:07:13] spend on it so that’s how we we think about it and hopefully that sort of metaphor helps people

[00:07:18] think about how they could plan their software development projects is what are you willing to

[00:07:22] spend on this feature what’s it worth to you i love that and related to that there’s also the

[00:07:27] metaphor of the stop loss if you’re in the stock market and you’re like you know what if this stock

[00:07:32] i bought it at what 100 if it goes down to 80 i’m out i’m done i’m willing to spend 20 bucks

[00:07:39] on its on its way down but then i’m out gives you a sense of discipline where you don’t

[00:07:43] end up in this like shit i gotta make it back which is as jason says just as common in software

[00:07:49] development as it is in gambling of all kinds it is so common that someone will reach the end of

[00:07:54] their estimate and they’re like no no we’re 90 done we’re 90 done we just need the last 10 yeah

[00:08:01] except there’s another 90 worth of effort in those last 10 and you’re going to end up keep chasing

[00:08:07] those and you’re going to feel worse and worse about it just like a gambler would trying to win

[00:08:11] back what they lost at the table right like you’re going to end up chasing those and you’re going to

[00:08:13] like a gambler would trying to win back what they lost at the table right like you’re going to end up

[00:08:13] you just start feeling worse and worse but you feel like you cannot give up now

[00:08:17] and that is absolutely the worst position possible to be in if you’re trying to make rational logical

[00:08:24] decisions about how to spend your resources is to be in this state of like i gotta dick myself out

[00:08:29] of this hole well do you know what the first move stop digging stop digging so this stop loss is

[00:08:37] actually something we end up hitting occasionally at um at 37 singles as well occasionally we’ll have

[00:08:43] a thing where we’ll hit the stop loss and we just go like well we gave it four weeks and it’s not

[00:08:49] it’s not going to be there we’re not that close to it either and okay that was that was an investment

[00:08:55] in part in our discipline to be able to stick with this right because that’s the other thing if you

[00:09:00] have a software methodology like this and you’re broadcasting to the entire team that you know what

[00:09:08] the limits aren’t actually the limits yeah we could just like yeah we can just keep pushing and

[00:09:12] if there’s something we can just keep pushing and if there’s something we can just keep pushing and

[00:09:13] sort of falls out of it we’ll just give it another cycle we’ll just give it another six weeks

[00:09:16] no one’s going to believe that these limits are actually the limits and then it all just sort of

[00:09:21] falls apart so you have to have the intellectual honesty to stick to your guns on this and just

[00:09:27] say like you know what this is what we’re willing to lose and when when that’s out we close the

[00:09:31] position out we may return to it and i mean just to illustrate how hard this is is the number of

[00:09:38] times i mean we’ve been running this operating system for how we develop for quite a long time

[00:09:43] i think shape up really started taking its recognizable final form and how we used it maybe

[00:09:51] a few years after that so we’ve been running that methodology for a good 10 years but even so um just

[00:09:57] a few months ago we we had a project i think we might even have talked about none of the podcasts

[00:10:01] before with this my side project that jason even demoed um we showed it to customers before it was

[00:10:07] ready to ship and as us we felt we hung ourself up on the expectations that like it’s got to go out

[00:10:13] and we just we blew through our stop loss and then we set another stop loss and we blew through that

[00:10:18] too right this is the thing these estimates and the revised estimates if you revise your estimates

[00:10:23] once you can be pretty damn sure you’re going to revise it twice three times four times five times

[00:10:28] right it becomes this never-ending screw and it’s very rare that even if you end up making

[00:10:32] the final set of estimates that you’re going to feel good about it that this was a good use of

[00:10:36] time so i’d actually go as far as to say that flipping it on its head getting out of estimates

[00:10:43] and budgets is the single most important thing that we have instituted as a barrier for our

[00:10:49] software development process over all these years i cannot point to another single fact that really

[00:10:54] is as influential in keeping us on the narrow track of shipping good software that doesn’t

[00:11:00] grow too large and for us not to get into these mega projects that swallow all your motivation

[00:11:07] and spirit because this is of course the other thing right like once you’ve been working on

[00:11:11] something that that feels overdue and feels like it’s going to be a lot of work and it’s going to

[00:11:13] feel late um you’re just so inclined to end up in a death march like the software industry is

[00:11:20] renowned for its endless death marches and some branches of the software industry it’s even worse

[00:11:25] like in game development as well someone just be churning they’re like working 12 14 hour days for

[00:11:31] weeks or months on end all because someone missed some estimates and i think that’s the other part

[00:11:37] of it what’s that mean to miss some estimates what it means in a lot of companies is you did a

[00:11:44] core job that was your estimate that was the thing you said you said it was going to take

[00:11:47] four weeks we’re at four weeks where is the thing and you’re like i i don’t know i didn’t uh what is

[00:11:54] that you that’s the creative process no one has the capacity to be able to estimate accurately

[00:12:00] at four or six weeks that is just not within our human powers yes we take it on as a human burden

[00:12:05] to feel embarrassed by the fact that we couldn’t hit our estimates to feel ashamed that we didn’t

[00:12:09] hit our estimates and then feel like we have to double down and repeat and etcetera like that but

[00:12:12] you don’t know how much of that…

[00:12:13] on it. And that whole cycle, especially as it goes between an individual contributor,

[00:12:19] a programmer, a designer, and their manager, it’s just like everything that’s awful about

[00:12:24] software development, like half of it lives in that scope on the estimate front.

[00:12:31] So this kind of sounds opposite of what I assume a lot of people are doing. They’re

[00:12:35] setting like, this is what we want to have accomplished, and then trying to figure out

[00:12:38] how long that will take. But we’re taking features sometimes out in order to meet a date

[00:12:44] or meet how long we’re willing to work on it. I think this works really well when you have

[00:12:50] the humility to accept that you’re not going to get everything you want. That’s just like,

[00:12:56] who gets everything they want? No one gets everything they want in software development.

[00:13:01] The customer doesn’t get everything they want. The programmer doesn’t get everything they want.

[00:13:04] The owner of the company making the software doesn’t get everything they want,

[00:13:08] except.

[00:13:08] That fact, except the fact that like, you know what? You have all these wishes. You have these

[00:13:12] inspirations, things you’d wish to be true in software you wish that exists. And then you

[00:13:17] start building it, and you learn something. You learn this takes longer than you thought.

[00:13:22] I was going to say that this takes shorter than you thought. That’s a rare one. It’s usually,

[00:13:26] it takes longer than you thought. And then you realize, you know what? I got to give something

[00:13:29] up. I got to trade here. I got to trade. We like to call it trading concessions.

[00:13:34] I got to trade the fact that like, I cannot make it all happen within the three weeks. You,

[00:13:39] you outlined all your hopes and dreams here, but we’re going to have to take a knife and we’re

[00:13:42] going to cut to it. So there has to be that level of trust between the people working on it and the

[00:13:47] people asking for it, that we will come up with something good. It won’t be perfect. It won’t be

[00:13:53] great. It won’t be everything you wanted. But if we can consistently ship good things inside these

[00:13:59] time boxes, we call appetites of budgets. You know what? That’s a really repeatable process

[00:14:04] that’s going to increase the trust between us. We work in these six week cycle,

[00:14:08] and Jason, I mean, I’d be surprised if you felt otherwise. Virtually all the cycles this year,

[00:14:14] I look back on it at the end of the cycle and I go, hot damn, we built a lot of stuff.

[00:14:19] We really made the products significantly better. Both of them at once, both Hay and Basecamp,

[00:14:26] wow, they got better. Even if you look into it and you look at each individual product and you

[00:14:31] go like, do you know what? They all left something on the table. They all left something. They all,

[00:14:34] there’s all, always, whenever we finish a cycle work on a project,

[00:14:38] there’s always to do’s left. There’s always like five things. Hey, here’s the things we could

[00:14:42] have worked on. But you know what? It doesn’t matter. The grand picture that we are machine

[00:14:46] to create software and the continuity of that machine is super duper important. I remember

[00:14:53] reading about these, how you bake bread at an industrial scale, like thousands of pieces of

[00:14:59] bread, right? And the most important thing for that oven is to keep it going. It literally takes

[00:15:05] weeks to get it going and get it started again.

[00:15:08] I feel like software development has a lot of those qualities to it. You need to keep the engine

[00:15:13] moving and you need to move things off the conveyor belt if they’re blocking it. And then you need to

[00:15:19] put something on there so that you get this cadence and you get this rhythm that you are

[00:15:22] shipping stuff. Nothing will clog down the momentum and motivation of a software development

[00:15:28] team as not being able to ship. And nothing will prevent you from shipping, like having projects

[00:15:34] that continuously get pushed out because you want to have all your hopes and dreams,

[00:15:38] but if the

[00:15:53] system doesn’t work, people won’t buy them, right?

[00:15:54] Now thing I mean, even if I had, I’m not gonna lie, the kind of refrigerator. I bought this

[00:15:57] whole thing. I bought this entire thing and you said it was gonna happen inside of them. And then

[00:16:01] you said the both estimates were gonna happen. And of course, they were wrong. So now we end up

[00:16:06] feature in a product like hay or in base camp that’s worth backlogging everything

[00:16:11] else for move it off the table another way to think about that is that you’re

[00:16:16] always practicing something and if you practice being late over and over and

[00:16:21] over and over you’re gonna get good at being late and that’s how you’re gonna

[00:16:24] work if you get good at shipping which is what we are good at you ship and that

[00:16:29] doesn’t mean cutting corners or anything like that you know you have to ship

[00:16:32] really good stuff but you’re gonna practice something I think what ends up

[00:16:36] happening is this companies are always late or perpetually late or keep putting

[00:16:40] more time after bad time or whatever that’s just what you keep doing because

[00:16:44] that’s all you know how to do and you actually unfortunately get really damn

[00:16:48] good at it that’s sort of the problem we are what we keep doing and I think that

[00:16:53] that’s that’s just the the factor of it right that you have to get into doing

[00:16:58] the shipping thing and it’s I mean it’s funny when I

[00:17:02] go out and I have all the flexibility to do it but you don’t have to get into it

[00:17:02] compared to lots of other people who work in software and our shipping ratio is incredibly

[00:17:08] high but everything we ship has compromises in it and part of that compromise just comes from like

[00:17:13] you know what we’re going to ship something good not going to be perfect that’s going to have it

[00:17:16] all but as jason said it’s also important to not hear this and think the thing well just shipping

[00:17:23] that’s the most important thing therefore cut quality cut um quality control just like whatever

[00:17:29] just push it out there at all costs absolutely not the thing you cut is scope and if you have to

[00:17:34] cut too much scope you cut the project you don’t do to do the project i mean again as i say even

[00:17:41] though we ship a lot we’ve also canceled quite a few projects as a ratio of the number of projects

[00:17:46] shipped it’s a small ratio but it’s important that it’s there it’s part of keeping the system

[00:17:52] integral i think it’s interesting that your philosophy is cut the scope and not just put

[00:17:58] in more hours because i think that’s what it’s all about

[00:17:59] probably where a lot of businesses are coming from is just the cram like cram for the test

[00:18:03] to make sure that it gets done by a certain date but that’s clearly what you guys are not doing

[00:18:08] you know what that is is that you’re gonna again just like you’re always practicing something

[00:18:12] you’re always losing something too and i think the way we look at it is if we keep pouring more

[00:18:16] time into this thing we’re losing other opportunities to do a bunch of other things

[00:18:20] and you’re better off losing just that one thing and getting to a bunch of other things

[00:18:24] they’re getting stuck behind this one thing that

[00:18:28] probably wasn’t worth it

[00:18:29] in the first place so you know you just have to choose your losses

[00:18:32] it’s such a negative feedback cycle too because if you end up continuously shipping late you

[00:18:39] create more uncertainty in the people who are deciding what we should work on because they

[00:18:44] have to get everything in now because they’re not going to have another shot at this perhaps

[00:18:48] for a very long time because you’re going to go off in the wilderness and who the hell knows when

[00:18:52] you’ll be back we put a premium on the fact that every six weeks we get to the side again

[00:18:59] we make new decisions

[00:19:02] and at those six weeks and the fact that we continue to get that opportunity to change our

[00:19:08] mind is what gives us the confidence to sit on our hands while the cycle is running

[00:19:14] while oven is baking we won’t constantly be peeking inside is it hot enough or is it strongly

[00:19:22] no keep the damn oven shot six weeks enjoy the bread

[00:19:25] okay so on that same note since we’re talking about these six week cycles

[00:19:27] tell me do you feel inspired and motivated now that you’re older and like everyone else has

[00:19:28] a lot of

[00:19:28] Tell me about forecasting. I know that a lot of companies are planning like a year in advance or

[00:19:34] two years in advance. We’re talking about just six weeks. How does that help with estimates and

[00:19:40] appetites and all of that? I would say that we plan 10 years,

[00:19:45] six weeks at a time. Everyone plans something. So you can plan 10 years, one at a time,

[00:19:52] basically over the next 10 years, or you can get there gradually as you go. And so

[00:19:56] we’re coming up for air constantly and looking around and deciding where to go next.

[00:20:01] And we’re not whiplashing. I think people assume that if you do it this way,

[00:20:06] you have no idea what you’re doing. That’s not the case at all. We have a direction roughly that

[00:20:12] we’re headed. And then we course correct all the time. We leave ourselves open to changing

[00:20:19] directions if we need to. We leave ourselves open to taking three steps to the left instead of one

[00:20:23] or whatever it might be, right? You can make these adjustments.

[00:20:26] As you go. But this gets back to something David was saying is that since we’re all bad estimators

[00:20:31] in general, how can we possibly know where we want to even be in five years or where we want

[00:20:37] to go in five years? The best information you have is the information that’s the most current

[00:20:42] information. I know more about what’s going to happen today than I do next week, obviously.

[00:20:48] Don’t we all? I mean, probably. We have in front of us, what’s in front of us? We can probably

[00:20:52] look at that and make an assumption about where we’re at.

[00:20:56] So by shortening these sort of planning moments or times or periods of time,

[00:21:01] you just have more accurate information on which to make your decisions about where you want to

[00:21:04] go next. Why wouldn’t you do that? It just baffles the mind. Now, it boggles the mind, of course.

[00:21:11] Again, we’re not building airplanes here. We’re not building medical systems where people are

[00:21:16] going to die. All the stuff that people always come up with these examples. We’re making software

[00:21:20] and we can make choices along the way. And this is a malleable thing. We don’t need to ship

[00:21:25] anything physical.

[00:21:26] So you must take advantage of that situation. And our approach takes full advantage of the fact that

[00:21:32] we just don’t know, but we’ll find out as we go. And then we’ll make calls as we go. And the

[00:21:38] product, the results are there. We’re shipping great things within every six-week cycle. The

[00:21:44] products are getting better all the time, both Basecamp and Hay. And we rarely miss, sometimes

[00:21:50] we do, but we rarely, rarely miss things and we rarely have to throw them out. And we’re making

[00:21:54] a ton of progress with a small team.

[00:21:56] This works really, really well. And we’ve been around for 23 years as a company. Basecamp’s been

[00:22:00] around for 18 years as a product. Hay’s going on the next few years, or been on a couple of years

[00:22:05] so far and going forward, of course. So it works. It works really, really well for us. And if you

[00:22:11] talk to other people who’ve come from other companies, so we hire people, they come from

[00:22:14] other companies. They’re shocked by the amount of stuff that we actually are able to get done

[00:22:18] in a reasonable amount of time without driving everyone into the ground. And it’s because of

[00:22:23] the way we do it.

[00:22:24] And I think a lot of that comes to,

[00:22:26] just compare. Are you happy with the way you’re shipping software? Are you hitting your roadmap

[00:22:30] that you planned two years ago to the dot and all everyone is just cheering and everything is

[00:22:35] shipped? Fine. Keep your process. I mean, that’s wonderful. Congratulations. I think you should be

[00:22:40] written up for just an amazing outcome. That is not something that’s generally seen in this

[00:22:46] industry. But if you are curious to have a process that feels like it’s cutting with the grain of

[00:22:51] human nature, that’s what ShapeUp is. That is what giving up on

[00:22:56] estimates is. That sometimes we just have to accept our fallacies as humans. The things we’re

[00:23:03] good at that fall right to what we can do really well. Getting something good done within a finite

[00:23:10] space, within constraints. Humans are pretty good at that. You can drop a lot of people into that

[00:23:17] kind of box and say, you have three weeks to do something good. And at the end of that three weeks,

[00:23:21] they’ll be like, I’m almost done. I’m almost done. But they’ll have something done. Versus if you say,

[00:23:26] hey, built this exact box to these specifications. And by the way, here’s like 50 unknowns. How long

[00:23:31] is it going to take? Yeah. The history of the human race and certainty of software development

[00:23:35] is like they will fail. Why would you sign up for that? Don’t keep doing things that don’t work.

[00:23:42] That is like fundamental insight of progress, right? Just stop doing the shit that’s broken,

[00:23:47] that does not work, that’s producing the bad results and try something else.

[00:23:52] I love that. Well, I think we should wrap it up there. That’s perfect.

[00:23:56] Rework is a production of 37signals. You can find show notes and transcripts on our website

[00:24:00] at 37signals.com slash podcast. You can also find us on Twitter at Rework Podcast.

[00:24:06] And in case you haven’t yet checked it out, you can learn more about the 37signals programmers

[00:24:09] and ops team, what they’re up to at their new technical blog. You can find that at dev.37signals.com.

Visão de gráfico