What similar changes have you seen that

could compare to some extent to AI in

the technology field?

>> It's the biggest I think in my career. I

think if we looked back at the history

of software development as a whole, the

comparable thing would be the shift from

assembly language to the very first

highle languages. The biggest part of it

is the shift from determinism to

non-determinism and suddenly you're

working in a non with an environment

that's non-deterministic which

completely changes.

>> What is your understanding and take on

vibe coding? I think it's good for

explorations. It's good for throwaways,

disposable stuff, but you don't want to

be using it for anything that's going to

have any long-term capability. When

you're using vibe coding, you're

actually removing a very important part

of something, which is the learning

loop. What are some either new workflows

or new software engineering approaches

that you've kind of observed? One area

that's really interesting is Martin

Fowler is a highly influential author

and software engineer [music] in domains

like agile, software architecture, and

refactoring. He is one of the authors of

the Agile Manifesto in 2001, the author

of the popular book Refactoring, [music]

and regularly publishes articles on

software engineering on his blog. In

today's episode, we discuss how AI is

changing software engineering, and

[music] some interesting and new

software engineering approaches LLMs

enable, why refracting as a practice

[music] will probably get more relevant

with AI coding tools, why design

patterns seem to have gone out of style

the last decade, what the impact of AI

is on agile practices, and [music] many

more. This podcast episode is presented

by Statsig, the unified platform for

flags, [music] analytics, experiments,

and more. Check out the show notes to

learn more about them and our other

season sponsor. If you enjoy the show,

please subscribe to the podcast on any

podcast platform and on YouTube. So,

Martin, welcome to the podcast.

>> Well, thank you very much for having me.

I didn't expect to be actually doing it

face to face with you. That was rather

nice.

>> It's all the better this way. Uh I

wanted to start with learning a little

bit on how you got into software

development which was what 40ish years

ago.

>> Yeah. It was yeah it would have been uh

late 70s early 80s. Yeah. I mean like so

many things it was kind of accidental

really. Um at school I was clearly no

good at writing because I got lousy

marks for anything to do with writing.

>> Really?

>> Yeah. Oh absolutely. Um, but I was quite

good at mathematics and that kind of

thing and physics. So, I kind of leaned

towards engineering stuff and I was

interested in electronics and things cuz

the other thing is I'm hopeless with my

hands. I can't do anything requires

strength or physical coordination.

So, all sorts of areas of engineering

and building things, you know, I've

tried looking after my car and, you

know, I couldn't get the the rusted nuts

off or anything. You know, it was

hopeless. So, but electronics is okay

because that's all very, you know, it's

more than in the brain than, you know,

you need to be able to handle a

soldering iron, but that was about as

much as I needed to do. And then

computers and it step easy. I don't even

need a soldering iron. So, I kind of

drifted into computers in that kind of

way. And uh that was my route into into

software development. Before I went to

university, I had a year um at working

with the UK at Atomic Energy Authority.

Wow. or ukulele as as we call it. Um and

I did some programming in forran 4 and

um it seemed like a good thing to be

able to do. And then when I finished my

degree, which was a mix of electronic

engineering, computer science, I looked

around and I thought, well, I could go

into traditional engineering jobs, which

weren't terribly well paid and weren't

terribly high status, or I could go into

computing where it looked like there was

a lot more opportunity. And so I just

drifted into computing. And and this was

before the internet took off. This was

>> what what what kind of jobs were there

back then that that you could get into?

What was and what was your first job?

>> Well, my first job was with a consulting

company Koopers and Librand or as I

refer to them, Cheetum and Lightum

and um we were doing advice on

information strategy in the particular

group I was with although that wasn't my

job. My job was I was one of the few

people who knew Unix because I'd done

Unix at college and so I looked after a

bunch of workstations that they needed

to do to run this weird software that

they were running to help them do their

strategy work and then I got interested

in the what they were doing with their

strategy work and kind of drifted into

that. I look at it back now and think,

god, that was a lot of snake oil

involved. But hey, it was my route into

the into the industry and it got me

early into the world of object-oriented

thinking and that was extremely useful

to get into objects in the mid80s

>> and and how how did you get into like

object-oriented was back then back we're

talking probably the mid80s that was a

very kind of radical thing

>> and you said you were working at a

consulting company which didn't seem

like the most cutting edge. So how does

a two plus two get together? How did you

get to do cutting edge stuff?

>> Because this little group was into

cutting edge stuff and they had run into

this guy who had some interesting ideas,

some some very good ideas as well as

some slightly crazy ideas. And he

packaged it up with the term object

orientation, which wasn't really the

case, but it was it kind of, you know,

it's part of a snake oil as it were. I

mean, that's a little bit cruel to call

it snake oil because he had some very

good ideas as well. Um but that kind of

led me into that direction and and of

course in time I've found out more about

what object orientation was really about

and uh that events led to my whole

career

>> in in the next 10 or 15 years. How did

you make your way and eventually end up

at Thought Works and and also you

started to write some some books, you

started to publish on the side. How did

you go go from like someone who was

brand new to the industry and kind of

wideeyed and just taking it all in,

learning things to starting to slowly

become someone who was teaching others?

>> Well, here again bundles of accidents,

right? So, while I was at that

consulting company, I met another guy

that they had brought in to help them

work with this kind of area, an American

guy um who became the really the biggest

mentor and influence upon my early

career. His name is Jim Odell and he had

been an early um adopter of information

engineering and had worked with in that

area and he was he saw the good parts of

uh these ideas that these these folks

were doing and he was an independent

consultant and a teacher and so he spent

a lot of his time doing work along those

lines. I left Coopers and Librand after

about a couple of years to actually join

this the crazy company which is called

PEK. Um and um I was with them for a

couple of years. It was a small company.

There was a grand total of four of us in

the UK office and that was the largest

office in the company.

>> Wow. [laughter]

>> Kind of thing. Um and um so I did I saw

a bit of you know having seen a big

company's um craziness. I then saw a

small company's craziness. did that for

a couple of years and then I was in a

position to go independent and I did um

helped greatly by Jim Odell who was um

who fed me a lot of work basically um

and also by some other work I got in the

U in the UK and that was great. I I

remember leaving PEK and thinking that's

it independence life for me. I'm never

going to work for a company again.

>> Famous last words.

>> Exactly. And um I carried on. I did well

as an independent consultant um

throughout the '9s and during that time

I wrote my first books. I moved to the

United States in 93

um and I was doing very very happily and

obviously got the rise of the internet,

lots of stuff going on in the late 90s.

It was a it was a good time and I ran

into this company called Fort Works and

they were just a client. I would just go

there and help them out. Yeah. The story

gets more. I had had met Kent Beck and

worked with Kent at Chrysler, the famous

C3 project, which is kind of the birth

project of extreme programming. So I'd

worked on that,

>> seen extreme programming, seen the agile

thing. So I'd got the object orientation

stuff, I got the agile stuff, and then I

came to Fort Works and uh they were in

tackling a big project, a big project

for them at the time. Still sizable,

about 100 people working on the project.

So, it's a sizable piece of work and it

it was clearly going to crash and burn.

Um, but I was able to help them um both

see what was going on and how to avoid

crashing and burning and they figured

out how to sort of recover from the from

