Crafting Code Podcast

[00:00:16] Allan Stewart: Welcome to the Crafting Code Podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking about breadth and depth in video games. Replaying ones I already own versus exploring new ones.

[00:00:33] Dave Adsit: And I'm Dave Adsit, a VP of engineering, and recently I've been thinking about the relative value of story versus mechanics and world building in fiction.

[00:00:44] Allan Stewart: Our topic for this episode is commitments. And when I think about commitments, the first thing that it makes me think about is the desire that I have as a software developer to be perceived as a professional. Because if I'm not going to act professionally, then commitments probably don't matter. But if I do want to be seen as somebody who takes their craft seriously, somebody who does a good job that you can trust to do what is needed, and that, you know, I'm not going to be sandbagging my work or spending half of my day looking at cat videos on the internet or whatever it is that people want to do. It's important that we have that level of professionalism. As kind of a baseline.

[00:01:31] Dave Adsit: Yeah, I like to think about other professions that we interact with. The ones that come to mind are, I mean, first of all, lawyers, doctors, even your typical blue collar professions like construction, electrician, whatever. And when you are working with those people, you expect them to say what they're going to do and then do what they say. Because we don't understand their job or how to do it or what it means. I mean, you go to a doctor or a dentist or a lawyer and you're like, this is expensive. And I have no idea how to validate the work that they're doing. Is it the best that it could be? Is it what they said it was going to be? Whatever. And so when I think about professionalism from the perspective of software developers, I think of a lot of those same concepts. You know, fulfilling your obligations and commitments is a critical aspect of behaving professionally from my perspective. Absolutely.

[00:02:40] Allan Stewart: And so as I think about that, how much control we have over a task, I think plays greatly into a commitment because I always want to be aware of committing thing, committing to things that I don't control or cannot control. And in cases, when I think about commitments, a lot of a lot of the time, that's what it turns into, right, is commitments are some kind of question, something that is being asked of us. And so there is a level of commitment to are you committed to the work that we're doing? Are you committed to the product that we're building, the company that we're building? But most of the time when there are questions, it's well, how long is this going to take? And can we have something done by a certain time?

[00:03:30] Dave Adsit: Right. Yeah, that's what it comes down to me all the time is the one that the one that I think about the most is can you do this by this date? And for a professional, there are really only two answers to that. One is yes and one is no. And a lot of the times we struggle with no, even when we know it should be no, partially because people who don't understand what we're doing are going to. Try to coerce us. They're like, well, maybe they're just not doing their best or going as fast as they can. I mean, when we were early on in this company, it seems like we got features so much faster than we do now. What's different? Why are they going so much slower? They must not be. They must not be working hard. And so people who don't understand what we do will start to apply pressure and then very likely someone on the team will say those. Dr. Clay Clay. Can you get feature X done in two weeks? Can you get feature X done in two weeks? Can you get feature X done in two weeks? Can you get feature X done in two weeks? Can you get feature X done in two weeks? Can you get feature X done in two weeks? Can you get feature X done in two weeks? elected come hell or high water. And that's not the right way to say yes.

[00:05:03] Allan Stewart: Yeah. There's a difference in communication there, I think, because the person who eventually breaks down and says, we'll try, is meaning it as a soft no. It's like, no, it probably can't be done, but we're going to work on it. And if we get lucky, it's possible.

[00:05:26] Dave Adsit: Everything aligns and we cancel a few meetings.

[00:05:28] Allan Stewart: Yeah. We believe that there is a possible world, right? If you roll your D20 and it comes up with a 20, well, in that case, it could happen. So we'll try. We'll roll the dice. But that's not what is heard, right? What is heard is, okay, they said they would do it. Yeah. I finally got them to say they would do it. I got them to say they'd stop being lazy. Yeah. Trying means that they're going to work nights and weekends. Trying means that they're going to reschedule the meetings and they're going to do whatever it takes, right? They're going to go and hire some extra people or get a consultant or I don't know what it means, but it means that they're doing something. Yeah. And when we say yes as professionals,

