The human part is the hardest part in

software engineering.

>> This is the biggest cosmic practical

joke ever. We were promised here's this

computer and if you completely

understand this computer, you'll be

fine. That's all you need to do.

>> When did TDD come along?

>> I was just kind of farting around and I

would write the test before I wrote the

code. And I can remember laughing out

loud cuz it was such a stupid idea. Why

would you write a test that you know is

going to fail? TDD is a good example

where it almost went out of style

completely. The big part of it is I work

on something for a while and then I

switch to something else. I moved on to

the next thing. TDD is out there [music]

and then there were people who used it

as a moral cudel like you should be if

you're not using TDD you're not

professional. Extreme programming was

born. I didn't want Grady BCH to ever

say that he was doing this thing. So I

had to pick a moniker that was

unattractive enough that somebody would

try and steal it. A little bit of thumb

the nose at the establishment. Extreme

sports were there. I like the analogy

with extreme sports. 17 people rolled,

but you're the first one listed. The

agile manifesto.

>> Things weren't going very well because

there's all these people and I want my

stuff in. No, I want my stuff in and

that contradicts your stuff. And we took

a break. We walked out and [music]

Martin and Jim Highmith stayed behind.

When we came in from the break, there

was the basics of [music] the manifesto.

For a couple of years, we've had AI

alums. So, one of the things is that the

pace of development is definitely

accelerated. One thing I wonder

Ken Beck is one of the living legends of

the industry. He's greatly shaped the

software engineering profession and

[music] keeps impacting it even today.

But there's not been a podcast episode

covering his whole career from start to

present [music] until today. In this

conversation, we cover how Ken grew up

with computers in the 70s and how he

fell in love with small talk. The origin

stories behind TDD, extreme programming,

and the Agile Manifesto and while agile,

the word was a [music] mistake. lesserk

known stories like how he got fired from

Apple, Ken's laws decade in the 2000s,

and why he thinks TDD has failed, how he

thinks about and uses AI and what still

excites him with coding after 40 plus

years and many more. If you'd like to

understand how True Legends was shaped

by the industry and shaped software

engineering himself, this episode

[music] is for you. This episode is

longer than most of my podcast episodes,

and I do hope that you'll find that it's

worth the time to listen to Kent longer

than he's ever told his story in one

setting before. This episode is

presented by Antithesis. If you work

with agents, your job is no longer just

writing code. It's specifying and

testing it. And antithesis is the most

effective method of verifying agenda

[music] code today. This episode is

brought to you by Turbopuffer. A fun

fact about Turbopuffer is how they

become the search engine for AI agents.

It seems like every week they add a new

use case from one of the leading AI

companies. RAM, Lorra, Harvey, Granola,

they're all on Turbopuffer. Or as the

team likes to say it, they're all

puffing. Turbopuffer offers a full set

of search tools. vector search, full

text search, attribute filtering, ragex,

and more in one API. It's built on

object storage as a sole stateful

dependency. So, it's extremely scalable,

reliable, and cheap. But it's also very

fast thanks to its intelligent caching

layer. One cool thing about Turbopuffer

is you can have unlimited search

indexes. So, it's perfect for

multi-tenant AI applications. Build an

index per tenant, data is isolated by

default, and you can scale without

thinking about it. Here's the best part.

Turbopuffer just announced last week

that they've dropped their base price

from $64 per month to $16 per month. So,

there has never been a better time to

test it out. Head to

turbopuffer.com/pragmatic.

And it's so good to have you in person

on the podcast. Guy, it's great to talk

to you again. Yeah, I wanted to kick off

with something really timely. There was

this uh tweet going viral by Daario

where he said, I quote, "Coding is going

away first than all of software

engineering." you had some things to say

about it.

>> Yeah. My response is that that's a

statement by someone who doesn't

understand software engineering. Coding

is part of what you're doing, but it's

only a small part of what you're doing.

Even if it takes up a fair amount of

time,

you're building confidence, you're

building connections with other people,

you're building your own understanding.

All those things are happening while

you're coding. And coding's actually a

great way to cement understanding. The

more you program, the more you

understand the domain that you're

working in. So to say, well, we're just

going to pass all that off to a machine.

Well, you're that's not all there is to

it. Interesting because one thing that

is so obvious with LLMs is they just

code really quickly, right? like it it

used to take us a lot of time to both

type it out and also thinking out but

you're saying that there was thinking

involved and understanding involved as

well in that process right so a couple

of days ago I I I

saw a phrase and it really hit me that

we're accumulating code faster than

we're accumulating trust and that sense

of trust comes from me

struggling to understand some domain

concept I get it. I represent it in the

code. I have I write tests that

demonstrate that I really did understand

it. And now I trust my program. But if

we're programming together, that act of

programming together means that we trust

each other more. If we talk to someone

an eventual user and we demonstrate that

we understand their needs and we, you

know, they tell us, "Well, I want a

button that does this." We're like,

well, what problem are you really

solving? And we go back and forth and

back and forth. That builds human trust

as well. None of that can be automated.

None of that occurs if we prompt the we

get the finger guns, you know, the genie

goes, "Yeah, it's all finished, boss."

And it's like, "Well, hang on. Finish.

What's finished?" As we're talking about

software engineering, you mentioned

trust, connection, understanding.

You didn't mention technologies, you

didn't mention programming languages,

you didn't mention wouldn't even mention

refactoring. This is really interesting.

You you've been doing this for what 50

plus years now. Do I understand that the

human part is the hardest or most

important part in software engineering?

Th this is this is the biggest cos

cosmic uh uh practical joke ever. As

young people who some of whom like I

don't understand humans very well, we

were promised, okay, here's this

computer and if you completely

understand this computer, you'll be

fine. That's all you need to do. So I

set out the first part of my career just

to become the best programmer that I

could be because that's what it would

take to be successful. And then woo

sorry there's this whole human side and

your ability to affect change in the

world is gated by your ability to

communicate with empathize with gh

empathy

not my natural strong suit to convince

to communicate with to soothe to

understand other human beings and those

are exactly the skills that I thought I

didn't need to learn. So I was promised

just understand the computer and then

just kidding understand people from a

position where I was already 10 years

behind. So I I'd like to go back to to

right there to the very beginning cuz so

many people know you from from your

books from a lot of the techniques and

and the techniques that that that you've

co-created or or

made it made a lot more popular. XP,

TDD, a bunch of other just small

refactorings and so on. But going back,

how did it all start? How did you have

your first contact with computers? I I

know your father was an electrical

engineer.

>> Yeah. So, my father started out as a an

electrical engineer. He was in the Navy

in the Korean War as a radio operator.

uh came out of that, went to school, got

an electrical engineering degree,

started working in uh aerospace

uh as an electrical engineer, and then

we moved to Sunnyvale, Silicon Valley

before it was Silicon Valley. This is

before the invention of Silicon.

>> Oh, this was before.

>> Yes. Before there was this is when there

were still uh cherry orchards on El

Camino. And I was born there

about the time

So I was in sixth grade. He brought home

a programmable calculator which was as

big as not as big as this table, maybe

half the size of this table.

>> Probably weighed

>> 65 or 70 lb. Yeah. Yeah. It was

