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 playing with Arduino programming, controlling simple hardware components.

[00:00:33] Dave Adsit: I'm Dave Adsit, VP of Engineering, and I have been recently thinking about team motivation, morale, and healthy versus unhealthy ways to create a sense of urgency.

[00:00:44] Allan Stewart: This episode topic is rewarding bad behavior. There are many things that people and companies do, which almost always unintentionally. Reward bad behavior. The one that comes first to mind for me is an old Dilbert comic where the engineers are going to get paid for every bug that they fix. And while he says that he's going to write himself a new minivan this afternoon, but there's, there's plenty of others that get recognized in various ways. Whether it's a bonus programs or sick or vacation policies. Sometimes the way things are structured, the way it is set up. Unintentionally motivates people to do things, not how you want them to do. And you're rewarding a bad behavior.

[00:01:31] Dave Adsit: Yeah, when it comes to bonus programs, one of the things that I think about is the, the less direct influence a person has over the outcome, the more likely they are to do something that is unexpected or undesirable. Um, if, if your bonus is directly related to your program. Then that can be a useful thing to encourage a reward. Right. But one of the things that we know is that rewarding engineering performance or measuring engineering performance is very, very challenging.

[00:02:07] Allan Stewart: Absolutely.

[00:02:08] Dave Adsit: Uh, another thing that I think about is just the annual performance review in general for an engineer. There's a lot of ways where that creates a negative incentive. Um, the, the fact that you're only getting actionable, legitimate. Feedback once a year is already a red flag because the closer the feedback or the corrective instruction is to the event that needs to be corrected, the better. And you can give people a lot of opportunity to change and grow. If you give regular consistent feedback. Uh, if you wait until the end of the year, then I've often seen people game the metrics or frankly tank team performance just to accomplish whatever their. So good intention, bad outcome. For sure.

[00:03:26] Allan Stewart: Some others that can come to mind for me, referral bonuses. Sometimes you're going to have employees recommending people who aren't necessarily a good fit for the company, but if they stick around for a few months, then you get a referral bonus. Vacation or sick policies can kind of go either way, and it almost doesn't matter what the policy is. There's some kind of negative behavior that you're incentivizing. Because there's a lot of traditional limited PTO policies out there that I used to encounter more frequently. And sometimes they incentivize things like employees were more likely to come in when they were sick, get other people sick too, because they didn't want to use up that time or they didn't have any time left. Or they're just trying to bank up all their time for a huge vacation later or get paid out or something like that. But if you go to unlimited PTOs. Then some people don't take enough time because they don't know how much to expect. How much should they be taking? Or they take way too much time. And HR secretly judges the people for how much time they're taking, regardless of what the policy says.

[00:04:38] Dave Adsit: Yeah, I've definitely seen that one on both sides. You'll have your people who definitely need a break so that they can go recharge, unwind and recharge and come back to work fresh and ready to do some of the good things. Yeah, I've definitely seen that one on both sides. So when it comes down to it, they're like, well, you know, so-and-so took 63 days of PTO. And you say, well, as the manager, I didn't know that because all the work got done all year. And so I wasn't really paying attention, but someone is.

[00:05:31] Allan Stewart: Someone is. There's a quote from Juergen Apello. I probably butchered his name. Apologies. But he says that rewards may briefly motivate people who win them. But they also seriously. Demotivate those who don't. The net result is often more negative than positive. For every person you make employee of the month, you turn dozens, hundreds or thousands of colleagues into losers of the month.

