Vox

Leitura de 12 min

Offensive and Defensive Software Engineering Strategies

Summary

This episode of Developer Tea introduces a dual mindset for software engineering: offensive and defensive strategies. Host Jonathan Cottrell explains that most developers start with an offensive approach, focusing on building new features to attack problems, often imagining their code exists in a vacuum with ideal user contracts.

Cottrell argues that we frequently forget the complex environment where code actually lives—users, other systems, physical realities, and current events. Once released, software often faces broken contracts and unexpected contexts, necessitating a defensive mindset. He uses a sports analogy: focusing solely on offense leaves you unprepared for counterattacks, while only playing defense means missing opportunities.

The offensive strategy begins with learning through “tracer” work—small, intentional experiments that illuminate pathways and provide grounds for learning, often meant to be thrown away. This iterative, responsive development then shifts into a defensive strategy, where engineers observe how the environment actually interacts with their code, paying attention to broken contracts and unintended usage.

The key insight is that effective engineering requires integrating both strategies. A good offensive strategy should consider defensive implications by asking “what happens next?” and anticipating chain reactions. Offense and defense should be seen as a codependent relationship rather than distinct modes, working in tandem to create resilient, adaptable software.

Recommendations

Podcasts

  • Design Details — Mentioned as one of the other incredible podcasts available on spec.fm alongside Developer Tea.
  • React Podcast — Mentioned as one of the other incredible podcasts available on spec.fm alongside Developer Tea.
  • Tools Day — Mentioned as one of the other incredible podcasts available on spec.fm alongside Developer Tea.

Tools

  • Linode — Sponsored service mentioned as a ‘safe bet’ for hosting, starting at 20 credit with promo code DEVELOPERTEA2020.

Topic Timeline

  • 00:00:00 — Introducing the offensive vs. defensive mindset in coding — Jonathan Cottrell opens the episode by contrasting the typical offensive approach to coding—attacking problems—with a proposed defensive perspective. He explains that developers often think about what code should do but forget the environment it operates within, which includes users, other systems, and broader contextual realities.
  • 00:02:41 — The need for both offensive and defensive strategies — Cottrell advocates for shifting feature planning to incorporate both offensive and defensive moves. Using a sports analogy, he notes that focusing only on offense leaves you vulnerable to counterattacks, while only playing defense means missing opportunities. Effective engineering requires seamlessly switching between the two integrated strategies.
  • 00:03:40 — Offensive strategy: Learning through tracer work — The offensive strategy in software development starts with learning via “tracer” work—small, specific experiments not meant to be final solutions. Tracers light up pathways, provide learning grounds for future iterations, and are intentionally small with minimal planning. This initial offensive move helps understand the environment before shifting to response mode.
  • 00:05:26 — Defensive strategy: Responding to the environment — After the sponsor segment, Cottrell defines defensive strategy as being in response mode—observing how the environment actually interacts with released code. This involves paying attention to broken contracts and unexpected usage patterns. The goal is to design offensive strategies that integrate with defense by anticipating chain reactions and potential failures.
  • 00:07:49 — Integrating offensive and defensive strategies — Cottrell emphasizes that great offensive strategy doesn’t undermine defense, and great defense isn’t just recovering from reckless offense. Engineers should think steps ahead, considering how a feature might go wrong or differently than planned. Offense and defense should be viewed as a codependent relationship rather than distinct operational modes.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-07-06T09:00:06Z
  • Duration: 00:10:12

References

Podcast Info

Transcript

[00:00:00] Most of the time when we are writing code, we think about what the code has to go out

[00:00:08] and do for us.

[00:00:10] We think about it as an offensive attack against our problems.

[00:00:16] But what if we were to think about it from the other direction, from the position of

[00:00:19] defense?

[00:00:21] That’s what we’re talking about in today’s episode.

[00:00:23] My name is Jonathan Cottrell and you’re listening to Developer T. And my goal on the show is

[00:00:26] to help driven developers like you find clarity, perspective, and purpose in their careers.

[00:00:33] If you think about the way that we tend to write code or the intuitive way that we think

[00:00:39] about software engineering to begin with, it starts with something new.

[00:00:46] We build a new class and we add methods and we try to construct something that changes

[00:00:54] the environment.

