From Extreme Programming to TCR and Limbo

Extreme Programming

Daniel Terhorst-North: Hello, Kent Beck.

Kent Beck: Hello, Dan North.

Daniel Terhrorst-North: What an absolute pleasure. I'm Daniel Terhorst-North. I've been in technology for about 30 years, and the latter 20 of that have been massively influenced by the gentleman I have the pleasure of speaking with today. This is Kent Beck. Would you like to introduce yourself?

Kent Beck: Sure. I'm Kent Beck. I've been in technology for 50 years. And I've had the pleasure of working around Dan. But we've never actually worked together, have we?

Daniel Terhorst-North: We haven't. We haven't worked on the same gig. That would be very fun.

Kent Beck: For us.

Daniel Terhorst-North: I think. Not necessarily, for the client, let's just say. Okay, so where do I start? There's so many different places I want to go. I'm just going to pick one. So, as I said, I've been doing this for about 30 years. Twenty years ago, I was working with a good buddy of mine, and he'd come across this thing called Extreme Programming that he'd heard of, and it was a book, and he read this book.

One of the things I like about the original "Extreme Programming" book is that it reads like a case study, right? It's not, "Go and do these things." It's not hypothetical, "If I were you, I would do these things." It's a load of really practical, applicable things that said, "We did this and it worked out really well for us. You could try them too." We went, "They sound really good, we're going to try." And it turned out that we tried them and they worked out really well for us.

It has one critique I've heard leveled out of it, or one criticism is, the team where these ideas and these techniques came out of was made up of a dozen of probably some of the best programmers in the world at that point, or certainly in the industry at that point, like, very talented people. They could have kind of done anything and it would have been fine. Why those things?

Kent Beck: Well, so my snarky answer, I'm just gonna...

Daniel Terhorst-North: Go snark. Go snark.

Kent Beck: We can snark. I mean, by the time the project was mature, they were awesome, but you should have seen them when I got them. Now, the fact is they were experienced programmers, to begin with, but the level of collaboration that they developed and the skills that they developed through that collaboration was really amazing. They took basic ideas and ran with them and implemented them in really interesting ways. But the thing about Extreme Programming is, a year on an XP team is better than graduate school. You learn so much about design, about testing, about integration, about tooling, about interacting with clients.

Recommended talk: Tidy First? A Daily Exercise in Empirical Design • Kent Beck • GOTO 2024

The Power of Feedback and Continuous Delivery

Daniel Terhorst-North: About feedback. I mean, for me, the whole thing I was about to, like, you get to...it's almost an addiction, right?

Kent Beck: Sure.

Daniel Terhorst-North: And you want to know the product's working, you want to know it's solving the problem it's supposed to solve. You want to get these...

Kent Beck: Oh, you feel terrible if you don't. Yes, absolutely. And I'd seen too many teams who felt terrible if they got feedback and wanted to create an environment which felt bad if you hadn't gotten feedback.

Daniel Terhorst-North: Well, and often because when you do get feedback it's distant in space and time, a, from when the thing happened, and certainly from when you could have done anything about knowing that feedback. So, it just comes across as a beating rather than a kind of opportunity to course correct.

Kent Beck: Right. That you've caused the damage and you don't learn, so let's shorten the feedback loops. Now, it turns out the shortening feedback loops have social consequences. If somebody comes to you and says, "We want all of this functionality by this date," and you say, "Oh, no, that's not possible." Organizations aren't set up to deal with that answer. But that doesn't change the answer. And so, it requires careful cultivation of the relationships in your whole development team in order to be able to handle that feedback. First, you have to have the technique to create the feedback, but then you have to have the relationships to actually deal with it.

Daniel Terhorst-North: Right. And for me, that manifests in two ways. One is, your traditional, kind of gated project life cycle, if you like, was, each of these meetings is only designed to hear yes, right? Well, at the end of the analysis phase does the analysis pass muster. Well, if the answer is no, we haven't got any more time to answer, so it's going to have to be a yes. So, we'll just lie and go with yes, same with the design phase, same with the coding. Each of these phases, there's no kind of give in the process to hear no. And so then, you get a culture of, like...I call it kind of the Stepford Wives type of thing, where just everyone goes around nodding like this. You're like, "There's something wrong here," right? Something weird is happening.