[00:05:57] Dave Adsit: You know, that actually reminds me of something I wanted to say about the annual performance reviews. I think that the annual performance review, much like employee of the month, can only create negative outcomes, can only truly be. A moral killer versus booster. Right. Because if you think about the four potential outcomes, the four potential scenarios, right. I'm doing well or I'm doing poorly. My manager evaluates me as doing well or evaluates me as doing poorly. Well, if I'm doing well and my manager says I'm doing well, then no change because I already knew that. I already expected that you were going to give me a high marks for my annual performance review because I know I'm awesome and performing at the beat at my. Peak. If I'm doing poorly and my manager says I'm doing poorly. Well, you've just reinforced and reconfirmed what I already suspected was true. And I feel even worse about it. If I'm doing well or if I'm doing. Yeah. If I'm doing well and my manual manager evaluates me as doing poorly. And now I'm super demotivated because I thought I knew what I was doing and I haven't been getting feedback to help me understand where I make where I'm missing the mark. Right. Yeah. Yeah. Another scenario is I'm doing well or I think I'm doing poorly and my manager corrects that misconception. Right. They think I'm doing well. I thought I was doing poorly. Maybe, maybe that motivates me to think, oh, I'm not so bad at this after all. But more likely, I just think my manager's an idiot and I don't want to work for an idiot because he's letting some slacker get away with things. Right. So I see very little upside to doing this kind of an annual performance review. Especially if it's tied to your annual compensation.

[00:07:47] Allan Stewart: So. It's shocking, Dave. Shocking that you would have so many things to say about annual performance reviews after knowing you for all these years.

[00:07:55] Dave Adsit: Right. It is surprising that I would still hold so many grudges against so many bad annual performance reviews. Even when I got good marks. Right. But employee of the month, very much the same thing. I've seen this happen a lot as well. You call out one individual for a month. But it turns out that individual was part of a team. And you forgot to call out the 15 full-time members and three part-time members and six associate members and junior contractors and the janitor who all contributed to that team actually getting the thing done. And the one person takes credit for it all. Usually the person with the highest, the longest tenure or the highest rank. Or for some reason, the most visible. And you just think, man, why is that guy getting credit for our work? I don't want to come to work tomorrow. I'll probably call in sick. Or go intentionally get sick because we have limited PTO and then I can share it with my coworkers. Okay. So I haven't quite seen it get that bad. But the point remains.

[00:09:07] Allan Stewart: So with a lot of these that are tied to financial incentives. Yeah. Or otherwise kind of company-level policy. A lot of times we don't have great control over over-influencing those policies. But you just kind of have to do your best to advocate for something better or go and find a different place that doesn't have such backwards policies. But I think that there are a lot of bad behaviors or things that we do to motivate and encourage bad behavior that impacts software development that are less policy-oriented. oriented. Probably the big generalized one that you can see, not just in software, but in lots of different environments is around hero behavior. And what I mean by that is the guy who goes and works long hours, or the team that decides they're going to work weekends to meet a goal, or the architect who decides that she's going to put in a drastic solution for a production issue that just has to go straight out and we're just going to do it live. So the problem that I see with these kind of behaviors is it sets up this weird expectation. So for example, the team that's working weekends to meet a deadline, anybody who does work off hours, they seem like heroes, right? They sacrifice something, their time, so that they could accomplish something that we deemed important. But then immediately, that casts shade on all the other employees. They just not care? Are they not devoted to the cause? How much pressure is there going to be next time to work extra hours? And that pressure could impact everybody, right? All the non-heroes are going to be like, well, I want to be the hero this time. And the people who were heroes last time are going to think, oh, well, this is expected of me now. And then you start getting into the consequences of long-term weekend work. If it happens very often, now people are starting to burn out. People are worried about the crunch time. And what does this mean for your compensation? If you regularly work more hours than you're getting paid for, do you deserve a raise? At what point are you no longer going above and beyond, but this is just the status quo? And

[00:11:29] Dave Adsit: is it healthy? Yeah, I've got a lot of personal experiences with things like this from the past. Um, one of the places I worked, we had a team that would regularly release, release software that would break and they would all jump in and work super hard and fix the problem and stay late and work into the evening. And they would just really push hard to fix these problems. And meanwhile, we had another team that thoroughly tested all their code and almost never released production failure or a code to production that caused failures and outages. And so that team, everybody went home at five o'clock and, every time we would have a department meeting, the leadership would get up and just tell everybody how grateful they were that this, the first team was willing to put in that extra time and work so hard and like get stuff done. Uh, meanwhile, members of the other team were always sitting around thinking, well, they lit the fires that they put out that they were the cause of the solution. They, they were the cause of the problem that they solved. They, they could have prevented They were a huge asset to their customers and they could have prevented themselves from having to work late and work hours extra hours to solve those problems if they had done their jobs properly during the time a lot of like we did. And so it created some animosity between those teams. There was a lot of competitiveness and a lot of us versus them, which was unfortunate because we were a fairly small department and it would have been more valuable for us to work as a team than at odds with each other.