the problem. Um, but then invited me to

join them and I thought, hey, you know,

join a company again maybe for a couple

of years. They're really nice people.

They're my favorite client. You know, I

I always thought of it as other clients

would say, "These are really good ideas,

but they're really hard to implement."

And while Thoughtworks would say, "These

are really good ideas. They're really

hard to implement, but we'll give it a

try." And they usually pulled it off.

And so I thought, "Hey, with a client

like that, I might as well join them for

a little while and and see what we can

do." That was 25 years ago.

>> Yeah. And then fast forward today, your

title has been for I think over a

decade, chief scientist.

>> Since I joined, that was my title at

join.

>> Since you joined. So I have to ask what

does a chief scientist at Thought Works

do?

>> Well, it's important to remember I'm

chief of nobody and I don't do any

science. [laughter]

The title was given because that title

was used a fair bit around that time for

some kind of public facing ideas kind of

person. If I remember correctly, Grady

Buch was chief scientist at Rational um

at the time

>> actually. True.

>> And um and there were other people who

had that title. So it was a it was a

high looting very pretentious title but

they felt it was necessary. It was weird

because one of the things of

Thoughtworks at that time was you could

choose your own job title. Anybody could

choose whatever job title they like. But

I didn't get to choose mine. I had to

take the chief scientist one. They

didn't like titles like flagpole or

battering ram or um [laughter]

or loudmouth which is the one I most

prefer. And one thing that Thought Works

does every six months and the latest one

just came out is the Thought Works Radar

>> and this latest radar, it just came out

I think a few days ago. It's the

>> Today it was launched I think

>> actually it was today. So by the time

this is in production it will have been

a few weeks but

>> uh it's actually really really fresh. So

I just looked at it and things that it

it lists. But I'll just list a few

things that I saw there and the adopting

which is the the ones that they

recommend using pre-commit hooks click

house for database analytics vlm this is

for learning LLM on on cloud or on

on-rem in a really efficient way for

trialing cloud code fast MCP which is an

MC framework for MCB servers and they're

they're also recommending a lot of

different things related for example to

AI and LMS to assess uh can you share a

little bit of how Thorkworks comes up

with this technology radar what's the

process And it it feels very very kind

of on the pulse every time like it feels

close to the pulse of the industry and

again I I talk with a lot of other

people. How do people at Thought Works

stay this close to what is happening in

the industry?

>> Okay. Yeah. Well, this will be a bit of

a story. Okay. So, it started just over

10 years or so ago. Its origin was one

of the things that we've really pushed

at footworks is to have technical

people, practitioners

really involved at v or various levels

of running the business and one of the

leaders of that um was our former CTO

Rebecca Parsons. So Rebecca became CTO

and she said I want an advisory board

who will keep me connected with what's

going on in projects. So she created

this technology advisory board and it

had a bunch of people whose job was to

brief her as to what was going on. We'd

meet you know two or three times a year.

She had me on the advisory board not so

much for that reason but because I was

very much sort of a public face of a

company. She wanted me present and

involved in that. And originally that

was just our brief. We would just get

together and we'd talk through this

stuff. And then one of these meetings um

Daryl Smith who was actually her TA at

the time technical assistant

um he um said we what we got all these

projects going on it would be good to

get some picture what kinds of

technologies we're using and how useful

they are and so as to better exchange

ideas because we like so many companies

we struggle to percolate good ideas

around enough I mean even then when

we're only just a few thousand it

struggled and we're 10,000 now so yeah

it's So we thought okay this is a nice

idea and he came up with this idea of

the radar metaphor and the rings of the

radar that we see today and we had

little meeting and we created the radar

and it's it's a habit if we do something

for internal purposes we try and just

make it public

>> and that's always been a strong part of

the works ethos it's part of why I'm

there of course is you know we just we

talk about everything that we do and we

share everything we we we give away our

secret source all the time so we did

that and people were very interested and

so we continued doing it now the process

has changed changed a bit over time. At

that original meeting, many of the

people that were in the room were

actually hands-on on projects, advising

clients all the time. Now, as we've

grown an order of magnitude, um it's

much harder to do that. And we've also

created more of a process where people

can submit blips, nominate them. A blip

is being a point on the radar, an entry

>> and um they will go to somebody that uh

either connected through geographically

or through the line of business or or

technology or whatever and say, "Hey, we

think this technology is interesting."

They'll brief us a little bit about it.

And then they brief the members of the

what's now called the Doppler group

because we make a radar. Yeah. I mean,

we can be a bit loose with our metaphors

at times. Um and they and then at the

meeting we'll decide which of these

blips to put on the radar and not and

obviously you get some crosspollination

because somebody will say oh yeah I

talked to somebody about this as well

and and so it's very much this bottomup

exercise

and that's how it's created now. So we

will have these we will do blip

gathering sessions about a month or two

before the radar meeting and gradually

shake them up and then in the meeting

itself we go through them one by one and

for me it's a bit weird because I'm so

detached from the day-to-day these days

that it's just this this lineup of

technologies and things I have no idea

what most of them are but interesting to

hear about and sometimes I latch on to

certain themes or something like that.

Um and that was an important part of

microservices about 10 years ago because

that came up in through that radar

process and uh we got together with

James Lewis and we ended up writing a

good bit further about that. Um but

that's really what happens is we go

through this process of spotting this

stuff.

>> Yeah. And and the the radar analogy I

know some companies also take the idea

which by the way Thoughtworks encourages

saying make your own radar take it in

your own company. You can I think they

even like have tools around it. I really

like how Thoughtworks never said like

this is the thing for the industry. They

said this is the thing for us. This is

what we see. This is what we recommend

our team our team members or or maybe

our our clients to consider or there's

also I like that there's a hold maybe

just be beware. We're we're not seeing

great results with this and and here's

the reasons for it. And yeah, I guess

the reason it feels fresh is uh probably

a lot of work that Thork works does is

it feels cutting edge because it's all

it's all about half of it or a third of

it feels that it is around the hottest

topic right now AI LMS and and all the

techniques that people are trying to see

if they work or are the things that we

are seeing that actually starts to work.

Yeah, I mean what I mean for works has

basically got several thousand

technologists all over the world doing

projects of various kinds to all sorts

of different organizations

and the radar is a mechanism that we've

discovered is a way of getting some of

that information out of their heads and

spreading it around both internally and

to the industry as a whole. And you're

right, I it is a recommended thing for

clients to do is to try and do their own

radars. It's slightly different when

it's a client radar thing because

sometimes there it can be more of a this

is what we think you should be doing

with a bit more of a forcefulness to it

than than we would give and also they

can be a bit more choosy in the sense of

they can say yeah we're just not

interested in doing certain technologies

while for us it's a case if our clients

are doing it then we we're going to find

out about it right we have to use it

>> of course the the radar is full with a

lot of AI and LM related things because

this is a huge change in in my

professional career, it it feels by far

the biggest technology innovation

changes coming in. Looking back on your

career, what similar changes have you

seen that could compare to some extent

to AI in the technology field? I

>> it's the biggest I think for my career.

I think if we looked back at the history

of software development as a whole, the

comparable thing would be the shift from

assembly language to the very first

highle languages which is before my time

right when we when first started coming

up with cobalt and forran and the like I

