Host Intro (Gene Kim)

All right. Actually, as I was writing Kent's intro, I just realized that this is something I've wanted to do for at least two years. I've been complaining to Kent Beck that I just really don't like the way he introduces himself. So I'm going to cosplay Kent Beck.

Hello, my name is Kent Beck. I've been programming for 50 years. I've had the privilege of working on so many fun and interesting projects in my career, and many people ask me, "What does all those projects have in common?" And I finally realized what it was.

I want geeks to feel safe in the world. This applies to me. It applies to programmers who need to be creative and do their best work. It applies to teams and organizations who need the results of that best work.

I created Extreme Programming in the 1990s to create safe social interactions for disparate teams. Pair programming, frequent replanning, continuous integration — XP — to make every collaboration safe, natural, and awesome.

I also created the xUnit in Smalltalk and Java JUnit testing frameworks because we wanted to make it easy for developers to write their own tests, which — would you believe — at one point was considered reckless and irresponsible.

I was one of the 17 people who strongly felt that the heavyweight development frameworks like Rational Unified Framework and other heavyweight processes were a sure route to madness, and the output of that was eventually known as the Agile Manifesto that was signed in 2001, and I was the first signatory because it's in alphabetical order.

And for me, it's all about two people. We're going to minimize the distance between the person with the problem and the person who can code up the solution. And maybe we can get rid of all the processes and tools between them.

And I was at Facebook for seven years, and I was so proud that of the top 100 engineers, eight of them were people that I had coached back when they were junior engineers.

So I'm Kent Beck, and long live Smalltalk. How was that for a Kent Beck impression?

Kent Beck

That was so much better than me. My name's Kent Beck, and — what Gene said.

Out of the eight topics that I wanted to talk with you about today, I've picked three of them — one kind of large and two kind of small. So we'll get into it.

Now, I've invited Gene to interrupt me in case I get this first one a little bit wrong. That's a dangerous thing to do. But we'll see what happens.

01Nobody Knows

I have three words for you.

Nobody knows.

And yes, I realize that's actually two words. Anyway, just in case anybody has OCD, I wanted to trigger it so that you'd listen to the rest of what I had to say.

So, nobody knows. That's the answer to all the questions that I get. It's not that I don't know — it's that nobody knows. So when I hear someone confidently say, "Here's how you use the Genie" — I call it the Genie because it grants your wishes, but it's not what you really wanted — I prepend to whatever they say, in my short and limited experience, in my particular context, without understanding the long-term consequences, here's what you do. Because that's all any of us can say at this moment.

What a fantastic time to be a programmer. Everything is changing so fast. And for me, I'm just delighted. I'm a little jealous of Adrian's presentation because I have a bunch of projects too, and I'm not going to talk about any of them. But I'm very excited about all of them. I wake up in the night with ideas for what to do next. An idea pops into my head — I could do anything. I can't do everything. But now, in a way that just wasn't true two years ago, I could do anything.

So I have low-level projects. I have formal methods projects. I have ridiculously ambitious — building a database, an object database from scratch, just because I can. Maybe. I think so. We'll see.

So last week, I was at a workshop with Gene, and I got a question from the audience. Someone — I'll call them Olive — stood up. I heard that some people know who I'm actually talking about. Olive stood up and said, "Is TDD important in the age of augmented development?" And I said, "Nobody knows."

That was not an emotionally satisfying answer for Olive. "Yes, but you've been talking about TDD for lo these long and many. I've heard people say that it's really valuable for the Genie. I don't particularly like TDD, never have. Is it important?"

And I didn't say, "I don't know." I said, "Nobody knows." Nobody knows — and that was not good enough.

It was one of these interesting moments where, as a speaker, sometimes you'll get a question that's so emotionally loaded that the best you can hope for is to be there emotionally for the person who's asking the question. And I completely blanked out the intellectual content of whatever my answer was to them, just to say, "It's okay. It's going to be okay. Nobody knows. That's not a tragedy, that's an opportunity."

And I don't know — I haven't heard from Olive since then, so who knows? They may be onto their career as a couch-surfing tango teacher, which is not a random example of somebody who started with Extreme Programming. I got a message a few years after the XP book came out: "Well, I started this XP stuff and now I am a couch-surfing, internationally-traveling tango teacher." I'm counting it as a win.

So, topic number one: nobody knows.

If you've heard the 3X — explore, expand, extract — stuff that I talk about: in software development, we were firmly in Extractistan. There was a menu. You'd pick from the menu. You had known problems. You had known solutions. You could learn new solutions. You could tweak stuff, but it was a menu, and it was printed, and everybody agreed on it. That's extract world. And you gain power in that kind of world by knowing more of the menu than other people do.