[00:06:18] Dave Adsit: we need to say yes and mean yes. And sometimes saying yes comes with caveats. And sometimes saying yes comes with exceptions or exemptions or whatever. And one of the things I'm thinking about here is that sometimes saying yes starts with no, meaning what you are asking for is not something that we can do within the timeframe that you want. However, what we can do within the timeframe that you want is this most important subset of the thing you asked for. Will that work for you this time? And so we need to try to find a yes inside of a no when no is the correct answer. So we don't want to commit to something that's impossible or that we think we're going to fail out, but we do want to find a way to collaborate with the person requesting the work so that we can find the yes that they need. So, or so that we can understand together, what is possible and what is likely. And so that kind of leads into the, the idea of, of giving rough estimates, right? Can you do this in two weeks? It's like, I'm going to, if I say in the best case, I can do it in two weeks, but in a more reasonable case, it'll take three worst case. It'll take six. Does that make sense? Let's talk through all of those reasons. And like Hit the best case and what is much more likely and what it would look like if we hit the worst case. And so now where we are collaborating on what the commitment can reasonably be. And so that now we have now, now the hard work of call it negotiation begins where we say, Hey, this is, this is what you are likely to get. Um, and a lot of that comes down to, to negotiating kind of scope and schedule, uh, and, and what a yes looks like given various

[00:08:33] Allan Stewart: scopes of work. I really like thinking about it as a negotiation, partly because oftentimes what happens is that there's a lot of assumption built into a question around making a commitment that goes unstated. So the person that's coming to ask a question, they have some assumption. Right. They've got things that they're thinking about. It might be when the next, um, you know, marketing push is going to be, or the next conference or trade show or something like that. And they want to have an understanding, Hey, can, will we be featuring new feature out in, you know, on our banner at the booth next week, right? They want to be able to know these things, but meanwhile, the developer might have a very, very different thought about, okay, what does this take? And what is it going to require to be able to build this feature? Because they said they, they use some terms like, Oh, I, I just want feature X and the developer looks at X and they think, Oh man, that's huge. And the person asking only thinks about like one small facet of, of that. And so you've got to start breaking it down away from the binary mode of, well, it is just yes or no binary. You can either have it all, or you can have nothing because that's not very realistic. And when you tell them they can have nothing, then they feel bad. And if you say that they can have everything and then they don't get everything, they also feel bad. And so you've got to start breaking it down in that negotiation, which makes me think about, um, that idea from like impromptu, um, uh, improvisational acting kind of stuff where they say, uh, yes. And, or no, but so when, when they come at, And then someone comes and asks you, Hey, can this software thing be done? No, but a part of it could, could be done, but couldn't you tell me why you want it or like, start, start digging into that. And, and even with the, yes, like you were saying, yeah, we're going to say we might say yes, but you got to understand that yes, it's still a gradient. It's not a hundred percent guaranteed. You're going to get everything. It's like, yes, we will do this and try to do this. And we might get to the third thing, but the first thing is, is the, you know, is, is that understanding of definitely this possibility, this remote possibility that.

[00:11:05] Dave Adsit: One of the things that I think about in this case is when someone comes to us with a scope of work in their head, it may be written. A lot of it's probably still being imagined. And I think from the perspective of the professional software engineer, you're thinking, why do they always bring me these huge batches of work and these very tight timelines, and it's impossible for me to get it done. And they still demand that I say yes or commit to it regardless. If you flip that, if you engage your empathy and, and see it from the perspective of the person who only gets to ask for one software project, a quarter or a year, and now they're finally, it's finally their turn. Their project has been prioritized and they've come in and they're like, okay, I have to get every single scope, every single piece of scope or bit of scope for this feature for this product, because it'll be another year before I get these developers, they work in these big quarter long batches and it's my turn and it won't be my turn again for until the next year. It's everything I've ever imagined. I have to ask for it now, or I'll get nothing or what I get won't satisfy the needs of my users. And so that's where there's a lot of things that we can do as professionals that make those commitments easier to make. And, you know, we talk a lot about working in small batches and working iteratively, right? If I can say, Hey, let's take this apart. Let's find the, let's follow the 80, 20 rule that everybody in business knows. Let's find the 20% of the pro of the solution that creates 80% of the value. And let's get you that as soon as possible and put it in your hands. Let's, let's find a way to give you that piece. And then we can start talking about the other 80 percent. And that actually enables us to start working overall as a system in a different way. But even if your system can't adjust or won't adjust, you can still meet the bulk of the need by focusing on the most critical component of what's been asked for. And now whether you met the full commitment of delivering a hundred percent of the scope or not, everybody's going to feel a lot better about the interaction and about, you know, the, the, the, the, the, the,