>> 65 lbs.

>> And it had uh it had Nixie tubes. Nixie

tube is this is before seven segment

LEDs cuz LEDs hadn't been invented. uh

you'd have a uh an incandescent light

bulb with 10 filaments in the shape of

the numbers. And my first program

was uh was a loop that would just count

up and down and up and down because the

filaments were set one in front of the

other. 0 1 2 3 4 5 6 7 8 9. So, I I just

uh wrote a program that would count up

and down cuz I loved watching this go

back and forth and back and forth and

back for hours. I could just was

>> mesmerizing. Oh,

>> absolutely. That was the first time I

had my hands on any real hardware.

Although I did find my dad would bring

home books and I was a kind of obsessive

spectrumy kind of kid. I would

obsessively read these books and I found

one of them lately in uh in during a

move, the Burroughs B6700

instruction set manual. And this was a

really interesting machine to imprint on

early because it has a hardware stack.

It wasn't register based, it was stack

based. How they did that with discrete

transistors, I will never know. But it's

just a really interesting architecture.

And that book I would just read the

pages over and over and I understood

nothing but I was just fascinated with

this mechanism. So when I got an actual

machine and I could play with it and

something that that resembled assembly

language and I could get it to do stuff,

I could have an idea in my head and if I

understood this mechanism, I could get

it to do the stuff in my head which

would spark the next idea.

That's what really hooked me is is that

that creative impulse coupled with

knowledge of the machine together I

could create things in the world that I

wanted to see and this was very early

'7s right Microsoft

72

maybe so Microsoft wasn't even founded

founded in 75

>> what was it like in terms of how common

or uncommon were these machines means

how much or little did you even think

that they would go anywhere or was it

just just a a fun thing that has just

been invented?

>> Probably the first wave

of miniaturaturization was the

programmable calculator.

>> Mhm.

>> So the one that your dad brought home.

>> So no, the like handheld calculators.

Okay. So, so, so the the big tabletop

calculators was was one thing, but then

there were these little calculators. I

remember my dad buying an HP35 for $400,

which is I don't have no idea how much

that would be today, but a lot of money

just for this little thing.

>> It'll probably $2,000 location.

>> Yeah. So you you had to keep the stack

in your head of what order do I want to

put the operands in and you know make

sure that I stack everything and then

you go plus+ and that would pop stuff

off the stack. And then the HP45 came

along and it would it had its own little

programming language in it and that was

just like okay this is really really

cool. And then microprocessors started

to come out and we had the Z80 and the

808 and the

6800 and my dad and I soldered together

our first 600 6800based

machine. Then we were programming in

assembly language.

Then out came basic then

>> this was mid70s.

>> Yeah. Yeah. So, so that was really I I

was spending a lot of time working on

that machine. Again, I wouldn't say I

understood it at a at an elite level,

but I was fascinated. I Everything I

could learn about it made me that much

more effective at that creative impulse,

imagination of a thing in the world,

execution. There's a thing in the world.

And that just has always felt great for

me. And then when it came to college,

you you chose University of Oregon,

right?

>> Well, University of Oregon kind of chose

me because no none of the other places I

applied accepted me.

>> No way.

>> Yep. And what did you study there? How

how did your college years go?

>> Well, the first year was computer

science. And

>> so they already had a computer science.

Yes. Yes. We had invented computer

science by then. The first year was CS.

and and I enjoyed it, but I I still

wasn't a great programmer, but classes I

breezed through. So, I was a little bit

bored. So, before the start of my

sophomore year, it was really hot and I

was walking through the music building

and there were some some flyers for uh

signing up for auditions. I thought,

"Oh, I play guitar. Let me see what I

can do." Next thing I knew, I was a

music student. So, [laughter]

>> wow.

>> So, I'd been playing I started playing

guitar when I was eight, kind of the end

of the folk boom. Mrs. Card at a summer

school class and uh uh there was a

guitar laying around at our house. And

so I I went and and again just obsessed.

She'd show us something and I'd go home

and I'd play it until my fingers bled

and come in the next day and and

everybody else was kind of where they

were before, but I would have mastered

some picking pattern, some strumming

pattern because I just played it for

three, four hours. So, I was very into

music and in high school I was in the

choir and which was the big deal. We

didn't have a lot of sports at our high

school, but we certainly had music. It

was kind of natural that I would study

music. At the end of a year of music, I

missed programming, so I went back to

programming. Then I went back to music

so I could do my senior recital. Then I

went back to programming for a master's

degree uh in another year and and uh

finished that. And so and as I say, I

just ended on the wrong year. Yeah.

Because I I I checked I think it was

eight years in total. uh that you spent

at Oregon at University of Oregon.

>> 5 years full-time and then I had a hard

time finishing my master's thesis.

>> Why did you have a hard time? What was

your master's thesis on?

>> It was

a novel query language. Not

surprisingly, I did not get along with

the authority figures,

which is a a theme of my career. Yeah.

Just had a hard time like checking off

all the boxes and getting getting the

whole thing finished. People said, "Oh,

you're gonna be sorry if you I was just

ready to quit." Just like, "Yeah, you

know, this is all hoop jumping and has

nothing to do with programming and I was

making a good living as a programmer by

then. So, oh, but you're going to regret

it if you don't get your degree. If you

don't finish, you're so close." And it's

never never helped me one bit as far as

I can tell. So, but you completed it.

>> I did complete it. It is important to

complete things that in that in that

process from vision of thing in the

world to careful activity to the thing

in the world there has to be some

finishing even if I'm uh as the Reverend

Jesse Jackson said uh I'm a tree shaker

not a jelly maker and that's definitely

me. Yes it's true true for your work as

well also for software. Well, I keep I

keep switching topics. That's uh that's

something that'll probably come up as we

go through the various things that I've

worked on.

>> What was your first job? It was while

you were still finishing your degree the

the last few years. You started to work

as a programmer, right?

>> Correct. So during that uh graduate

student year, a team from Tektronics

came down to give a presentation about

the programming environment work they

were doing. Tektronics was uh started

out as an electronic test equipment

company in Portland. Did well in their

little niche, but they they opened up an

indust uh industrial lab as lots of

companies at that point did to do basic

research and part of that basic research

was on uh programming environments. They

came and gave a presentation.

Uh, I asked them questions they couldn't

answer and so they invited me out to

dinner which led to an interview which

led to a job.

>> Tektronics was an interesting one

because this is where you met Ward

Kunigum, right?

>> Yeah. So, uh, Tektronics had invested

early in this crazy object-oriented

programming language called Small Talk

and was trying to make a commercial go

of it.

And I got there and the looked at the

the research that had been presented

down at Oregon and it kind of played

itself out. But this small talk thing,

wow, that's cool. So I dove right into

that. For those of us who have not

touched small talk, might have heard of

it. What made small talk so such a hit?

What pulled you in? What is the language

like? There's a beautiful paper called

the design principles behind small talk

by Dan Engles and the opening line is

small talk is computer support for the

creative spirit in everyone which had

two big

themes. One was a language of

programming, the small talk language,

and another was a language of

interaction, overlapping windows, mice

as pointing devices, panes,

scroll bars, those were all things that

uh were pioneered out of the user