would imagine that would be a similar

level of shift.

>> So you started to work with forran and

you probably knew people who were still

doing assembly or at least knew knew

some of people from that generation.

>> There was a bit of assemble around when

I was working still from from what you

picked up around that time. uh what was

that shift like in terms of mindset or

or you know like because it it was a big

change right you really needed to know

the internals of the hardware and the

instructions and the the different

>> uh I I did very little assembly at

university but it it's been very useful

because I never want to do it again

[laughter]

>> very wise but but what did you pick up

in in terms of what needed to change and

and how it changed the industry just

moving from mostly assembly to mostly

higher level languages

>> well I mean for a start as you said

things were very specific to individual

chips. You had the instructions were

different on every chip. The you know as

well things like registers where you

access memory. You had these very

convoluted ways of doing even the

simplest thing because your only

instruction was for something like move

this value from a memory location to

this register. Um and you so you've

always got to be thinking in these very

very low-level forms and even the very

relatively poor um high level language

like forran at least I can write things

like conditional statements and loops

else is in my conditional statements in

forran 4 but I can at least go if and I

can get one statement I can't do a block

of statements I have to use go-tos but

you know it's better than what you can

do in assembly right and so there's a

definite shift of moving away from the

hardware to thinking in terms of

something a bit more abstract and I

think that is a very very big shift and

then of course once I'm using forran I

can be insulated to some degree away

from the hardware I'm running on. I'm

now am I running this on a main on a

mainframe? Am I running this on a mini

computer? I mean there's there's issues

because the language is always varied a

little bit from place to place but

you've got a degree of decoupling there.

Um that was really quite significant I

think. I mean I only did it on small uh

microprocessor like units because again

it was the electronic engineering part

right so we were fairly close to the

metal anyway for some of that um but um

you you definitely had that mind shift

and I I think it's with LLMs it's a

similar degree of mind shift although as

I've you know written about it I the

interesting thing is the shift is not so

much of an increase of a level of

abstraction although there is a bit of

that the biggest part of it is the shift

from determinism to non-determinism and

suddenly you're working in a non with an

environment that's non-deterministic

which completely changes you have to

think about it Martin just talked about

how AI is the most disruptive change

since the move from assembly to highle

languages that transition wasn't just

about changing the language we use they

required entirely new tool chains

similarly AI accelerated development

isn't just about shipping faster it's

about measuring whether what you ship

actually delivers value that's where

modern experimentation infrastructure

comes in and we're presenting sponsor

stats can help. With stats, instead of

stitching together point solutions, you

get feature flags, analytics, and

session replay all using the same user

assignments and event tracking. For

example, you ship a feature to 10% of

users. As you do, the other 90%

automatically become your control group

with the same event taxonomy. You can

immediately see conversion rate

differences between groups. drill down

to see where treatment users drop off in

your funnel. Then watch session

recordings of specific users who didn't

convert to understand what went wrong.

The alternative is running jobs between

different services to sync user segments

between your feature flag service and

your analytics warehouse and then

manually linking up data that might have

different user identification logic.

It's a lot of work and it can also go

wrong. Static has a generous free tier

to get started and pro pricricing for

teams starts at $150 per month. To learn

more and get a 30-day enterprise trial,

go to stats.com/pragmatic.

And now, let's get back to the shift in

abstraction with LLMs. Can we talk about

that shift in abstraction? Because one

very naive or naive way of looking at is

saying like, well, we we've had the

three levels, right? We have assembly

where you have commands for the

hardware. You need to be intimately

aware of the hardware. We have high

level programming languages starting

with C later Java later JavaScript and

uh where you don't need to be aware of

the hardware you're aware of the logic

and what you might say as well we have a

new abstraction is you have the English

language which will you know generate

this code you're saying you don't think

it's an abstraction jump why do you

think this is

>> I think there's a bit of an abstraction

jump I think the abstraction jump

difference is smaller than the

determinism nondeterminism jump and it's

it's worth remembering one of the key

things about highle languages anguages

which I didn't mention as I was talking

about earlier on is the ability to

create your own abstractions in that

language that is particularly important

as you get to things like object

orientation towards u more um expressive

functional languages like lisp which

didn't really have so much in I mean

forran and cobalt you could do that to

some extent um because because at least

with forran you can create subutines and

build abstractions out of that but

you've got so many more tools for

building abstractions when you've got

the the abilities of more modern

languages and that ability to build

abstractions is crucial.

>> So you can build a building block inside

of the language that sets you and of

course here we have like domain driven

development later enables these things

and so on.

>> Exactly. I mean an old lisp adage is

really what you want to do is to create

your own language in lisp and then solve

your problem using the language that

you've created. And I think that way of

thinking is a good way of thinking in

any programming language. you're both

solving the problem and creating a

language to to describe the kinds of

problems you're trying to solve in. And

if you can balance those two nicely,

that is what leads to very maintainable

and flexible code. So the building of

abstractions that's I think to me a key

element of high level languages and AI

helps us a little bit in that because we

can build abstractions a bit more easily

a bit more fluidly but we have this

problem and now we're talking about

non-deterministic implementations of

those abstractions which is an issue and

we've got to sort of learn a whole new

set of balancing tricks um to get around

that. My colleague Unmesh Jooshi has

been has written a couple of things um

that I really been really enjoying about

his thinking about how because he's

really pushing this using the LLM to

co-build an abstraction and then using

the abstraction to talk more effectively

to the LLM and that I'm finding really

really interesting way of thinking about

how he's working with that because he's

really pushing that direction. There's a

a thing I read in and I can't remember

the book off the top of my head. We'll

have to dig it out later that talked

about how apparently if you can describe

to an LLM a whole load of chess matches

and describe it just in plain English

and the LLM when you do that the LLM

can't really understand how to play

chess. But if you take those same chess

matches and describe the LLM to those

chess matches in chess notation then it

can. And I thought that was really

interesting that you that by obviously

you're shrinking down the the token size

because you've but you're also using a

rigorous a much more rigorous notation

to describe the problem. So maybe that's

an angle of how we use LLM. What we have

to come up is a rigorous way of speaking

and we can get more traction that way.

And of course that has great parallels

in with the ideas of domain driven

design in ubiquitous languages and also

some of the stuff that I was working on

a decade or so ago around domain

specific languages and language

workbenches. So I there's some

fascinating stuff around there that be

interesting to see how that plays out.

>> Yeah. Yeah. And I guess is this the

first time we're seeing a tool that is

so wide in software engineering that is

nondeterministic because we did have

neural nets for example in the past they

were not but they were more I feel the

application of those was a lot more kind

of niche and not not everywhere now

every single developer is I mean if

you're using code generation you are

using non-deterministic things of course

we're integrating them left and right

trying out where it works. Is is it fair

to say that this is probably the first

time we're facing this challenge of

deterministic computers which we know

very well. We know their their limits

and all those things and of course

there's some race conditions and some

exotic things but now we have

>> exactly problem to solve for

>> it's a whole new way of thinking. It's

got some interesting parallels to other

forms of engineering. Other forms of

engineering you think in terms of

tolerances and my wife's a structural

engineer right? She always thinks in

terms of what are the tolerances? How

much how much extra stuff do I have to

do beyond what the math tells me because