[00:13:54] Allan Stewart: And that assumption was still lingering. You've got to really work through the communication to make sure that the message being sent is the one that actually has received and that the message that you sent was the one that you intended to send in the first place.

[00:14:09] Dave Adsit: Well, and that's very much the case, right? We have said for years that communication happens at the listener's ears, not at the speaker's lips, right? What I think is filtered by what I say, what you hear is filtered by, you know, there's various filters that everything passes through before you actually receive a message from me. And so we have to make sure that we are doing diligence on communication. To ensure we're doing things like the active listening technique of replaying what you think you heard using different words to make sure that the other person still agrees with you, because then you know, you have a higher probability of having communicated effectively between the two of you. So one of the things that I like to think about when it comes to saying yes, saying no commitments is that what we've been talking about so far requires work on both parts. And a lot of times. It just feels easier to coordinate around a date. If we just say, let's just schedule it, then we can avoid all the hard work of negotiation, all the hard work of scope management, all the hard work of workforce management. And we just say, hey, we're coordinating around this date. And for a lot of things in business, that works pretty well, right? We coordinate on what date we're going to pay our bills, pay this bill or ship this product. You know, a lot of things are coordinated around dates. And so we just think we should be able to do that for everything. And there are certain classes of work that that's just not a reasonable way to do it.

[00:15:50] Allan Stewart: Yeah. Skip all those hard discussions and go straight to the dream reality where you think it's going to get done up until the day of, and then you're sad that it didn't get done. Skip straight to that.

[00:16:05] Dave Adsit: Well, and that's the thing, right? Is that we talk about deadlines a lot in software. Development, but you just said a critical word there. Sad. Almost none of our deadlines are real. Meaning in almost zero cases in software development, will someone die if we don't deliver the feature on the day we've said we would? Will people be sad? Yeah, they will. Maybe even angry. So I, I like to talk about a lot of deadlines just as though they are sad lines. That's the term I use. Oh, that's not a, we don't have a real deadline. We have a sad line. Even a, even a real deadline, like a conference that we've bought a booth at that we need to deploy software at. That's probably still a sad line. It's a very sad line. I like to think of those as real deadlines because we can't move it. We didn't pick it. We're just, we're committed to it by external forces where, you know, a lot of the deadlines that we have in software development, they came from nowhere. They're just wishful thinking. Right. Or maybe. Or maybe somebody extrapolating forward from, Hey, when we did this type of work in the past, it took us about this long. So it should take us about that long again, even though all the context has changed, but I'm still going to commit us to this deadline because I think we can probably still do the same amount of work in the same amount of time. And I think that it's the same amount of work because it kind of sort of looks like work we did before.

[00:17:31] Allan Stewart: It's not just people who fail to die at the deadline, but also the business, right? A company. My experience is that when a deadline is not met, it is very rare that there is major disruption to a business. And the converse is also true that when you achieve the thing by the deadline, it's very rare that it makes a dramatic and sudden difference to the business that, you know, Oh, if we miss this, we're dead in the water. Our competitors are going to, you know, beat us down. it, yeah, I don't know that the thing that you just built is going to actually be that killer feature that turns, that really moves the needle, right? It's usually iterative progress on the software rather than this one weird trick that you won't believe what happens next.

