Vox

Leitura de 16 min

Plans Should Be Functions, Not Documents

Summary

The episode explores the fundamental flaws in traditional planning models, particularly the path-dependent approach where each step relies on the previous one. The host discusses how these models create rigidity and increase risk because they don’t account for changing circumstances, unexpected events, or new information that emerges during execution.

Research shows that people consistently underestimate the time needed for projects (the planning fallacy) and fail to account for random events that disrupt timelines. More importantly, path-dependent planning assumes we know exactly what needs to be done from the outset, when in reality, our understanding of requirements and context evolves as we work.

The solution proposed is to shift from viewing plans as static documents to treating planning as a repeated function. Instead of creating a single comprehensive plan at the beginning of a project, teams should engage in regular planning sessions that produce short-term action lists. This approach acknowledges that agency and decision-making during execution are crucial for adapting to changing environments.

By making planning a function rather than a document, teams can create shorter pathways with fewer dependencies, reducing risk and increasing responsiveness. This aligns with agile principles but focuses more fundamentally on avoiding the pitfalls of long, rigid planning timelines that inevitably diverge from reality.

Topic Timeline

  • 00:00:00 — Introduction to planning and its importance in human life — The host introduces the broad topic of planning, distinguishing between microscopic immediate planning and longer-term strategic planning. He sets the stage for discussing how we actively choose to use our time and the planning process itself, framing it as a fundamental human capacity that extends beyond our own lifetimes.
  • 00:01:23 — The problem with plans: they often go awry — The host references Robert Burns’ poem about ‘the best laid plans of mice and men often go awry’ and connects this to developers’ and humans’ experiences. He discusses how looking back at our expectations from the past reveals significant gaps between what we planned and what actually happened, highlighting research showing people expect future stability despite evidence to the contrary.
  • 00:03:07 — Traditional software project planning and its failures — The host describes typical software project planning: listing requirements, estimating timelines, getting team buy-in, and then watching those plans fail. He questions why teams continue making these same kinds of timelines despite repeated failures and introduces the core question of how to replace this flawed mindset with a better one.
  • 00:05:29 — The planning fallacy and underestimating randomness — The discussion moves to the planning fallacy - the well-researched phenomenon where plans consistently underestimate time needed. The host explains this happens because we underestimate random events (like people getting sick or having jury duty) and fail to account for changing requirements and capabilities during project execution.
  • 00:06:51 — Path-dependent planning models and their risks — The host introduces the concept of path-dependent planning models where each step depends on the previous one. He illustrates with an 8-month project example, showing how divergence from the path (like market changes) forces expensive replanning. Longer pathways increase risk due to more opportunities for divergence and environmental changes.
  • 00:09:27 — Human psychology and sunk cost fallacy in planning — The host discusses how humans fall prey to sunk cost fallacy - continuing down failing paths because of prior investment. He explains that path-dependent models satisfy human needs for certainty and immediate gratification, even when they’re ultimately counterproductive for adapting to reality.
  • 00:10:50 — When path-dependent models work (and when they don’t) — The host acknowledges that path-dependent models work for robots or situations with no agency or environmental feedback. However, for decision-making agents like humans who can evaluate context and make intelligent decisions, rigid path-dependent planning creates unnecessary risk and limits responsiveness.
  • 00:12:29 — Making planning a function rather than a document — The host presents the core solution: treat planning as a repeated function that produces short-term action lists rather than creating a single comprehensive document. This approach requires agency during execution and aligns with agile principles. The key insight is that shorter pathways with regular replanning reduce risk and increase adaptability.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-01-31T10:00:00Z
  • Duration: 00:14:59

References

Podcast Info

Transcript

[00:00:00] how do you plan for the future this is an intentionally broad question that comes into

[00:00:11] play every single day in our work in our personal lives we plan both at the microscopic level what

[00:00:21] we’re getting ready to do in a moment or two but then at a much higher level we plan out our days

[00:00:28] or weeks or months even to our years and beyond one of the unique aspects of being human is that

[00:00:38] we have the capacity to think in the very long term even beyond our own lives for the sake of

[00:00:45] today’s episode we’re going to ignore the microscopic immediate scale planning because a

[00:00:53] lot of our actions are somewhat involuntary instead we’re going to talk about the

[00:00:58] things that we are actively choosing to do with our time but perhaps more broadly we’re talking

[00:01:06] about the process of planning in today’s episode my name is Jonathan Cottrell you’re listening to

[00:01:12] Developer T and my goal on the show is to help driven developers like you find clarity perspective

[00:01:16] and purpose in their careers and you’ve probably heard this phrase before the best laid plans of

[00:01:23] mice and men often go awry this actually comes from a

[00:01:28] poem written by Robert Burns back in 1785 I had to google that but this this phrase and this feeling

[00:01:36] is something that we as developers and just as humans we know this is the case we had expected

[00:01:45] things to go one way and turned out they went a different way and in fact we can kind of feel this

[00:01:52] if we look back over our past week we can think what did we expect to happen and what

[00:01:58] things didn’t we expect to happen what things were totally unexpected that we could never have

