« All Episodes

Complexity As A Depreciating Asset

Published 12/21/2022

Complexity is an asset, but often it depreciates in value over time. Simplification strategies should evaluate what kind of value complexity is providing, and whether that could be replaced or if it doesn't provide sufficient exponential value versus the cost over time.

🙏 Today's Episode is Brought To you by: Square

Square has APIs for almost every aspect of running a business from employee management, to order creation and tracking, to inventory synchronization. Square’s APIs also integrate with software business owners already use like tax and bookings. so business owners can have an integrated software stack that empowers them to achieve their goals. To get started building remarkable business applications, visit https://developertea.com/square to learn more and create an account.

📮 Ask a Question

If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

📮 Join the Discord

If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

🧡 Leave a Review

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.

Transcript (Generated by OpenAI Whisper)

you probably treat complexity like the plague and honestly this this show is probably uh responsible for some of that for some of you the truth is complexity is often something to avoid something to stay away from something to put into a box to simplify but simplification is not in and of itself simple in today's episode we're going to talk about complexity as a strategic asset my name is jonathan cutrelli listening to developer t my goal on the show is to help driven developers like you find clarity perspective and purpose in their careers most of you especially senior engineers you know that a lot of the value that you create is in taking complex things and making them simple taking a complex idea turning it into a simple feature in fact this isn't just software engineers this is anybody who's creating software engineers this is anybody who's creating software engineers this is anybody who's creating a product it's anybody who's providing a service complexity is in many ways considered an enemy but i want to change your perspective a little bit on complexity and how it applies to our day-to-day work where we should put it in our mental model of our work when we think about complexity the things that spring to mind are bugs in our code we think about hard to uh hard to understand uh features we think about hard to understand algorithms code that we wish wasn't there at all and in fact often our prescription for complexity is to remove it to remove complexity is one method of simplifying let's think about this for a second complexity that doesn't provide value right this is very important to understand it's the core of today's episode complexity that doesn't provide value is something to get rid of this is a simple concept complexity that doesn't provide value is something to get rid of here's the important thing to understand about complexity it doesn't have to be cognitively complex to be considered complexity in other words any code that you have any root that you have, any energy that is being spent, anything that exists in your code base that doesn't provide value could be considered complexity. Even if it's low complexity, if it's not providing value, it should be removed. Now take this with a bit of a grain of salt. We don't necessarily need to go out of our way to remove boilerplate code that is not helping nor hurting, but that is complexity that we have to decide what to do about. That boilerplate code, especially if you didn't write it, and even more especially if you don't understand it, that represents a little piece of complexity. But complexity isn't always the bad guy. In fact, I want to give you a mental model for complexity that will change your relationship with it and hopefully provide you with a more mature model, a more mature model of how to deal with complexity. A mature strategic outlook on complexity itself. First, I'm going to talk about today's sponsor. Today's episode of Developer Tea is brought to you by Square. Just like all of the simplifications that we've been talking about in this episode, you probably imagine that Square is a simple service. It provides some way for sellers to sell their products, whether in a physical or digital format. And that's true. Millions of sellers across the globe use Square to run every aspect of their business, not just selling. They also use it for things like inventory. But there's some complexity that Square is not well suited to handle. Part of this is because there are specific customized solutions that are needed by those same sellers that don't apply to everyone or even most people. But if you could take advantage of that, you could grow your own business. This is where you can grow your own business. You can grow your own business. You can grow your business. You can grow your business. You can grow your business. You can grow your business. You can grow your business. You can grow your business. You can grow your business. By extending or integrating with Square using their free APIs and SDKs to build those custom tools for those sellers, you, in this case, will be capitalizing on the complexity. Go and check it out. Head over to developertea.com slash square to get started today. Thanks again to Square for sponsoring today's episode of Developer Tea. The complexity that we've been talking about in today's episode is that it's a complex system. It's a complex system that we've been talking about in this episode. We've not defined exactly why it exists in the first place. We've just said that if the complexity doesn't provide value, then you should probably get rid of it. But that usually isn't true. Usually, the complexity does provide some kind of value. It's just our job to determine what kind of value. And we do this in tandem with our various cross-functional partners like product managers or whatever the equivalent is in your situation. Maybe you are that person, but you need to evaluate what kind of value that complexity generates. More specifically, we need a good mental model to put complexity in its place. Because complexity can generate value, but if you could generate the same value with a simple solution, then the simple solution would be preferred. This is because complexity costs us over time. In this way, you could consider complexity as a value. And if you could generate the same value with a simple solution, then you could generate the same value with a simple solution. But if you could generate the same value with a simple solution, by default, if the complexity generated X amount of value over time, it would also generate a negative drain on your energy, which represents a negative value. So you have to do some kind of evaluation on what level of value are you generating? The good kind of complexity generates exponential value over time and at scale. If you can manage complexity, and that's the other way that we simplify, by the way. The first way is by removing the value of the complexity. And that's the other way that we simplify, by the way. The first way is by removing complexity. That will simplify your system. The second way is by creating good management of that complexity. This is what software, generally speaking, does. We take complexity and we encapsulate it so that you can access what is underlying a complex service, for example, in a simple manner. This is what an API does. This is what an algorithm, generally speaking, does. And as nice as it is for us to encapsulate that complexity, that doesn't necessarily mean that the people who are maintaining it escape the complexity itself. What it does mean, though, is that it provides a value to abstract away the complexity from the consumers of your service. Sometimes this is end consumers. Sometimes this is other consumers in your software system. And the question you have to answer is, is the maintenance of this complexity, is the management of this complexity producing enough value for the people who are maintaining it? And if so, then what is the maintenance of this complexity? And if so, then what is the maintenance of this complexity? And if so, then what is the maintenance of this complexity? In other words, let's say you had a big machine, a big machine in a factory. This is the mental model I want you to use for complexity. The machine takes up space. It uses power. It requires people to run it. It requires special maintenance. Sometimes it might require special replacement parts. And so having this machine, this complex machine, this expensive, big kind of lumbering machine in your factory, it's going to be a lot more expensive. And so you're going to have to have to have a lot more money. And so having this machine, this complex machine, this expensive, big kind of lumbering machine, this expensive, big kind of lumbering machine is not a good idea unless it's critical to your business, unless it gives you a competitive advantage. Maybe it produces some component that downstream in the process is absolutely necessary. Maybe it has a high quality of output. Whatever it is, that complexity, if it is generating sufficient value, is an asset. And so the good strategy, someone who has a mature strategy, doesn't come in and see the get rid of this thing. Instead, they say immediately, we must justify why we have it. We need to look at the upside of having this. Does it create a competitive advantage? What are the costs over time? Are there ways that we can better manage the complexity? Maybe we're exposing too much complexity outside of that machine. Maybe we're requiring all of the workers in the factory to know how to use it. Instead, we should manage that complexity better. So the challenge here is to avoid complexity as a rule. This can be a good heuristic to avoid complexity until you need it, but don't necessarily rip it out. Simplification doesn't require removing complexity. It is just one method of simplification. The other methods of simplification, especially managing complexity, should be considered, particularly when that complexity is generating exponential value, a competitive advantage. It's a critical part of the of your chain. That said, when an opportunity arises to generate a replacement value, even if it doesn't do a one-to-one replacement, even if it just changes your process, maybe it changes your product for a simpler alternative, now you no longer have that management issue. Now you no longer need to simplify and you no longer need to do that calculation. So finding ways to simplify, finding ways to remove complexity is a good idea, but don't demonize it. Thanks so much for listening to today's episode of Developer Tea. Thank you again to today's sponsor, Square. Maybe you want to capitalize on the complexity of all of the millions of businesses that are using Square today. All of those sellers, they all have their own complex problems and you can solve little parts of that market. Head over to developertea.com slash square. You can get started with their free SDKs and APIs today. If you enjoyed this discussion, if you would like to dive into the nuance with other software engineers, discuss things that popped out to you, ideas that came up in your mind when we were talking about this, go right now to developertea.com slash discord. That discord community is 100% free and this is a good time to be building your social networks outside of the other channels that you might be presently leaving. Thanks so much for listening and until next time, enjoy your tea. Bye.