[00:13:11] Allan Stewart: Absolutely.

[00:13:12] Dave Adsit: And at that same company, we had a weekly release cycle that we followed. And if we got to the middle of the night, so we would start the release at about 11 o'clock at night. And so because we had to take our full system offline in order to do updates, which, I mean, who does that anymore? But back in the day, that wasn't uncommon. So we would take the system offline. We would do all the updates. We would test all the updates in the production environment. And then if everything worked, we would turn it all back on and we'd be off the call at 1130, 12, maybe 1 o'clock at the latest. But if anything started to go wrong when we were testing after the deploy, we would push it and try to fix things and try to apply emergency patches. And pretty soon it's 2, 3 in the morning and somebody finally calls it and says, we're going to do a rollback and go back to the previous version so that we can all get off this. I'll get off this call and go to bed. And inevitably, if we had one of those rollbacks, the next day they would order in pizza or something for the team as kind of a sorry you had to work until 4 in the morning. Here's your consolation prize of pizza. And I actually worked with a guy who, after years of this, he's like, now every time I have to stay up late, I just crave pizza the whole next day. I don't know. I don't know how bad that unintended consequence is, but rewarding a failure seems like a challenge to, you know, if you have a consistent pattern of failure, we should be rewarding learning, not necessarily rewarding failure. I think that's the key there.

[00:14:55] Allan Stewart: And it's funny how those rewards turn out, right? I bet that every developer could afford pizza on their own. They don't need you to go and buy them some pizza. They are capable of paying. And for them. Another area that I think about as far as these things we do that cause bad behaviors. One is judging people how by how busy they appear to be. Yeah. I've been on a lot of teams that have done mob programming or ensemble programming or even just pair programming. And if you go and look at what's being done and you see several people sitting and talking and only one typing, then it does feel like kind of naively you look at him like, Oh, it seems like three people are just sitting and only one is working. But that's a misunderstanding of how knowledge work happens. You know, we actually want less typing, more talking instead of the other way around, because a lot of typing creates a lot of mess very quickly. We, uh, I think we've discussed this in the past, but code is a liability. So we want less of that. And if we can work together and use our, use our brains to make it so that there is less code, because we've done this before. Then that's great. Kind of related to that. I've seen that sometimes we'll build up cues of product design work at the dev, the, the developers just can't get around to it, but they're there and your UX person. They're busy. They're staying busy, just like you want them to. And they're making so many designs that you will not be building for six months and it looks good on the surface, but actually. Yeah. Building up this inventory of wasted work.

