Vox

Leitura de 12 min

Two Principles To Improve Your Software Design Decisions

Summary

In this episode of Developer Tea, host Jonathan Cottrell introduces two principles to help developers make better software design decisions. The first principle focuses on the cost of commitment, emphasizing that saying yes to the wrong thing is often more costly than saying no to the right thing. Cottrell explains that time is the key resource at stake, and that choosing to spend time on something that doesn’t help achieve your goals removes your optionality for better opportunities.

The second principle centers on minimizing assumptions in software design. Cottrell argues that designs requiring fewer assumptions are statistically less likely to contain errors, as each assumption introduces potential for mistakes. He clarifies that this doesn’t mean avoiding all assumptions, but rather choosing solutions that make the fewest assumptions while remaining flexible to future changes.

Cottrell connects these principles by showing how they work together in practice. When facing uncertainty, developers should lean toward saying no to commitments that don’t clearly advance their goals, and choose design approaches that minimize assumptions about future requirements. This combination allows teams to build flexible systems that can adapt as needs evolve without prematurely closing off options.

The episode concludes with practical advice for applying these principles in real-world development scenarios. Cottrell encourages listeners to discuss these ideas with their teams and managers, and to consider how bias toward ‘no’ under uncertainty combined with assumption-minimizing designs can lead to more robust and adaptable software solutions.

Recommendations

Principles

  • You Aren’t Gonna Need It (YAGNI) — Referenced as a complementary principle to the assumption-minimizing approach, suggesting developers should avoid building features before they’re actually needed.

Tools

  • Square APIs and SDKs — Mentioned as a sponsor, Square offers free APIs and SDKs that developers can use to build tools for sellers and extend or integrate with Square’s platform.

Topic Timeline

  • 00:00:00 — Introduction to decision-making principles — Jonathan Cottrell introduces the episode’s focus on principles for making better software design decisions. He explains that while developers should adopt their own principles, they can use evidence and others’ principles to inform their choices. The goal is to provide practical tools for finding clarity and purpose in development careers.
  • 00:01:14 — First principle: The cost of saying yes — Cottrell presents the first principle: ‘Saying yes to the wrong thing is almost always more costly than saying no to the right thing.’ He clarifies that ‘wrong’ means something that doesn’t help achieve your goals, while ‘right’ means something that would help. The principle centers on time as the key resource, emphasizing that saying yes removes optionality and commits irreplaceable time.
  • 00:04:27 — Sponsor break and principle clarification — After a sponsor message from Square, Cottrell clarifies the first principle’s application to situations of uncertainty. He explains that leaning toward ‘no’ makes sense when you lack evidence that a direction will help you succeed. However, this doesn’t mean perpetual inaction—when options seem equal, choosing the simplest approach can be effective.
  • 00:06:51 — Second principle: Minimizing assumptions — Cottrell introduces the second principle: ‘Choose designs that allow you to make the least assumptions.’ He defines assumptions as beliefs acted upon without sufficient evidence, noting they often appear as expectations about the future. Systems with fewer assumptions are statistically less likely to contain errors, as each assumption introduces potential for mistakes.
  • 00:09:13 — Applying the assumption-minimizing principle — Cottrell explains how to apply the assumption-minimizing principle in practice. When comparing solutions, choose the one requiring fewer assumptions, all else being equal. He clarifies this doesn’t mean ignoring future possibilities, but rather building flexible systems that don’t predict specific future features. This approach combines well with the ‘You Aren’t Gonna Need It’ principle.
  • 00:10:41 — Conclusion and practical application — Cottrell concludes by encouraging listeners to discuss these principles with their teams and managers. He invites them to join the Developer Tea Discord community to share how these ideas play out in real development jobs. The episode ends with a reminder about Square’s sponsorship and their APIs for developers building tools for sellers.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2022-03-02T08:00:00Z
  • Duration: 00:11:40

References

Podcast Info

Transcript

[00:00:00] When making difficult decisions, whether in software or in life, it helps to have a set

[00:00:10] of principles.

[00:00:11] In today’s episode, we’re going to talk about some principles that you can employ to make

[00:00:18] better decisions and make better software.

[00:00:21] My name is Jonathan Cottrell.

[00:00:22] You’re listening to Developer Tea.