I need it for tolerances because yeah, I

mean I mostly know what the properties

of wood or concrete or steel are, but

I've got to, you know, go for the worst

case. We need probably some of that kind

of thinking ourselves. What are the

tolerances of the non-determinism that

we have to deal with and realizing that

we can't skate too close to the edge

because otherwise we're going to have

some bridges collapsing. I I suspect

we're going to do that particularly on

the security side. We're going to have

some noticeable crashes. I I fear um

because people have got skated way too

close to the edge in terms of the

non-determinism of the tools they're

using.

>> Oh, for sure. But before we go into

where we could crash, what are some

either new workflows or new software

engineuring approaches that you've kind

of observed or or aware of that that

sound kind of exciting that we we can

now now do with LMS or at least we can

try to give them a goal that would have

been impossible with, you know, our old

deterministic toolkit,

>> right? One area is one one that has got

lots of attention already is the being

able to knock up a prototype in a matter

of days. That's just way more than you

could have done previously. So, this is

the vibe coding thing. Um, but it's it's

more than just that because it's also an

ability to try explorations. Um, people

can go, hey, I not really quite sure

what to do with this, but I can spend a

couple of days exploring the idea much

much more rapidly than I could have

before. And so for throwaway

explorations for disposable little tools

and things of that kind um and including

stuff by people who aren't don't think

of themselves as software developers. I

think there's a whole area and you know

we can with good reason be very

suspicious of taking that too far

because there's a danger there. But we

also realize that as long as you treat

that within its right bounds, that's a

very valuable area and I think we'll

that's that's really good on a

completely opposite end of scale. U one

area that's really interesting is

helping to understand existing legacy

systems. So my colleagues have have put

a good bit of work in this um year or

two ago. And basically the idea is you

take the code itself um do the the

essentially the the semantic analysis on

on it. populate a graph database

essentially with that kind of

information and then use that graph

database as kind of in a ragl like style

and you can begin to interrogate and say

well what happens to this piece of data

which bits of code touch this data as it

flows through the program incredibly

effective and in fact if I remember

correctly we put actually understanding

of legacy systems into the adopt ring

because we said yeah you if you're if

you're doing any work with legacy

systems you should be using LLMs in some

way to help you understand

>> so so in this ring in the thought force

radar the the fewest things are in the

adopt adopt says we strongly suggest

that you look at this at least you know

thought works themselves look at it

there's only four items and one of them

is yes uh to to to use genai to

understand legacy code which to me tells

that you have seen great success which

is it's refreshing to hear by the way I

did not hear this as much and I guess it

helps at thought works I'm sure you have

to work with a lot of

>> well I mean it came from the fact that

some of the folks who had done some

really interesting work on on legacy

code stuff um happened to bump into and

look at this and say, "Hey, let's try

this out." And they found it to be very

effective and it also has been an

ongoing interest for many of us at

Thoughtworks because we have to do it

all the time. And how do you effectively

work with the the modernization of

legacy systems because every big company

that you know is older than a few years

has got this problem. Y

>> and they have it in spades

>> and then especially just simple things

people leave right as as as simple as

that and having uh Gen AI that can help

you make some progress is it's already

better than making no progress.

>> Exactly. So those are two areas that are

clearly um right away I would say those

are there's great success for using LLMs

and then there's the areas that we're

still figuring out. I mean, I'm

certainly seeing some interest more in

more and more interesting stuff as

people try to figure out how to work

with an LLM on a one-to-one basis to

build decent quality software. We're

seeing some definite signs of how you

you got to work with very thin, rapid

slices, small slices. You've got to

treat every slice as a PR from a rather

dodgy collaborator who's very productive

in the lines of code sense of

productivity. Um, but you know, you

can't trust a thing that they're they're

doing. So, you've got to review

everything very carefully when you play

with the genie like that. The genie is

GK Kent's term for it. Or or Dusty the

uh sort of the anthropomorphic donkey,

which is how Bita

I love her take.

>> Yeah. But using it well, you can

actually definitely get some speed up in

your process. It's not the kind of speed

up that the the the advocates are

talking about, but it is non-trivial.

It's certainly worth learning how to to

make some use of this and it's folks

like Burgita or Kent or um Steve Jagg

those are the those are the folks I

think who are pushing this. We're still

I think learning how to do this.

>> Everyone is learning it. Absolutely.

>> And it's still the question and most of

the experience we're gaining is building

in a green field environment. So that

leaves big questions in terms of a the

brownfield environment. Well, we know

that that LLMs can help us understand

legacy code. Can they help us modify

legacy code in a safe way? [screaming]

It's still a question. I mean, I was

just chatting with with James Lewis

because he's in town as well this

morning and he was commenting about he

was playing with cursor and he's been

was just building something like this

and he said, "Oh, I I wanted to change

the name of a class um in a not too big

program and he sets it off to do that."

and comes back an hour and a half later

and has used you know 10% of his monthly

allocation of tokens and all he's doing

is changing the name of a class

>> and and we actually in IDs we actually

have functionality which which I I still

remember when was cutting edge this was

probably 20 years ago when Visual Studio

it wasn't even Visual Studio it was Jet

Brains who came out with an extension

called ReSharper which helped refactor

code and people paid serious money this

was like $200 per year or something to

get this plugin and now you could right

click and say rename class and it went

and it built that the graph behind the

scenes somehow it went and changed you

could rename variables and again this

was a a huge deal in fact uh in Xcode

Apple's developer uh plat uh ID for a

while when swift came out you couldn't

do these refactors and it was you know

people were like so it's interesting how

some things are easy we've solved it and

LMS are not very very efficient at not

very good at it

>> y

>> yes and then I mean he did that just to

see what it was going to be like right

cuz he knows you can just I mean we've

had this for a long technology for a

long time so it's kind of amusing I mean

but it's also to the point that when

working with an existing system and

modifying an existing system we that's

still really up in the air and then

another area that's really up in the air

both green field and brownfield is what

happens when you've got a team of people

because most software has been built by

teams and will continue to be built with

teams because even if and I don't think

it will um AI makes us order of

magnitude more productive

We still need a team of 10 people to

build what a team of 100 people needed

to build and we will always want this

stuff. There's no sign of demand

dropping for software. So we will always

want teams and then the question is of

course how do we best operate with AI in

the team environment and we're still

trying to figure that one out as well.

So there's lots of questions we got some

an some answers some beginnings of

answers and it's just a fascinating time

to watch it all.

>> You mentioned vibe coding. what what is

your understanding and take on vibe

coding?

>> Well, when I use the term vibe coding, I

used I try to go back to the original

term which is basically you don't look

at the output code at all. Maybe, you

know, take a glance at it out of

curiosity, but you you really don't care

and maybe you don't look don't know what

you're doing because you don't you've

got no knowledge of programming. It's

just spitting out stuff for you. So,

that's my how I define vibe coding. Um,

and my my take on it is kind of as I've

indicated, I think it it's good for

explorations. It's good for throwaways,

disposable stuff. Um, but you don't want

to be using it for anything that's going

to have any long-term capability because

it's I mean, again, just this is a a

silly anecdote, but I was working um my

colleague Unesh, he's just wrote

something that we published yesterday.

And uh as part of doing this, we we