[00:16:43] Dave Adsit: Yeah. There's a couple of things that I, I was thinking about that. One of them is, uh, Jamie Rainsburger always says typing is not the bottleneck. And that is definitely true when we're solving problems in software. It's not the speed with which we can type them into the computer. That is the bottleneck. It's the, the time between when we correctly identify the problem. And when we have identified a solution that will work. Right. So having people discuss the problem and the solutions that could work together is likely to get you a better solution that will work more quickly, or at least a solution that is more robust to the potential problem space. Right. So it's, it's not how fast we can type. That's the bottleneck for solving software problems. It's how well we can communicate, collaborate and problem solve. And those are not, those are not things. That involve a keyboard typically. Yeah. Uh, when you said design cues of design work, design in inventory, that made me think of, um, one of the excerpts from principles of product development flow, where if you were, um, Don Reinertsen talks about if you have an error in an early design, but you've built a lot of other designs on top of it. You are going to have to redo a lot. A lot of designs where if you don't build up a ton of inventory in front of the execution of the team, you will avoid all of that rework. And I've seen that happen where there was an assumption that we could make a certain UX control work a certain way. And when it came time to implement it, it turns out that it was very awkward to use or uncomfortable for users or just not technically feasible. And so we make a change to. So we make a change to how we're going to do that. And now you have three to six months worth of other designs that you have to re reevaluate at the very least to make sure they'll still work with the, with what actually happened in the implementation. Or you have to update them based on the fact that you have learned more as you executed the software. So one of my, one of my hot buttons for bad behavior. Yeah. Is pull requests. For me, pull requests are actually typically a symptom rather than a problem in and of themselves. They're typically a symptom of a team that is not working very collaboratively. Where everybody has got individually assigned tasks and they're working on them solo. And so there's low communication, low collaboration. And the software you're getting doesn't typically represent the combined. No. Knowledge of all the members of the team. It represents isolated pockets of knowledge. And so when, when you submit a pull request, if every member of the team has individually assigned tasks and is working hard on their solo list there, you know, their personal queue. You're very unlikely to get very good feedback on those pull requests. You're going to get comments like looks good to me or ship it. And those don't necessarily tell you what's good or bad about your code. And now if your pull request is, if you're doing continuous integration by the definition, which is that you are integrating into main or master or trunk or whatever you're integrating into your, your main branch every single day, which is the definition of continuous integration. Well, maybe your PR isn't that long lived and maybe looks good as an acceptable response. But typically when people, when I see teams working with a pull request based on a single request. What I see is someone will pick up a card and they'll start working on it on a branch. And several days will go by maybe a week. If you're doing like a two weeks long sprint, maybe it's been eight of the 10 available work days. And now you're ready to put this PR up. And now when your coworker sees it, they, they may not like your architectural decisions. They may not like how you did your code. They may think your tests are brittle, but. Nobody has time to rework two weeks worth of work right before the end of the sprint. So I guess looks good to me. Merge it. We'll deal with the bugs and the inevitable consequences later.

[00:21:21] Allan Stewart: It's really hard to know what is behind. Looks good to me. Is that I couldn't be bothered, but this is the nice way of saying that, or did somebody actually go through it and. Yeah. And, and think that it actually does look good. Looks good. It can be. Yeah.

[00:21:40] Dave Adsit: I don't, I, as the, yeah, as the person who put up the PR, I don't know if looks good to me means. I don't even know how to tell you how bad this is. So I'm not going to, or I didn't even take the time to read through the code. It, it passes the syntax checks. So that's all that I'm going to take the time for.

[00:22:00] Allan Stewart: I think it's also interesting how many queues build up between employees because of what, what are you incentivizing? If you. You have a tendency to incentivize or, or to measure how often people are working and, and what you're measuring is whether they're typing out their code, they're getting their tasks done well, then the employees are going to care more about getting their tasks done than reviewing other people's pull requests, which in turn just slows down everybody. But. If the employee focuses on getting their pull requests done. It improves. Your. Flow because things are getting done and getting out to production, hopefully, or getting completed at least. But what is that individual developer doing? They, it, they may be perceived as just like sitting around and like, they're not getting any of their work done, even though it's all kind of collect collaboratively. Everybody needs to do this. And so I think this is one that's also kind of context sensitive, right? Because we talked about like employees that are members of a team. Who are probably working. Near to each other or close in time zones, maybe a couple of times zones off. If you're in a fully asynchronous mode, right? You're doing. Um, like open source development, then this might be a little bit different because the, the context of how you work is different and pull requests are kind of the best way that we've figured out how to do fully asynchronous work, but there's also a different expectation about the timeline of any. Pull request getting done. As opposed to I'm the employee I'm supposed to be working my 40 hour week or whatever.

[00:23:45] Dave Adsit: Yeah, that's definitely true. This is the technique of using pull requests is definitely context sensitive.