Then the other part of it, like you say, someone comes along and says, "I want all of these things by this date." And, like, the message behind the message is, "Because I've been conditioned to know that there's never going to be a second go. If I don't get it all on this train, it's the only train leaving." And as you say, the relationship is, I've heard this, when you start working in much smaller chunks, you start delivering every quarter and every month, and it's not just that you're delivering more frequently, it's that the things you're delivering are younger, right? The stuff that's coming out this month that went in the hopper four weeks ago.

Kent Beck: That's part of it. Right. It must have been the priority four weeks ago. But then the second part of that is you get used to those deliveries, so you say, "If it doesn't come this month, it's fine."

Daniel Terhorst-North: There's another train. I now believe that there will be more trains, right? And yeah, the anxiety goes away. And this is a bit of command and control. It's not command, it's regular human beings that are concerned, right, because they've got reason to be concerned. And if you can take away that anxiety by, "Look, if you forget it this month, you drop it in the next hopper and it will come out the next month." They're like, "I can sleep at night. I like working with this team." And they're not trying to ram everything into the one train that's leaving.

Kent Beck: Which doesn't work any more than putting all the cars on the freeway at the same time, right?

Daniel Terhorst-North: Exactly. I learned that there's a name for that law and I've forgotten it already. Holly came up with this brilliant name for the idea that if you overload a... And if you make a motorway, if you make a highway wider...the idea is you make a highway wider then you're great, all the cars are moving. No, if you make a highway wider more cars come on and it stays just as jammed. And there's a name for that principle. I can't remember what it was.

I suspect this is one of these hiding-in-plain-sight things for you. But when I experienced it, because you wrote the second edition of the XP book, I grinned, I grinned like an idiot, right? The reason I grinned like an idiot is this, and this is how I describe it as well. In the first XP book, folks, there are 12 sorts of practices, techniques, things that you should probably do that we think kind of play well together, right, they integrate nicely. These things...

Kent Beck: I would explain it differently, but, yes.

Recommended talk: The Best Programmer I Know • Daniel Terhorst-North • GOTO 2024

The Evolution of Extreme Programming: From Practices to People

Daniel Terhorst-North: There's a bunch of things that we've figured out that we do, they work well together, they support each other, and so on. They kind of...and they actually go in little groups as well. There's a lovely diagram of which things go well together. And it doesn't matter what the things are that you do, those are just the things we happen to do. Underpinning all of this is communication, simplicity, courage, feedback, right? That's actually XP. The rest of it's just some implementation detail, right? XP is actually these four things, right? And I know you're going to tell me I'm wrong.

Kent Beck: Yes.

Daniel Terhorst-North: However, let me get to the question, and then you can then you can unpack how I got that so badly wrong. My observation is this, you then wrote a second edition of the book. On top of communication, simplicity, feedback, courage, you added respect, right? And I think you probably had the same, what's the word, disbelief thing that I had, which was like, "Why would you have to actually make that an explicit thing," right? It's like saying communication, simplicity, feedback, courage, and don't kick puppies, right? We're gonna have to not kick puppies because people started kicking puppies and we don't know why. And people had picked up the XP Bible, and they were just using it as a blunt instrument...

Kent Beck: Absolutely.

Daniel Terhorst-North: To tell other people that, "You're not pairing and you're not doing TDD and you're not doing that." "Oh, I didn't realize it was like..."

Kent Beck: Or telling the client, "Oh, I can't. I'm not going to make any promises."

Daniel Terhorst-North: Right, right, right, because you don't do that.

Kent Beck: XP is my excuse not to make promises. Now...Have you gotten to the question yet?