We have all been forcibly relocated to Exploristan. And in Exploristan, nobody knows.

It's okay, because there are good techniques for living in Exploristan. You learn to try everything. You learn to try the stupid stuff. Do you know, trying stupid ideas? It's the best. Don't do it in public, but if you try stupid ideas, usually they fail. So the key skill is invalidating stupid ideas as inexpensively as possible. It's not "how certain can we be that we're not making a mistake" — that's an extract kind of thought. It's "how quickly can we invalidate this idea?"

And then if this happens to be one of those ideas that turns out to be correct — by the way, those are the most exciting words in engineering: "it turns out." Oh, I love it when I hear somebody say that, because I'm about to learn something new. If this stupid idea turns out to be a good idea, one, you have no competition, because nobody else is dumb enough to try this idea, and two, you have a lead on everybody else. It's going to be surprising, it'll be valuable, and you can take advantage of that.

So when you're in the extract world, learning to quickly reject ideas that probably aren't going to work is a valuable skill. But when you're in the explore world, learning to trust your impulses and your curiosity — that's the valuable skill.

Cultivate it in yourselves. Try everything, a little bit of everything. And if you miss something, it's okay. The community is going to try everything. But figure out how you can quickly invalidate ideas.

02Features Versus Futures

So that's topic number one. Topic number two:

I've been puzzled for a long time about why development slows down. And I notice with the Genie, development slows down faster. The kind of messes it used to take me a team of 10 and two years to get into, I can create for myself in a week. Talk about your 10X productivity.

But if you look at my GitHub, there'll be a project, project two, project three, project four, new project, new project two, new project... I never number the first one. I don't, because this is going to work this time. It's going to work this time. I'm not going to just drive this into the ground.

So the intensification of this experience — of progress slowing to a crawl and having to start over — got me thinking.

The usual visualization of it is: over time, we have this graph, and then we plateau. And everybody hates this. It's a little like the weather — everybody hates it, but nobody does anything about it. But we can.

So I was thinking about that graph and thinking about how that timeline now shrank from years to minutes. But do I understand it any better?

And I remembered a trick from Edward Tufte's book, The Visual Display of Quantitative Information, which is a mind-altering book if you haven't seen it. And the trick is: if you want to understand causation, don't use time as one of the axes.

So if I can't use time, what goes on the other axis if we want to understand the relationship?

My first thought was technical debt, but technical debt is, one, negative — and I like being positive because it's too easy for me to be negative — and two, people just don't get it. We've been trying for 30 years. Perhaps it's time to give up.

So what's the alternative? The alternative for me is something that I published in Tidy First. Two years ago now, I published an O'Reilly book called Tidy First about software design and the natural laws underneath it. Took me 18 years to write, and it's only 90 pages, so I don't know what that says about my productivity. I guess there's no AI-generated text in it, so that's why it took so long. Anyway, in that book I talk about the optionality of software. And in my desire to go for clever verbiage, I started talking about the futures of software.

Now, the diagram I'm about to show you was refined over the course of four breakfasts in Tokyo with Gene Kim. Not a sentence I ever expected I'd say, but there you go. We were both in Tokyo, both presenting, both feeling kind of under the weather, but we felt good enough to get together to talk for two hours at breakfast every day, and then we were wiped out for the rest of the day. Should've known.

And I'd shown him the basics of this diagram, and we worked out the details from there.

So the way it works is: when you develop, you start with any number of futures — you could implement lots of different things. When you add a feature, you burn some of those futures. At the very least, you'd have to rip that feature out if you wanted to replace it with a different feature, or you have to maintain backwards compatibility if you add another feature. So every time you add a feature to a system, you reduce the futures to some degree.

And now what happens with the Genie? You get the finger guns, right? You know, the finger guns. "Great idea, boss. Got your feature finished. We're all set. Do you want the next feature?" Those are the finger guns. And it's just so tempting to say, "Sure. That was easy. I got some benefit. I hardly had to work. Give me another feature." But then you're going to burn more futures.

Can you see how futures is the inverse of tech debt?

And then another one, and then another one, and eventually you get to what they call in the nuclear power industry, going solid. Going solid is not a good thing if you're running a nuclear power plant — it means you have no more control. And in this world, you have no more chance to add features.

Now, what people do when they reach this is they just add a little bit of optionality and then... but regular people can do that. We're not regular people.