[00:23:52] Allan Stewart: One that you mentioned before, but we'll just hit on a little bit here is a stack ranking employees or comparing the individuals instead of looking at what the team is doing together. You can really demotivate people. Yeah. Or incentivize them to try to appear to be better than their peers. If they, if they don't help each other, then all of a sudden, you know, they start getting more secretive or they might even sabotage each other because they're trying to look good because they want to be perceived. In whatever the stack ranking is. And sometimes it's, sometimes it's for things like promotions, but other times it's just the praise of the drive by manager who comes by and says, Hey, it looks like so-and-so is doing a really good job. You should be more. Like. Like her. And, and suddenly you're creating this tension within the team that just didn't need to exist. And it's counterproductive.

[00:24:45] Dave Adsit: I think one of the concepts there that we're seeing across multiple of these bad behaviors or incentives to perform badly is the idea that we are looking at individuals in isolation rather than as a team. I think this is one of the things, if you've ever seen little kids play soccer versus. Pros play soccer. Little kids soccer is all about me, me, me. Am I kicking the ball right now? And so you see a mob of potentially 22, hopefully not 22, hopefully not more than 20, because hopefully the goalies know their job, but at least 20 little kids clustered as tightly as they can around a ball. So they all get a chance to kick it and get the, the, the rush of doing that. But when you see a professional soccer team play. It's very much a team sport where there's tons and tons of passing back and forth. And it doesn't at the end of the day, really matter who scored the goal because the team takes the victory together, celebrates the victory together. Every player contributed to getting the ball downfield and letting the striker get it into the net. Right. That's, that's how I think of a software development team, how we want them to behave is we have a goal of delivering. A working software with certain features that creates certain value for our customers. And if I'm stack raking my employees, then instead of having them in a collaborative mindset, working together to move towards a goal, suddenly they're in competition with one another. And I hear managers say all the time, well, I have to have some way of comparing them. How do I know who's doing well? Who should get the bigger raise? Who should get the smaller raise? And it's a challenge. It really is a challenge to understand the performance of individuals, especially when you're working on a collaborative effort. That no individual could have pulled off on their own in a reasonable timeframe. So I see, I see hints of that in the individually assigned cues that lead to a pull request based workflow. I see that very much in stack ranking and comparing individuals. And if you make it public, if you compare individuals or you compare teams, let me tell you another story about a bad incentive created by comparing teams. At a certain point, the project management office decided to standardize the value of a point. Having read none of the agile literature and not understanding that points are completely arbitrary and we wished we had never made them up, they decided that we should standardize the value of a point to a person day. And I'm like, well, that just makes it a regular estimate. They're like, no, no, no, there's still points, but each point is worth one person day on your team. And so after a few months of this, nonsense, we had one team say, yeah, our estimates are okay. We typically get between four and six points done per person per week. So they're pretty good. And another team came back and said, wow, you guys are really horrible slackers. We typically get between seven and eight points done per person every single week. If you're good at math, you may notice that it's super easy to game this by just estimating. Badly. But of course the team that got more points done per week was ranked higher than the team that got roughly five points done per person per week.

[00:28:16] Allan Stewart: And that goes into kind of a related one for me around rewarding output rather than outcomes, right? We can, we can game the estimates. We can game the number of features that are pushed out or number of times that we've deployed to production. But that doesn't. Necessarily mean it was good. Doesn't mean that you, you did the right thing. I've seen plenty of teams that got tasks done and they're out delivered super fast features, but the quality was low. There were security problems. There were bugs. And so over the lifetime of that feature, you end up paying for it again and again and again, and the customer is impacted. And meanwhile, management is recognizing people who delivered something quick and dirty. Because. They. Are worried about now. And not worried about the long-term impact of, of what happened there. Yeah.