interface. Those things are kind of

ordinary today. But Small Talk, the

language, was built out of a very small

number of primitives. There's really

only three primitives in the language.

Sending a message, assigning a variable,

and returning a value. And that's really

all that there is. And so, um, maybe,

uh, towards the end we can talk about my

current projects, one of which is to

build another a new Small Talk from

scratch, just because now that's in

within reach for anybody. But what what

I found beautiful was that the language

pushed its own mechanisms to the

absolute limit. So everything is an

object in small talk including numbers.

You don't call a function that adds two

integers. You send a message plus which

is received by an integer and takes

another object as a parameter. If that

other object happens to be another

integer, then you add them together.

This leads to interesting things like

there are no control structures defined.

So no if then if then else is not part

of the language. It's part of the

library because there's a you send the

message if true with a closure

to true and it evaluates the closure.

You send the message if true to false

with a closure and it does nothing. Just

returns null. Everything is built out of

the same kind of substrate. There

there's very few special cases in small

talk which

means that sometimes you have to get

clever to understand things like h how

does how do how do conditionals work but

also when the time comes for you to

build abstractions you you don't have a

bunch of special cases getting in your

way. It is a different way to think

especially looking at the modern

programming languages that have a you

know the language comes with so many

things built in whether even if we're

thinking of like later languages like

coughlin or swift or any of them they

they have things like control structures

and reserved words why would you reserve

words how rude the programming language

should give me as much vocabulary as

possible but I do notice that with small

talk the people who have used it just

get really really passionate about it

and love using it and I understand doing

my research that there was a time around

that time for a few years where it

started to become a lot more popular.

Can you tell me why it got more popular

and then what happened? It seems to have

kind of fizzled out. Yeah, longer story.

Some of which I was not privy to. Some

of which comes down to business

decisions. Objects were were hopping.

We'd been programming with the previous

generation of languages cobalt forransc

alascal

for a long time and we were used to kind

of the constraints that those provided

and along came these objects and objects

were going to change everything. People

were really, really excited, but you

know, objects were going to make

programmers so much more productive that

we wouldn't need nearly as many

programmers. And in fact,

>> really.

>> Yeah. And you know,

it's so much easier to program with

objects that ordinary people can write

their own programs. They don't have to.

>> I've heard this recently. [laughter]

>> Exactly. But seriously, like this was

what they were saying where like inside

of the industry, this was a thing. Use

objects or small talk and do more with

do more with less programmers, cheaper

the works.

>> Yeah. And and to a degree it was true.

We would people would come in. So

built a workstation, there weren't

workstations. Tecttronics built a

workstation and started to sell it with

Small Talk bundled in it. and technical

people but in different domains like

chemical engineers or structural

engineers or hydraulic engineers would

come in and show us the systems they

built with small talk and on the surface

they looked fantastic the solve the and

oh they were so happy so proud of their

baby. You look under the underneath

though at the code and it was just a

horrible unmaintainable mess. But the

fact that people could program the

programs that they wanted was a a

significant step forward as opposed to

I'm going to write a thousandpage

requirements document and then wait 8

years and not get what I want which was

the alternative that we were offering at

the at the time. So it's not the first

time that we're expanding because again

if we jump to today similar things are

happening. People in different domains

who could never dream of hiring a

developer are now building their

programs and the same thing is playing

out which is if you look under the hood

if you put your software engineering hat

on and look under the hood of that mess.

There's lots of corner cases that aren't

covered. It's impossible to to modify

and evolve. Yeah. But so far this story

with small talk and Tektronics selling

machines that come with small talk make

everyone more productive. Clearly it

pays for itself. That sounds great. But

then what happened? There were

alternatives that were easier to

understand. So for example, small talk

syntax is uh funky. It's this keyword

infix syntax.

Along comes C++ which was originally

called C with objects. And the syntax

looks familiar

even though it's the design philosophy

is entirely the opposite of small talk.

There's lots of mechanisms and they're

very complicated. But just the fact that

it was approachable that you could there

was a compiler because we were used to

having compilers in small talk.

There'd be some code you'd edit it and

now you're running with the new code.

There's no compile and link step. It's

of course it's just sitting right there.

And if you're in the middle of, you

know, you could be editing a some text

and say, "This doesn't work the way I

want and hit control C and you get a

debugger and go down the stack and you

find the code that's not doing what you

want and you fix it and you continue on

your way and then you're you're writing

again." That was that was that level of

this is intended to be a personal

computer. And part of that that sense of

ownership was that you could see

everything and you could change

everything. Now it turns out if you have

a hundred people working on the same

program, you need to put the brakes on.

Everybody can't be changing everything

in incompatible ways at the same time.

That just doesn't work. But in terms of

this is my computer and I feel power

because I understand it. I can have more

ideas

that I can then execute on to create

things in the world. It worked great for

that. Now while at Tektronics you work

with War Kunagum who would later become

the developer of the first ever wiki. Uh

he had a huge influence or he helped

create design patterns. He also helped

with extreme programming. Can you tell

me about what it was like working with

him and and how you and him started to

get into design patterns which back then

didn't exist right this was something

you you would invent later we needed to

give training classes on small talk and

Ward had written some small talk code we

knew each other there were probably 60

people 80 people in the labs so we knew

each other by side I had learned a bunch

about small talk working on my own

projects I was working on programming

language for prologue because logic

programming was also a big deal at that

time. So I implemented I think three

different virtual machines for prologue

including some nice animations showing

how prologue's unification mechanism

worked.

>> And I guess for for those who don't know

prologue is this declarative language is

a very different way of thinking. No no

no variables is I I think

>> no no it's got variables. No variables

is FP box. Oh, this FP sorry, but it

does have some some funky stuff. I I I

used it a long time ago.

>> It's fun.

>> Turns out to be difficult to write big

programs in, but it's it's it's a good

exercise because you there there aren't

control like do this thing, then do this

thing, then do this thing. It's it's

more like a theorem prover. So, I was

working on that. Ward had built this

example code for the small talk class

and he said I just want to run you

through this code. So I sat down next to

him and he showed me the code for

plumbing called plumbing and I suggested

some some improvements. We gave the

class together.

I met some people who would later become

lifelong friends in that class and then

we just kind of fell into

a rhythm of well, I wonder if we can

make Small Talk do this because the

universe of of what it meant for a

computer to support programming was just

exploding. We had the this high

resolution screen which nobody had ever

had before. we had this dynamic language

uh including our own implementation of

it so we could tweak it if we needed to

and we just didn't know what was even

possible. So

uh at first

and Ward was always a much better

programmer than I was in terms of

low-level technique. He also had a gift

for design at a higher level and a gift

as you see in the wiki of uh picking

powerful top level goals and then making

something that does that. But I was this

24 year old punk with attitude and he he

didn't let me touch the keyboard for a

while. I could watch him and then

eventually I was like h those

parentheses don't balance you need a

period here and I was actually being

useful to him even though and I was

absorbing watching a master programmer

at work but I wasn't really driving

stuff eventually though I started you

know understanding the low-level

patterns and then building up to the

next level and the next and then I would

say why is this called this and not that

pull out a thesaurus and look it up and

find just the right word for things and

then continue.

And eventually I started making