create this little pseudo graph of

capability over time kind of thing,

which is, you know, one of those silly

little pseudo graphs that helps

illustrate a point. And he asked the uh

at LLM to create this. He described the

curves he wanted and produ came up with

and put it up there. And I and he he

committed it to our repo. And I was

looking at it and thinking, yeah, that's

a good good enough graph. I want to

tweak it a little bit. I want to, you

know, the labels are a bit far away from

the lines they're labeling, so I'd like

to bring them closer. So I open up the

SVG of what the LLB has produced and oh

I mean it was astonishingly how

complicated and convoluted it was for

something that I had written the

previous one myself and I knew it was

you know a dozen lines of SVG and SVG is

not exactly a compact language right

because it's XML but this thing was

gobsmackingly um weird and I mean that's

the thing when you vibe code stuff it's

going to produce god knows what and

often it really is and you cannot then

tweak it a little bit.

>> You have to basically throw it away and

hope that you can generate whatever it

is you're trying to tweak. And the other

thing of course that's the difference

and this is the the heart of the article

that Unmesh wrote um that we published

yesterday is when you're using vibe

coding in this kind of way, you're

actually removing a very important part

of of something which is the learning

loop. If you're not looking at the

output, you're not learning. And the

thing is that so much of what we do is

we come up with ideas, we try them out

on the computer with this constant back

and forth between what the computer does

with what we're thinking. We're

constantly going through that learning

loop program approach and unash's point,

which I think is absolutely true, is you

cannot shortcut that process. And what

LLM do, they just kind of skim over all

of that and you're not learning. And

when you're not learning, that means

that when you produce something, you

don't know how to tweak it and modify it

and evolve it and grow it. All you can

do is nuke it from orbit and start

again. The other thing I've done

occasionally with vibe coding is oh vibe

coding as a consulting company, so many

problems to fix

for sure. But you are right on the

learning the the the learning side both

on on vibe coding and AI. One one thing

that I'm noticing on on myself is it is

so easy to you know give a prompt you

get a bunch of output and you know you

should be reviewing a lot of this code

either yourself or or in a code review

but what I'm seeing on myself is I'm at

some point I start to get a bit tired

and I just let it let let it go and this

is also what I'm hearing when talking

with software engineers is the ones who

are working at companies which are

adopting these tools which is pretty

much every company it's there's a lot

more code going out there, a lot more

code to review, and [clears throat]

they're asking, "How can I be vigorous

at code reviews when there's just more

and more of them than before?" Have you

seen approaches that help people, both

less experienced people and also more

experienced engineers, keep learning

with these tools? Just approaches that

seem promising.

>> Not a huge amount. Um I do I am very

much paying attention to what Unmesh um

is doing with this because his approach

very much is that notion of let's try

and build a language to talk to the LLM

with work with the LLM to produce a

language to communicate to the LLM more

precisely and carefully what it is that

we're looking for. And I do feel that is

a promising and very much a more

promising line attack. make sure do we

create our own specialized language for

working with whatever problem that we're

working on and I think that actually

brings another um we're talking about

things we know LLM are useful for

another thing and this is again

something unme has highlighted is

understanding an unfamiliar environment

again I was chatting with James he was

working with um he's he's working on a

Mac with C which is not a language he's

terribly familiar with using this game

engine called God.

>> Godo. Yeah.

>> Yeah. Go.

>> And he doesn't know anything about this,

right? But with the LLM, he can learn a

bit about it because he can try things

out. And if you take it with that

exploring sense, and I mean, I I mean, I

can't remember. I've I've certainly got

to the point where I'm typing in to the

L. Oh, well, how do I do so and so in R

that I've I've done 20 times, but I

still can't remember how to do it. And

you and exploring and Umash makes a

point again setting up initial

environments. you know, give me a

starting project, a sk a sample starting

skeleton project so I can just get

moving. Um, and so that kind of

exploratory stuff and helping in an

unfamiliar environment and just learning

your way around an unfamiliar set of

APIs and and coding ideas and the like.

it can be quite handy for I

>> I wonder if this is not all that new in

the sense that I remember you know one

of the last kind of big productivity

boosts in the industry uh about 10 or 15

years ago was Stack Overflow appearing.

So before Stack Overflow when you

Googled for questions you bumped into

this site called experts to change and

there was the question and you had to

pay money to see the answer or you had

to pay money to get an expert to answer

but usually there was nothing behind it

even if you paid and most of us I was a

college student I just didn't pay right

>> so you just couldn't find the answer and

you were all frustrated but then Stack

Overflow came along and suddenly you had

code snippets that you could copy and of

course what a lot of young people or

like less experienced developers even

like myself did is you just take the

code, put it in there and see if it

works. As you got to more experienced

engineers or developers, you started to

tell the junior engineers like you need

to understand that first like or even if

it works, you need to understand why it

works. You need to you should read the

code. And I I feel we've been there was

a few years where where we were going

back and forth of people mindlessly

copying pasting uh snippets. There were

problems with uh I think there was a

question about email validation and a

top voted answer was not entirely

correct. And turns out that a good part

of software and developers just use that

one.

>> I feel we kind of been around this

already.

>> Yeah, it's a similar kind of thing, but

>> maybe at a smaller scale.

>> Yeah. But even more boosted and on

steroids and with the question of, you

know, how how are things going to

populate in the future because who's

going to be writing Stack Overflow

answers anymore?

>> Yeah. So, I I I wonder if what we're

getting to is like you need to care

about the craft. you you need to

understand what the LLM's output is and

it's there to help you and if you're not

doing it I mean like you should but but

if you're not you'll eventually be no

better than someone just prompting it

mindlessly.

>> Exactly. Yeah. I mean it I mean I have

no problem with taking something from

the LLM and stick putting it in to see

if it works but then once you've done

that understand why it works as you say

and also look at it and say is this

really structured the way I'd like it to

be don't be afraid to refactor it don't

be afraid to put it in and then of

course the testing combo anything you

put in that works you need to have a

test for and and if you constantly are

doing that back and forth with the

testing process Martin Fowler was just

talking about the importance of testing

when working with LMS and in general

when building quality software. Speaking

of the quality software, I need to

mention our season sponsor, Linear. I

recently sat on one of Linear's internal

weekly meetings called Quality

Wednesdays, and I was completely blown

away. This was a 30-minute meeting that

happens weekly. In this session, the

team went through 17 different quality

improvements in half an hour. 17. It's a

fast and super efficient meeting. Boom,

boom, boom. Every developer shows a

quality improvement or performance fix

that they made that week. And it can be

anything from massive backend

performance wins that save thousands of

dollars to the tiniest UI polish that

most people wouldn't even notice. For

example, one fix was fixing the height

of the composer window very slightly

changing when you entered the new line.

Another one was fixing this one pixel

misalignment. Can you imagine caring

that much about about the details? After

doing this every single week for years,

their entire engineering team has

developed this incredible eye for

quality. They catch these issues before

they even ship. Now, one of their

engineers told me that since they

trained this muscle over time, they

start noticing patterns while building

stuff. So, fewer of these paper cuts

ship in the first place. This is why

Linear feels so different from other

issue tracking and project management

tools. Thousands of tiny improvements do

add up and you feel the difference. When

you use Linear, you're experiencing the