[00:02:04] planned for in the first place on a more kind of grand scale you can think back 10 years ago

[00:02:10] trying to put yourself in the mindset of where you were 10 years ago and where you expected to be

[00:02:18] and depending on what stage in life you are the difference between those two is likely quite large

[00:02:26] and in fact research has shown

[00:02:28] people expect that the next 10 years on average is going to be more stable than the last 10 years

[00:02:36] this idea that we’ve somehow in some way arrived at the present moment and that the present

[00:02:43] is what will continue on into the future for some indefinite period of time

[00:02:49] perhaps this is one of the driving kind of reasons that we continue to plan we continue to make the

[00:02:58] plans as if we know what that future holds. Interestingly, if you look at the average

[00:03:07] plan, let’s say for a software project, the average plan tends to lay things out in some

[00:03:14] logical format. We have some list of requirements and we try to reasonably estimate how we’re going

[00:03:22] to accomplish the software needed to meet those requirements. We lay it out on a timeline.

[00:03:31] We all get in a room and we look at the timeline. We sign our names next to it and fast forward to

[00:03:38] the end of that timeline. Things look different. What causes us to continue making these same

[00:03:46] kinds of timelines and then seeing them fail? And how can we describe this bad mental

[00:03:52] mindset? What causes us to continue making these same kinds of timelines and then seeing them fail?

[00:03:52] And then replace it with a better one. That’s what we’re going to talk about right after we

[00:03:59] talk about today’s sponsor, Linode. You can get a $20 credit just for being a listener of

[00:04:06] Developer Tea and get started on Linode today. Linode has native SSD storage, a 40 gigabit

[00:04:12] internal network, and industry-leading processors. Their enterprise-grade hardware,

[00:04:17] S3-compatible storage options, and their next-generation network means that Linode

[00:04:22] provides the performance you expect at a price that you don’t expect. In fact,

[00:04:28] Linode plans start as low as $5 a month. That’s going to get you root access to your server

[00:04:33] along with API access. This is a version four of the API. They’ve been doing this for a while now

[00:04:40] and they have a Python CLI. So you can do all of the things that you’d love to do

[00:04:46] to automate your server management. It’s a very developer-friendly workflow and that’s because

[00:04:51] Linode is built by developers. And in fact, they’re hiring. If you’d like to check out the

[00:04:58] jobs that Linode has available for developers like you, head over to linode.com slash careers

[00:05:03] to find out more. Or if you’d like to get started with a new Linode account and $20 worth of credit,

[00:05:09] head over to linode.com slash developer tea and use the promo code developer tea

[00:05:14] 2020. That’s developer tea 2020 when you check out. Thanks again to Linode for sponsoring today’s

[00:05:21] episode.

[00:05:21] Developer tea. The topic of planning is not new to this show. We’ve talked about things like the

[00:05:29] planning fallacy, which is fairly well researched at this point. The idea that our plans are almost

[00:05:37] invariably underestimating the amount of time necessary to do something. And that the reason

[00:05:44] for this very often is that we underestimate the prevalence of random events.

[00:05:51] Things that might keep us from achieving those plans. We don’t plan for people being sick enough

[00:05:59] as an example, or another example from a real recent experience that I had people having jury

[00:06:06] duty, but it’s not just about capacity. The problems that we have with planning go beyond

[00:06:13] our capabilities and into the what, not just whether or not we can finish what we’ve planned,

[00:06:20] but whether or not we’re going to be able to do something. And that’s what we’re going to do.

[00:06:21] We’re even going to execute on what we planned in the first place. If the plan was good. So this

[00:06:28] discussion is not just about rearranging the work or rearranging our estimation abilities

[00:06:35] so that you end up with the same planned product with a kind of a different execution style.

[00:06:42] Instead, this discussion is about a more fundamental and foundational approach to planning.

[00:06:50] If we take

[00:06:51] our planning exercise as a single moment in time task, where we lay out our game plan for the next,

[00:07:02] let’s say, eight months. We have a long project in front of us, and we want to lay out our game

[00:07:08] plan for that long project. And we start to create a pathway where in the first month,

[00:07:15] we kind of lay the groundwork for what we’re going to do in month two, and then we expand

[00:07:21] on whatever we do in month two, in months three and four. And then we build variations on the

[00:07:26] things that we built in months three and four, in months five and six. We polish things in month

[00:07:31] seven, and perhaps we do user testing in month eight. None of these things sound bad on their

[00:07:39] own, but what we’ve done unwittingly is we’ve built a path dependent model. In other words,

[00:07:48] our fifth step can only happen if our fourth,

[00:07:51] second step happened, and the fourth step can only happen if our third step happened.

[00:07:57] And so if we diverge from that original path, let’s say, in our second month, we realize that

[00:08:04] the market doesn’t really want the things that we’re planning to do in month three.

[00:08:09] Well, now our entire pathway changes. And there’s some work to be done in replanning,

[00:08:18] responding to this change. Very often,

[00:08:21] a lot of the kind of built up preconceived ideas about what we’re going to do with our resources

[00:08:27] are based on the first path. So this can be very expensive if you have a lot of path changes