[00:29:12] Dave Adsit: Jeff Patton has a really interesting and valuable video that I've showed to my team several times. It's under 10 minutes and he talks about inputs, outputs, outcomes, and impact. And the short summary, the TLDR on that is inputs are what you do or what you put into the system, whether it's hours worked or ideas or whatever. Outputs are what you create, uh, features releases, whatever. Outcomes are changes in user behavior based on the changes in the software system. And impact is where you start measuring it at the business level. Your impact is, you know, increased revenue, increased retention, whatever. Right. So those are the types of things where. If you talk to your people in accounting or maybe your executive team, they're going to be looking at impact more than they're going to be looking at the other aspects. And sometimes people will tie impact. So you want to make sure that you're measuring your inputs directly to impact, which is skipping a few steps, a few very, very critical steps. Um, so if you're measuring inputs, if you're measuring the hours worked, that's not necessarily tied to your actual goals as a business. I recommend moving those goals further down the chain to at the very least out. I mean, yes, you should have some impact related goals. The. The best we can typically hope for. And software. Is to have outcome related goals, which typically means trying, trying more than once to figure out what it is that people want. Mm-hmm. Like that. How to impact that behavior or how to, yeah, how to impact that behavior, how to change that customer behavior. And so if we're rewarding outputs or even inputs, I've seen inputs rewarded as well. Unfortunately, we're going to run into a lot of problems when it comes to actually getting the business to do what we want the business to do.

[00:31:05] Allan Stewart: Another one that I think about is punishing failure. So examples are things like, oh, you accidentally deleted the database. So now you're fired and you, you make a big impact. By doing things like that as a, as a manager, because now people are scared because they know that accidents can happen and we didn't really learn from our mistakes. We just punished the mistakes. But the problem is that you're going to keep hiring more humans and the humans just always make mistakes. It just, they can't not, they're human. And, and then all of a sudden you're fostering a culture of less innovation because people don't want to take risks because look what happens to the risk takers. Look what happens to the people who make a mistake. We don't set up guardrails and say, oh, that's dangerous. Let's take away the button that allows you to delete, or let's not let you run commands directly on the server. But instead, we'll just fire that guy and hope that the next guy doesn't. Make the same dumb mistake.

[00:32:06] Dave Adsit: Yeah, it's, it's definitely, um, I I've, I've heard people say we should celebrate failure. Uh, and I've also seen people punish failure. And I think that, I think that both of those missed the mark. We should celebrate opportunities for learning. And often if we're looking at the system, right, if we're looking at the problem, right. We created a feature and put it out there with the best event intentions and the best expectations. And it turns out that it did not improve the customer metrics. It didn't change. It didn't change customer behavior the way we wanted. And in fact, our income, our outcomes are worse than they were before we made the change. So now we have to do something about it, right? Do we learn from it and move forward? Maybe roll it back to try something else, or do we just scapegoat somebody and fire them? And you're a hundred percent, right? When you do that kind of thing, when you create scapegoats and punish failure, you incentivize people not to stick out, not to take risks, not to do anything that could potentially have a big impact or a big payback or reward for the company, but instead to just do the safest thing possible. And that's very rarely the best thing for the business as a whole, or even for the individual. Like the safest thing possible is to never upgrade your JavaScript framework. And if you never update your JavaScript framework, you're probably still running jQuery, or maybe you started the project later and now it's Angular. But it's. Certainly not going to be React. I mean, unless it's a very new project, right? And when the thing that replaces React comes around, you'll be stuck on React because you won't be willing to take the risk of moving forward with something that could have a big benefit to the organization.

[00:33:50] Allan Stewart: It makes me think maybe the thing that you should be celebrating there is not even just the learning, but applied learning. We learned something from this and it changed us in some way. Oh, for sure. Now we celebrate. We. We don't just go through the motions of doing a retrospective or postmortem on an incident and be like, huh, well, now we know what happened. We've come to a root cause. We know all the things that went wrong. But because we're. If you just stop there.

[00:34:20] Dave Adsit: Because we're averse to risk, we're going to keep doing things the same way we've always done them, even though we now know that this is the inevitable outcome.

[00:34:28] Allan Stewart: Yeah, we've got a whole list of postmortems that point to the same problem that we just. Are unwilling to fix.