results of literally hundreds of these

quality Wednesday sessions. Thomas,

their CTO, recently wrote a piece about

this week ritual, and I'll link it in

the show notes below. If your team cares

about craftsmanship and building

products that people actually love

using, check out Linear at

linear.app/pragmatic.

Because honestly, after seeing how they

work up close, I understand why so many

of the best engineering teams are

switching. And now, let's get back to

the importance of testing when working

with LLMs. I mean, one of the people I I

particularly uh focus on in this space

is Simon Willis and something he

stresses constantly is the importance of

tests, but testing is a huge deal to to

him and being able to make these things

work. And of course, you know, Bea is is

from Fort Works. We're very much an

extreme programming company. So, she's

steeped in in in testing as well. So,

she will say the same thing. You got to

really focus a lot on making sure that

the tests work together. And of course,

this is where the LLM struggle because

you tell them to do the tests and I'm

I'm only hearing problems [laughter]

or experiencing them myself like when

the LLM tells me, "Oh, and I ran all the

tests. Everything's fine. You got npm

test five failures." H yeah, I I I see

some improvements there by the way with

with clock code also like other agents.

But yes, it's the nondeterministic

angle. Sometimes they can lie to you,

which is weird, right? I'm I'm still not

>> They do lie to you all the time. In

fact, if if if they were truly a junior

developer, which is how sometimes people

like to say they should be

characterized, I would be having some

words with HR.

>> Yeah. Like I the other day I just had

this really weird experience, which is

the simplest thing. I have a

configuration file where I add just new

items, a new JSON, you know, blob, and I

I put the date of when I added it just

in the comments saying added on, you

know, October 2nd, added on November

1st. It's always a current date. And I

told the LM, can you please add this

configuration thing and add the current

date? And it added it and it added it

just copied the last date. And I said

that is not today's date. I said, oh,

I'm so sorry. You know, let me correct

that for you. And it put yesterday's

date. [laughter]

And and I I feel you need to get this

experience to see that it can gaslight

you for a simple thing of today's date

which uh you know you know you could

call a function whatnot but it's it's

down to which who knows which model I

was using how that model works whether

the company creating it is optimizing

for token usage or not etc etc etc so

like in the end even for the simplest

things you are as as a when you're a

professional working on important stuff

you should not trust Yeah, absolutely.

Never. Yeah, it's got to you've got to

don't trust, but do verify.

>> Verify. Yes. Uh, speaking with

developers at at Thought Works and and

the people you're you're chatting with,

what areas

that they are successfully using LM's

day-to-day though, like we we we did

mention just right now testing. We we

also mentioned things like prototyping,

but do you see some other things where

starting to become a bit of a routine?

Like if if I'm doing this thing, let me

reach for an LLM. it can probably help

me

>> that yeah I mean I'm I've mentioned many

of that right the prototyping the legacy

code understanding oh yes the fact that

um you can use it to explore um new

technology areas um potentially even new

domains as long as you you know you

trust it significantly less than you

would trust Wikipedia 10 years ago those

are the things that I'm hearing so far

>> yeah one interesting area that Burgetta

is exploring ing is spec development.

There's this idea of what well you know

LMS have have their own limitations but

what if we define pretty well what we

want it to do and give it this like

really good specification and you know

it can run with it it can run long it

had iterations and so on. What is your

take on this and do you have a bit of a

dja vu because we we've heard this once

right your your career started around

this thing called waterfall development.

So how how how are you seeing it similar

but also different this time? Well, the

the this the similar to waterfall is

where people try and say let's create a

large amount of spec and not pay much

attention to the code. And here I mean

whether you whether you talk again this

is what you mean by speciment is it so

much focusing on that or is it doing

small bits of spec do the tight loop I

mean to me the key thing is you want to

you want to avoid the the waterfall

problem of trying to build the whole

spec first. It's got to be do a do the

smallest amount of spec you can probably

you can possibly get to make some

forward progress. Cycle with that, build

it, get it tested, get it in production

if possible, and then cycle with these

thin slices. What role a spec may play

to drive in either case could be argued

to be a spec form of spec driven

development. But to me, what matters is

the tight the tight loops, the the thin

slices, that kind of thing.

>> And I know big definitely agrees on that

point. coming because she and you have

to be the human in the loop verifying

every time that's that's clearly crucial

where the spectrum and development then

ties in interesting again it comes back

to this thinking of building domain

languages and domain specific languages

and things of that kind can we craft

some kind of more rigorous spec to talk

about and that's you know I mentioned

what the wood mesh was doing there using

it to build an abstraction because

essentially what we're saying is that it

gives us the ability to build and

express abstractions in a slightly more

fluid form than we would be able to do

if we were building them purely within

the codebase itself. But we still don't

want them to deviate too much from the

codebase, right? We still want the

ubiquitous language notion that it's the

same language in our head as is in the

code and we're seeing the same names and

they're doing the same kinds of things.

The structure is clearly parallel, but

obviously the way we think is a bit more

flexible than the way the code can be.

and then you know can we blur that

boundary a bit by using the LLM as a

tool in that area. So that's the area

that I think is interesting in in that

direction. It

>> it's interesting as new because I I feel

we've never been able to use language as

close to representing code ever or or

like business logic and this is very

new.

>> Yeah. Although again people I mean there

are plenty of people who take that kind

of DSL like thinking into their

programming and I would to I know people

who would say yeah I would I would get

to the point where I could write certain

parts of the business logic in you know

a programming language like say Ruby and

show it to a domain expert and they

could understand it. They wouldn't feel

the ability to be able to write it

themselves but they could understand it

enough to point out whether what was

wrong or what was right in there. And

this is just programming code, but it it

that requires a certain degree of the

way you go about projecting the language

in order to be able to get that kind of

fluidity. And so it's but that kind of

thinking like trying to make an internal

DSL of a programming language or maybe

building your own external DSL

DSL meaning domain specific language

like if you're working with accountants,

you're going to have the terms that they

they use, the way they use it and so on.

>> Yeah. And what you're trying to do, of

course, is create that communication

route where pe where a non-programmer

can at least read what's going on and

understand it enough to to be able to

find what's wrong about it and and to

suggest changes which may not be

syntactically correct, but you can

easily fix them because you as a

programmer, you can see how to do that.

And that's the kind of goal and some

people have reached that goal in some

places. So the interesting thing is

whether whether LLMs will enable us to

make more progress in that direction and

see that happening more widely

>> and I guess this must be I'm just

assuming correct me if I'm wrong this

must be especially important in

enterprises these very large companies

where software developers are not the

majority of people let's say they're 10

or 20% of staff and there's going to be

accounting marketing special business

divisions who all want software written

for them and they know what they want

and historically there's been layers of

people translating this may that be the

project manager the technical pro etc.

So you're saying that there could be a

pretty interesting opportunity or or

just an experiment uh with LM that maybe

we can we can make this a bit easier for

both sides.

>> That is the world I'm most familiar with

right is that world. I mean um one I

mean I I my sense is you're very

familiar with the big tech company and

the startup worlds but this corporate

enterprise world of course is a whole

different kettle of fish because exactly

the reason that you said suddenly the

software developers are a small part of

the picture and there's very complex

business things going on that we've got