suggestions that he wouldn't understand

right away. And so I would take the

keyboard for a little while say

something like this. Oh, I get it. I get

it. And then he'd take the keyboard

back. Over the course of a few months,

we developed both a programming style

where the keyboard was going back and

forth where we were talking at multiple

levels. You know, we talk about here's

this code, why isn't it working? Is this

the thing we should be working on at

all? What programming

tools would we need for this to be easy?

What should the design be so this whole

thing should work well? Should we even

be doing this at all philosophically?

We would bounce between all those levels

in the in the active programming. And we

had a weekly cadence where Monday

morning we'd have a coffee and we talk

about of the list of things because we

would then out of those conversations

we'd come I wish we had a thing that did

a thing. We would talk about that and

then we'd say okay well let's go down

and see how far we can get. And over and

over, Tuesday, Wednesday, we would make

a bunch of progress on what we were

working on. Thursday, we'd be giving

demos and refining it. And Friday, we'd

write a tech report. So, there's this

whole string of tech reports that we

wrote over the course of maybe 6 or 12

months of really working together

intensely. Even if one of those weeks

failed, you know, we'd we'd have our

coffee Monday, Tuesday, Wednesday. ah,

this didn't work. We would know why it

didn't work and what it was that we

needed in order for that thing to be

easy in the future. And that goes into

the hopper for the next Monday's coffee.

So, we developed a wide range we of

programming tools and applications,

some foundational stuff. So, we had a uh

graphics editor called Hot Draw because

we we had this graphical interface and

everybody had been used to text

interfaces for so long, but now we had

high-speed graphics. Oh my goodness.

What can we do with this? So, we kept

making graphical interfaces, but it was

hard to make graphical interfaces.

>> Yeah. I I have a photo of of early draw.

>> Yes, absolutely. And and this reminds me

when I look at hot draw this, you know,

like these boxes and arrows, they do

remind me later of things like UML and a

bunch of just the not not the exact

ideas, but but visualizing and of course

later I think these days people don't

use UML, but you still you just go to

the whiteboard and you draw out boxes

and arrows and how they connect. Sounds

like so you did this back in in ' 87 or

something like that.

>> Correct. And because we had uh high

performance for the time graphics

primitives, the magic moment out of hot

draw was we drew a series of rectangles

kind of on top of each other. We

selected every other one. We clicked on

it and we started to move it back and

forth and you could and because we could

we could do maybe 10 hertz animation. It

was it was smooth and you could just see

half of the rectangles, you know, kind

of moving behind the other half and it

was just this is so hot. We were just

really excited about it.

>> Oh, that that's that's why that's why

you called it hot draw. That was the

name because that was the reaction to

being able to see this smooth animation.

And before that, writing that kind of

smooth animation

was a bespoke thing and took a lot of

work. And with this, you subclass figure

and now you have something that works in

this 2 and 1 halfd world and away you

go. Those figures though were meant to

represent something in the interface. It

wasn't just a rectangle. It was a

processor, it was a generator, or it was

a whatever. And then you click on it and

you get these handles on the figure

which each of which represents some way

to manipulate the state, not just of the

graphic thing, but again of there was

intended to be meaning behind it. So

you'd have a handle that would raise and

lower the temperature and another handle

that would change the pressure or

whatever whatever domain you were

working in. And then you had it was a

boxes and arrows uh model. So you'd have

connections between things and the

connections again were intended to be

semantic but would follow the figures

around. And actually the the words

figure handle drawing uh Ward came up

with those. Mine were something

pedestrian drawing object

drawing handle. I I I didn't have good

words for it. And this was where the

thesaurus

came in was

Ward would think about okay this is like

figures in a book. You know we had an

analogy there. there there was a

metaphor to what we were doing. But in

the computer world, you can you can have

figures and figures and figures.

>> And do I understand that you actually

had a physical thesaurus like a book?

>> Yeah. Yeah. An actual book with words in

it.

>> You would actually as a programmer reach

for this book with words and open up to

find better words all the time.

>> Was this just you doing it or did

programmers in general have like people

that you knew that they also have the

satarist? We were on the far end of the

obsessive scale for this. There were

other people certainly who were fighting

for the right words. But this just this

just reminds me of how programming is is

just more than just you know like

writing code. how you need the skills of

for example if you are well read you can

probably write more expressive programs

or if you're not well read having a

thesaurus of of course you could do it

online but I assume that by opening up

the book and looking through and reading

a lot of other you know words your

vocabulary was will start to grow there

therefore making you a better programmer

or someone who can write a lot more

understandable or maintainable part of

the goal of programs is to communicate

intent to other human beings and now to

models as well which which is a much

more open-ended problem. We understand a

lot more about how to communicate to

other human beings whether we apply that

understanding or not. We don't

understand at all how to communicate

effectively to models and people are

trying out all kinds of things which is

that's great. That's what you do.

>> Yeah. And and then later Ward went on

and he he got very much involved with

design patterns. I can all now see with

hot draw how you know the design

patterns in the gang of four later you

see boxes and arrows how I see some

resemblance on being able to visualize

objects on on a monitor. Yes, all of the

pieces were working together for us. Um

the patterns work I had become

interested in Christopher Alexander at

the University of Oregon. I couldn't

afford the timeless way of building. So

I read it standing up in the bookstore

uh over the course of several visits and

Ward had also been exposed to

Christopher Alexander and patterns.

Alexander wanted to build

wanted buildings with a certain spirit

to them. He talks about it in kind of

mystical terms, but that's okay.

And he hypothesized that if people made

their own decisions about the design of

buildings that this spirit would exist

in a way that didn't. When the the

architect would say, "Oh, well, you

know, tell me what you need in a

building and then I will program myself

to dream of your perfect space and then

I'll tell you I'll bring to you the

solution." The way he wanted to work was

to empower people to make decisions

within constraints. Like me designing a

house, I'm going to have roofs that fall

down and walls that don't match and

whatever cuz I don't know. So, I need

constraints, but I know more about my

life. So, I should be the one making the

decisions about, oh, family family

dinners are really important. Oh, so so

this is in the domain of architecture

like like strictly physical buildings.

>> Yes.

>> Wow. So you got a lot of inspiration

from this domain even though software is

very much a virtual it's in our head

right and or in the computer right. So

the patterns are the constraints.

You can't just make any decision. You

make particular decisions at per

particular times based on the

constraints that come from the decisions

you've already made and that creates

constraints for the next decisions that

you make. We wanted that for the users

of programs taking this small talk

personal computer ethos to the next

level. And so

we were consulting on a project that

wasn't going well at Tektronics. some

programmers were writing software for

some test engineers and it just it

wasn't going well. So Ward came up with

the initial set of patterns that we

would use for designing a user

interface. Again, graphical interfaces

were brand new. Nobody knew what to do.

There were all kinds of crazy things

coming out in in music school. We

learned about the the evolution of

musical notation. And when musical

notation first came out, before then it

was entirely an oral tradition, then

musical notation was invented. And some

of the most complicated music ever

written was written in like 1200 or

1300, right after musical notation had

been invented because nobody knew what

the limits were. And then then they they

settled down. It's like, okay, a

four-part motet, that's fine. and we