[00:00:55] It changes the problem, it goes and accomplishes something.

[00:00:59] But what we often tend to forget is the environment that the code is living in.

[00:01:05] That environment is built up of many different things.

[00:01:08] It may be users, actual people or computers that consume the product or maybe even the

[00:01:16] service.

[00:01:17] Maybe you’re upstream from other digital products, other APIs, for example, that use your code.

[00:01:25] But the environment includes a lot of other things as well.

[00:01:27] Beyond just the clients that might use our code, we can imagine the machine that is running

[00:01:33] our code and we can jump up a level to the kind of situation in the world, the current

[00:01:42] events that are happening around the people who are using our products and our services.

[00:01:48] We can think in terms of physical realities.

[00:01:51] We can think in terms of conceptual realities.

[00:01:55] But we very often forget that these things exist when we’re writing our code to begin

[00:02:00] with.

[00:02:01] When we’re writing our code to begin with, we imagine that the features that we’re building

[00:02:07] are in a vacuum in a way.

[00:02:10] That we can define some kind of contract between us and the user, that they will use it in

[00:02:17] a particular way and that because we are creating the software to be used in that way,

[00:02:23] that it will be used in that way.

[00:02:25] Of course, on the realistic side, once we release our software, we find that those contracts

[00:02:31] tend to be broken and the context that we imagined that our code would exist in tends

[00:02:37] to be much more complex than we ever planned for.

[00:02:41] So I want to help you shift your thinking about feature planning or about feature development,

[00:02:47] about software development in general.

[00:02:50] Shift it to think about both the offensive moves and the defensive moves that you can

[00:02:55] make as an engineer.

[00:02:58] In the same way that in any sport or game, if you solely focus on being aggressively

[00:03:05] offensive, in other words, if you are making all of the attacks, then you’re not prepared

[00:03:11] for someone who makes a counter attack.

[00:03:14] You’re not prepared for a situation that disables your offensive attacks.

[00:03:20] On the flip side, if you’re only playing a defense, then you’re not really ready to

[00:03:25] take advantage of opportunities when you see them arise.

[00:03:29] So we need both.

[00:03:30] We need offensive and defensive strategies and we need them to be integrated so that

[00:03:35] we can seamlessly switch between the two.

[00:03:37] So let’s talk about our offensive strategy.

[00:03:40] In the beginning of almost any software development process, the offensive strategy is one of

[00:03:47] learning.

[00:03:48] You can imagine that your feature development is like a tracer.

[00:03:53] The concept of a tracer, as it relates to software engineering, refers to the practice

[00:03:58] of trying something very specific, maybe even very deep, but not expecting that initial

[00:04:06] shot to be everything that you need it to be.

[00:04:10] It more lights up the pathways around that particular concept and most importantly, provides

[00:04:17] grounds for learning for future iterations.

[00:04:20] In fact, in tracer work, you may end up throwing away everything that you’re doing.

[00:04:26] This is entirely an offensive move and it’s intended to provide you a next step kind of

[00:04:33] hint, a way of moving forward.

[00:04:36] A critical characteristic of tracers is that they are intentionally small.

[00:04:42] They don’t require a lot of planning, they don’t require a lot of work to implement relative

[00:04:47] to what they would represent in the full scenario.

[00:04:52] So this is your first offensive move and as you move forward, you adjust your strategy

[00:04:57] into response scenario.

[00:05:00] You start with that tracer to kind of learn the environment, the kind of context that

[00:05:06] your code will be running in and then you respond to that.

[00:05:11] This is our iterative development.

[00:05:12] We respond to our environment and we slowly change things as we learn new information.

[00:05:19] That response is fundamentally what we’re talking about when we say defensive strategy.

[00:05:26] That’s what we’re going to talk about right after we talk about today’s sponsor, Linode.

[00:05:30] No matter what your strategy is when you develop software, one of the most important

[00:05:34] things you can do is find things that are always safe bets.

[00:05:39] Linode is always a safe bet.

[00:05:42] That’s because Linode starts at just $5 a month and it’s a very basic concept.

[00:05:47] The idea of Linux and the cloud, but Linode goes beyond that in additional services that

[00:05:52] they provide now, like GPU compute plans that are suitable for AI or machine learning or

[00:05:56] video processing or dedicated CPU plans with physical cores that are reserved just for

