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
In an interview with Bill Vinner, Ward Cunningham talks about flattening the cost of change curve. In today's episode, we're going to talk about a specific thing that Ward calls out that allows you to write your code to be more future-proof. My name is Jonathan Cottrell. 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 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 it increases at an exponential rate, since there's so many intermingled dependencies in a given code base. And in the interview, Ward talks about flattening that curve. Instead of increasing over time, the cost of change would instead stay relatively constant. And you can probably understand the intuition here. Imagine that you're programming. The whole idea behind 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. we have to unravel that code and perhaps change the entire structure of that block stack. And Ward 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. But Ward 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 and I highly encourage that you go and read this interview yourself because there's a lot more detail. A lot more to glean the key concepts that Ward Cunningham uses when he's developing software. But this idea of lowering the cost of 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 rest of the world. So you can do that by using the word reader. Now, this is important because there's a nuance here that Ward 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, you would probably make those changes now rather than trying to predict what the changes will be in the future. So instead, what Ward 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 brief note, a brief comment, and then you start to think about 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. And the whole point of this exercise, the whole point of reducing the cost of change over the curve. In other words, flattening that curve. 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, but 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 Cottrell. And until next time, enjoy your tea.