Daniel Terhorst-North: Yeah. Well, sorry. Sorry, so the question is this, the respect appearing in the second edition, what kind of led you to, "Oh, my goodness, I need to make this thing explicit."

Kent Beck: I grew up a little bit.

Daniel Terhorst-North: Was it really an experience that you had had since the first book?

Kent Beck: Yes, absolutely, personal experience. I think there were a group of people who were attracted to that first edition because programmers were the heroes and everybody else were the idiots and us and them and if only they'd let us be in charge. That was a reflection of my attitude at the time. I had a pretty big life reset right around then, and had to take a hard, ugly look at myself and find the things... I had to find a way forward that I could live with. And respect for people who are respectful was a big part of that reset for me. The second edition was written from a perspective where I had to look at some of the stuff I'd said and some of the stuff I'd done and gone, "Ah, I'm not treating other people like people consistently. I need to...and I want to do that, both as a moral imperative and as a practical matter in my own life."

Daniel Terhorst-North: again, because, I mean, obviously, there's going to be folks watching this that have read one of the books, both the books, if you read both of them... And I got to experience them in real-time. I read the first one in the late 90s and the second one. They're two different books. For me, it's not like a second edition like, "Oh, you know, we've added a couple of chapters here and on this." The first book is a bunch of practices around software development, and the second book is how human beings should treat each other in a software delivery world. And it's definitely felt...it felt like there was a different tone to it, like a different focus.

Kent Beck: I paid for that.

Daniel Terhorst-North: So that I'm living in the past here, right, this is all 20-odd years ago.

Kent Beck: It's fine.

Daniel Terhorst-North: So, that's your first album.

Kent Beck: No, that's my second.

Daniel Terhorst-North: Well, second album. Yeah, it was a very, very successful album, right?

Kent Beck: Yes.

Daniel Terhorst-North: You've done a ton of stuff since then.

Kent Beck: Yes.

Recommended talk: 3X Explore, Expand, Extract • Kent Beck • YOW! 2018

The 3X Model: Managing Risk Through Software Evolution

Daniel Terhorst-North: Let's see, we've got your 3X's. I'm really interested in the genesis of that and also, I'm really interested in where you've taken that. There's an arc in terms of, I think, how you see...and you're kind of just alluding to it there, not just how software gets developed, but the ecology in which software is a necessary thing and how it comes into organizations, and that kind of pace.

Kent Beck: This was a missing piece in Extreme Programming, is a missing piece of context, which is that the risks to a software project change dramatically over time and how you respond to those risks necessarily changes as well. XP was, I mean, you can only do what you can do, naively just assumed, "Well, this is like how you develop software," and...

Daniel Terhorst-North: I got a steady state vibe to it, didn't it? Just like, "If I would just keep on doing these things and we just keep on doing these things and...?

Kent Beck: 3X came out of my experience of watching projects at Facebook, early Facebook, and how they were treated very differently depending on whether... At first, the first risk you have is just, "Nobody cares." People at Facebook would try out lots of different features and most of them flopped. Every once in a while, one was the Like button or photos tagging that was just massively, massively successful. What I noticed is Facebook treated projects very differently when it was just speculation and when the rocket engine had lit and the thing was just going crazy.

Daniel Terhorst-North: I just took it some context to this sort of viewers, is Facebook at the time, I don't know what it's like now, had this culture of, "We know that we don't know what's going to be successful, so we're going to make it inexpensive," in terms of not just like money, but in terms of social capital, risk, or whatever, to try a bunch of stuff.

Kent Beck: Correct.

Daniel Terhorst-North: Because otherwise people wouldn't. You try all the things, and the reason you tried it is because you thought it might work, but no one tried something new, it wouldn't work. So, everyone tried the thing that they thought would work, and then every one in "N," where "N" is probably quite a big number, one would be enormous, and more than paid for all the others. But it wasn't like a loss of social capital or loss of status to be on one of the ones that wasn't successful.

Kent Beck: No, no, it would be...

Daniel Terhorst-North: It was just, "We tried the experiment and moved on."