don't need to have 60 different

instruments doing 60 different things

all at the same time just cuz we can.

Well, it was the same kind of way with

these user interfaces. Nobody knew how

to organize them. So we gave this

initial set of patterns that Ward had

come up with and we'd talked about

Christopher Alexander and patterns and I

ran across a copy of notes on the

synthesis of form at Powell's books in

Portland and devoured that which is kind

of the theoretical underpinning of

patterns. We handed the patterns to the

test engineers and said okay we're just

going to start over. use these patterns

to break your process down into windows

with pains. And we were careful to only

allow them to do things that we knew

that we could implement. So they

couldn't come up with anything. The

pains had to be lists or text or

waveforms.

The waveforms were special, but that's

okay. We could do that. Each task that

you had to do in this testing process

would have its own window and so so

there was you know a four or five

different patterns and they came up with

an interface that was eminently

implementable

and they felt like they owned it and

then the small talk programmers would

look at that and go okay well how do I

implement this how do I implement that

so that was our first foray into

patterns People get really fussed about

this transfer of responsibility.

They want to think I I am the designer

of interfaces and I worked hard at this

and I want to ask you a bunch of

questions and then I want to cogitate on

that and then I'm going to bring you the

solution and then you'll thank me and

pat me on the head. Of course, that

doesn't happen. Your understanding of

somebody else's problem is bounded

because you're not in the middle of it.

You don't have the same skin in the

game. If you're not semiconductor test

engineer, you don't have as much skin in

the game as somebody who is because

they're going to have to be using this

interface for a long time after you're

gone.

>> Yeah. There's also this concept of the

flyby architect on teams who, you know,

this very senior person has built a lot

of stuff and the team is struggling.

They call them and they call him or her

in. This person comes,

does some suggestions and kind of flies

off.

>> This is a seagull.

>> The seagull. The seagull. Because it

should

>> You fly in, you make a bunch of noise,

you crap all over everything, and then

you fly out. Yeah.

>> Yeah. And you drop skin in the game.

Yeah. And it's interesting because we've

anyone who's worked in in teams of a

certain size or or certain tenure, you

see it happen. And it doesn't really

matter how highly skilled that person

is. There might be a few exceptions, but

generally if you don't have skin in the

game, you just make different decisions.

And then after Tektronics, you worked at

Apple. I only realized this about you.

What how did you get into Apple? This

was in 1987. It's a very exciting time

from from my research. How did you get

in there? What did you do there? So,

Small Talk was going up like a rocket at

that time. Xerox had developed Small

Talk. It handed it to four I think

companies to see can you also implement

it or is this something special. So HP,

Apple, Tektronics and blanking on the

fourth one. HP really didn't do anything

with it but Apple and Tektronics ran

with it. So Apple had its own

implementation of Small Talk and they

wanted to not commercialize it in the

sense of selling it, but commercialize

it in the sense of having something that

this was right after the Mac had come

out, something that you could use on a

Mac. And so I I knew about that project.

It was getting too big for my britches

at Tektronics. I I learned a lot. You

know, there's a there's a thing there's

this kind of compression that happens

when you're growing faster than the

organization can recognize that you're

growing, but also you're not growing as

fast as you think you're growing. And

eventually that gap between how people

see you and how you see yourself and

then somewhere in between is how you

really are. Those if those gaps get too

wide, you just have to move. So, I was

ready to move on. So, I contacted Apple

and I I worked for about a year on the

Small Talk project, which ended up going

nowhere cuz it really didn't make sense.

Small Talk could work in quite a small

memory footprint, but the the only

developer tools Apple really needed was

a C compiler, Pascal compiler,

>> because that that's what they built

their software on mostly C. That's what

they built their software on. That's

what everybody else did. There there was

a thriving third market uh for other

developer tools. But the small talk

wasn't going to do really do anything

for anybody. Maybe school kids or

something, but it wasn't it wasn't

driving Apple sales. People who bought

Apple computers typically didn't want to

do small talk. Right.

>> Correct.

>> Correct. So So we talked about the

decline of small talk. I'm sensing

around this time it's if if you know

like as personal computers started

spreading it's it seems like it just

remained the niche right no it was quite

strong at that time it was growing fast

um lots of people like relative to the

previous year were using it a company

had spun out of Xerox called Park Place

uh which was selling small

as a big ticket item for developers and

this is before there was open-source out

there. So the idea that you could set

you could charge money for a language

implementation was a lots of people were

doing that kind of thing and this was

running out of that same kind of

playbook.

>> Okay. So it was still doing it. It would

just didn't make sense for Apple's

customer base.

>> Correct.

>> And and their

hardware.

>> Yeah. Also though at the same time a

bunch of the ex Xerox people had come to

Apple. So my friend Larry Tesler was

there and by friend I mean bitter enemy

who I respected a lot. Sometimes you

know you there are people who just

raised the hair on the back of your neck

and Larry Tesler was one of those to me

and I don't know if even the feeling was

reciprocated. He passed a few years ago,

but so I never got a chance to talk to

him, but I talked to him, you know, we

we would check in afterwards. Anyway, he

was the head of the advanced technology

group at Apple at that time. Alan K had

moved to Apple and was working on a

programming language for kids, another

programming language for kids called

Playground.

Dan Dan Engles was there. So, a lot of

the Xerox folks were were at Apple and I

heard about Alen K's project and thought

that was a dream of mine. Bite magazine

had an article on small talk. I read

about the development of Small Talk. The

project started in like 71 and it was

1980 before they released anything at

all publicly. And just imagining working

in that environment just seemed like

heaven to me. So, I moved to

the Alan K's playground project. Now, I

was horribly ineffective.

Uh, ended up getting fired from that

job.

>> No way.

>> Yeah. Oh, sure.

>> As as a programmer, you being

inefficient. What happened?

>> I wanted to do my own thing. And this

was still, you know, I'm still in this

punk

mode where I'd listen to somebody else's

ideas and I go, "Nah, I don't think so.

I have a better idea." And if you're

working by yourself, that's okay. But if

you're working in a team, that's not

okay. So, uh, uh, the it came to a head.

I was the program chair for the oops

conference, which we probably should

have mentioned earlier. Um there was

this conference and it was the hottest

conference and everybody who was ever

anybody was there and it was growing

fast and I was involved in it kind of

stumbled into it but I was in ' 89 I was

the program chair for oops right for

oopsla and I spent a month just reading

papers while uh ignoring my duties to

the playground project and that was kind

of the final straw. okay, you're you're

not helping us, so you you need to move

on. And then the conference happened and

my second child was busy not being born.

So I didn't even get to attend the

conference, but I had heard about the

playground project. So I moved to the

the playground project and and did a

little bit to help build this

programming language for kids. That was

the next thing beyond object-oriented

programming. You would you would call it

today you'd call it reactive

programming. So you didn't you couldn't

send a message. You could only

raise some condition that some other

object would would be waiting on. So

it's like pub sub but that was the only

control mechanism. And then I wanted to

ask you about this this was around this

time CRC cards. What are CRC cards? I

know they stand for class responsibility

collaborator cards but what were they

and how did you come up with them? You

have this these imperative programs and

you have a flowchart which represents

accurately if kind of verbosely the

