Latest / einfach gelöst / #11: Kent Beck - Action, Reflection, Community
Transcript
- Stefan Roock (it-agile): Hello and welcome to the IT Agile podcast Einfach gelöst. translates to solved a simple way or a more subtle meaning could be being relaxed. And I'm very happy to have Kent back here. Hello Kent. Kent: ⁓ hello, Stefan. Pleasure to see you again. Stefan Roock (it-agile): ⁓ Maybe there's one or two listeners who don't know you already. May you introduce yourself? Kent: Sure. So in my long career, some of the things that I've been involved in introducing are patterns for software development, work I did with Ward Cunningham. ⁓ The X unit family of testing frameworks came out of work that I did in Smalltalk. ⁓ The... documentation of refactoring, like here's this catalog of refactorings, ⁓ was something I was involved in. Test-driven development, once I had a testing framework, I started to have weird ideas about testing, so TDD came out of that. ⁓ Extreme programming was something I invented for a project, and then people took it in lots of interesting directions from there. And since then, ⁓ some things you might have heard of is ⁓ the 3X model, explore, expand, extract about how different development and management and everything is depending on where your risks lie and how that evolves. And I spent 18 years writing a book on software design, which has turned into multiple books. ⁓ the first of which is a tidy first question mark about ⁓ individual practice of software design and trying to understand it at ⁓ a deeper level, psychologically, sociologically, economically, and technically, like why is software design interesting? So that's my most recent. Well, not most recently. And then most recently, I've spent the last year on augmented development using these fancy new genies that grant your wishes, except it's not really what you ask for. So that's what I've been doing most lately. Stefan Roock (it-agile): Okay, thank you. So you already mentioned you invented extreme programming, ⁓ I'm pretty sure some similar kind of ⁓ development happened before that Kent: Yes? ⁓ absolutely. If there's an original thought in extreme programming, I apologize. I was trying to chronicle the very best software development activities that I'd ever seen. And so ⁓ the Lisp world certainly did this kind of very interactive, very short feedback cycles. Stefan Roock (it-agile): Mm-hmm. Kent: close contact with customers, that had been done already. Ward Cunningham had a process he called episodes, which was similar in a lot of ways. And the process was similar to the process that when Ward and I were programming together, we had a very social process focused on delivering functionality, ⁓ which... is kind of seems like kind of a contradiction for people who tend to be on the spectrum, but turns out you can make social interaction safe even for people who find usual social interaction very uncomfortable. Stefan Roock (it-agile): And then programming emerged in ⁓ Chrysler Kent: Yes. So in 1996, was asked to help with a project. I suggested restarting the project. They said, OK, but you'll have to be in charge. And I tried to not be in charge in charge, but I gave the team a lot of aspirations. And that's where that word extreme comes from. What if we did the things that we know really matter, but we did them as intensely as we can imagine? Now it turned out that we weren't anywhere near the limit. So we thought three week cycles was blazingly fast. Turns out that one week is a really good cycle time and one day is a really good cycle time for different sets of decisions. And a few hours is a really good cycle time for even smaller grain decisions. And now we're getting to minutes for even for those kind of smaller decisions to be made. But there's still a cycle going on at the larger grain sizes of a day, a week, a month, a quarter, a year. There's a reason that human beings mostly agree on those cycle times. Stefan Roock (it-agile): I met you in Italy in There was conference, ⁓ Extreme Programming and Methods. started ⁓ voting about renaming extreme programming excellent programming. Kent: It could be. I tried lots of experiments. Stefan Roock (it-agile): Okay. But was no majority for the renaming Kent: Yeah, and honestly, I might not have listened even if there was, but it's a separate set of issues. Yeah, that word extreme, I think it took a lot of criticism for it. And if I'd had a better alternative, I would have gone with it. But I was working with no marketing budget. I had to find a word that was both catchy and accurate. Honest. Stefan Roock (it-agile): Hmm? Hmm? Kent: And that was the best one that I could find. And there were people who just wouldn't look at XP because of that. shortening it to XP was a conscious decision to, you know, if you didn't want to call it extreme programming because people would laugh at you, you could just call it XP. And so I've called it XP for years and years now, and I seldom use the full name. Stefan Roock (it-agile): Some weeks ago, asked question if we have to understand the extreme in extreme programming in a way like, extreme sheeing. it would only be suitable for very few companies. since most people won't be able to do extreme sheeing, Kent: Yes and no. At the limit, the very best teams applying extreme programming are doing stuff that looks impossible. ⁓ couldn't possibly be... deploying 40 versions of financially important software every day. It just doesn't make sense. But it does make sense if you've done all the preparation to be able to do that. the other part is, can you get started? Stefan Roock (it-agile): Mm-hmm. Kent: with improvement, in a way, extreme programming is a rubric for improvement. Improving individual skills, improving social skills, improving collective skills, improving the organization that embeds software development among its many other activities. It's a way of pointing out where friction lies and Stefan Roock (it-agile): Mm-hmm. Kent: giving you means to address that friction. If you do that for a year, if the team gets together and they have the support from executives and they have a vision and they improve solidly for a year, they're gonna be doing amazing stuff. They're going to be much more effective. Customers are gonna be much happier. Defect rates are gonna go much lower. Costs are gonna go down. Unplanned work is gonna go down. If you look at that team after a year, you could say, well, only the best teams can possibly do this. But you should have seen them when I got here. Stefan Roock (it-agile): Mm-hmm. Kent: So, ⁓ I mean, in my cynical old age, I would say something like, some people would rather have an excuse not to improve than to go through the unpleasant experience of admitting how messed up things are today and then doing something about it, even though that's not a linear step by step. Stefan Roock (it-agile): Mm-hmm. Kent: And if you don't want to improve, don't improve. But don't blame, you know, that's a you problem, not a me problem. It is absolutely possible for people with ordinary skills, ordinary software development skills, to achieve extraordinary results. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. And then in the year 2001, there was the agile manifesto, one of the authors. Kent: I'm the first author, Stefan. Yeah, absolutely, because the authors are listed alphabetically. Stefan Roock (it-agile): You're the first of them. Yeah. Kent: I did not in fact write. I think I added one word to the whole thing. I ⁓ was sick as dog. had a bad sinus infection. I was on some heavy duty antibiotics and I hardly remember anything. Stefan Roock (it-agile): there? ⁓ Okay. Kent: Now, I've had several people approach me and say, ⁓ we need a manifesto for augmented development. Stefan Roock (it-agile): Mm-hmm. Kent: And what I tell them is it took us 15 years from the first UPSLA conference. So that's when people started talking about, hey, we've got these objects and we have a new level of flexibility that we've never had before. How are we going to use it? That question started in 1986 and it wasn't until 20. 2001 that we were able to articulate an answer. So it took 15 years. Augmented development has been here for a year, two years. And we just don't have the answers. And that's fine. A manifesto right now wouldn't help because we'd be focused on the wrong things, because we just don't know enough. The only way we're going to know enough is by trying a whole bunch of stuff. and in community discussing what seems to work. sharing back and forth. What of my experience applies to your context? What about your context maybe invalidates the generality of my experience? ⁓ I can't do that because blah, blah, blah. ⁓ I didn't know that was important. Well, how about this? And back and forth. And if we do that for 15 years, then we'll be able to write the next manifesto. People will say, we need a manifesto today. Boo hoo. You can't write one. that's going to have any effect because we just don't know what's universal and what's particular yet. I mean, it's kind of good news, bad news. As I was saying, what a great way to end a career on this massive revolution in how we do this thing that I love doing so And nobody knows, that's what I tell everybody I talk to. Well, how should we blah, blah, blah, blah, blah, blah? Nobody knows. You don't know, I don't know, nobody knows. So how are we gonna find out by doing a lot of stuff that doesn't work? And talking about Stefan Roock (it-agile): So the agile manifesto really the start of the thing. Kent: No, it was the culmination of a long process and ⁓ workshops, a bunch stuff was happening behind the scenes. Private conversations, ⁓ workshops, ⁓ visits and ⁓ lots of experimentation, up lots of stuff, teaching things in school and seeing what stuck and what didn't. All of that stuff was going on behind the scenes as a setup to the manifesto. It wasn't like, okay, let's get some more people in a room and we're just gonna meditate and then we'll write down what comes to us. No, no, there was tons of hard work and people want the cake without the baking. Yeah, I want the cake too, but. I gotta bake. Stefan Roock (it-agile): What afterwards with the industry software development? Kent: Nothing. We're at the status quo ante. Here's how I think about it. If you look at your development process, you might think, okay, well, I changed the development process this way, that way. I'll test like this. I'll deploy like that. But those development activities are really a projection. You know, Plato's cave? Plato has this metaphor, you're in a cave, there's a light behind you, all you see are shadows. Stefan Roock (it-agile): Mm-hmm. Kent: And you're not seeing yourself, but you're seeing the outline of yourself. And I think the same is true of software development. you go and look at development processes, they're the shadow that's cast by whatever the power structure is. So if you're in an organization where you can say, this is going to take six weeks, and somebody can say, no, it has to take three weeks or else. If that's OK behavior, if that's the power structure, then you're going to ⁓ cast a certain set of shadows. Stefan Roock (it-agile): Mm-hmm. Kent: that won't care about defects until later, hopefully it's somebody else's problem, where the developers are gonna say, well, he's gonna cut it in half, so I'll double it. And then the manager says, well, he's gonna double it, I have to, blah, blah, blah, blah. Right? Those activities, which can be absolutely bizarre. Like if you walk into that situation, you're like, well, why don't you just tell the truth to each other? Well, we can't do that. Stefan Roock (it-agile): Mm-hmm. Nice. Kent: So knowing what the power structure is, any to the development process are only going to be temporary because it's going to self-heal. And that's what the Agile Industrial Complex did, ⁓ is power structures didn't change. And so ⁓ development is pretty much what it was like 25 years ago. ⁓ Cycles are shorter, ⁓ Provisioning servers is a lot easier than it used to be, sure. But that balance, I talk about the features versus futures. How much are we going to invest in the next feature? Or when are we going to invest in the next feature versus investing in the optionality of the system? You know, things like. Stefan Roock (it-agile): Mm-hmm. Kent: what used to be called technical debt, paying down technical debt. I prefer the positive, you know, I'm a positive guy. So I prefer the positive explanation of that to talk about, now we have more things we could do in the future, even though we don't have more features. That balance really hasn't changed much. You have the same set of complaints now that we did 25 years ago. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: my frustration that computers could be doing so much more than they're doing now. They could be creating so much more value than they're creating now. ⁓ part of me just still doesn't understand why ⁓ haven't taken that path. Stefan Roock (it-agile): Mm-hmm. Kent: But I'm not gonna, I mean, we're we are and we're doing what we're doing and... I'll privately whine and complain about it and then I'll get back to work. Stefan Roock (it-agile): The Manifesto ⁓ was about software development. some tried to transfer to product just replacing software by product. others start talking about organizations ⁓ problems you described with the power structure may correlate to agile organization Would it be useful to about agile organizations or just keep agile for the software or product development? Kent: Well, think it depends on your goals and purposes. My mission has always been to help geeks feel safe in the world. Because when you have this kind of Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: skewed experience of the world, it's really to feel unsafe, even in situations where you are safe. ⁓ it's easy to ⁓ in unsafe ways, ⁓ though you have alternatives which would be safer, like yoloing code into production versus writing tests. ⁓ could be safe. ⁓ if somebody's yelling at you, you could still be safe. in that situation if you choose, if you've built that habit. in English you'd say stick to knitting. I have a focus, I ⁓ stay with focus. ⁓ And ⁓ I'm more comfortable talking about that have personally experienced than speculating. ⁓ The few times I've broken that rule have ended very Stefan Roock (it-agile): Mm-hmm. Kent: So ⁓ I'm happy to talk about specifics and let other people generalize. Should other people generalize? Should they have, what's the equivalent of pair programming for sales or? I don't know, fine. Try it, who knows? Might work well, might be a disaster, but you can't predict. So the only thing, if when you can't predict, the only thing to do is experiment. ⁓ I'm happy if other people do that. I've had the extreme programming book called a cult business classic. that CEOs read it, discuss it, some CEOs, maybe kind of odd CEOs, but that's fine. But that's not a me thing. I tell my stories, I explain how I understand the world. I try and make that useful to people who are more or less like me. And I'll let the generalization fall to somebody else. Now, is that a mistake? Stefan Roock (it-agile): Mm-hmm. Kent: I don't know. I mean, I'm happy. It keeps me out of situations. Here's what I don't want to have the incentive. Can I curse on your podcast or? OK, I don't want to have an incentive to talk out of my ass. Stefan Roock (it-agile): Mm-hmm. Kent: I don't know how that one translates, but I'm sure, you know, ⁓ the activity is universal. And I just don't wanna, like, I don't wanna be on a stage in New York City wearing a custom suit. So far, yes, absolutely. But then have somebody ask me some business question and I feel the... Stefan Roock (it-agile): Hmm? Kent: urge to make up some bullshit answer. I just don't want to put myself in that position. You know, we can tell you say, well, what level of optimization do you use for the, when you compiled with GCC blah, blah. Like, yes, fine. We can dig into that. And if I don't know, I'll just say, I don't know. It doesn't, doesn't bother me. I just don't want to be in the position where the, best response is to make some shit up that. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: is gonna harm somebody else's life. I'd hate to do that. So I stay out of that. Stefan Roock (it-agile): let's come to Present and future, already talked about AI and augmented development. what do you do there and what do you think will bring the future? Kent: First are saying this is unprecedented. Nothing like this has ever happened You know since the invention of silicon. This is the biggest change in community. That's not true Stefan Roock (it-agile): You Kent: ⁓ We've felt the sand shift underneath our feet before in development. Like when objects hit, it was like, ⁓ all the rules have changed. And we don't remember that because that's ancient history. But it absolutely took the set of certainties that we had about development leading up to that, whether they were true or not, and blew the whole thing up. and people didn't know what to do. What I've observed is that people reacting the best are either people who've been through times of change like this before or the people who just don't know any better. So I think now is a wonderful time to be a junior programmer. Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: because you're gonna learn so much faster, or at least you have the opportunity to learn so much faster than we did. You have more community, you have better tools for it. The Genie is an outstanding tutor. If you don't, if you double check the answers. Stefan Roock (it-agile): Mm-hmm. Kent: So you can say, how does this work? So if you have curiosity, ⁓ it's heaven. Well, turn this into a haiku for me. Sing it to me as a folk song. Draw a picture as if by Monet. however you understand the world, you now have ⁓ a genie that's willing to explain the world in those terms to you. So the juniors are reacting well. The people kind of on the far side of their career, like me and maybe you two, also seem to be reacting, by and large, reacting well. Like, OK, let's dig in to do it. The people who are having the most trouble are people with 10 to 20 years of experience, who've grown up in a world where Stefan Roock (it-agile): Yeah. Mm-hmm. Kent: Yeah, you can always improve, the solutions came from a known menu. You had a menu, you know, we have too many defects in a production. ⁓ refactor like this, test like that. Like, we know what kind of what to do. And they learned that menu and they learned how to pick items off of that menu and apply them. But they never operated in a world where there wasn't a menu. And figuring out that menu, that's what I did. That's what you did too. And you know, I was happy to have a menu, but I'm also really thrilled not to have a menu anymore. And to be like, well, what do skills do? What's an MCP server do for this? How can we recast this old thing that people thought was obsolete into this new content? Like, ⁓ wow. fantastic. So I'm trying all kinds of stuff. I'm building fundamental data structures. Like I have a, I don't know how many times I've implemented the B plus tree now, but high performance versions of it, like library quality, both in performance and in reliability. And I just keep trying it over and over again. Stefan Roock (it-agile): Hmm. Mm-hmm. Kent: Because it's a complicated algorithm. It's easy to get wrong. Performance really matters. So I'm doing, yeah, how many cache misses do we have if we tune this parameter like that? Like, ⁓ that kind of programming is really, speaks to my heart. And I love doing it. So I'm able to do that kind of, make decisions at that level in a way that I haven't been able. But I'm also trying just ridiculously ambitious projects like re-implementing Smalltalk from scratch. Yeah, why not? I want a persistent Smalltalk within memory transactions and ⁓ multiprocessing. Sure, from scratch. New bytecode set, here we go. I ⁓ mean, part of my trouble, I've always been a... Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: As the late Reverend Jesse Jackson put it, a tree shaker and not a jelly maker. I like getting stuff started more than putting the finishing touches on things. And it's so easy to start stuff now. You know, so just tracking the tides outside my window. Build an app for that. Sure, why not? Never built an app before. Fine. Never looked at Kotlin. One of the astonishing things is how little programming languages matter. Oh, you want me to do this project in Rust? Okay. You know, I would, two years ago, you'd say, well, but the project has to be in Rust. I'm like, my thing. Now I did, that didn't scare me. After I spent a hundred, 200 hours in Rust, I'm going to know a lot because I have that habit of learning. Stefan Roock (it-agile): Mm-hmm. Kent: So I look at Rust code, I'm like, ⁓ what is the single quote bracket bracket, what does that do? If I don't know, I ask. And so I learn very quickly if I'm not just focused on how much Rust can I crank out, I don't care. I care how tickled my curiosity is. Stefan Roock (it-agile): years ago there was a movement called polyglot programming. The idea was using the most suitable programming language for ⁓ a certain task. ⁓ you would need several programming ⁓ from point of view, it was too challenging ⁓ with AI support that could become reality. Kent: ⁓ could, but also ⁓ of programming language doesn't have the leverage that it used to. Stefan Roock (it-agile): Mm-hmm. Kent: Which, know, I was deeply invested in the small talk world, still love it, you know, and I'm trying to bring it back. That's how crazy I am about it. But ⁓ how much does it matter? You know, there's so much else that matters. So yes, we may have multiple languages, but those languages may not matter all that much. I've got a thought experiment for you. What if we invented a language? Stefan Roock (it-agile): Yeah. Mm-hmm. Mm-hmm. Kent: that the genie could manipulate very, well, much better than our current languages, but human beings couldn't read and understand it. Would we use that language? Stefan Roock (it-agile): Mm-hmm. Mm-hmm. Kent: Yeah, exactly. I love thinking about it because it really bugs me. It's like, I know what the answer is and I really don't like it. Of course we'd use it, but I really don't like that. And as long as the genie's given us contradictory answers and, you know, as far as it has come, last week I had a ⁓ ⁓ Stefan Roock (it-agile): Yeah. Mm-hmm. ⁓ okay. Kent: ⁓ Wednesday or a Thursday. Two different genies gave me two different answers and I, and I, you know, ask one, help me convince Gemini that it's actually a Thursday. You know, what should I say? Here's the prom and then copy the prompt over to Gemini. Like, no, it's absolutely a Wednesday. You tell chat GPT blah, blah, blah, blah, blah, and forth. You know, it was kind of fun for a little while, but even basic stuff like that as as amazing as some of the things a genie can do. It's still a genie and it will grant your wish in its way, not in your Stefan Roock (it-agile): call it augmented development. What ⁓ exactly that mean? Kent: I'm the programmer. Stefan Roock (it-agile): Mm-hmm. Kent: I'm making the programming decisions at a high level. Project management, task breakdown, tracking decisions, looking for mistakes, looking for cheating. know, the genie will just delete the contents, still will just delete the contents of tests so that it can, I call it finger guns. You bitch a boss, yeah, we're all finished. Stefan Roock (it-agile): Mm-hmm. Kent: Like, nah, hang on. So I'm the responsible party. I haven't handed anything off to any, I don't expect that like, ⁓ this myth of write me a profitable app. Chug, chug, chug, ding. Like, no, no, I mean, I'm building a database here. There are trade-offs to be made. Stefan Roock (it-agile): Mm-hmm. Kent: I have assistance in making those trade-offs. That's what I mean by augmented. The genie is helping me to make better decisions and then ⁓ dealing with the details of the consequences of those decisions. So for me, feels like it's like an exoskeleton. If I could lift 50 kilos just with my body, I put this mech suit on and now I can lift. 10,000 kilos. But the impulse to pick something up is still my impulse. I'm not giving that. Stefan Roock (it-agile): Mm-hmm. Kent: Now, and then I have, I have arguments with the kids these days. They're like, ⁓ now you're, you're hanging on too much control. And that might be true. ⁓ but that's how I see it. That's the framing I put around it. Programmers are still programming. I'm still making, it feels like programming. I'm still making decisions. I'm still learning about the same thing. I mean, what got me into programming is this mechanism is so complicated. I can show you. have my dad when I was a kid, my dad brought back the Burroughs 6700 reference manual. And the Burroughs 6700 is a fascinating architecture because it doesn't have registers. It has a stack in hardware, implemented in hardware. And I read that cover to cover when I was a kid. I understood nothing. Stefan Roock (it-agile): Thank Mm-hmm. Kent: But I was just absolutely fascinated with this mechanism that's so complicated. And I still am. I still have that same sensation of... wow, all this stuff is going on behind the scenes and I don't understand it and I want to understand it because the degree to which I understand it, like that just, that moment of insight feels fantastic to me. And once I have it, I can use those insights to have more power to open up possibilities for myself. And that all feels exactly the same, except now, Stefan Roock (it-agile): Mm-hmm. Kent: I got this power suit and I can build a database from scratch if that's what I want to do. Stefan Roock (it-agile): And XP practices, they still valid or are they changing? Kent: There's nothing there that I wouldn't still do. test-driven development more important than ever. When you have a genie with no conscience, with trained to get to... Task completion, yeah, finished boss. And not really be, not think about the future. It's more important than ever to have feedback loops and feedback that's persistent over time. One of the things that's kind think is the wrong direction people are going? Is they're trying to get genies to work longer and longer autonomously. Stefan Roock (it-agile): Mm-hmm. Kent: as opposed to using the genie to figure out how to integrate more and more frequently. So I this thought experiment called Limbo that asks, if, ⁓ you know, people talk about having 10 PRs per day or 20 PR, what if programmers had a thousand PRs per day? What if I extract some function, I give it a nice name, Stefan Roock (it-agile): Mm-hmm. Kent: And that appears instantly in your copy of the code. Why not? What if that goes directly to production? I can't have broken anything if I use automated refactoring. So Limbo is an experiment in how small can we make changes that go to colleagues, in this case would go to other agents. that go to production that goes into everybody's pocket all around the world. We could use the augmentation of the genie to help make those steps be smaller instead of thinking, let's have bigger and bigger batches. We know what bigger batches lead to. Merge hell. Like, queuing theory, nothing about the genie changes anything about queuing theory. So ⁓ it might be uncomfortable, but I think the direction I'm going in is exploring how much more extreme can we make extreme programming, not how much less can we make it and still survive. Who cares? Stefan Roock (it-agile): Okay, So we will end up with even more extreme programming. Kent: I hope, yeah, least some people will. ⁓ ⁓ feedback loops need to be in place. That's the whole, people have this vision of one shot. I'm gonna make a prompt and it's not gonna be what I want, so I'm gonna make a bigger prompt. I'm gonna start over from scratch. I'm not gonna take a thing and modify it and modify it and modify it. Stefan Roock (it-agile): Mm-hmm. Kent: And I just, like if it works, it works, but it just doesn't scale very. So ⁓ I want to figure out how to use the augmentation of the genie to help me make, here's a thing that's valuable, I modify it, now it's more valuable. Now I take that thing and I modify it and it's more valuable. Now I modify it, maybe I don't add any features, but I make it more option rich. And I keep looking up because there's birds flying by my office. ⁓ So that's goal. And I think at the limit, that is going to be much more extreme. The cycles will be shorter. The size of batches of changes will be smaller. Stefan Roock (it-agile): you read and understand all the generated code or just the tests? Kent: Hmm. Depends on my goals. I certainly feel the temptation to just... Stefan Roock (it-agile): Mm-hmm. Kent: And then I go and read the code after a while and I'm, is a disaster or it's a lie. ⁓ So that's another one of my projects is called Wait What? Stefan Roock (it-agile): Mm-hmm. Kent: You know, for when the genie goes, I want to say, wait, what? I want to see what you just did. And the genie is actually pretty good at summarizing changes. Especially if you use a different genie than the one that generated the code, because the one that generated the code likely to lie to you. But if I use a different one, hey, well, what just happened? know, critique this. You're an expert in whatever. Stefan Roock (it-agile): Mm-hmm. Kent: critique this, what changes do you wanna make? So I feel the temptation not to look at the code ⁓ and I learn less when I give into that temptation, which I do sometimes. Stefan Roock (it-agile): you for these insights. Where can people learn more about augmented development? Kent: I write at, ⁓ so a newsletter, that's my main business now, it's called tidyefirst.substack.com. ⁓ And you can read about stuff there. ⁓ I give talks. I like giving talks to internal conferences if you're interested in that sort of thing. ⁓ My latest book, Tidy First, is my thinking about software design. I'm working on a follow-up called augmented software design that recasts software design in an augmented world. It's still a test of human relationships, software design is. Yeah, I wish that it was just coupling and collision and blah, blah, blah, all that stuff. But it really isn't. ⁓ The bigger conversation around software design is when do you do it and how much do you do? And how do you break it, a large software design investment up into small pieces? Those questions still remain whether you have a genie involved or not. So that's the best place to catch me is at the newsletter. Stefan Roock (it-agile): did we miss any stuff? ⁓ But do know which? ⁓ Kent: ⁓ That's the key question. ⁓ Stefan Roock (it-agile): You Kent: the message to everybody is nobody knows. And if you've never been in a position where nobody knows, it can be really uncomfortable, but it's okay. Because the solution is action, reflection, and community. Same way we got to the relatively stable software development in the last 15, 20 years. That came out of a process of action, reflection, and community. And we can do it again. In fact, there's no other path towards having a set of principles and practices that are adapted to the new context that we use for development. Stefan Roock (it-agile): thank you very Kent for ⁓ your time and insights. I liked it very much. Kent: Thank you so much, Stefan. It's great talking to you again.