Kent Beck: That is a characteristic of that. I call that the exploration phase, where you don't know where that...you're looking for a reinforcing loop, where the more you grow the easier it is to grow more. And you can't guess at where one of those is going to be. And so, you just...one over "N" investment, you try a little bit of all the things. But the risk that you're trying to counter, is nobody's ever going to care about this. Every once in a while, you overcome that risk. As soon as you overcome that risk and people are actually engaging with the feature that you've implemented, they're going to start yelling at you because they hate it. That is the best thing that can happen to your feature. Number one, because now it means you've overcome the first risk. Now, people care. If you have a mature product and people yell at you about it, that's bad. But if you've tried this experiment, this exploration, and now people are yelling at you, oh, that's success. But now you have to listen. But people say, "You're an idiot. If only you had this in this feature, then this would be useful to me, and right now it's just crap." "Okay, good, I know what to do next."

Daniel Terhorst-North: You have to take the signal without taking part of that.

Kent Beck: Without taking on the emotion of it. You're going to be over... It's kind of like the seven labors of Hercules. When Hercules fails any of the laborers, no princess. There's the next barrier to growth and the next barrier to growth and... But the way you manage that is completely different from the way you manage exploration. I call that expansion.

The way you manage exploration is loosey-goosey, try a little bit of everything. If somebody makes a joke and everybody goes, "If we could just delete the button now, everything would be fine." Delete the button, see what happens, because you have nothing to lose. Once the rocket's been lit, now you have...you still haven't achieved anything. You're going up, but you're not up in orbit yet. So, you manage that completely differently. Instead of being all loosey-goosey and everybody trying everything, you're like, "Let's throw away as much as we can so we can focus on the one thing that matters next."

In expansion, it's a different style of engineering, it's a different style of management, it's a different...oftentimes, new team members come in because we're breaking the infrastructure in some kind of way and we need some really high-class expertise to get over this, it's a different kind of financing. Everything changes when you go into expansion. The thing is, organizations will get addicted to exploration because it feels good, it's kind of loosey-goosey, and then they'll have one of these successes, and they'll just keep being loosey-goosey. The next risk that hits you kills you.

Daniel Terhorst-North: Because you aren't... You got to have resilience, yeah.

Kent Beck: You're done. But what early Facebook was really good at was shifting gears to say, "Okay, something is taking off, so now we're going to go into the second mode." And that's the, we're all going to camp out in a conference room and be right on top of each other because that's what lowers the risks. And that's the risk to growth, we can't make this thing grow. So, first, the risk is nobody cares. Second risk is that we can't make it grow. You can only live that way for so long. You can't stay that way. Again, organizations get addicted to that kind of expansion mode they think, "Oh, that's how development is." But eventually, you have to get to a more predictable style.

At the beginning of expansion, you don't know what's going to cause growth, you don't know where the levers are, you don't know how they're attached. But eventually, you're like, "Oh, the fourth country we launch in, we know how to launch in new countries." And then you write a playbook. And that's its own style. That extraction phase is its own style of engineering, management, sometimes even the technology style. "Oh, now we convert it to C++ so we can reduce the costs." And the recruitment team size, OKRs suddenly make sense. In the early days of exploration, you don't know what metrics matter, you don't know what numbers would be good or bad. I was talking to somebody who said, "Yeah, we're forced to predict our revenue of our experimental ads products, and we either achieve $0 or 100 times what we predicted."

Daniel Terhorst-North: Of course.

Kent Beck: Those are the two options.

Daniel Terhorst-North: Well, if we knew what we were doing that wouldn't be called research.

Kent Beck: Correct. Organizations get addicted to that. Extract looks like adult behavior. You can make predictions, pull this lever, that dial goes up, you know, people can estimate, you have big teams, you have hierarchical structures. It feels like adult development. And so, people try to cram all of their development into that exact style. So, you get organizations who are exploring and they stay exploring. They usually just kind of die out because you never take advantage of the opportunities you create. You get organizations who get addicted to the adrenaline rush and the cortisol of expansion. Then you get organizations that are addicted to that incremental, extractive kind of style. What Facebook, at that time, was really good at doing is managing different projects in completely different styles, and noticing the transitions between the phases.