to somehow interface in and of course

also there's usually a much worse legacy

system problem as well. Um and and

there's going to be regulation, there's

going to be a history, there's going to

be exceptions because of all the

knowledge. I I think we can all just

think of banks of all the things cuz

there's there's perfect storm, right?

They have regulation that changes all

the time. They have incidents that they

want to avoid going future. They'll have

special VIP, I don't know, accounts or

whatever that they'll want to do. And of

course, they have all these business

units that all know their own rules and

and frameworks. And they've been around

since before technology. Some of some of

the banks have been around for, you

know, 100 plus years.

>> Yeah. And remember, the banks tend to be

more technological advanced than most

other corporations in software.

[laughter]

>> That's a good one.

>> You're looking at the at the good bit

when you're talking about banks.

[laughter]

>> You you have worked with some with some

of the less advanced folks as well.

>> I mean, yeah, retailers, airlines,

government agencies, things of that

kind. I mean, it was interesting. I was

chatting with some folks working in the

Federal Reserve in Boston and uh you

know they're

they have to be extremely cautious. They

are not allowed to touch LLMs at the

moment because

you know the the consequences of error

when you're dealing with you know a

major um government banking organization

are pretty damn serious. So you've got

to be really really careful about that

kind of stuff. and and yeah, their

constraints are very different and and

it it it brought to mind this there's a

an adage that says that to understand

how the software development

organization works, you have to look at

the core business of the organization

and see what they do. Interesting. I I

was at this agile conference for the

Federal Reserve in Boston and they took

me a tour of the Federal Reserve, but

where they handle the money. And so I

saw the places where they bring in the

the notes that have been brought in from

the banks and they kind of clean them

and count them and all the rest of it

and and send out the stuff again. And

you look at the degree of care and

control that they go through. own as you

could imagine. I mean, when you're

bringing in huge wges of cash and it has

to be sorted and counted and all the

rest of it, the controls have to be

really really strenuous. And you look at

that and you look at the care with which

they do all of this and you say, "Yep, I

can see why in the software development

side that mindset percolates because

they are used to the fact that they

really have to be c careful about every

little thing here." A lot of

corporations of course have that similar

notion. you're you're involved in an

airline, you are really concerned about

safety. You're really concerned about um

getting people to their death that

affects your whole way of thinking or

ought to and it does and I guess this is

a reason we are clearly seeing we always

see a divide in technology usage because

you have the startups which is a group

of people they just raised some funding

or they have no funding. They have

nothing to lose. They have they have

zero customers. They have everything to

gain. They they need to jump on the

latest bandwagon. They want to try out

the latest technologies. oftentimes

build on top of them or sell tools to

use the latest technology and they're

here to break the rules and you know

midway when there's when you start to

have a few customers in a business

you're starting to be a bit more careful

and of course you know 50 or 70 years

down the road when the founders have

gone and and now it's a large enterprise

you will just have different risk

tolerance right

>> exactly yeah

>> but what what what what I find

fascinating talking about this that I'm

unsure if there has been any new

technology that has been so rapidly

adopted everywhere. You mentioned that

let's say the Federal Reserve or some

other government organizations might say

let's not touch this yet but they are

also evaluating it sounds like it. So if

they're you know they're the one of the

most I guess behind in the technology

curve for very good reason they're

already aware of it or using it which

probably means that it's everywhere now.

Oh, it is. I mean, it is. I mean, we see

it all over the place, but again, with

that with with more caution in the

enterprise world where they're saying,

"Yeah, we we also see the dangers here."

>> And then you're you're seeing kind of

more nimble companies that you work with

and the more enterprise focused. What

would you say is the biggest difference

between their relationship of of AI uh

their approach? Is it is it this caution

or are there other characteristics that

the the the big more traditional less

more riskaverse companies approach it

differently? The the important thing to

remember with any of these big

enterprises is they are not monolithic.

So it'll be small portions of these

companies can be very adventurous and

other portions can be extremely not so.

And so what you'll see is small I mean

like you know when I when I started at

cheetah lightwe right and I was in this

little bit that was being very very

aggressively doing really wacky things,

right? I mean you'll find that in any

any big organization you'll find some

small bits doing some stuff. Um, and so

it's really the variation within an

enterprise often is bigger than the

variation between enterprises.

>> Good to keep that in mind. So speaking

about refactoring, LM are very good at

refactoring and and you you've written

the book back in 1999 called

Refactoring. This is now the second

edition which 20 years later it's it's

been refreshed. And it's it's actually a

really detailed book going through

different code smells uh that could show

that where the code is, techniques of of

refactoring it. On the first page

already, it has I really like this. It

has a list of refactorings on I don't

know how the publisher printed this

because it's so so unusual, but it's

it's it's right here on the table of

contents. Why did you decide to write

this book back in 1999? Can you bring us

back on what the envir environment was

like and what was the impact of the

first edition of this book? Okay. So, I

first came across refactoring at

Chrysler. Yeah. When I was working with

Kemp Beck, right early on in the

project. Um, we we I remember

in my hotel room, the courtyard or

whatever in Detroit, him showing me how

he would refactor some small talk code.

And what I mean, I was always someone

who liked going back to my something I'd

already written and make it more

understandable. I've always cared a lot

about something being comprehensible.

That's true in my pros writing and in my

software writing. And so that I knew,

but what he was doing was taking these

tiny little steps and and I was just

astonished at how small each step was,

but how because they were small, they

didn't go wrong and they would compose

beautifully and you could do a huge

amount with this sequence of little

steps. And that really blew blew my mind

away. I thought, "Wow, this is a big big

deal." But Kent was at the time his

energy was to write the first extreme

programming book, the white book. He

didn't have the energy to write a

refactoring book. So I thought, well,

I'm going to do it then. [laughter]

And I started by, you know, whenever I

was refactoring something, I would write

careful notes. And partly to because I

needed it for myself. How do I extract a

a extract a method so as I don't screw

it up? And so I would write careful

notes on each one. And then each of

those turned it the mechanics in the

refactoring book would be that step. And

then I' I'd make an example for each

one. And that was the first edition in a

book. And that and I did it in Java, not

in small talk because small talk was

dying sadly. And Java was the language

of the future, the only programming

language we'd ever need in the future in

the in the late 90s. And so that's what

led to the um to the first book. And um

the impact well I mean and also

refactoring. I should also stress it

wasn't invented by Kent. I mean it was

very much um developed by um Ralph

Johnson's crew at the University of

Illinois the Bona Champagne. They built

the first refactoring browser in Small

Talk which is the first tool that did

the automatic refactoring. that we talk

about now. That was the original the

refactoring browser built by um um I'm

blanking on John Brandt and Don Roberts

>> um did that and um then when the book

came out that got more interest there

was already some interest from the IBM

visual age folks because they came out

of Small Talk. the original versions of

Visual Age were in fact built in Small

Talk. Um, and so they were already aware

of what was going on to some degree, but

it was the Jet Brains folks that really

caught the imagination because they put

it into the early versions of Intelligj

idea and really ran with it. Then you

ran into it with ReSharper, of course.

Um, and um, they really made the

automated refactorings become something

that people could rely on, but it's

still good to know how to do them

yourself because often you're in a

language where you haven't got those

refactorings available to you. So it's