[00:34:35] Dave Adsit: First, the inevitable outcome of my choices. So one of the things that I think we've both seen at different points in the past is that there's a lot of developers and especially managers and people outside of the day to day writing of code who discourage the creation of unit tests. Everybody wants a good automated test suite so they can deploy code fast. Faster and release valuable features sooner. But we don't necessarily. We don't want you to take the time to write unit tests because why would you have to write the code twice? That's twice as slow. Or maybe we have some tests, but the code changed. Now the tests are all breaking and we don't know what to do about that or how to fix them. We don't know how to write tests that are not brittle, not fragile, flexible with the code as it changes. And so we get frustrated with the concept of unit testing as a giant waste of time. And so we want to get rid of that unit testing because it's making us slower.

[00:35:44] Allan Stewart: It occurs to me that a lot of these just kind of like you were saying before, there's some common threads. A lot of them have this same kind of quality that we care about the now and not about the future.

[00:35:57] Dave Adsit: Yeah, I think that's right. It's over indexing. I think they call that a there's a bias. Specifically around that time bias. I can't remember the exact name, but there is definitely a tendency to over index for what I can have right this second versus building a system that allows me to deliver a feature now and tomorrow and the next day and the next day and the next day without without having a large slowdown in our ability to deliver new value. And frankly, that's what I find as one. One of the big values of a robust unit test suite is that you can make changes and you can quickly verify them. I've worked in code bases where we had close to 10,000 unit tests that it would run in under a minute. And because none of them reached into outside resources like databases or API calls or whatever, we put those behind an integration test suite. Right. So your unit tests just exercise your code in isolation from the world around it. And so they run super, super, super fast. And you can have a very high level of confidence that the change you made over in this one part of the code didn't break something over in that other part of the code that you weren't thinking about. And if you don't have those, you have to pay that cost of of doing your testing manually and validating as much of the system as you think could possibly be affected. And I feel like this one's a false economy, right? We're saving time by not writing unit tests, but it's costing us tons. And tons of time by doing manual testing or by making our customers doing manual, do the manual testing for us when we just throw it over the wall and then it breaks for them and then they get upset.

[00:37:43] Allan Stewart: And we don't want to invest in in the developers because they're going to have to learn. Unit testing is a skill and getting good tests that don't break often isn't easy. It's going to require you to change not just your skill in testing, but your skill in how you deliver code. In the first place, how you structure it, how you create it so that it's more testable.

[00:38:08] Dave Adsit: Yeah, that's definitely one of the things I've heard is that, I mean, this is a totally different topic for a different day, but I've, I've heard developers complain about the fact that writing unit tests forces me to design my code in a different way that I don't prefer. Like, that's an interesting conundrum because that's exactly why I do unit testing is to help me design code in a way that will make it more robust. So that the next one is probably one that. Very common across all people in all places. Right. And that's the idea that you shoot the messenger. Right. Somebody brings you bad news and then you blame that person or at least you. Yeah, I guess you blame that person. You give that person a negative consequence for telling you the bad news where we should be not necessarily celebrating bad news, but we should be celebrating the fact that we've created an environment that is psychologically safe enough for people. To. Share bad news as soon as they discover it so that we have the best chance to create a mitigation for it as soon as possible. Yeah.

[00:39:14] Allan Stewart: Yeah. When you shoot the messenger, nobody wants to be the messenger anymore. Nobody wants to get blamed for things, especially when it's not their fault. It's, it's a systemic problem or it's something that happened to them and they're just coming along to tell you. Which reminds me of a article. That I read. Probably 15 years ago now that talked about carrying watermelons. When you go to your status meeting, you always take a watermelon with you. It's nice and green on the outside. This is your status report. Everything is good. But the problem with the watermelon is that it's red on the inside. And eventually when you get further and further down the project, and especially if you're in it, like a big kind of corporate agile waterfall setting. It turns out that. And then eventually everybody ends up reporting red. Like, yeah. Okay. Actually this thing that we said was green all along. Yeah, it's not. It's. It's the end. It's the end of the line and it's not ready to ship. It's not ready to go live. So now I have to tell you the truth is it was always red on the inside.