[00:18:59] Dave Adsit: Well, and that to me goes back to the idea that we can make massive progress in a single bound, right? We do tend to make more progress incrementally than through leaps. And even when you look at the history of science, even when we think of great leaps forward, if you go back and analyze it, you realize, oh, that was actually the next logical increment from where the science had been before. Uh, I, I can't remember the exact number, but the year the light bulb was patented, a bunch of other equally good light bulbs were patented. The year the Wright brothers flew for the first time, several other people also flew. In fact, there is some debate over who did it first. They get the credit, but maybe they don't deserve all the credit. I mean, they did it independently, right? Everybody was working from some of the, some similar, the similar state of the, the universe, the state of science, the state of our human understanding. And the next logical increment was to try some things and then figure it out. And of course the Wright brothers had a fantastic, uh, working model. We've talked about this in the past. They, they were working in very small increments with very, that, you know, they're like, try something. Okay. Adjust it right now. Try it again. Very tight feedback loops. And so that is a fantastic way to make very rare that you are going to create a killer feature that puts another company out of business immediately, or that you are going to create a killer feature that doubles your revenue overnight. You're going to find it's a lot harder work than that. It's much more incremental.

[00:20:43] Allan Stewart: It reminds me of the iPhone when it was released. One of the criticisms was, well, it's nothing that new, right? Technology-wise, it wasn't like they had brought down some new technology that just received from the aliens and we don't even know how it works. No, it was all based on things that had been evolving over time. It just happened to hit at a time that did cause a revolution, right? I mean, phones do not look like my flip phone or some of the old Nokia cell phones that we had before the iPhone. Everything has changed, right? Definitely, it made an impact. But even then, it wasn't an overnight thing. It wasn't that everything changed all at once. It takes time. And there are plenty of other phones that are Android-based or something else that have similar features because it was technology that had been iterating over time.

[00:21:46] Dave Adsit: Well, and that's still the case today. If you compare a 13 to a 14 to a 15 to a 16, you'll be hard-pressed to find any radical differences. If you compare a 16 to a 14 to a 15 to a 16, to an eight, you might say, oh, wow, we have made a lot of progress over time. But at each individual step, it's going to look a lot more subtle. Right. So we have deadlines. They show up. Why? And what leads to deadlines? And I say that one of the things that leads to deadlines is estimates. When we talk in terms of commitments, people ask us, well, how long? And then we give an estimate, usually the most optimistic one, one we can imagine because we want to please people. And then that estimate turns into a deadline in a lot of cases. So let's talk a little bit about estimates. What's the deal with estimates? Like there's estimates have been part of software forever, but also no estimates is a thing.

[00:22:44] Allan Stewart: Yeah. The thing I think about most often when it comes to estimates is that software tends towards the new. It's code, it's software, and so it can be copied and pasted. And so as soon as you can do something reliably, repeatedly, it gets automated and then you don't worry about it anymore. That's just, that's just another thing that the computer is doing for you. And so most of the time, software developers, I feel like are doing new things that have never been done, at least not in this company, in this code base. And so it becomes very difficult to, you know, how long anything will take. You were saying before that there's, we think we will often think about, well, I've done something similar before. And so I'm going to base, you know, when I'm trying to say yes to somebody, yes, we can do this. I think we can, because we did this other thing that was kind of like it, but it's not exactly like it. And that makes the whole estimation process difficult. And then on top of that, there's so much variation in the world, right? Yeah. There's the unplanned work, the bugs that you received, that you were not expecting. There's the fact that Lisa was sick today. And so you can't actually get something done that you thought you were going to get done. And so you're making this guess, trying to predict the future based on a past that is at least somewhat irrelevant to what you're trying to accomplish now.

[00:24:23] Dave Adsit: Past performance is no guarantee of future results, right? Yeah. That's what we say in the stock market. We also need to say it in software development. You're exactly right. Software is the process of building a machine to do a thing. And if we've already done it, then the machine already has the capability of doing the thing. We don't need to do more software. We just let the machine do it. And so we are almost always doing net new things, maybe for the first time, maybe just for the first time in this company, like the only part of the part where the machine is working. But the only part where the machine is working is the part where the machine is working. But the only part where the machine is working is the part where the machine is working. But the only part where the machine is working is the part where the machine is working. But the only part where the machine is working is the part where the machine is working. faster? If we do it incorrectly, will we break a while we're building a prime? All of these things become that even if the features are very similar, a lot of things in software become problems because it all goes back to those original two concepts of coupling and cohesion.