nice to be able to pull out that stuff

and some of them aren't obviously in

there and yeah so the impact it's had is

refactoring became a word and of course

like all of these words got horribly

misused and people use refactoring to

mean any kind of change to a program

which of course it isn't because

refactoring is very strictly these very

small semantics pres behavior preserving

changes that you make tiny tiny steps I

always like to say each step is so small

that it's not worth doing but you string

them together and you can really do

amazing things I I I think we've all had

that story. At least I had a story where

one of my colleagues or you know it

could have been me but often times one

of my colleagues would say like oh stand

up saying like oh I'm I'm just going to

do a refactoring and then next day oh

I'm still doing the refactoring next day

oh I'm still doing the refactoring and

[laughter]

you know that that that missed a part of

the small changes for sure. What made

you do a second edition for the book 20

years later in 2019 which was fairly

recent? Well, it was a sense of um

wanting to refresh

um some of the things that were in it.

Some there were some new things that I

had. I was also concerned that I mean

when you've got a book that's written in

late 1990s Java, it it shows its age a

bit.

>> Yes. [laughter]

>> And although the core ideas I felt were

sound and people could still use it, I

felt you coming giving it a more doing

it in a more modern environment. And

then the question was which you know

would I stay with Java or did I switch

to another language and in in the end I

decided to switch to JavaScript. I felt

it would reach a broader audience that

way and also allow a less

object-oriented centered way of

describing things. So instead of extract

method it's extract function because of

course it's the same process for

functions and also some things that you

you don't wouldn't necessarily think of

doing in an object-oriented language.

But um it was mainly just to to get that

refresh um to redo the examples to

really hopefully give it another 20

years of life because it's got to keep

me going until I croak, you know.

[laughter]

>> Yeah. So you published this book 25

years ago or 26 years ago in the

industry based on your interactions with

developers. How has the perception of

refactoring changed? because in the book

you you specifically wrote that you you

see refactoring as a key element in the

software development life cycle and

you've also talked about how when you

refactor uh the overall cost of changing

code over time can be a lot cheaper. Was

there a time where there was a lot more

uptake on this or is there still or or

do you feel it's kind of like a little

bit like being

maybe refracting went a little bit out

of style as some of those really

innovative tools at the time like Jet

Brains and others. They're maybe not as

as uh kind of referenced even though

they're everywhere.

>> It's hard to say for me. Um because I

mean again most of the interaction I

have is with folks at Fort Works. they

tend to be more clued up with this kind

of stuff than the average developer.

Certainly, I read plenty of things on

the internet that make me just shake my

head at

>> how even refactoring is being described,

let alone the lack of doing it in the

and certainly in the kind of structured

way, controlled way that that I like to

do it because I like doing it quickly

and effectively. And you know, it's one

of those things where the disciplined

approach actually is faster, even though

it may seem strange to describe it that

way. But I mean, I I have to it's at

least been part of our language now.

People talk about doing it. It's in

these tools and they do it very

effectively. The refactorings that they

do, I mean, it's wonderful to work in in

an environment where you can actually

automatically do so many of these

things. And so I feel we've definitely

made some progress. Maybe not as much as

I'd have hoped for, but you know, that's

often the way with these things.

>> Looking ahead with AI tools, they they

generate a lot more code a lot faster.

So, we're just going to have a lot more

code. We already have a lot more code.

>> How do you think the value of of

refactoring thinking about the your

intended meaning of of those small

ongoing changes is going to be

important? And are you already seeing

some of this being important?

>> I wouldn't say I'm already seeing it.

Um,

but I I can certainly expect it to be

increasingly important. Um, because

again, if you're going to produce a lot

of code of questionable quality,

but it works, then refactoring is a way

to get it to into a better state while

keeping it working. Um, these tools at

the moment can't definitely cannot

refactor on their own. Although we've

combined with other things. Adam

Tornhill does some interesting stuff

with combining LLMs with other tools to

be able to get a much more effective

route and I think that kind of approach

combining could be a good way to do it.

Um but definitely the refactoring

mindset and thinking how do I make

changes by basically boiling them down

to really small steps that compose

easily. That's really the trick of it.

The the the smallalness and the

composability. combine those two and you

can make a lot of progress.

>> It's interesting because because right

now if you want to refactor you need to

have your IDE open for sure. And I mean

the fast way is just just using the

built-in tools or you moving things

around. What what I found as well is

describing it when I have a command line

open with like cloth code or something

similar. It's it's tough or I I spend

more time explaining it than me doing

that that small change. And I do wonder

if uh if we will see more integrations

in this end as well so that LMS can

actually do it or some of them might do

it automatically cuz as you say it it

doesn't work out of the box but I think

for any quality software that I mean we

we all learn the hard way that if you

just kind of leave it there and don't go

back and don't change it up when your

when your functions get just the simple

things right when your function gets too

long when your class gets too long you

break it up otherwise you're not going

to understand it later. Yeah, it'll be

interesting as well to see if it

provides a way for us to control the

tool. I mean, one of the things that

interests me is where people are using

LLMs to describe queries against um

relational databases that turn into SQL.

You don't know how to get the SQL right,

but if you type the thing at the LLM, it

will give you back the SQL and you can

then look at it and say, "Oh, this is

right or not right." And tweak it and it

gets you started, right? And so

similarly with refactoring, it may allow

you to get started and say, "Oh, these

are the kinds of changes I'm looking at

and be able to make some uh progress in

that. I mean, particularly where you're

talking about these automated changes

across log large code bases." There was

an example of this was it a year ago or

so when one of these big companies

talked about this massive change and

made to change APIs and and clean up the

code and they mentioned it as an LM

thing, but it wasn't an LLM. It was a it

was that different tool and I'm

completely blanking on what the names of

all of these things were. Oh, I'd have a

60-y old brain and I can't be able to

remember anything anymore. It'll come to

me at some point. But actually, it was

it was a combination of, you know, maybe

10% LLM and 90% this other tool. Um, but

that was it again provided that extra

leverage that allowed them to to make

the progress. I think those kinds of

things are really quite interesting

using the LLM as a starting point to

drive a deterministic tool and then

you're able to see what the

deterministic tool is doing. That's I

think where there's some interesting

interplay. Speaking about going on from

refactoring to software architecture,

you were very busy writing books around

the early 2000. You wrote the book

patterns of enterprise application

architecture in 2002 and this was a

collection of more than 40 patterns uh

things like lazy load identity map

template view and many others and I

remember around this time there was your

book about enterprise uh architecture

patterns there was also the gang of four

book there was a lot of talk when I was

interviewing around that time on

interviews they were asking me questions

about how to do a factory pattern and

singleton and and all of these things

software architecture was talked about

my sense was in a lot of places or a lot

more. Then something happened something

starting from the 2010s I I no longer

hear most technologists talk about

patterns or architecture patterns. How

have you observed this period of when

the book came out? what was the impact

of it and why why was it important to to

talk about it and and put it into the

industry and how have you seen this

change of where we stopped talking more

on on patterns and why do you think it

happened?

>> Yeah, that I mean I've always found it a

I mean what you're doing with patents is

you're trying to create a vocabulary to

talk more effectively about this kind of

these kind of situations. I mean it's

just like in you know in the medical