Daniel Terhorst-North: What you won't know is I'm not a finisher. I've got lots and lots of things in flight. I'm 12 years into a book at the moment with 40-odd patterns in it, one of which is essentially about the maturity of a software product, and I call it explore, stabilize, optimize. And it turns out it's remarkably similar. I didn't want to interrupt you at all. I wanted to hear your story. Your story is a risk story. It's how you manage risk at different stages. So, the way I describe it, and exactly the same...obviously, we've observed similar things. For me, it's about what you're optimizing for at each stage. So, explore, I'm optimized. I want to maximize discovery. The thing to explore, I want more surprises. If I do something and I don't get a surprise, that's a failure, right? It means I did something I've done before, right? I want to do things...

Kent Beck: And you're guaranteed that that's not going to be it.

Daniel Terhorst-North: I want to maximize discovery. Now, I've got the thing, the rocket's launching. Now, what I want is to make it the same every time. I want to minimize variance at this point. At this point, I want to focus on keeping it stable, right? Stability is repeatability, is... What I don't want is, I deploy it this time and it's fine, I deploy the next time, and it just breaks, right? Because, guess what? That's when I don't want surprises, right?

Kent Beck: And as you scale new sources of instability appear.

Daniel Terhorst-North: Exactly.

Kent Beck: The stabilization isn't, "Let me take this known thing and then make it stable."

Daniel Terhorst-North: And make your cookie cutter.

Kent Beck: Stabilization is, "Okay, now, I go into third gear, and now the steering squirrely or so, I got to get it settled down. But now, I go into fourth gear, steering squirrely again."

Daniel Terhorst-North: Yes, exactly. And stabilization may not be...makes the thing repeatable. Stabilize may be a bunch of continual, small corrections to keep it on track. And then the third part, which is optimized, is now, "I am maximizing cost, so this is my efficiency piece," right? I've got this mass market. I've got this thing that's clearly a revenue generator. What I want to do now is reduce all the inefficiencies, and look at the economics of it. So, there's, like, maximize discovery surprises, minimize variance, economics, minimize cost. And when you publish your 3Xs thing, I was like, "This tracks so well with explorers, people, optimize," but, again, from a different perspective. I tell sort of both stories because they align differently.

Kent Beck: Well, this is also Simon Wardley’s...what's the new...explorers...

Daniel Terhorst-North: Planners.

Kent Beck: ...town planners.

Daniel Terhorst-North: It's the same language part of it, yeah, yeah.

Kent Beck: It's the same dynamic. It's a little bit the same dynamic as Knaffen. So...

Daniel Terhorst-North: It's like when you bring the grownups in.

Kent Beck: Right. So, exploration done right where you're maximizing discovery is adult behavior.

Daniel Terhorst-North: Exactly.

Kent Beck: In that context where you're looking for something new. If you do an extract-style project in exploration, you're doing it wrong, you're a bad engineer, you're a bad business person, you should feel bad. You should just be like, "All right." We need to try stuff safely, as many different things. And the more different they are the better. So, I say you're optimizing for latency, the time between idea and feedback, variance, and throughput.

Daniel Terhorst-North: I buy that.

Kent Beck: But software development is going to look similar in some ways. Something like continuous delivery is useful in exploration to reduce latency. Continuous delivery in expansion is useful for repeatability, to reduce variance. Continuous delivery and extraction is useful for reducing the risk of catastrophic mistakes, because when you get to extract you got a lot to lose if you make a mistake. So, you're going to see some of the same behaviors out of your engineering team, but they serve different purposes depending on where you are on the curve.

Daniel Terhorst-North: Fantastic. Okay. So, you say, like, you're half a century into this.

Kent Beck: So far.

Recommended talk: X Marks the Spot: Navigating Possible Futures with Wardley Maps • Simon Wardley • GOTO 2024