[00:08:34] in a path dependent plan. It can also be very scary for people who are on a team, for example,

[00:08:42] who are constantly changing that path because they don’t know if the path is getting ready to end

[00:08:48] or if it’s going to go on twice as long as they had.

[00:08:51] Finally, it’s important to note that the longer that pathway is,

[00:08:58] the less likely it is to happen. The longer the pathway is, the more opportunities there are

[00:09:07] to diverge from that pathway. Additionally, as time passes, and as more is added to

[00:09:15] kind of your already traveled path, the more your environment changes,

[00:09:21] in ways that you can’t really predict, requiring a change in that pathway.

[00:09:27] Unfortunately, as humans, we often fall prey to things like sunk cost. So we choose a path. And

[00:09:34] because we go 50% of the way down that path, if we find out that the path is leading towards

[00:09:40] inevitably a bad end point, we still feel like we bought in originally. And we want the path to work.

[00:09:48] So we have a hard time abandoning that.

[00:09:51] Particular pathway. This path dependent model for planning may seem like a good idea because

[00:10:00] it helps us gain a feeling of certainty early on. We can project into the distant future

[00:10:09] and we can take what we currently think we want or need and imagine when we will have it.

[00:10:18] This satisfies a lot of our human needs,

[00:10:21] like the need for certainty, as well as the need for immediate gratification.

[00:10:27] The feeling that we are going to get the thing that we want right now,

[00:10:32] even though the timeline tells us that it’s not going to be until much later.

[00:10:38] So how do we fix this problem? And how can we plan in ways that don’t expose us to all of the

[00:10:44] kind of risk that we’ve just discussed about a path dependent model? Well, let’s imagine a

[00:10:50] scenario where a path dependent model is going to be a path dependent model. So we’re going to have a

[00:10:50] path dependent model that’s going to be a path dependent model that’s going to be a path dependent model.

[00:10:51] model is the only thing that could possibly work. A path-dependent model might be the only thing

[00:10:58] that can work if you have a robot that can only execute tasks, a robot that cannot evaluate their

[00:11:07] environment, and they don’t have any way of taking additional cues in the future, and no way of

[00:11:15] responding to their context. So a path-dependent model in this case makes sense. Additionally,

[00:11:23] we often operate in path-dependent models that we don’t really have control over to begin with.

[00:11:29] However, if we are creating a plan, if we can avoid a path-dependent model and instead

[00:11:36] look at other possible models, we might be able to avoid disaster and risk altogether.

[00:11:43] For example,

[00:11:45] imagine that instead of a robot, you have a decision-making agent like a human. The human

[00:11:53] can evaluate the context, and they can make an intelligent decision along the way. You can give

[00:11:59] a rough definition of where that human should go, but making a determination about, for example,

[00:12:07] a detour in a given context allows the human to respond to the environment. So when you

[00:12:15] create a decision-making agent, you can evaluate the context, and they can make an intelligent decision along the way.

[00:12:15] So when you create a model that provides for agency during the execution phase,

[00:12:22] you can intelligently respond to changing circumstances. So here’s what I recommend.

[00:12:29] When you are in the planning phase, whether it’s for a project, for your day, perhaps for your life,

[00:12:39] evaluate what those trade-offs are. Do you have agency to be able to make decisions on the

[00:12:45] fly? Is there some hybrid between laying out a plan, but then leaving room for flexibility?

[00:12:52] Ultimately, when you are planning software projects, one of the most valuable things you

[00:12:57] can do is make planning a function rather than a document. Think about this for a second.

[00:13:05] If you imagine that planning is a repeated function that produces a short-term list of actions,

[00:13:14] this requires,

[00:13:15] that you have some level of agency to perform this function. Rather than starting a project

[00:13:21] with a list of things to do that eventually degrades, that eventually is no longer as

[00:13:29] relevant because you’re starting to learn more as you go through that project. Instead,

[00:13:34] you start a project with a planning session. This is a function that you and your team perform.

[00:13:42] If you’re like most developers, you’re probably hearing this, and you’re

[00:13:45] immediately correlating this to an agile process. The fundamental tenet here, though,

[00:13:52] is about thinking about the path dependencies. The longer you have on your path of dependencies,

[00:14:00] the more risk you’re accepting. If you can create shorter pathways and instead rely on functions and

[00:14:08] agency in your planning process, you’re more likely to be able to respond to the context,

[00:14:14] be able to respond to the environment, respond to changes, rather than believing that your plans

[00:14:21] are going to mitigate all of your risk for you. Thank you so much for listening to today’s episode

[00:14:26] of DeveloperTea. Thank you again to Linode for sponsoring today’s episode. Get $20 worth of

[00:14:31] Linode credit by heading over to linode.com slash developertea, using the code developertea2020.

[00:14:37] That’s developertea, and then the number is 2020 at checkout. Today’s episode, along with every

[00:14:43] other episode of the show, is going to be a little bit different. I’m going to be talking about the

[00:14:44] can be found at spec.fm, and today’s episode was produced by Sarah Jackson.

[00:14:49] My name is Jonathan Cottrell, and until next time, enjoy your tea.

Visão de gráfico