control flow in an imperative program.

Now we have these objects and you send

messages which are polymorphic. So you

don't know exactly what code's going to

be invoked when you send a message. And

people were like, well, how do you even

visualize, internalize?

For me, I'm um I have kinesesthetic

synesthesia. So, I can feel

in my body if I'm looking at some code,

I can feel in my body. It wants to go

this way. It's

Yeah. which is, you know, I've I don't

know if I've met anybody else who

describes their experience of

programming in the same kind of way, but

but there we go. How do you get a sense

of however you internalize this of

what's going on in this program where

you you can't just say we execute this

line and then we execute that line

because as soon as we send a message, we

don't know what's going to happen. So

Ward came up with the idea

to write

down on cards, index cards, here's

what's going on. Because we would we

would talk this way all the time. So you

know, we've got a we have a rectangle

and it asks the renderer to do the thing

and then that goes into the pipeline

which dah.

So we would talk with our hands a lot.

So he said, "Well, why don't we write

these things down on cards?" So

a a big challenge in object-oriented

programming is dividing the

responsibilities because you're moving

the computation

to where the data is. Saying, "Well,

this object does this and that object

does that is a really critical decision

because you want to you want the

computation near to the data so that

there's less coupling between them."

which is a lesson that I I think uh kind

of got lost in the noise. That's the

fundamental design move in ob in

designing object-oriented programs and I

I think I stand behind that. So so have

have the data be close to where it's

used where the computation will happen

>> uh backwards

>> backwards

>> have have the computation move to where

the data already lives

>> have the computation move to where the

data is. So like if you have a rich

object with the lots of data inside of

it for example, you want the

computations to move there. So you want

the like objects to invoke and just just

get the data and do whatever computation

they need to.

>> If I'm going to operate on stuff that's

on the inside of a rectangle like area.

>> Yeah. Do I have height time width

scattered all over the universe or do I

have an area inside the rectangle that

does height and width at the limit? Now

I don't care that the rectangle has

height and width

that's hidden from the rest of the

world. Like I can I can represent the

rang rectangle with two corners

>> or I can represent the rectangle as a

top left a height and a width. Mhm.

>> To the rest of the world, it doesn't

matter as long as they both respond to

area. So now I can come up with another

representation and another

representation and the rest of the world

doesn't have to care if I've moved the

computation where the data lives.

>> Yes. And that means you can have looser

coupling.

>> Correct. Understood. It's a good lesson.

>> Yeah. Yeah. Yeah.

>> And and even today cuz everything that

we do is under the hood. Almost

everything we do is object. A lot of it

is object-oriented. And I don't think we

think about these.

>> Yeah, I see a lot of criticism of

programs written in object-oriented

languages that aren't criticisms of

object-oriented programming or design.

So after Apple, you moved to a company

called Maspar.

And the thing that I notice here is unit

testing. This was the place where, as I

understand, you came up with something

called SUnit. While I was at Tektronics,

uh, I got interested in testing. At that

point, testing was a sociological

divide. If you got A's and B's in

computer science school, you got to

program. And if you got C's, you had to

be a tester. So, it really was like a

status. I'm not going to test. I'm I'm

one of these guys, not one of those. But

I got interested in how would you

automatically test programs? How would

you get a sense of confidence in what

you were doing? So, I tend to be an

anxious person and the more complicated

my programs were, the more I had to be

anxious about. The more experience I had

with what kind of bugs could possibly

exist, the more anxious I got. And I

thought there was just some way to kind

of quell this without pills. That would

be great. I tried out a bunch of

different approaches to writing

automated tests. At that point in

addition to this this uh status divide

there was a tool divide. You had testing

tools which would have their own kind of

language and some way to connect with

the program that was under test. So I

tried this and that and the other thing.

It was actually after Maspar that uh I

think is all ancient history. So we'd

have to go you know dig through the

archaeological layers. I started

consulting and I was going to tell a

client that they should write tests. I

was going to fly out to Chicago the next

day, but I didn't have any way for them

to write tests. So, out of these five or

six experiments that I'd done, I

synthesized

test case, test suite, and test result.

That was the it was like three classes

and 12 methods. But it was a framework

where you could write tests that would

execute isolated from each other

fully automatic and give you a rollup of

the results of it.

>> So this was pretty much a unit testing

framework for small talk.

>> It was written in yeah the first version

was written in small talk. So, Maspar

was a Silicon Valley startup

venturefunded intended to build an

entire new architecture which was uh

SIMDI single instruction multiple data.

So, we would have a Taurus of process

processing elements

uh up to 16,000.

So, you have 16,000 and they're

connected in a toridal grid. So you

could talk to the the processing

elements in your left, right, up, down,

and diagonally. And it looks very much

like the Nvidia architecture now, but

this was way back when, and it was just

too early. So three years of that

building programming environments for

high performance computing. So the

intention was to get the kind of

performance you'd get out of a cray at

that time um

but for a tenth the cost and they needed

a programming environment. So we built a

programming environment in Small Talk

that did some really cool stuff. You

could you could single step a forran

program

and build a performance profile at the

same time.

>> No way. So you built a runtime that

allowed you to do in in small talk to

interpret for example program programs

and run them.

>> No the we had a a standard compiler an

optimizing compiler but because we had

we controlled the operating system we

could build really low-level probes to

collect performance profiling data. So

we could get line level profiles for

these four trend programs running on

16,000 processors and great gobs of

data.

>> That's awesome. Like when you're going

from not just like you're going to lower

level, you know, like building

infrastructure that runs programs, but

then I want to go back to to SUnit. So

the concept of of SUnit, the the these

concept you put together a test case.

What was it? the test case,

>> test suite and test result.

>> This really became sticky because then

there was JUnit which you later created

with with Eric Gama and there's a whole

suite uh nunit for uh I think that was

fornet xunit.net

all of them took over some of these

ideas and a lot of modern unit testing

frameworks are built on some of these

ideas. Why do you think it was so sticky

and why do you think it wasn't created

beforehand? So beforehand

because of this social divide between

programmers and testers. There was a lot

of

incentive for the testers to have their

own language. This is my tool. I know

how to run it. I'm going to run it. And

it was very adversarial at that time too

and kind of patronizing like you're a

programmer. you can't be trusted to

test, you know, you'll just say it works

fine. I'm going to be the adult

supervision,

you know, and sometime and sometimes the

programmers really did act that way. So

I, you know, hard to hard to argue with,

but I think that encouraged this idea

that a testing tool is its own its own

world. the inspired decision to use the

same language

to test as you're testing. It was a

natural decision because I was in small

talk and you should be able to represent

anything in small talk. So, you know,

and I was just used to how do I

represent this as objects. So, sounds

like small talk as a language has been

early to a lot of things. I sense a lot

of innovation coming from small talk

because it was one of the first

languages that did have objects but it

was a very simple language. So you

needed to build a lot of things which

then led to representing a lot of things

to talking about them design patterns

and now also you know being able to

write your test environment if if you or

being forced to do so if if you wanted

to do it. Well there was an ethos that

went along with small talk. So if you

didn't like the tools, if you're running

the debugger and the debugger doesn't

have some feature that you really need

right now, you just hop on the stack,