[00:00:23] My goal on this show is to help driven developers like you find clarity, perspective, and purpose

[00:00:29] in their careers.

[00:00:31] And I want to give you these practical tools as often as I can.

[00:00:37] The reality is that you have to adopt your own principles.

[00:00:43] And hopefully, you’re using some good evidence and the principles of others to inform the

[00:00:51] ones that you feel are going to be most effective for you.

[00:00:56] But I don’t want you to just take this point blank.

[00:01:00] I want you to take this and run it through its paces to see if it’s going to work for

[00:01:05] you.

[00:01:06] It works for me, but it doesn’t mean it’s going to work for everybody.

[00:01:10] With that said, let’s jump into the first principle.

[00:01:14] Saying yes to the wrong thing is almost always more costly than saying no to the right thing.

[00:01:27] Let’s think about that again.

[00:01:29] Saying yes to the wrong thing is usually more costly than saying no to the right thing.

[00:01:40] Let’s explore this principle a little bit deeper here.

[00:01:44] The resource that we’re talking about implicitly in this principle is time.

[00:01:50] When we choose to do something, when we choose to spend our time in a particular way, we

[00:01:57] are actively choosing to not spend our time in a different way.

[00:02:03] This seems obvious, but this is the crux of this principle.

[00:02:08] If you choose to do the wrong thing, and in this case I want to define what I mean

[00:02:15] by wrong thing and right thing because those definitions might change the way you think

[00:02:21] about this principle.

[00:02:22] When I say wrong in this case, I mean something that doesn’t come close to helping you achieve

[00:02:29] your goal.

[00:02:32] When I say right, the right thing in this case, it is something that would help you

[00:02:38] achieve your goal.

[00:02:41] I don’t want to talk about rare opportunities that aren’t going to come around.

[00:02:46] That’s not what this principle is about.

[00:02:48] The truth of the matter is most of those opportunities are exactly what I already mentioned.

[00:02:54] They’re rare.

[00:02:55] The vast majority of the opportunities that you’re going to be presented are going to

[00:03:00] be one of many good options.

[00:03:03] While you may have many good options, there is a whole ocean usually of bad options.

[00:03:11] So choosing to say yes to one of those bad options, it takes the time that you could

[00:03:18] have said yes to a different right option even if you did say no to another right option.

[00:03:27] In other words, you’re removing your optionality by saying yes, which means that yes costs.

[00:03:35] Yes is expensive, whereas no is not necessarily expensive.

[00:03:42] Notice that I don’t want you to ignore the opportunity costs of saying no to a good thing,

[00:03:48] but instead recognize that no to a good thing doesn’t necessarily mean no to all good things.

[00:03:56] It also doesn’t mean no forever.

[00:03:59] When we say yes to something and we spend time on it, that’s time that we can’t capture back.

[00:04:06] And so if your yes is a large commitment especially, it makes sense to make those decisions carefully.

[00:04:14] Make those decisions deliberately.

[00:04:17] And when in doubt, you might want to bias your decisions towards a no.

[00:04:24] We’re going to take a quick sponsor break and then we’re going to come back and talk

[00:04:27] about a second principle that will help you make better software design decisions.

[00:04:40] Developer T is proudly supported by Square.

[00:04:44] There are millions of sellers across the globe using Square to run every aspect of their business.

[00:04:49] Many are looking for customized solutions that are deeply connected and easy to use.

[00:04:54] This is where you as a developer come in.

[00:04:56] You can grow your business by extending or integrating with Square using free APIs and

[00:05:02] SDKs to build tools for sellers.

[00:05:06] Learn more by going to developert.com slash Square.

[00:05:10] That’s developert.com slash Square.

[00:05:14] Thanks again to Square for sponsoring today’s episode of Developer T.

[00:05:19] Before we move forward with our second principle, I do want to clarify one part of that first

[00:05:29] principle, the idea that you should lean towards no.

[00:05:33] When I say you should lean towards no, the situation that I’m referring to is when you

[00:05:38] don’t know, right?

[00:05:41] You either don’t have enough information, enough evidence to suspect that that direction

[00:05:46] is the right direction, or you have any evidence to suspect that that direction is the wrong

[00:05:52] direction.

[00:05:54] Obviously, if you know that you have a good direction versus a bad direction or a direction