[00:25:40] Allan Stewart: Yep. And they become constraints because as soon as you've built the first feature, well, that constrains your options of what you can do in the future, especially if you want the system to continue running. If you're okay with move fast and break things and the product is going to be in a mostly broken state, well, then you can get a lot done very quickly. But if you want things to continue working, I think that's the answer to the question that you raised before. When somebody comes asking, can you please? And you say, no, it's going to take longer. And they're upset. They're wondering, well, why? It used to be when we first started this company, and there was nothing holding us back, we would develop features so quickly. We didn't have any customers, and we didn't have any code. We didn't have any features. But all of those things become constraints as you move forward. Oh, well, we can't actually change this code because, you know, big customer that we always try to please is dependent on a behavior of how it works. And so we've got to leave something in place. Or just the fact that we've got 300 features where there was only two before, that's a constraint that makes it harder to accomplish what you're trying to accomplish. And so when it comes to being asked for an estimate, the first thing that I like to think of these days is not kind of stopping down and saying, okay, well, how long does this take? What have we done that's similar? How optimistic am I feeling today? But rather, I start thinking about, why are they asking me for this? Because there's oftentimes understanding the reason for the question helps out a lot. Because sometimes working with product people, they'll come in and ask me, hey, could we do this? Would that take very long? And if I say, well, no, that's probably going to be a few weeks of work. They're like, oh, never mind then. I don't even want it that badly. I was just wondering if it was something that we could get done today. And if it was just like, low-hanging fruit, that's cheap and easy, then let's just do it. But if it's not, then forget about it.

[00:27:52] Dave Adsit: Yeah. I think that that's a very good technique to develop as a professional software developer is doing a little bit of discovery with your users, who may be your product manager, of what are they trying to accomplish? And what can, I mean, you really have to get back to that whole discovery and negotiation process of what can we do to meet the need? You know, we talk a lot about how in software development, we are often presented with fully baked solutions that may not be good or efficient. And then if we want to do good work, sometimes we have to take that solution and work backwards to what problem it's trying to solve. And then work forward again from that problem to a reasonable solution that meets a lot of criteria, including criteria like it's really only worth about a three day investment. Yeah. So what can we get done in three days, not three weeks. Right.

[00:28:52] Allan Stewart: And you start finding out things as you start asking, well, why, why are you asking? Oftentimes it's just wondering, because going back to what you're saying at the beginning about being a professional, we want to be treated like professional that we know what we're doing. Well, part of that is that people who are not in your profession don't know. They have no idea. Because to them, it all just looks like a pretty, you know, web browser screen or the neat thing that bounces around on the phone screen or whatever. And they're only seeing like a very thin facade of what the software is, or it's the iceberg principle, right? They're only seeing the tip of the iceberg and they literally don't know. And so you can help educate them and inform them. Other times it's because there's some other objective like the sales conference that is going to be happening and they want to be prepared adequately. And so asking them, well, why can help you to figure out where to start in that negotiation process? Because it might not actually be an estimate that they need in order to understand what they need to understand.

[00:30:03] Dave Adsit: So one of the things I think about is that estimates become commitments. When we give an estimate, whether it's a best case, usually a best case estimate, or even an average case a common case estimate. Those implicitly become commitments. That's like you've accidentally committed to something, whether you meant to or not. So if you say, I think this will take about a week, what was heard is I will definitely 100% have this done in a week. You can count on it. You can print the marketing material. You can plan the week at the work for the week after already, because you know that when I said, I think probably this will take a week, that means guaranteed for you one week.

[00:30:49] Allan Stewart: One week from today, not even one week after we start it and we can't start it for a week.

