This is a transcript of episode 321 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Go ahead and bravely demand the next feature right after the completion of the last!
Listen to the episode on SoundCloud or Apple Podcasts.
Who is Kent Beck?
Listen to this section at 00:14
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hi, Squirrel. So, I wanted to bring up the topic for today, someone who has been a very long time contributor to my career, someone I’m sure that most of our audience probably has heard of, which is Kent Beck.
Squirrel: Oh, yeah! He’s an old friend now! I’ve never met him, but, I’ve read so much of his work and followed so much of what he does. I think he’s fascinating. But not all our listeners will necessarily know who he is, so you better help us out. Who is he, and why is he amazing?
Jeffrey: So probably the widest audience would be people who know him from being one of the cosignatories of the Agile Manifesto. So he was up there in the really early days. Now, people who were into agile in the early days would know him even more as the person who was one of the main creators, the definer of extreme programing. He wrote the classic book Extreme Programing Explained, the White Book was the first edition, and that was just an absolutely transformative book for myself. And I know many, many others in software read that and really had epiphanies.
Squirrel: But the weird thing is that somehow, he hasn’t seemed to form a whole bunch of certification authorities and, and groups that promulgate it, and decide on how it works, like scrum or SAFe (Scaled Agile Framework) or some of the other agile methods.
Jeffrey: Yeah, that’s true.
Squirrel: So, it’s interesting that extreme programing is not so well known, I think, because, it hasn’t had this kind of commercial amplification. On the other hand, I think that might be why it’s so successful.
Jeffrey: That’s right. And it really does remain influential to people today. He’s also known for, and people may not even realize this, but he’s the creator of JUnit. He and Erich Gamma wrote it, I believe, like on a plane flight. He thought it was something so trivial. He did it mostly as an exercise to show people how easy it was to create your own testing framework. And lo and behold, it became just absolutely transformative to the industry. Even if you’re not using JUnit, odds are, in any given language, you have a unit testing framework that’s inspired by JUnit.
Jeffrey: So, amazingly influential guy. Over his career he’s had a big influence on people in technology, developers in particular. He’s a big proponent of refactoring. I’ve been following his career, his time at Facebook, for example, where he went in to help them be better at software.
Jeffrey: He’s done a bunch of different things, the latest thing he’s working on is a new book, and this one with a slightly different audience. This time he’s aiming more squarely at executives. I think it’s very interesting to see him changing the focus, realizing that to really be successful, you need an alignment between the technologists and executives in particular. Now, this is not entirely new for him. He’s often talked about the importance of business buy-in and things like this. But, this is the first time I’ve personally seen him really focus so much on the executive audience. So that’s the context. He has a Substack where he’s putting information up, and it’s from that Substack. He just put something up recently that I thought would be a good thing to discuss on this podcast. So what do you think? Are you ready to hear the actual topic now that we’ve introduced Ken Beck?
Squirrel: Oh, sure. Anything from Kent Beck is worth talking about, even though I have the feeling we might find something to disagree about.
Jeffrey: Yeah. Well, that’s part of the fun! So what he’s done is he has this book that he’s working on, and he put up a briefing on what the book is about. And then he had a shorter version, a briefing on the briefing and what I liked about this is, he had a very quick section, four bullet points, of what he called ‘classic software design blunders’. And to be clear, when he’s talking about design here, he’s also talking about the critical role of refactoring, that continuously refactoring the software is the process of design. It’s not something you do once up front. It’s a continuous process. And so that’s the context where he comes in saying, ‘hey, here are four classic design blunders that you should be concerned about.’ So you ready? I’m going to go through them one at a time.
Squirrel: Fantastic! The first one ‘obviously’ is that refactoring is so important, you should be doing it all the time! You should be completely rewriting the system at least once a month! Right? So you take everything apart, you do it all again, now that you finally understand how the system should work! Isn’t that what Beck is saying?
The First Classic Blunder
Listen to this section at 05:20
Jeffrey: Exactly not! Number one: thou shalt not rewrite the whole system.
Squirrel: Alright! Okay, we got it. The problem here is that so many people use refactoring wrong and what I’m pointing out in my attempt at humor there is that refactoring is something that you should complete in one minute, not in one week or one month or one day. So when developers come to you and say, ‘oh, we’re going to be refactoring for the next couple of months, don’t bother us,’ you should run away in fear! Something is going wrong. So we violently agree with Kent on item number one. Do not rewrite the whole system.
Jeffrey: Yeah, and the reason they call these classic mistakes, by the way, is that there’s a natural tendency for them to happen. I can’t tell you the number of times I’ve heard people say, ‘yeah, we’re busy refactoring the system, and we’ve been working on it for the past couple of months, and we think it should just be a couple of months more.’ People didn’t really understand the refactoring memo.
The Second Classic Blunder
Listen to this section at 06:16
Jeffrey: Classic mistake number two, I like this one even more. Thou shalt not pause delivery of features for an extended period to fix the design.
Jeffrey: This, I think, is a more subtle version of the first one. People might say like, ‘okay, fine, we’re not going to rewrite the whole system, but we do need to take a month to fix this subsection.’
Jeffrey: Like, ‘we just don’t have this quite right, you know?’
Jeffrey: ‘We need to improve the scalability of this, so we’re going to have to go and fix the design here.’
Jeffrey: ‘You know, now that we have this technical debt, it’ll take us a while. So we’re going to have a pause.’
Jeffrey: ‘You know, we’re going to take a pause of what we’re doing to fix things.’
Jeffrey: I think this is less obviously an error, but still an error. Do you have any immediate thoughts on this, Squirrel, about when you’ve encountered this, and it’s something less than a whole system rewrite?
Squirrel: Yeah. The reason you don’t do this is the same as the reason that it would not be helpful if you’re lost to pull out multiple maps or try Google Maps and then Apple Maps and then a physical map in order to try not to be lost. When you get lost, it is very helpful to consult a map. That’s a great thing to do, but if you stop driving the car completely and the only thing you do is try to consult experts who can try to help you move to where whatever it is you’re trying to get to, we all know that doesn’t work. Eventually what you need to do is ask someone or drive to the next major road and see if you see a street sign.
Squirrel: Those are things that are pretty obvious to us when we’re trying to navigate, but when we’re trying to navigate to a working system that solves problems, that is valuable, that gives people benefit, somehow we forget that. And so my strong advice here is that the keyword, there’s a keyword in a couple of these, here the keyword is ‘extended’. I don’t mind stopping briefly to check out whether we’re on the right street, whether we have the right map, whether we’ve got the right address that we’re trying to get to. That’s great. But when you stop for an extended period, you’re likely to lose touch with what you’re actually trying to do. And there’s more information out there that you could get. Passing up that by eliminating it and saying, ‘we’re just going to go fix the design,’ is certainly a classic blunder in my experience.
Jeffrey: Yeah, absolutely. And I think for me, when I think about both of these two, there’s a bit of hubris here. It’s sort of like, ‘well, we couldn’t get it right the first time, but certainly we’ll get it right the second time.’ And the point about continuing to deliver while you’re working on your refactoring is proof that the changes you’re making are working, that you have contact with reality, this test of reality.
The Third Classic Blunder
Listen to this section at 09:07
Jeffrey: That’s why I think that this is a very nice lead in to the third classic software design blunder, which is: thou shalt not delay the first feature to “get the design right”.
Jeffrey: ‘Yep. As soon as we get the design right, then we’ll ship.’ It has the same problem, which is people have the belief they’re doing the right thing, but they’re not in touch with the reality, and therefore they’re not getting the feedback on ‘is this actually working? Is this actually delivering value? And are we delivering value as a team, as a system?’ As opposed to just, you know, ‘we’re in an isolated playground where we’re building something that we think is good,’ but not getting that feedback. The proof of the correctness of our design is the fact that we’re able to ship. And so if that’s not happening, you’re not getting proof that you’re on the right track.
Squirrel: You can’t argue with that one. Yep. First three working real well for me. In particular, it’s just sort of a compounding of the second problem when you say you’re going to delay the first feature. So not only are we not going to pause delivery of all features, we’re not going to pause the first one. And that’s a fallacy that I think often is driven by developers who say, ‘well, I need to get greater understanding. I need more information ahead of actually encountering any customers.’ And that’s just exactly backwards.
Jeffrey: Yeah, absolutely. And certainly I’ve been quoting people recently at my work the saying that came from the early days of agile and extreme programing, which was like, there are three steps here. First, you make it work, then you make it right, then you make it fast. We have to prove that we have it working, and then we can make it right. But that’s, as we say, an ongoing process.
The Fourth Classic Blunder
Listen to this section at 11:02
Jeffrey: And the fourth one goes a little bit different direction. And I thought this is interesting to compare. It says: thou shalt not thoughtlessly demand the next feature immediately upon completion of the last.
Squirrel: I’m blowing the whistle! Hang on! Blowing the whistle! I don’t want to break our listeners ears, but imagine a whistle blowing at this point because we just did something unfair. Or rather, I’m calling Kent Beck on doing something unfair. He stuck in the word thoughtlessly! Well, clearly, if we do thoughtless things, that’s going to be a blunder, there’s no question. But I think it’s perfectly reasonable to demand the next feature immediately on completion of the last, in certain situations.
Squirrel: There’s a way to do that that’s not thoughtless. So what I wouldn’t want is listeners, or readers of Beck, to pick this up and say, ‘well, what we do not want to do is just demand that we do one feature after the next.’ Yes, that’s right… But there are lots of situations in which having a follow-on feature, having a follow-on change, as quickly as possible gives you tremendous information! It’s tremendously useful, and it’s not thoughtless at all. So I’d be very cautious about number four here.
Jeffrey: My thought about this one is it does go in a different direction. I do feel like the first three are more initiated by technologists, and this one maybe is more initiated by the business. And I think the point here is, like you pointed out earlier, that ‘extended’ was doing some work. And here ‘thoughtlessly’ is doing a lot of work. I think it is the case that sometimes people will just demand like ‘we’re going to have 27 features come out.’
Jeffrey: I think what he’s pointing out is not allowing time for making it right, not allowing for the time to fix the design. Because like through the first three, part of the reason that they’re problematic is because you’re going to make mistakes in your design. The idea for all of this is we should accept that, and plan that what we do is, we get the thing working, and then once we’ve written it, we know what the design could have been or should have been, something more natural. And then we can make the refactoring, make the change to make it more like it should be, especially in line with what we’ve learned from having put these pieces together. That’s the kind of ever evolving nature.
Jeffrey: So, definitely, I agree with you 100%, there are times when we say, ‘yep, we absolutely need the next feature,’ and you should know that you’re deferring those improvements to the design. Depending on your situation, that could be a false economy. In other words, you’d better know that you actually are getting value for the fact that you got say, three features in this sprint, or in this time period, rather than two. Is that worth it for the fact you’re going to have to spend a little bit more time later cleaning up the design? There probably was a bit more friction in getting that third feature done, than there would have been if they had fixed things as you went along. Because the idea is that if we’re constantly refactoring, we’re actually generating an engine towards improved velocity later down the road. And that time to payback can actually, in my experience, be very short.
Jeffrey: So, I agree with it here, and I agree with what you said, which is the word thoughtlessly, is kind of thrown in here. I can very much see some discussion between a business and technologists and someone says, ‘well, look, we should not go ahead and ship that next feature because Kent Beck says we shouldn’t thoughtfully demand the next feature,’ or they might even leave that off and say, ‘you know, he says you shouldn’t demand the next feature immediately upon completion of the last.’
Exceptions to the Fourth
Listen to this section at 14:42
Squirrel: And in fact, to leave out use cases where it’s very, very helpful to release the next feature right after the first. I’ll describe two of them.
Squirrel: One, I often make the analogy of a potter throwing a pot, and if you’ve ever seen someone doing that, that person is constantly changing the pot and constantly moving. I’m sort of crooking my hand in the way that potters do, if you’ve ever seen someone do it. They make ridges in the pot, and they reshape it, but they’re doing it all the way along, as they’re working. So if you have a situation where you can constantly change the software you’re building, like a potter, rather than being like a sculptor who has to make a choice about which chip to knock off, and you can’t put it back on, you can’t just glue it back. If you’re in that situation where you’re in a state of continuous change, doing the next feature might be the place where you make the design improvement! And I have been in that situation it was a very nice one. Not everyone is there, but when you have frequent feedback from your customers, you have easy access to production, the consequences of error are low, you can move extremely fast and make changes as you go.
Squirrel: The other situation is one in which the cost of error is extremely low. In fact, you want to make errors. I’ve got a client right now who hired something like 50 people in the last two weeks, an insane level of growth. But that’s because they’re trying to make a land grab. The continent they’re on has not been well served in their market. So, they have an entire continent to go after, and it’s a rare situation. In their situation, getting new things out quickly, even broken things, even wrong things, even things that will be hard to maintain, has tremendous value. So it makes an awful lot of sense for them, not thoughtlessly, to crank out more and more features. They know they’re building up a tremendous debt. They’re okay with that, because if they can manage to get ahead of the competition, they will do very well. But they have to be doing that thoughtfully rather than thoughtlessly. And in both the cases I described, where you have this kind of rapid modification, where you can make the improvements almost every single hour, or in the situation where you’re making a land grab. Those are two I can think of immediately as applying to my clients where I would not want someone to thoughtlessly apply blunder number four.
Jeffrey: Yeah, I agree completely. We can come up with all kinds of different scenarios and situations. The underlying truth here is that, look, we’re talking about situations where there’s no substitute for professional judgment on both sides, both on the technologist side and on the business side. And really, people should be coming together have mutual learning conversations to make the judgment. “What is our situation? What is the right way to move in our situation?” And simply binary rules about, ‘we should always do this’ or, you know, ‘never do that.’ Those are always going to be a bit mistaken. There will be circumstances that make something that’s normally not a good idea, right for your scenario.
Jeffrey: Now that I can’t think of a case for rewriting the whole system, that might be an exception, but the idea that you’re going to have to bring judgment in on some of these, I think is absolutely true. However, I’ll say, even with our caveats, I do think that Kent Beck, in putting together these four items has done a really good job of identifying very common areas where people do get themselves into problems with their design. In all four cases, the common element is that of failing to use the opportunity of learning to then refine the design as you go, and to have your system always be working clean. There’s probably a reason why Kent’s Substack is called Tidy First. He’s wearing his bias on his sleeve.
Squirrel: Indeed. And that’s what the book is called, if I understand it right. I haven’t read it, but I wonder if more of these principles, like always keeping a working system and getting frequent feedback from customers, I wonder if those are more prominent in the book. I would hope so. If he happens to listen to this, and wants to come on and be a guest, that would be wonderful. I’d like to hear from him about what underlies this list of four mistakes.
Squirrel: I’d say for sure, if you’re doing any of these four things, and you’re not being really thoughtful and careful, you’re probably making a classic blunder. But it would be possible, I think, to do even the first one, even rewriting the system in a careful and thoughtful way. But you know what? The odds are the other way. What is the old quote? The race is not always to the strong nor the fast, but that’s the way to bet?
Jeffrey: Yeah.
Squirrel: Haha, I’ll try to look up the actual quote. If you’re doing one of these things, and you’re not sure, you’re probably wrong, but there are cases where you can adopt the fundamental principles and do these things and not be making a blunder.
Jeffrey: Yeah, absolutely. So thank you, Kent Beck. Actually, I did work with Kent during my time at Agitar, so I will end up reaching out to him and see if he’d like to come on the podcast and talk. And if anyone of our listeners know Kent, you know, feel free to reach out and encourage him to join because I think his insights are fantastic, and we’d love to have him on.
Squirrel: No question. And we maybe have minor disagreements, but Kent is someone certainly to watch and listen to. Whether you’re a technologist, which is what he is through and through, or an executive, which is who he’s trying to reach out to. Something, you know, I’m doing all the time, and that Jeffrey, you and I both are very interested in. So grateful for Kent’s contributions and ideas.
Squirrel: We’d sure like to hear from listeners, no matter what they come up with. So if you’ve read the book, and you have a different point of view from us, if you, see that there are examples where you’re making some of these supposed blunders, and you don’t see that there’s a problem, or you’re wondering how to get out of the problem, any of those kinds of questions and comments and discussion, we love that. And we’d sure love to hear from you.
Squirrel: Come back again next Wednesday when there will be another edition of Troubleshooting Agile, and we’ll be taking apart some other new exciting idea. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.