implement the feature that you want, and

then get back to whatever it was you

were doing. That was just a natural

thing because there was never this huge

gap. You know, imagine today, uh, I'm

I'm using a C compiler and I realize,

oh, I wish C had this new feature. We're

embarking on a multi-year project to go

and like the huge barrier to entry to go

to the next level. And in small talk by

design, for example, you have pop-up

menus and they you can see all of the

options right there. That's a deliberate

pedagogical choice. It says, "Okay,

well, you know about cut and paste, but

you don't know the other things that you

can do right here." So the menu doesn't

just give you cut and paste. It gives

you all the things that you can do as a

way to encourage you to learn about them

because eventually you're going to I see

this format item here and I well what

does that do? So that was very much part

of the small talk ethos that this system

would teach you as you kept using it. So

yeah it was very natural to build the

testing tool in the language. And of

course you have to kind of bastardize

the language a bit here. Here I've got

this this class for some test case and I

have a method which is one of the test

cases and it starts with t is kind of

magic you know uh this is getting

squidgy and then when you execute it you

create one of these objects you send it

setup because you don't you know may

have to build some stuff and then you

send it the test t something or other

and it executes that one thing and then

you Then assuming well then regardless

you run the tear down from that. So it's

not it looks like the the syntax is the

same as the language.

The the representation of the tests

you kind of borrow from the

representation of just any kind of code

and then you interpret it yourself. So

it's it it it it it's in the language

but it's not really in the language at

the same time. But people don't think

about that. They just think I subclass

this I give a method with the annotation

of test or with starts with tst and then

it just starts working and that's fine.

I want to jump to a few years later from

to 1996 you started to work on a project

at Chrysler and this is where you met

Martin Fowler. What was this project?

I'd actually met Martin Fowler a little

bit before that. So as early as the

first oops conferences, the question of

how do we manage projects with objects

differently than we manage projects with

the previous generation of tools. The

previous generation of tools definitely

gave you a many fewer options for

change. You'd still have to change code,

but it was just a lot harder compared to

working with object-oriented programs.

So what is the methodology? We had we

had the structured analysis, structured

design. What is the methodology for um

for objects and how should it be

different? That was the million-dollar

question at the original 86 oops law. By

the time 9495

rolled around, we were starting to get a

clue what that would look like. There

were I think uh the rational and unified

process or the the things that would go

into the rational unified process

already existed by that time which was

>> Brady Buch was involved in that.

>> Brady BC Evar uh James Rumba Ivar

Yakabson. So people were coming up with

some kinds of answers. Ward had come up

with his own

uh answer called episodes written into

as a pattern language because we were

like you know I don't have a big bag of

tricks I have to keep using them over

over again and the same is true turns

out of of everybody. So you can find

that episodes

on uh Ward's C2 site. It's really

interesting to compare that because I I

borrowed heavily from that. I borrowed

from everything else that I had seen and

experienced. But at that point, I'd been

when did I leave Masspar? 92. So I had

been an independent consultant for four

years at that point. And there were a

couple of workshops

uh held in Snowbird. I don't know why we

picked Snowbird, but somebody else did

uh about this methodology question.

Um, and I met Martin at the first one of

those that I attended. And his

introduction was, it's just the classic

Martin introduction. He said, "I am the

only person here I've never heard of."

And he was already doing some some great

work on uh analysis patterns

uh at the time, which I knew about. So,

I was excited to to meet him. Get to

this Chrysler project. The project's

important for Y2K, but it's not clear

that it's going to be finished in time.

Martin was already there as a

consultant.

Uh I had met Ron Jeff doing small talky

stuff. I don't remember exactly how we

met, but long story short, I came in as

I know lead consultant or something

restarting that project in a very

different development style. And for

that style,

I took everything that I knew that was

useful and cranked it up to 11 and

discarded all the stuff that I couldn't

prove we needed.

So that was the value system behind this

new style of development. Uh Martin and

I would visit there periodically. Ron

was there full-time. I was originally

brought in as a performance consultant

because I knew a lot about small talk

performance and they were using a

database called gemstone which it was

small talk objects small talk semantics

but coupled with persistence

transactions indexes all that database

good stuff but it wasn't going fast

enough so I said well where's the test

case that makes sure that I don't break

something if I make some changes and I

said well actually it's not computing

the right answers yet. And I said,

"Well, then I can make it go really

fast." And they didn't like that answer

very much. Anyway,

most change I've ever seen over the

course of one week. At the end of which,

everybody was exhausted. They've been

working very long hours. I said, "Send

everybody away for 2 weeks. Tell them to

get some rest. We'll come back. We'll

throw away all the code that we've

written so far, and we'll restart." And

we restarted on this 3-w weekek cadence.

Every three weeks we would have more

test cases specified by Marie, the

payroll expert would be working and then

we'd start another 3-we segment and

another and another.

No, it turns out those 11s that we

turned everything to, there were several

notches beyond that, but it was just

that was the most intensely we could

imagine replanning, integration,

deployment, refactoring,

and so on. The ideas that went into that

was this synthesis of all these

experiences that I'd had. And then so

this is from from Ward when the two of

you started to pair and pass the

keyboard and and decide on all the

different things that you're going to do

your experience with tests as as a

concept of that it doesn't needs to be

the testing team that does it themselves

but you can do it yourself in your own

language which was just new new and and

so all of these ideas just all came

together.

>> Yeah.

>> And then when did you give it a name? It

started going well. At first I was like

I was excited. I was scared. I was

excited. Then it started going really

well.

>> So like the project started to go

visibly well.

>> Yeah. Yeah. After my like six weeks and

then I was happy to be telling my

friends about it. This new style of

working that we're doing here at

Chrysler. This new style of working

we're doing here at Chrysler. This new

style. They got kind of old to say that

over and over again. So now I'm back

with the C thesaurus trying to figure

out what are the words

>> called us.

>> I thought we were really on to something

that was going to be big. So I wanted to

protect it. Apologies to Grady who's a

good friend now. But um I didn't want

Grady BCH to ever say that he was doing

this thing. So, I had to pick I had to

pick a moniker that was unattractive

enough that somebody would try and steal

it. And this is about the point at which

uh

>> you're you're now this punk again.

>> Yeah. Well, yeah. I still am, but

[laughter]

I'm just I'm just an older punk now.

Yeah. Yeah. But but a little bit of

thumb the nose at the establishment.

Extreme sports were there. I kind of

like the analogy with extreme sports

because you don't just hop on a

snowboard at the top of some avalanche

and the first time. No, you have to be

supremely prepared.

You have to have done all of your

research and then if you have these

outstanding skills, then you accomplish

things.

>> Yeah. And training and all that,

>> right? that seem impossible and are

impossible if you haven't done all the

prep. So it's accurate, it's edgy, it's

the that word extreme and hence extreme

programming was was born.

>> That's so that's the extreme part.

Extreme we had I knew that a bunch of

people wouldn't like it but that's okay.

I started out calling it development

which I still kind of like because

there's more to delivering value with

software than programming

but the methodologies extent at that

time treated programming as this

clerical task.

We'll we'll we'll draw these diagrams

and these diagrams and build this thing

and the 14 ways to visualize this and