[00:30:57] Dave Adsit: Right. Yeah. And so that is one of the tricks, right? One of the things that I've learned is that when we estimate software, people often think about it in terms of the scope and the time. I mean, it's scope and time. How long will it take to get this scope delivered? And so there's constraints. And so the estimate becomes a constraint on time. Unfortunately, most of the time in software development, we are working towards a scope. People imagine what they want the software to be, and it's not done until it does all of those things. Or worst case, you are building system two and system two is not done until it does everything that system one does and everything we add to system one while you're building system two and a few things that we imagined along the way. So the scope of system two is an ever growing target, right? So we can work with two types of constraints. One is the scope box, which is what I just described. It's the set of features the system has to have before we can ship it before it's done. And the other is a time box where we say, Hey, we're going to work on this thing for one week, three weeks, whatever. And at the end, we'll reevaluate where we are. And make a decision of whether we should continue or whether we should change direction. And that is, that is a challenging decision to make because most of the time for most of the work, people assume that you were working in a scope boxed way, but true engineering occurs when we start thinking in time boxes, where we start putting the constraint on time and saying, Hey, we're going to work for a week and then we're going to evaluate our progress. And we're going to make a continue or stop decision on whether to keep doing that or not. And that's a challenging And that is where your true engineering happens. You are working. If you are working on the highest priority thing, then at a certain point, it's easy to say, you know what you did the 80% that deliver, you did the 20% that gave us 80% of the value. And then for the remainder, you did the 20% that gave us the 80% of the value. That's enough of the value. What's left is edge cases. And we don't, we don't want to keep investing to get to those edge cases. And we definitely don't want to invest in gold plating this feature that's already ready to be delivered. Right. And that is something that we, we too often do as engineers, where we, we get comfortable working on a certain feature and we just keep, we want to keep working on it and working on it and working on it because we feel comfortable. We're gold plating. It's unnecessary. We could be moving on to something else, but either we got done early, unlikely, or we've given up on the schedule entirely. And so we can just keep working. Working on it forever.

[00:33:48] Allan Stewart: Yeah. I find it interesting that in my past, and I've just been just thinking about this now, as we're talking about it in my past, I would often be working towards scope and have a scope based approach. And yet what I kept finding is that more and more, I wanted to make things smaller, break it down into smaller batches, make it so that things will not take as long. And so that you can get some nice vertical slices done. Right. So this isn't just like the database task, and now there's a new table in the database, but nothing writes to it and nothing reads from it. So who cares? But actually there's a vertical slice of functionality. And as you do that, it's kind of almost like taking the limit, right? Like you, you make those things smaller and smaller and smaller until time, it becomes kind of a time box based way of working. You're thinking about it still in scope, but really you've carved it up. So that each piece is just a small time box and you can stop after any given one. And that is how I've kind of tried to move myself to work. And I just didn't realize that it's just around the corner from, we'll just use a time box, spend some time on it, see what you get done and then decide, are you going to continue or not?

[00:35:06] Dave Adsit: Yeah. Well, and we're kind of talking about alternatives to the concept of estimating a thing I want to talk about before we move too much further into alternatives is the idea that sometimes we'll make a commitment based on a scope and then the scope will change. Whether the scope of the thing that we're actually working on, you know, product feature A is growing or equally likely we're working on product feature A, we've committed to have it done in two weeks or two months, more likely, right? We said, we will work on this. It'll be done in two months. And everybody says, that's fantastic. We love that this will be done in two months. That is a fantastic commitment for you and for the business. We'll all be happy if that's done. By the way, here are 100 bug reports that just came in and I need you to get those done in the next two months as well. Right? So now we've got a problem because if you say, Hey, Hey, Hey, Hey, Hey, no, that's out of scope. I can't do that. Well, that's bad for the business because we need to meet the needs of customers. If you say, well, now I have to move the schedule, back two months because you just gave me two more months of work to do in the same time period. And I'm only one person or one team. Well, now that's going to trigger my loss aversion. I'm losing something that I had, which was this commitment that you would get work done. And that's going to make me very sad. And so this is one of the things that when it comes to scope boxing, I, I have had this struggle with scope boxes. You know, if you scope box, then time is variable. If you time box, then scope is variable. And so, I have had this problem over and over and over in my career where we committed to a fixed window of time based on a fixed scope. And then the scope changed and now everybody's unhappy. I'm unhappy because the scope is too big. You're unhappy because I changed my mind about giving you something on time. It's all a problem. And so I like to talk about these alternatives. The first one we've already talked about, you, you went into detail on time boxing. And I liked that you were it to the limit. It reminded me of calculus. What is the area under the graph? Well, let's just cut it into a whole bunch of thin rectangles. And I want those rectangles to be one day wide, please. Every day, I would like to deliver one piece of value. So that kind of leads into the first one or one of the alternatives, which is single piece flow. We'll work on this small batch and nothing else. Because if we put a hundred percent of our effort onto this one thing, we will deliver this thing as soon as possible for our team and skillset and tools and everything, right? Given our context, if we work on nothing but this, and we put a hundred percent of our available effort onto this thing, this one feature, we will deliver it as soon as is reasonable. And with as high as quality as possible too. And likely as high as quality as possible. And that allows us to do the, like, that allows us Right. Instead of that person that we were talking about earlier, who gets one quarter a year to get their software worked on and they have to wait a year to come back. Well, now we're doing this on the level of days and we're going to work instead of having four, serving four departments, one quarter a year, we're serving four departments every single week. That changes the entire dynamic

