Today we're talking about future-proofing your code and cost of change curves.
In today's episode we're digging into the C2 wiki interview with Bill Venners, which focuses on flattening the cost of change over time so that cost becomes more constant.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
This is a daily challenge designed help you become more self-aware and be a better developer so you can have a positive impact on the people around you. Check it out and give it a try at https://www.teabreakchallenge.com/.
Check out the new Square YouTube channel for developers + Square has SDKs and APIs to make payments and run a business -- check it out at youtube.com/squaredev
And an interview with Bill Vinner, word-cutting him talks about flattening the cost of change curve. And today's episode, we're going to talk about a specific thing that word calls out that allows you to write your code to be more future-proof. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. So the cost of change curve that is referred to in this interview, it's a five-part interview by the way and you can find it on the C2 Wiki. This is C2.com. If you've never been there, it is a treasure trove of information and ideas, but this cost of change curve is typically shaped exponentially. That is, as time increases, the cost to make changes increases and perhaps increases at an exponential rate since there's so many intermingled dependencies in a given code base. And in the interview, word talks about flattening that curve. Instead of increasing over time, the cost of change would instead stay relatively constant. You can probably understand the intuition here. Imagine that your program is, let's say, a stack of blocks. And as you begin to stack the blocks, changing one block at any point in that stack requires a cost that is relative to the number of blocks that are in the stack. Of course, this rate of growth would be more like linear, but the point still remains. As we stack dependencies one on top of the other, in some ways, we're kind of locking our code underneath. And in order to make a change in the future, we have to unravel that code and perhaps change the entire structure of that block stack. And word talks about ways that you might overcome this problem and ways that you might reduce that cost to change. Now we're not talking necessarily just about dollar cost here. We're talking about number of thinking cycles, which can convert to opportunity cost and it can convert to hard cost actual money. Of course, there's a lot of things that we can do to address this problem of inflexibility. We've talked about many of them on the show before. For example, having a reliable test suite, an integration test in particular, might help you make changes more confidently. The word talks about something more nuanced about code quality and understandability. We'll discuss this idea right after we talk about today's sponsor, Square. Today's episode is sponsored by Square. Square APIs and SDKs make taking payments and managing orders, catalogs, inventories, or employees a breeze. Square supports pretty much every platform that you're probably working on, including iOS, Android, Flutter, and React Native for in-app mobile payments. Or you can integrate square readers from your own app. That means you can take credit card payments directly from your own app. Square also has an embeddable payment form for adding a checkout experience into a website. You can check out tutorials and learn more about the key concepts that Square uses like Item Potency on Square's new YouTube channel for developers. Head over to youtube.com slash square dev. That's youtube.com slash square dev all one word. Thanks again to Square for sponsoring today's episode of Developer Tea. So we're trying to flatten the cost curve. I highly encourage you to go and read this interview yourself because there's a lot more detail and a lot more to glean the key concepts that word cutting him uses when he's developing software. But this idea of lowering the cost to change or at least flattening out that curve so that change late in a project would be just as consumable as change early on. This is incredibly important because you're going to learn so much more about your application. You're going to learn so much more about your users or your use case. And it's possible that your application will look nothing like what you started out thinking it would look like if you respond to those changes, those external changes by changing your software. So what is one way that we can help flatten this curve out? Well it comes down to a very simple mindset when you're writing your code. Writing your code so that other people can read it or more specifically it's optimized for understandability for the reader. Now this is important because there's a nuance here that word points out and that is to not try to predict what the change will be in the future. This is the critical point that I want you to take away from today's episode. Don't try to predict what the change that a future developer, whether that's you or another person, what their likely changes will be. Fundamentally, if you already knew what those changes would be, then you would probably make those changes now rather than trying to predict what the changes will be in the future. So instead, what word says is to write your code so that it's easy to understand what your intent was. In other words, I should be able to understand what your code is doing so that when I need to make a change, I have a very clear reference point that I'm starting from. You've probably seen this happen in your own work where you leave a big comment explaining the implementation and explaining how you would go about adjusting that implementation because you anticipate some kind of change in the future. It's important to avoid this kind of thinking because as you begin to optimize your software for a future change, you're optimizing it against a different future change. The whole point of this exercise, the whole point of reducing the cost of change over the curve, in other words, flattening that curve out, the whole point of that exercise is that the future changes that you need to make are fundamentally unpredictable. So the takeaway, once again, as you write your code today and into the future, remember, the people who need to change it in the future, you don't know what they want yet. You don't know how to prepare for those changes. What you can do is make your code today incredibly clear. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Square for sponsoring today's episode. Head over to youtube.com slash square dev. That's the brand new YouTube channel from Square. Thanks so much for listening to today's episode. This episode and every other episode of Developer Tea, along with show notes and other podcasts that you might enjoy, as a developer, can be found at spec.fm. Today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.