[00:06:00] that would help you succeed, if you had enough information to believe that, then that changes

[00:06:07] the picture a little bit.

[00:06:08] What we’re really talking about here is making a decision under uncertainty.

[00:06:15] When there is uncertainty and you don’t have a reason to believe that a particular decision

[00:06:20] is going to help you succeed, then it makes sense to lean towards no.

[00:06:26] Of course, you can’t just keep saying no and doing nothing.

[00:06:30] At some point, it might make sense to look at your options.

[00:06:34] Try to imagine which of these plays out the best.

[00:06:39] Let’s say that all of them are equal.

[00:06:41] You might go with the simplest option, for example.

[00:06:45] This actually plays into our second principle that will help you make better software design

[00:06:51] decisions, and that is choose designs that allow you to make the least assumptions.

[00:07:00] Choose designs, choose tools, choose paradigms, choose team constructions that allow you to

[00:07:10] make the least number of assumptions.

[00:07:15] Most of the time, assumptions are masked in the form of believability.

[00:07:23] Assumptions might also be masked in the form of expectations for the future.

[00:07:29] When we make assumptions, we are stating something that we believe to be true, acting on that

[00:07:37] as if it were true without sufficient evidence to prove that it’s true.

[00:07:46] We assume, meaning that we take on that particular concept, that fact, that assertion as if it

[00:07:58] was truth.

[00:08:00] Given two directions, given two systems, one where there is a large number of assumptions

[00:08:08] and one where there is a very small number of assumptions that are being made, the first

[00:08:14] system is statistically more likely to have error.

[00:08:19] What does this mean?

[00:08:20] Well, it doesn’t necessarily mean it’s going to have more bugs, but instead, the assumptions

[00:08:25] that are made may carry that software in a different direction than it needs to go,

[00:08:34] and that direction is going to be costly.

[00:08:37] Making assumptions introduces the potential for error.

[00:08:42] It doesn’t always mean that you’re going to have error, but it introduces the potential.

[00:08:49] If you add a bunch of assumptions to a given project, it’s possible that you’re right about

[00:08:56] all of them, but it’s very unlikely.

[00:08:59] You’re much more likely to introduce error when you create assumptions.

[00:09:06] Going back to our previous example, when we choose architectures, when we choose solutions,

[00:09:13] let’s say we have solution A and solution B, solution A allows us to make fewer assumptions

[00:09:18] than solution B, all things being equal, we should likely go with solution A.

[00:09:25] Now before you get frustrated with the fact that you’re pretty sure that you have these

[00:09:30] changes that are coming in a month or two and you don’t want to build yourself into

[00:09:34] a corner, it’s important to recognize that this works both ways.

[00:09:41] You shouldn’t assume that these features are coming, but you also shouldn’t assume

[00:09:46] that they’re not coming.

[00:09:49] In other words, if you build your software in a way that is open to future change, it’s

[00:09:56] flexible to future change, then you are limiting the number of assumptions that your software

[00:10:02] is making.

[00:10:04] You shouldn’t confuse this principle with the you aren’t going to need it principle,

[00:10:11] That principle combined with this one allows us to build the first layers of something,

[00:10:20] the first early features of something without closing the door to future expansion and future

[00:10:27] change.

[00:10:29] This means that we build flexible systems early that don’t try to predict future features.

[00:10:39] Thanks so much for listening to today’s episode of Developer Tea.

[00:10:41] I hope you found this episode intriguing and useful.

[00:10:45] Hopefully you can talk about these things with your team, maybe with your manager.

[00:10:49] I’d love to hear your takes on how these principles might play out in reality in your actual jobs.

[00:10:57] If you want to talk about those things, come join us in the Developer Tea Discord, head

[00:11:01] over to developertea.com slash Discord.

[00:11:04] Of course, that’s 100% free for listeners of this show.

[00:11:09] Today’s episode of Developer Tea was made possible by Square.

[00:11:13] Head over to developertea.com slash Square to get started with Square’s APIs and SDKs

[00:11:18] for software engineers like you.

[00:11:21] You can expand your business using Square, building tools for sellers.

[00:11:26] Again, that’s developertea.com slash Square.

[00:11:28] Thanks so much for listening and until next time, enjoy your tea.

Visão de gráfico