The Evolution of Agile: TCR, Limbo, and the Future of Software Development

Daniel Terhorst-North: I feel like you're just getting started. So, a couple of things. One is... And this is from a personal perspective. I've been around, and I don't know how to describe this, I was lucky enough to interview Ward Cunningham a few years ago, and I had a similar conversation with him, which is that you are a producer of this manifesto for agile software delivery, and I was a very early consumer of it. It's interesting to kind of look at this document, this artifact from these two perspectives of, like, you know, we wanted to come up with something that we could share with the world, and I'm like, "Hey, I'm the world, you shared it with me, and it was great."

I look at something like...and I'm going to name names, right? It's cool.

Kent Beck: Sure.

Daniel Terhorst-North: Let's start with Scrum. But they're all...most of the methods that came into the room you could say so. Let's start with Scrum. Scrum says, you know, I have these time boxes and they initially were six weeks and then they became four weeks and now sort of typically two or three weeks. We're going to have these time boxes, we're going to have these various ceremonies and stuff that we do. I'm looking at this and I play it forward a couple of decades, right? And mostly the wheels fall off. So, mostly if you look at the time frame, or the cycle time frame that it was designed in, it makes perfect sense. If it took me months to get a server, having a planning horizon of a few weeks made sense, right? If it took me weeks and weeks to build a feature, you know, planning each day made sense, right? Well, I'm now in a world where I can spin up a thousand servers in a morning and they're not even my servers, you know, and it's a credit card. I can deploy a feature through a browser, and every time you hit refresh, you just get a new app. Then suddenly, you know, these time frames are so compressed that, like, if you're planning in as enormous a time frame as a week, I'm eating your lunch, right?

I look at these, a lot of these things that came out of that time, and they're very much artifacts of an age, you can see the context they were in, you can see the problem they solved. I look at the XP practices, the technical XP practices, pair programming, test-driven development, continuous integration, right, working in small chunks, right, all of this stuff. And I'm like, "I still use that. I still use that every day." If I'm writing new code, I call it a code example, I generally start with a test because it's a model client, and the model client helps me design my API and design my code. I guess, it's a bit of a close question, but are you surprised that these things that you are articulating, you and Warden the gang are articulating decades ago, that they're still so relevant and so timely and so just applicable decades later? Would you have expected the field to have moved on enough to, like, that stuff was now?

Kent Beck: I'm sad that it hasn't, and I'm not surprised. I'm pushing past this replacement for test-driven development called TCR. Have you tried TCR?

Daniel Terhorst-North: So, tell me about TCR.

Kent Beck: TCR, it wasn't my invention. I was at a client and I said, "I have this thing where at the command line prompt, I run the tests, and if they pass then I make a commit." So, test.shell, and-and, git, commit. The student said, "Well, if you commit on test passing then, you have to revert if the test failed just by symmetry." I thought, "This is going to suck. Let's try it." You know you should try the bad ideas, right? Because everybody will try the good ideas.

Daniel Terhorst-North: What's the cost of trying a bad idea?

Kent Beck: Exactly. So, test, and-and, commit, or revert, get reset dash, dash on. So, practically what happens is you make some changes to the code. You save it. And you should auto-run this thing, but you save it, and if the test fails, the change you made just goes, poof. Then you're like, "Yeah, that was right. What's wrong with it?" You type it in again and you save it again and, poof, it's gone. Apparently that was a big change. I didn't know it was a big change. I thought it was four lines of code. Which two lines can I type in first? But this exact... I mean, the code didn't do what you thought it should do.

Daniel Terhorst-North: That's pretty hectic. I like this.

Kent Beck: It forces you to work in even tinier, tinier chunks. TCR is just a setup though. The payoff comes when we're programming separately. What if your machine's sitting there and it's loading the latest version just constantly, and my machine's sitting there loading the latest version from a repo that we share? And we're working in this TCR style. Now, I make a little change to it, it passes, commits, it pushes, it pulls right away to you.