[00:38:37] Allan Stewart: of product development and software development. Yeah. And I think it also makes people less likely to double down, right? You were saying before that everybody gets really fixed on their date, their schedule, and they'll feel bad. Their loss aversion gets triggered when that's not going to happen. Well, but the problem is a lot of companies, like they take it to the hilt of scope-based, fixing scope and time. You gave us this one date and we're going to use that to project the next date and the next thing. And pretty soon you have the Gantt chart that has the entire product roadmap with all the integrations between all the teams. And I've just never seen those actually

[00:39:22] Dave Adsit: work. Inevitably, it will be wrong. Those tend to only work when we pad the schedule substantially, when we create enough slack in the schedule that if something takes two or three times longer than anticipated, we can still get it done before it has to be done. And that is a very inefficient system to work in. It's not a lot of fun to work in either because you spend a lot of time idle or a lot of time scrambling because your date is far off in the future and you're already done or it's not coming or it's coming too quick and you have more work than you anticipated. So single piece flow is a way of handling that, especially for a single team or a small team. Single piece flow is a great way of saying, hey, we're going to get this done for you as fast as possible. We're not going to do any distractions until it's done. And we're also going to cut it into a small batch so that when we get to the end, we can do something else that's unrelated because we know customer requests are going to come in or whatever. Another thing that we can do, and this works especially well if we're doing small batches, if we're breaking our work down into reasonable sizes, even if they all add up to some great big feature, we'll break them down into small pieces that can eventually be combined into this giant feature, is to run MonteCarp. MonteCarp is a little bit more of a ! MonteCarp is a little bit more of a ! MonteCarp is a little bit more of a ! MonteCarp is a little bit more of a! MonteCarp is a little bit more of a! MonteCarp is a little bit more of a! MonteCarp is a little bit more of a! MonteCarp is a little bit more of a! to them uncertainty, which is helps with communicating with people outside of the software development team is like, Hey, 80% confidence interval, not a hundred percent, just so you know, to get a hundred percent, you look, we'll get these 30 things done in the next three weeks with 80% confidence. If you want a hundred percent confidence, notice that that number goes out to like 140 days. So instead of giving you that crappy 140 day estimate that you're going to be really upset about, I'm going to tell you, Hey, it's probably a lot less than that, but if everything goes wrong, it could be really long, really far from now

[00:42:53] Allan Stewart: before we get this done. I think that this method may also be a lot faster than most ways that people I have seen do estimates in the past, right? In the past, I've gone through and say, okay, well, let's, let's break down this problem and, and try to, to figure out, okay, well, we're going to design a table schema. We can probably do that in a day. And Oh, we're going to have to write this code or we're going to have to integrate with this API. Okay. We're going to need, you know, a couple of days to read through the documentation. And like you, you, you try to break down the task into all these smaller parts that you can actually get a hold on because it just mentally, it's so hard to think about the whole scope of everything that needs to be done, but the, but the pieces don't add up to the whole, and it takes a really long time to break it down and try to figure it out. And so if you have something like a ticketing system that keeps track of the cards or the bugs or whatever it is, and then it can give you some data back on, well, how long did these things take? I think doing the Monte Carlo, yes, it's going to take you a little bit of time to do it the first time to figure out, okay, how do I pull that data that I need out of this system? And then how do I run this Monte Carlo simulation? And probably hopefully finding some tools online or example code or something, or ask your AI to, to do it for you, I guess, I don't know. But even that it's going to, it's going to be so much faster and then you can do it again and again and again, instead of trying to break down a new task every time and getting it wrong every time. I mean, I like to use a digital Kanban board

