Generally speaking, you've probably heard it said to you that iterative planning is the right way to do software development. And the justification for this is that iteration is agile, that it allows you to respond to change. And we're not going to get into the specifics of whatever process you're running at your team level. But I do want to talk about this idea, the dichotomy between iterative planning or exploratory engineering. Exploratory development where you may not have more than a sprint or two worth of work planned out versus something like target state planning. Target state planning in some ways may look like a waterfall plan. Target state is essentially laying out where you think things should go. And this in some ways constrains. The direction that your sprints might take, especially the initial direction. These two things may seem at odds with each other. And in some ways they are. Of course, if you're purely doing iteration, then target state is a premature planning step in some ways. However, they are not necessarily at two ends of a philosophy. It is possible. For example, to update your target state as you learn things through your sprint. But then you may ask, why would we need a target state to begin with? The best answer for that question is that it allows you to set a general direction. Think about your target state as more of a directional state in this kind of situation. But I want to kind of go through the types of... Kind of... Decision factors that you might care about. When you're trying to think through, okay, how do we want to plan our work? And I want to give you kind of a practical example of this. Let's say that you have some software that you've already developed. A handful of services maybe. And they all talk to each other. And maybe you have downstream consumers. You're receiving data from an upstream source possibly. And you have a handful. A handful of problems. Maybe your upstream data source is difficult to deal with. Or intermittent, for example. Or maybe your API has performance issues. The way that most teams approach this, this set of problems, is as atomic kind of issues. So we have the data problem. And we have the API performance problem. And we have X, Y, and Z. And so we may take time to fix each of these problems as we believe they are high enough priority, for example. And this is kind of an iterative addressing of the issues that we have. And this is a valid way of working. There's nothing necessarily wrong with it. But there's also other ways of thinking about this kind of portfolio of issues. For example, take a metaphor. Let's say you own a home. And you're wanting to make an improvement to the home. You want to replace your windows, let's say. This is kind of a crazy improvement to make, right? Cut all of the windows out and replace them with casement windows. So you make a plan to go through that process. And then you get to the end of it. And you realize, you know, I'd like to make another improvement. I think I'm going to change. The siding on my house. I want to go from wood to a composite material. And so you have the workers who finished the job and gave you the invoice. They have to write up a new invoice. They have to come out and do a whole new set of work. And then you say, you know what? I actually think I'd like to do some interior work as well. I want to upgrade my shower. I want to go from a tub and shower to tile. Right? And so you keep on having... I want to go from a tub and shower to tile. Right? And so you keep on having... You keep on having these one-off upgrades. And maybe even you have different people doing each of these upgrades. And at the end of it, it's very likely if you have enough of these jobs. And certainly if you have jobs that look kind of similar to each other. That may have, you know, finishing work that overlaps with each other. It's possible that you have different looking outcomes. Right? That you're... You know, the finishing... The finish on one job is a little different than the finish on another job. And this kind of piecing together, right, of improvements over time, the comparative version of this or the alternative that you might instead choose is to evaluate, okay, what are all of the things that I would like to do? Are there multiple improvements I want to make all at the same time? Right. Right. Right. If they have all of the tools or the materials to do two or three jobs in the same kind of trip, then they can coordinate and reduce the cost in that way. They also are likely to plan the features that you're looking for, the improvements that you're looking for, plan them to work better together. If you're using white paint in one room and you want white paint in another room, they're going to match the type of white. They might match the finish type better than you would if you were to do those rooms separately. The idea is that some upfront planning about that kind of job may be useful. There may be a useful case for that. Let's talk about some of the decision factors. That story. Should give you some idea of what the decision factors are. When you might favor iteration planning, when there is high uncertainty, right? If there's high uncertainty about the problem or about what the users need, then you might lean towards iteration. And the reason for this is that you're going to be looking for what the users need through feedback. You're going to do that in either case. But if you try to make a guess, a large guess. About what users need or what the problem really is, then it's a more expensive guess, right? It's a more expensive endeavor. If you do have a lot of clarity on the problem, then that investment is more likely to make sense, right? It's more likely to be correct, right? So what's another decision factor? The nature of the work. The nature of the work. If you are doing learning-focused work, right? If you're doing things like discovery, if you're building prototypes, proofs of concept, those kinds of, that kind of work is obviously more suited for iterative planning, for iterative and discovery-type planning. On the other hand, you might prefer target state planning if it is directly in production, right? Or if you're already working on something. Something in production. Something that has a lot of coupling would be another reason to favor target state planning. Because the decisions in one area have strong impact and they constrain other areas. So as you begin to iterate, you recognize that the dependency between those things is causing a larger design effort anyway, right? You're taking on more risk if you do that without designing at a larger scale. So you're going to take on more risk if you do that with a larger scale. Regulatory, safety, risk-sensitive context like aviation, healthcare, financial payment-type systems. These are situations where you can't get half of the requirements in place, right? There's regulatory requirements and you can't go halfway on that without incurring potentially even legal risks, right? If you have fast-testing systems, you're going to take on more risk. If you have fast-testing systems, you're going to take on more risk. If you have fast-testing systems, you're going to take on more risk. feedback loops already in place, then you might favor iteration planning. If you have good observability, if you have users that already are providing you feedback, then iteration may be a useful direction to go. As a general rule, the more certainty or the more stability that you have, the higher the cost of mistakes that you have, these are all things that would lend to target state, right? Target state planning. Higher cost of mistakes in this case means, you know, in your iterative planning, you may take a swing that is not super well thought out, right? You didn't do a ton of discovery on it. Instead of doing that discovery, you are learning through the iterative planning. So, if you have a lot of mistakes, you may take a swing that is process of shipping something and getting feedback. And the cost of failure being very low in that situation is beneficial because you want to be able to fail in iterative planning. So, you're going to ask a series of questions. You're going to ask, what type of problem are you solving? Is it a discovery kind of problem? Is it a POC? Are we scaling an existing system? Are we building something that has a lot of clarity? You're going to look at the cost of mistakes, right? How painful is it to, to turn in the wrong direction? You know, can we, can we learn cheaply by shipping something and testing it right away? Or, or is that, you know, is, is that cost much higher than we expect? What is the, what is the scope of the impact? Are you doing this work only within a single team, right? The, the more people who are involved, the more likely it is that iterative planning is going to, to stall out. You're going to need to do a little bit more upfront design. You're going to need to do a little bit more upfront design. Feedback mechanisms. How fast can you learn, right? How, how, how quickly do you get feedback? For example, if your business operates with very long business cycles, if your customers have very long business cycles and you're not really going to get a very high signal on whether your new features are very good or not, except at that year long scale, it's very likely that the feedback timing is, is a critical factor and you might want to lean more towards target state planning rather than iterative planning. And then what, what is the coordination cost? If you, if the coordination cost is low, right? If, if it's all within a team, like we mentioned before if you have your stakeholders that are local to you, if your ability to make these changes and test them. And, you know, when we say this, this alignment cost, this coordination cost, it's not just about coordinating with your team. It's also coordinating with your users. It's coordinating, you know, with, with the resources that you're using. So if you have, you know, an external API that takes a long time to get, you know, some kind of change made on that API, for example, these are all reasons why you may want to lean more towards a target state planning. Whereas if the coordination costs are very low, right? If, if you're, you know, like I said, if your team is more local to you those, there's not a lot of external dependencies, then you may lean more towards iterative planning. Ultimately it's a red flag or at least a yellow flag, a warning sign. If you are choosing one of these by default, right? It makes sense to consider how much upfront, upfront planning is useful and to not be afraid of that through some kind of dogfight. That upfront planning is somehow going to limit you, right? It's very possible that upfront planning is actually going to enable you. And you know, in, in either case, you should set yourself up so that as you learn things, you can adapt your plans. Just following a plan because it's a big plan because it's a target state is not a rational choice, right? The, the reason why those upfront planning is going to limit you is because it's a big plan because it's a target state. So, you know, the reason why upfront plans have received so much negative feedback is because the cost of building the plan itself, in many cases, the plan, the likelihood that the plan was correct was very low and it was costly to generate. So changing that plan, there's a lot of friction to changing it because there's a lot of sunk cost in building the plan in the first place. So a lot of this, you know, a lot of the ideas that you hear or the negative perception, and perspectives of something like waterfall, in this case, we're not really talking about waterfall per se, we're just talking about planning a little bit more upfront. The negative perception of that is driven primarily off of those, you know, those early stage projects that would have benefited more from iterative approaches. That's not always true. All right. There's, there's not always true. And it is a spectrum, right? Um, you shouldn't necessarily think that a target state has, should be, you know, six months or six years down the road. Um, this is more of, of a spectrum than it is, you know, a, a, a pure dichotomy. Thank you so much for listening to today's episode of developer T. I hope this was insightful. I hope you will be able to think about, uh, your team and, uh, you know, the way that you're planning these projects out, uh, whether that's in your work and your life, you know, how much upfront design should you take on? Consider these questions that we talked about today, and you're likely to make a better choice. Thanks so much for listening. And until next time, enjoy your tea.