So what's the alternative? Well, that first feature — nothing you can do about it. But now we have a choice. We have the choice to either jump to the next feature, or we can look at what we have and say, "What's going to create more optionality?" And this might be refining the structure. It might mean better tests. It might mean documentation. It might mean spending some time looking at alternatives. There's lots of things — better build system, better deployment — that you can do to improve the optionality as we go along. And then you can add the next feature, and then add more optionality, more futures, feature, futures, and up we go.

And the thing I like about this trajectory is that if we just look at those top dots, it looks like the system is getting more features and more options at the same time. Now, you and I know that that's not possible, that it has to be this rapid alteration. But if you alternate fast enough, from the outside world it looks like a smooth curve.

And that's what I'm trying to promote in my own practice of augmented development — those moments of: just finished a feature. Hmm, what could I do to make this easier to change in the future?

Now, philosophically, this doesn't look any different than Extreme Programming. Philosophically, Extreme Programming always said: take the time, make your work easier. I have that phrase — for each hard change, make the change easy, then make the easy change. That's always been part of the XP ethos, but it comes into much sharper focus when you're working with the Genie. When you're working with the Genie, it just wants so desperately — not exactly to be loved, it wants to not be contradicted. Kind of like your kid comes to you with the pancakes and they're not really cooked — it just wants some validation. Whether the pancakes are good or not, validation's fine. And that's how the Genie treats me.

So it's up to me to say, "Okay, we got this" — and I was doing this earlier today on one of my projects — "fine, but now we have two mechanisms to do the same thing. Let's take a moment to unify those two mechanisms, and then we'll add the next feature." And the Genie's actually helpful. If you ask it for help, it'll help you do that kind of work. But it's not going to, as yet, volunteer to do that kind of work.

So that's the trajectory I'm trying to create, that I think we all have the opportunity to create.

A particular application of this is to the work of juniors. When seniors are adding optionality, we do it by improving the structure, by making builds faster, deployments better, better observability — those kinds of things. When a junior programmer takes that moment between features and improves optionality, they do it by learning something.

So I want my juniors to be taking time and learning. I don't even know what the upper bound is on how much time — like half maybe would be good. How could you implement this differently? Do you really understand it?

Actually, I want a version of Git that has multiple choice attached to each PR. Before I let you submit this, could you explain how this and this operation works? And if you get it wrong, it just rejects it. You have to start over entirely. If code is free, starting over entirely is the right solution to lots of problems.

So for me, this is the direction I'm exploring. What are all the different ways that we can add optionality to our systems? Technically, how can we do it? How can we create incentives so that teams of people do that? How can we manage so that people are encouraged to add optionality to the system? Features are very visible, very legible — it's easy to see features, and it's hard to see optionality. Inside the team, people know. But outside the team, it's hard to observe.

So this is the big idea. This is features versus futures, and if you have any questions about it, please let me know.

03What Comes Next

The last thing I wanted to talk about: I took this snapshot earlier today.

Nodes — I would say people, but that's okay. People that suddenly must talk all the time: customers and engineers, sales and engineering, executives to managers.

And you know what? I hate to say I told you so. I hate for other people to say, "I told you so." I don't like to hear it. I love saying it. But I figure other people probably hate it.

I'm not saying it's easy to have these conversations, which is why in Extreme Programming we worked very hard to make it safe to have productive conversations across specialties. It doesn't happen at random. If you just throw people into this, it's not going to happen.

Now, the other thing I noticed, though, is we never said, "Well, what's the role of executive leadership in creating the environment in which these conversations can happen?" And so that mostly didn't happen. We had lots of localized successes that didn't tend to spread. But this is exactly the kind of social network that we intended to create with Extreme Programming.

So if you'd like to know what comes next, I have a quarter century of experience in what happens next. So let me know.

The end of every Gene Kim-sponsored talk is what you can do to help. I have consulting time available. I would be happy to explain what happens next, or how to grow communities of practice that are dealing with situations of rapid change, high levels of uncertainty, what technical leadership looks like in that. Do let me know.

Now, I have a newsletter called tidyfirst.substack.com. If you subscribe to that, I will explain the other five topics. Within the next week, I'll have a post on the other five topics that I really wanted to talk about that I didn't have time for today. So if you subscribe, it'll be there. It'll bug you gently about signing up for money. You don't have to do that.

I also have a podcast now called "Still Burning" — which is not about hemorrhoids. Well, you just see the old people go, "Oh, did you have to say that?" It's about geeks who still care and are still doing something about it. And I recorded an episode with Angie this afternoon that will be coming out — I don't know exactly when. Subscribe to that.

And I think that's about it. Gene Kim, thank you so much for the opportunity of addressing this audience. I appreciate it.