[00:40:22] Dave Adsit: Yeah. That, that one's very interesting to me because first of all, I love watermelon and also I hate carrying watermelons. Right? If. If. If you look at the concept there, it's likely that this is a secondary effect of several other things that you've done in your system. So just punishing failure or shooting the messenger, but also you've cut yourself off from the opportunity to put in mitigations early and you've created a situation. You've created a situation of low psychological safety. Where. Everyone is rewarded. he was the first one to accept the red, right? It's kind of a game. It becomes a game of status chicken. You've got 10 projects that are all codependent on each other. They all have to be released as a cohesive program and they're all actually red, but every product, every project manager, let's call it project manager is still reporting green until they can lay the blame at someone else's feet. So like, not only is this terrible because it doesn't give you the opportunity to create mitigations, it doesn't give you the opportunity to do the hard work of leadership and management and, you know, reassign people, apply more resources in the terms of time and money and equipment, but you've robbed yourself of that opportunity, but also you're likely to rob yourself of the possibility of future success in your program. Because nobody dares be the one who says, Hey, we need some extra help here, or our scope is wrong, or we're, we're incapable of delivering this by the timeline that we need to.

[00:42:35] Allan Stewart: We'd rather fly without a compass than do course corrections.

[00:42:39] Dave Adsit: Yes. Sounds fantastic. We'll definitely get to the scene of the accident faster than if we had the

[00:42:45] Allan Stewart: compass. So then that kind of relates to metrics. When, when people get tired of the status reports, not reflecting reality and like, Oh, well, it's just, Let's just measure things. Let's just go in and measure how many lines of code are being generated. And then we'll know, then we'll know the answer, right?

[00:43:03] Dave Adsit: Well, yeah. And, and we don't have to do subjective stack ranking anymore. We'll do an objective measure of the productivity of the developers. We'll see who writes the most lines of code. That's the easy one. We'll see who is the most compliant with our mandate that every public function be documented. Or we'll, you know, we'll measure, here's a fun one that I've seen in the past. We'll measure whether or not a developer has to come back to the same code file again later, because if they do, that means they introduced a bug the first time and they should be punished or counterpoint. They're working iteratively on enhancing a certain functionality of the code and releasing in regular small batches. But it's hard to tell the difference between the two. If you're just looking at repeat visits to the same code file. So, and again, honestly, our goal is to, our goal should be to release value regularly, early and often, right? Consistently deliver new value to our customers. And so if we're creating scenarios as leaders in an organization where we've put in place these negative incentives, then we're not going to We're not going to drive the behavior we want from our staff. And frankly, we're most likely

[00:44:31] Allan Stewart: going to be getting counterproductive outcomes. Agreed. And I think it's worthwhile to think about these kinds of things and what's going on within your team. Even if you're not a manager, there's things that you can do to discuss with the other people on your team and get level set areas, those areas that view areas, those areas that view areas, those areas that view areas, areas that view areas, those areas that view areas, those areas that view areas, those areas areas that view areas, those areas that view areas, those areas that view areas, those areas you're wanting to measure and not just lines of code. It can let you make sure that you have an understanding about, hey, we're going to not try to be better than each other. We're going to take credit as a team, or we're going to actually look at the pull requests. And we have a practice within our team that we're going to talk about these pull requests, or that we're going to make sure that you go through and run them, or we're going to throw them out because we're going to do some collaborative coding instead. But you're not going to get there unless you've sat down with your team and thought about, hey, what are the things that are creating a perverse behavior, even though we thought that it was a good thing that we should be working on?

[00:46:09] Dave Adsit: Yeah. And it's definitely a separate subject, but I think it's important for teams to be retrospecting often, possibly continuously, and doing that. Doing postmortems, incident reviews, et cetera. Basically looking back at the impact of the incentives we put in place and whether that's what we want to have created, the incentive we wanted to have created. Are we incentivizing the correct behavior? And if not, we need to adjust the system. You're going to find a lot of interesting things in the works from people like Edward Deming, where they talk about the incentives the system creates, and they talk about the incentives the system creates being more important than the desires of the individuals in the system, because those are what drive the behavior consistently over the large scale and over time. And you're right. It's not just the manager and leader's responsibility to build a good system that delivers quality or valuable software.