[00:06:02] you.

[00:06:03] There’s no CPU steal.

[00:06:04] We’re talking about context and environment in this episode and Linode is providing you

[00:06:10] different types of environments that are specific to your use case.

[00:06:15] Whether you’re a brand new developer starting out, which Linode provides you the Nano plan,

[00:06:19] it starts at $5 a month, or if you have a whole team that you need to support, you can

[00:06:24] use their cloud manager, for example, cloud.linode.com, or you can automate everything with their

[00:06:29] version four API or their Python CLI.

[00:06:32] Go and check it out.

[00:06:33] If you’re a new customer, you can get $20 worth of credit towards your next project.

[00:06:37] Head over to linode.com slash developer T and use the promo code developer T 2020 all

[00:06:43] one word developer T 2020 at checkout.

[00:06:47] That’s linode.com slash developer T.

[00:06:50] Thanks to Linode for sponsoring today’s episode of developer T.

[00:06:54] So when we are in response mode, what this means is that we are open to the environment

[00:07:00] and what it is telling us.

[00:07:02] The environment may not be trying to communicate to us.

[00:07:05] Let’s be very clear.

[00:07:06] We are observing the environment.

[00:07:09] We’re observing what’s happening when we write code and release it.

[00:07:13] Perhaps, for example, the contracts that we hoped that our different clients, whether

[00:07:17] they’re humans or computers, would follow, maybe they don’t follow them.

[00:07:21] This is incredibly common and we need to be paying attention to the ways that they’re

[00:07:26] not following those contracts.

[00:07:29] But here’s the reality.

[00:07:31] If you want to become a better engineer, when you’re thinking about your offensive strategy,

[00:07:37] it makes sense to think a few steps ahead, specifically designing your offensive strategy

[00:07:44] by integrating it with your defensive strategy.

[00:07:49] If we release this feature in this particular way, what will happen next?

[00:07:54] What are the chain of events that could occur three steps down the line?

[00:07:59] How could this go horribly wrong or how could this go in a way that’s different than I planned

[00:08:06] it?

[00:08:07] A great offensive strategy when it comes to engineering doesn’t undermine your defensive

[00:08:13] strategy.

[00:08:14] And a great defensive strategy doesn’t just try to recover from a reckless offensive strategy.

[00:08:21] They work together in tandem.

[00:08:23] The categorization of defensive and offensive should be thought more of as a codependent

[00:08:30] relationship rather than distinct modes of operation.

[00:08:35] Thank you so much for listening to today’s episode of Developer Tea.

[00:08:38] Another thank you to Linode for sponsoring today’s episode.

[00:08:41] Head over to Linode.com slash Developer Tea.

[00:08:44] Use the promo code DEVELOPERTEA2020 at checkout.

[00:08:47] That’s DEVELOPERTEA2020 at checkout for that $20 worth of credit as a new customer of Linode.

[00:08:54] If you enjoyed this episode of Developer Tea, I encourage you to subscribe and whatever

[00:08:58] podcasting app you currently are using to listen to this episode.

[00:09:03] We have a huge back catalog of episodes and of course, we’re putting out two new episodes

[00:09:08] now.

[00:09:09] We’ve gone from three episodes to two episodes.

[00:09:11] We put out two episodes every week of this show.

[00:09:14] So it’s easy to forget about the show and then feel like you have to catch up.

[00:09:19] Two pieces of advice.

[00:09:20] If you subscribe, then you can choose as shows are coming out, which ones you want to listen

[00:09:24] to.

[00:09:25] And secondly, just a piece of advice.

[00:09:27] If you are joining us this late, there’s no reason that you have to go back and listen

[00:09:32] to the whole back catalog.

[00:09:34] This show is designed for you to pick the episodes that are most relevant to you.

[00:09:39] Thanks again for listening to this episode of Developer Tea, which can be found on spec.fm

[00:09:44] along with every other episode of the show.

[00:09:46] And of course, other incredible podcasts like Design Details, React Podcasts, Tools Day,

[00:09:52] and more.

[00:09:53] Go and check it out.

[00:09:54] Head over to spec.fm to find more incredible content made specifically for you.

[00:09:59] Of course, a huge thank you to today’s producer, Sarah Jackson.

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

Visão de gráfico