Daniel Terhorst-North: So, it's like extreme trunk-base development though.

Kent Beck: Because you're working with a much faster feedback loop, you have a level of safety that you can't live without. And now the question is, "Well, how many people could possibly work this way?" And the answer is nobody knows, number one. And number two, I can't even get anybody to try this. It's five minutes to set up and nobody wants to try it.

Daniel Terhorst-North: I think this comes back to this idea that code is an asset. That the code that you write is something valuable. Code is costly. Code is a liability. The thing it does is the asset, right? Code itself is... So, if I've just tried to make an investment of code, I'll try to spend some code and it didn't work, I just got my money back.

Kent Beck: Exactly.

Daniel Terhorst-North: I get to try a different investment, you know. But you have to kind of flip that mental model of like, "No, I just did this work, and you just deleted all my...you just wasted my time." Well, I just wasted my time. Why would I do a thing where I waste my time?

Kent Beck: You just did something that didn't work.

Daniel Terhorst-North: Which means it was a surprise because you learned a thing, and the point was to learn.

Kent Beck: It was already a waste of time.

Daniel Terhorst-North: It was already wrong, yeah.

Kent Beck: It was already wrong, so why not just delete it and you get back to that state where, "I know how everything..." So, the collaborative version of this is called limbo because the question is how small can you make the changes. How low can you go?

Daniel Terhorst-North: Very nice. Okay. And I had not come across this.

Kent Beck: So, let's see, and I started on that rant because you asked...

Daniel Terhorst-North: I was just going to have practices and how they... You said you're kind of moving beyond that now, yeah.

Kent Beck: Then why hasn't it gone further or am I surprised? I am surprised it hasn't gone further. I wish that people were inventing stuff that I think is crazy and couldn't possibly work. Instead, I feel this tug back, "Oh, don't make me write tests." There's this TDD backlash, "You can't make me write tests. I'm a great programmer. You don't understand how good I am."

Daniel Terhorst-North: That's why I stopped calling them tests, Kent. There's a reason I stopped calling them tests, is because if you end up in a load of arguments that are nothing to do with the practice. The practice is writing a model client, to guide what you're trying to do. It happens that you can use it as a test after the fact, which is nice, but you're not writing a test, you're writing a specification that you're going to...

Kent Beck: Maybe you should just get over that. Just saying.

Daniel Terhorst-North: You're not the first person who said that.

Kent Beck: The fundamental question is, are you responsible for the behavior of the code that you write? If you're responsible for the behavior of the code that you write, then I expect to be able to come in and see how you're taking that responsibility.

Daniel Terhorst-North: Show me an example.

Kent Beck: Show me your work.

Daniel Terhorst-North: Show me you're working. 

Kent Beck: Where are the receipts? And if you say, "Well, I'm too good for receipts," I think, no 

The Importance of Psychological Safety for High-Performing Teams

Daniel Terhorst-North: You don't get to spend my money. You don't get to spend my money. Fantastic. So, I just wanted to throw in here because it feels really timely. Amy Edmondson who's one of my absolute heroes. Professor Amy Edmondson coined psychological safety, which itself is brilliant. I love failure stories. She was doing this PhD in...she's studying surgical teams in the U.S. You'll notice, I didn't notice, surgical teams go around, like, a pack. We have a surgeon and that surgeon will have their anesthetist and their nurses and their whatever their crew and they go around and that surgical team goes around doing stuff. So, it's an interesting thing, if you want to do team studies, it's a really interesting thing to study. So, her PhD thesis was, "We believe that high-performing teams make fewer errors." Seems pretty true.

Kent Beck: Yes.