then then there's some programming and

then we'll draw some more diagrams and I

thought programming sitting fingers on

keyboard staring at code that's that's

where I do my learning

because that's where you can no longer

fool yourself that you actually

understand either you compute the

correct value or you don't compute the

correct value. So I wanted to elevate

that moment of reality meets program

and that's where the programming comes

from. Now from very early days I also

called it XP

as uh a way of separating from the

downsides of both of those words extreme

and programming. So we can just call it

XP and it's it's more of a generic

thing. Not long after that, Microsoft

releases Windows XP and there's an

alternate universe in which I sued them

and succeeded. And there's another al

alternate universe in which I sued them

and failed and bankrupted myself and my

children all starved to death. So,

>> Right. Right. Cuz this was right around

the year late '9s and XP came out. Yes.

Soon after, I think 2000 or 2001,

something like that. When did XP extreme

programming recall start to become big?

Was it as you gave it a name and you

started telling people or then there was

your book which came out in the year

2000? I remember the first talk about XP

I gave I had some flyers to hand out. So

I think it was at an oopsum on a panel

or something like that. I I talked some

about XP and afterwards

people were

give me a copy. No, no. Uh uh uh uh uh

uh uh. The reaction to it was just

tugging on my shirt wanting a piece of

this thing.

And I think the XP had exquisite timing

in that the dot the upside, not the

bomb, but the the upside of it was just

starting to hit. They looked at other

methodologies. It would say, you know,

very carefully prepare, do this analysis

document, do this design document, then

a bunch of coding, then a bunch of

testing.

They could tell that's never going to

work in a world that's changing as fast

as the internet wave starting to crest,

starting to come into, you know, the

this super hyper growth. On the other

hand, we know that this cowboy style of

just, you know, you have the Jolt Cola,

rest in peace, Jolt Cola, cowboy, you

have a bunch of programmers, they do

incomprehensible stuff, they don't talk

to anybody, you just slide pizza under

the door, and then you get the code out.

That's not going to work either. Here's

this thing that looks like it's kind of

in between the two. There's discipline

to it. There's iteration to it. There's

transparency to it. You have ways of

steering what goes on. You have ways of

tuning the process. You have all these

tests to make sure that stuff actually

works. You have frequent alignment

between people, whether it's business

people and technology people or

technology people with each other. Okay,

I can see how this could work. And so

they could see the internet is exploding

and I can use XP to take advantage of

that opportunity in a way that I I can't

I don't there wasn't really another

alternative to it.

>> Basically XP was giving you a way to

move pretty fast and nimble but also

have a sense of stability not just going

wild. tests there. You had the

iterations, the planning, the learning.

And then when did TDD come along?

Because there was a book that you you

wrote that came out, I think two years

later, uh, test-driven development by

example. And how did it relate to XP?

>> So TDD was an earlier test development.

>> Test-driven development was an earlier

rediscovery for me. Remember, I was a

kid. I read all these books. I remember

one of the books my dad brought home and

I still haven't found a a copy of it.

Said, "Here's how you program." This was

back in the days of taped to tape. So,

you'd have an input tape, you know, like

time cards, and then you put it through

the payroll program, which would write

an output tape, which was like dollars

for checks, dollars for withholding,

etc., etc.

>> Yeah. So it was always and then

>> really back in the day

>> really back in the day and and you'd

have these long strings of this and it's

actually functional programming because

you can't change the input tape but

operating payroll or operating accounts

payable or operating inventory was a

process of I take these tapes I feed

them into this program I take the output

of that feed them into this program and

blah blah blah blah blah blah and then

you really manual like actually

>> physically pulling a tape off and moving

it over. Yeah. And it so it said here's

how you write one of these programs is

you take an input tape an actual input

tape that you need to process and you

manually type in the output tape you

expect that to generate. You say okay

well this number of hours uh should I I

should have a record in the output that

like this. So I see where we're going

with this. You're you're defining the

the output. You're

>> before you start on the program.

>> Yeah. So first you need to know what do

I expect? How can I validate it?

>> Correct. I had read that as a kid,

didn't understand diddly squat, but but

it's it's back in the back here

someplace. I wrote sunit for the first

started using it. Gave it to Hal

Hildebrand, one of the smartest

programmers. I knew I didn't figure he

would need it. He used it. He loved it.

So, I knew I was on to something with

with this this testing framework. And

then I [clears throat] was just kind of

farting around and remembered this

typing in the output tape first and

mapped that onto the

testing that I was doing with SUnit. I

went, well, if I followed that pattern,

I would write the test before I wrote

the code. And I can remember laughing

out loud because it was such a stupid

idea. Why would you

write a test that you know is going to

fail? you you don't even have the

classes defined yet. You don't have the

methods defined yet. It's just it's

going to fail a bunch of different ways

before it could possibly succeed. Cool.

Let's try it and see what happens. So, I

I used stack as my first example. So, I

have a stack new and I push something

and I pop it. I should get the same

thing back. Okay. And then I went to

program it and okay, well, that's easy

to satisfy that. What's the next one?

You know, you push two things and you

get them back in the right order. Okay.

And this and uh

dupe

pop top

is empty and finished. Where's the

anxiety?

>> Oh, just gone.

Oh, for the first time.

>> Wow. I can't imagine another test case

that wouldn't pass. So, I'm really I'm

finished and I feel great. I feel

finished and I am finished.

Wow. Go going from this is a stupid

idea. Let's let's try it. Absolutely.

No, I made a comment. Always try your

stupid ideas if you can do it cheaply

and reversibly. Jumping off a bridge is

not a reversible decision. Not talking

about that. I'm talking about stuff like

this where you're just like, "Here's a

stupid idea." 99 times out of a 100

it'll fail. But that one time you won't

have any competition cuz nobody else is

stupid enough to try this idea. Part of

this punk attitude, I don't care what

you think about this has enabled me to

just try lots and lots of stupid ideas.

And most of them you don't see, but

there had been a string of them which

worked out way better than they would

have expected to work out. Well, and

then a bunch of other people tried these

ideas as well. You know, like I think

TDD is a good example where there was a

time where shortly after you wrote the

book about it as well. Uh it was it was

a super popular book. I still remember I

think I had a copy as well back in the

the late uh two 2000s people were like

doing you know group exercises

developers were developing accordingly

over time it it probably dropped I would

say in the 2010s I saw fewer and few

people doing it uh and it almost went

out of style completely and now with uh

with agents the idea is back because

turns out it might take more time what

not but agent agents can do that but

it's a It's pretty useful for them to

test themselves.

>> It costs tokens in the short run, but it

can save them in the long run because

one of the classic genie mistakes is

stuff doesn't work.

So, how do you how do you pull in the

reins a little bit? And why did TDD go

out of fashion? I I think uh there's a

big part of it is I work on something

for a while and then I switch to

something else. That was true of

patterns. It was true of Junit. It's

true of TDD. It's true of XP. I just

move on to the next thing. So I moved on

to the next thing. TDD is out there. And

then there were people who used it as a

moral cudgel. Like you should be if

you're not using TDD, you're not

professional. And that's just such

People can write very good

software with a wide variety of

workflows. Now, there's advantages and

disadvantages to different workflows.