[00:44:35] Dave Adsit: that has Monte Carlo simulations built into it. So that is my trick. That's my trick. It's very helpful. So one of the other alternatives that we haven't talked about yet is thinking in bets, which is to say, state upfront what it is worth for you. I mean, how many times have you worked on something for three weeks and come back and said, okay, it's finally done. And they're like, man, we really wish this has only taken two days. If we'd known it was three weeks, we wouldn't have done it at all. And what I like to do in those cases is start flipping the conversation around and saying, what is this worth to you? So tell me, do you only want us to spend three days And if you know what it's worth for the business, if it's a good investment at two weeks, it's a bad investment at four, because we know it costs us, you know, $24,000 fully burdened to run a dev team for every week they work on this thing. And so it costs 50,000 to develop it in two weeks, and it costs 100,000 to develop it in four. And we don't think it's going to pay back 100,000 in the first two years. We think, you know, whatever, somebody might be doing that math What is it worth to you to get this done? And if they say it's worth three days, fantastic. Here is what we can get done in three days, or we are going to do the most important part of this over the next three days. What is the most critical part of this so that we can actually get it done? And so we focus on the most critical part. And then we deliver that in hopefully our three days, whatever we get done in the amount of time allocated was the most important aspect of it, because we had previously agreed that that was the most important aspect of it. And if it takes a lot longer than that, then we just cut it off because we know we've already spent the budget for this. Our budget for this feature is two weeks worth of work. And if we can get it done in two weeks, fantastic. If we can't now, if we've done the most important parts first, we can say, hey, we're going to ship this feature, which there are still things we could iterate on to improve it, but it's good. Good at what it does. Or we could say, you know what, based on what we were able to get done in two weeks, we're just not going to ship it. Let's just go delete that. And we'll try again later when we have more understanding, more context, or a bigger budget to implement the whole thing. Right. That allows us to think in bets, which is something we're doing all the time in business is we're trying to make a bet on if we do X, we will get Y out of it.

[00:47:06] Allan Stewart: I think that there's also a kind of a built-in mental state there, right? Like the perception is this is a bet. Well, some bets lose, right? If you're only ever making sure bets that can't fail, well, you're probably not making very much money, right? Because that's not how betting works, right? Betting is designed for high risk, high reward kind of scenarios and low risk, low reward scenarios. And so getting them to think in bets. And if a bet doesn't pay off, I think that's easier to swallow. That's easier to understand why that happened. Yeah. So going back to the idea of professionalism, then I think as we are trying to make ourselves be professional software developers, we're trying to be good at our craft. It kind of comes back down to this. We take all these things we've discussed into consideration around saying yes and no, and the deadlines and estimates that come out of that. And I think ultimately, then you have can you honor the commitments you've made? And if not, how do you challenge them or renegotiate them in order to have a good scenario? I think the worst thing that you can do is say, well, we stuck to that. We decided on this plan. And so now we're just going to keep marching to it even after we've realized that it can't possibly be true. And people are doing their status reporting, saying everything's good, everything's green, even though we know it's red. Those are situations that you don't want to be in. But it can be hard. It can be very difficult to go back later after you've made a commitment and say, actually, no, I can't make this commitment after all. But failing to do so

[00:48:58] Dave Adsit: is unprofessional. Yeah. I mean, that just leads me to think about some of the things that we talk about repeatedly when it comes to effective communication. We've talked about radical candor. We've talked about crucial conversations. I think that these scope and date and commitment conversations are well-served from leveraging the concepts from radical candor and leveraging the concepts from crucial conversations. It is inevitable that some of these conversations are going to be very, very challenging because everybody wants what they want, and they want it when they want it. If we have to negotiate, have to make trade-offs, well, that's hard. I don't want to make trade-offs. I want it all. Give me everything. So for me, what it all comes down to is when we're talking in terms of professionalism and commitments, we need to be honest in our explicit commitments, and we need to be cautious of making implicit commitments.