Daniel Terhorst-North: "I'm going to go study high-performing teams and demonstrate they make fewer errors and get a PhD." So, she goes off with her research buddy, starts measuring teams, and she finds exactly the opposite. High-performance surgical teams with measurably higher success rates had more, like, statistically, significantly errors. She's like, "Brilliant, I just blew my PhD. What do I do now?" Then she had this insight. The insight was this, "What if they have exactly the same amount of errors as anyone else, but they report them." So now, it was, "Okay, so now these teams feel like they can report these errors, and once they're out and they're clear, they can learn from the errors and iterate and blah blah blah. Suddenly I've now figured out why these teams are successful." So then, her research was, "What is it about these teams that makes it okay for people to talk about errors?" That's where psychological safety came from. It languished as a kind of an academic backwater thing for nearly two decades.

Meanwhile, and you'll know this, Google was doing this project with Aristotle. They invested hundreds of people for years trying to figure out... Like, they got 60,000 engineers. "What makes a great team? We must have the data to make a great team." Two hundred data points. All right. Two hundred parameters. When in none of these parameters, no combination of these parameters was at all a signifier of successful teams. They're about to give up. Someone came across psychological safety, plug that into the model, bang. It was a bigger signifier of successful teams than all the other parameters put together. So, like, her failing her PhD, and then them failing Aristotle was what kind of brought it to attention. But that's her first album.

Second album. She's just done a thing. She's like, "Where does that go then?" Where that goes in terms of... And interestingly, so that's stable things, right, she's talking about. Now, what happens when you're starting a new thing? It's exactly your 3X's. She's just published a book from a year ago, I think, called "The Right Kind of Wrong." "The Right Kind of Wrong" is about failing well, right? And it ties in so well with what you're describing, is that, you know, if you're doing this kind of limbo-style development, what you're doing is you're plotting a path along exactly the right kind of wrong. How close can I escape to the edge of the right kind of wrong? I got it wrong, but I know how I got it wrong. As I learn more about how I got it wrong, I start getting it right. It just feels really nice...it feels... Though I can't articulate it, it feels like where you're going with limbo, and where Professor Amy is going with right kind of wrong, just feels like there's a convergence there.

Recommended talk: The Sociotechnical Path to High-Performing Teams • Charity Majors • GOTO 2023

Kent Beck: You're absolutely right that it's the degree of safety that we're shooting for. I imagine a kid picking up an iPad with limbo on it, and they're connected with the limbo server that everybody's using that's completely live, and they go and they drill into it and they see some code and they make a change to the code and they press save, or even, I mean... We'll start with this scenario, and if it sticks it sticks. They've just made a change to software that's being used by a billion people as a kid who doesn't really know what they're doing, but it's fine because it's perfectly safe. Now, you also have to make it perfectly safe for bad actors and scammers and all that stuff.

What would it take to have that level of safety in this system? I mean, this is super trunk-based development. And then you think, "Oh, well, that's not practical," and I say, fine, we call that a research agenda and we figure out how to create that sense of safety. How do you lower the latency and improve the results of that kind of filtering so that if you make changes that are going to cause damage, they don't make it through the mesh. If you make a change, doesn't cause any damage, it might be better, sure, it goes through, and it's immediately sent out to everybody else. That's the vision that I have.

I came up with this on Facebook. We had 5,000 engineers and a lot of people were thinking, how do you have 10,000 engineers? But nobody is thinking about, how do you have 100,000 engineers? And I thought, "Well, you know, this is just a dumb trick. Let me... I'm going to extrapolate 10 times as far as everybody else does," and so I did. That's what I came up with.

Daniel Terhorst-North: What's interesting to me is you've got... So, Ward takes his Wiki, his original Wiki idea, and says, "How do I federate the Wiki? The wiki is really cool but it's a single instance of Wiki. How do I get a federated Wiki." You're like, "I've got this sort of TDD into kind of like manic TDD, into limbo, how do I get, like, federated limbo?" I feel like it's kind of like this federated energy going on which is kind of cool.

Kent Beck: Well, the question is, how do I make a contribution that other people can leverage?

Daniel Terhorst-North: Fantastic, yeah. That's it. That's a lovely, lovely hanging question to finish on.

Kent Beck: Super.

Daniel Terhorst-North: Kent, absolute pleasure talking with you.