There's A Pattern To Follow: An Interview with Robert "Uncle Bob" Martin

0:00 Robert: The great thing about Agile is that you know how screwed you are really early on.

0:03 The purpose of Agile is to destroy hope.

0:22 Brad: Welcome, everybody,

0:23 to another episode of the How Many CTOs Does It Take podcast.

0:26 My name is Brad Hefta-Gaub, and my trusty co-host is?

0:29 Scott: Scott Porad.

0:30 Welcome,

0:31 Brad.

0:31 We have a special guest with us today.

0:33 Brad: Yes, we do.

0:35 Would you like to introduce our guest, Scott, or kick

0:37 Scott: Sure.

0:37 Brad: it to him?

0:38 Scott: I'd like to introduce everybody to...

0:40 Robert Barton or Uncle Bob or Bob as he likes to go many of you may not know him but he's been influential in almost all of your software engineering careers even without knowing it and we're feel really fortunate to have him here today to talk to him about what he's been doing lately what he's been doing what he's been doing lately and and some other things so welcome Bob could

1:00 Thank you very much. Glad to be here.

1:03 you take just a few minutes to

1:06 the 40 people that listen to our podcast and

1:08 Brad: 60.

1:09 Scott: It's and

1:09 Brad: up to 60, Scott.

1:10 Scott: um you know just tell them your background you know you've been doing this a long time you've been influential in our industry and not everybody knows um you know who you are and what your what your role has been so we'd love to hear it

1:24 Robert: Let's see, I'm 73 years old.

1:26 I wrote my first line of code when I was 12.

1:30 That would have been in 1964.

1:33 and the the thing I wrote it on I've got it over here okay

1:37 Oh, this is amazing. It's going to be interesting.

1:39 Brad: This is great.

1:41 Robert: so

1:42 Brad: I love

1:42 Robert: here

1:42 Brad: it.

1:43 Robert: it is this is a three bit see the three bits right

1:47 Brad: I love it.

1:48 Robert: they slide back and forth there's three little flip-flops in here and you crank it

1:54 With that little crank.

1:56 And if you set it up properly,

1:58 this will count in binary. It will count from zero up to seven and back to zero again.

2:04 If you set it up a little differently,

2:06 it'll count down from seven to zero.

2:08 You can have it play the game of Nim. You can have it add two bits and produce a sum and a carry.

2:16 There's a whole bunch of things you can do.

2:18 Essentially, it's a three bit finite state machine.

2:20 But at the age of 12, this thing fascinated me.

2:24 This was a birthday present from my mother.

2:28 Mm

2:28 And-hmm. I put it together and I worked through all the puzzles and I knew what I wanted to be for the rest of my life.

2:35 Brad: Bob, is that the actual original device that you got at 12 years old?

2:40 Robert: Yes, this is the original.

2:41 Brad: That's fantastic.

2:42 Robert: Wow.

2:42 Yes, it

2:43 Brad: I

2:43 Robert: is.

2:43 Brad: love it. I don't have my VIC-20.

2:49 Doggone it.

2:50 Do you still have your VIC?

2:51 Robert: Commodore 64 over here.

2:53 Brad: Nice.

2:53 Of course you

2:54 Robert: It's

2:54 Brad: do.

2:54 Robert: under glass.

2:55 Brad: Of course you

2:56 Robert: Wow.

2:57 Brad: do.

2:57 I love it. I love it.

2:58 Robert: I don't think I can show it to you, but there's a Mac 128 over there.

3:03 And then this thing over here is a PDP-8.

3:06 See the blinking lights?

3:07 Brad: Yeah.

3:07 Robert: Mm

3:08 Well,

3:08 -hmm.

3:08 it's actually a Raspberry Pi simulating a PDP-8.

3:13 Brad: Love it.

3:14 Robert: Yeah,

3:14 Brad: Love

3:14 Robert: it's fun.

3:15 So I was a programmer from that point on.

3:18 Yeah, I got my first job out of high school at 16,

3:22 a temporary job writing a little bit of assembly language,

3:25 got another job at 18 that was full time writing more assembly language for many computers because that was the age of the mini computer,

3:33 right?

3:33 And they had maybe 4k of core or 8k of, you know, some of them actually had RAM. That was the some of them were modern enough to not.

3:45 Not have core memory.

3:46 I spent probably 15, 20 years doing assembly language in various industries,

3:53 telecommunications and shop floor control,

3:57 aluminum diecast shop floor control,

4:00 all kinds of stuff,

4:01 writing code in assembly language for many computers that controlled devices to build a little bit of laser trimming.

4:10 controlling a laser trimmer eventually got into C that was like the early late 70s late 70s got into C I had been of the opinion that

4:23 compilers were for weenies real men were wrote assembly language damn it and

4:29 Of course.

4:29 and then I got a copy of Kernighan and Ritchie and as I read it I realized that was an assembly language it was just a better assembly language and so I very rapidly transitioned into C and then from there you know bit by bit into C++ and then Java and and so on yeah I've been a programmer for

4:48 for over 60 years and

4:51 Yeah.

4:51 and I still write code well actually now I control agents that write code but I I still have my hands on the keyboard still producing software

5:01 Love it.

5:03 Are you still producing software?

5:06 commercially or professionally like for clients are you just doing it because it's fun and you've been doing it since you were 12

5:11 Why would I ever stop?

5:13 No, no. Yeah.

5:14 No one's going to pay me to write code anymore.

5:17 So, yeah,

5:18 I just do it for fun and for research.

5:21 You know, I'm still writing books and I'm still writing articles and I still try to have an impact on various social networks,

5:29 mostly X nowadays.

5:30 Mm-hmm.

5:31 And I try to make sure that I know what I'm talking about by actually doing it.

5:36 And, I mean, what would I do with the rest of my day?

5:39 I'm going to be writing code.

5:40 I told Kent Beck a long time ago,

5:42 right,

5:42 they will find me with my nose stuck between the keyboard keys,

5:46 if there are any keyboard keys back then.

5:49 I want to code for the rest of my life, and

5:52 Yeah, of

5:53 I don't

5:53 course, why

5:53 want that

5:53 not?

5:54 to end anytime soon.

5:55 Brad: Yeah, I love it.

5:57 I love it. By the way, I don't want to like get too far ahead of ourselves now,

6:00 but it is so.

6:03 It resonates with me that you describe your passion as coding and now in a world where we have these AI agents,

6:17 these LLMs, these token prediction machines that are doing a lot of the coding.

6:24 Robert: Yes, yeah.

6:25 Brad: But I consider myself to very much be a coder.

6:31 even if the bulk of my coding is.

6:35 orchestrating agents and then keeping them online keeping them in line keeping you

6:40 Robert: Yeah, absolutely.

6:40 Brad: know keeping keeping tabs on them and keeping you know making them deliver the quality that i want to deliver as if i was the one typing the code yeah

6:49 Robert: I mean, they're not going to take responsibility for anything, but

6:53 Brad: yeah

6:53 Robert: on the line.

6:54 So you've

6:56 Brad: absolutely yeah

6:57 Robert: got to whip them into shape.

6:57 Brad: absolutely so somewhere between

7:01 12 years old and today you also have written a lot of books and you have been part of the movement of of the agile agile movement do you would you like to share more about like how that came about

7:17 Robert: Oh, my goodness. The agile movement.

7:20 This began in 95 and it began,

7:23 it came to my knowledge in the design patterns movement.

7:27 So a bunch of guys started the whole design patterns movement. Eric Gamma and, you know, a bunch of guys got together and they wrote the book. And early on, I was one of the people reviewing the book. This is back in the days before social networks.

7:42 So they would put the chapters up on an FTP mirror right and

7:48 Yeah.

7:48 we'd download it in postscript and then we would print it off on a laser printer and then we'd review it and then we'd email back and forth about it. That's where the name the gang of four came from, from that email group. And in that rapid discussion period.

8:08 a number of thoughts about getting rid of waterfall started, right?

8:14 Can't we do something more lightweight?

8:17 This whole, you know, upfront planning thing hasn't been working for us. We need a better way to do it. And along comes Kent Beck,

8:23 who is a big part of the patterns community.

8:26 And he says, well, there's this thing I've been doing called extreme programming.

8:31 And I got really heavy into that. I said, you know, Kent,

8:33 that's exactly what my clients need.

8:35 It's what the industry needs as a whole.

8:38 And he and I and Martin Fowler got together and we concocted this scheme to do extreme programming courses.

8:51 And these were like five-day courses. They went from nine in the morning till nine at night.

8:56 We built special tables so the people could pair program around the tables.

9:01 We'd have 60,

9:02 70 people coming in there.

9:04 This is like the height of the dot-com bubble.

9:07 Mm

9:07 So

9:07 -hmm.

9:07 everybody was doing anything they could to get hot on extreme programming.

9:13 And in the midst of all that,

9:14 there's some other lightweight processes that were beginning to get popular. Scrum was one of them. There were a few others.

9:21 others.

9:22 And it occurred to Martin Fowler and I that we ought to get everybody together.

9:26 So we we convened this thing at Snowbird was this February of 2001,

9:32 I think we sent a whole bunch of emails out, a bunch of people responded, those who could afford it and wanted to join.

9:38 And we all met at Snowbird and I stood up and said,

9:42 hey,

9:42 we need a manifesto and I sat down and that was my the end of my contribution.

9:47 And then everybody else kind of brainstormed it out. And in the end.

9:51 Up pops the Agile Manifesto on a board.

9:54 Right. It was written there on a board.

9:55 Nobody knows quite for sure how it got there.

9:58 Nobody remembers properly.

10:01 And then one a day later down in the basement in a different room, we had a vote about what to call it.

10:08 And one guy said lightweight. That was me.

10:11 And I said, we should call it lightweight.

10:13 Everybody hated that idea. And the other guy said we should call it adaptive.

10:17 And everybody hated that idea. And it was John Kern.

10:20 who said,

10:22 well,

10:22 the military really likes the word agile right now.

10:25 And the rest of us are going,

10:27 oh, that's a terrible word.

10:28 But we voted on it and agile won by a vote.

10:32 yeah

10:33 And then it was Ward Cunningham who said, you know,

10:35 I'm going to take this manifesto, I'm going to put it on my website,

10:39 I'll get a special domain name for it, and here was the key insight,

10:44 right?

10:44 I'm going to write some code that will allow people to sign this.

10:48 This is 2001.

10:49 Dynamic websites were like brand new.

10:52 The act of changing a website from a user,

10:56 that was very different.

10:58 And Orrin Cunningham writes that and tens of thousands of people sign the doggone thing.

11:04 Who do?

11:06 that's the story in a nutshell if you want a more complete story by the way let me get a book down here i wrote the whole story in that book there we go yeah the whole history the whole sordid history of who did what to who when it's all in here along with you know what this agile stuff really is because it's not what everybody thinks it is you know i wrote that book about

11:30 Eight years ago, something seven years ago,

11:33 something like that.

11:33 I've got two questions here.

11:35 Yeah.

11:35 First, for the people who are not watching video,

11:38 that book is called Clean Agile, back to basics, so everyone knows.

11:42 I have two questions,

11:43 Bob.

11:44 The first is...

11:46 You were experimenting with lightweight frameworks.

11:48 Other people were experimenting with lightweight frameworks.

11:51 What was it that was in response to something and you were trying to get from some place to some other place? What were you reacting to that was causing you and others to?

12:02 be trying to do something different.

12:04 There were two competing ideas in the industry,

12:07 and one of them was some kind of lightweight iterative process.

12:12 Barry Beam had done the spiral model years before,

12:15 and everybody looked at that and went, oh,

12:17 interesting,

12:18 but you've still got to have a big plan up front and you've still got to lay it all out and still have to do the analysis and then the design and implementation should be easy if you've done the analysis.

12:28 colors in the design.

12:29 That was a mindset that was so thoroughly entrenched.

12:34 that it took a very long time to shake out of it.

12:37 And sometime in the 90s, we,

12:40 the ones who were old at the time and had gone through that and had been proponents of it,

12:47 had to look back and say,

12:49 yeah, well,

12:49 that didn't work all that well.

12:51 And there's this other school of thought,

12:54 which is maybe we should just do it in tiny little iterations.

12:58 Maybe we should just work the way.

13:01 that programmers are observed to behave in the wild that was a catchphrase that we used to use and so okay then we started playing around with that and Kent Beck was one of the ones really early who did this and there were a number of other people Ken Schwaber,

13:16 Martin DeVoe, Jeff Sutherland they all kind of started to play around with this Alistair Coburn started to play around with it started to mention it at the

13:27 at the patterns conferences and we all kind of went you know there's probably something to this and

13:34 Yeah.

13:35 that's kind of how it all happened

13:37 And fundamentally what wasn't working about the.

13:41 The previous method was the software wasn't very good or it wasn't it was expensive to build or it

13:47 Oh, no.

13:48 was not fun.

13:49 Well,

13:50 it wasn't well, it wasn't fun.

13:52 That's number one. But what wasn't working was the idea that you could analyze everything up front and then design everything up front.

14:01 And then the code would come out just so easily.

14:05 And what you discover when you do that is when you start writing the code, when the rubber actually hits the road,

14:11 it goes in a completely different direction than anybody had thought.

14:15 but you don't now have time because you've blown all this time on the big analysis and the big design and

14:21 Yeah.

14:22 you've also got people looking over your shoulder saying you know you're not following the plan and the developers are sitting there going yeah but we can't the plan doesn't work this thing we spent six months on does not work and now we've got two months left and we're just going to have to hack like crazy that was the that was kind of the

14:41 The normal theme of doing software throughout the 70s and the 80s and into the 90s.

14:48 Brad: Yeah,

14:49 I remember that, Scott.

14:50 You started in that time frame, too,

14:53 but I definitely remember that in the,

14:55 you know, in my professional career from like my first,

14:59 you know, paid software gig was 89.

15:03 And by 95,

15:05 it's like it always were these big projects. They were like two year long,

15:09 three year long software release cycles where you spent the first.

15:14 six months first year of that two years like speccing things and designing things and then you didn't really start writing code until halfway through your allotted time budget and yeah like like the classic example is uh you know developers like has implemented some code and eventually qa is looking at it and it's behaving you know it's behaving a certain way and it's like

15:39 what's the spec say about this and the developer's like the spec's silent on this like the spec completely didn't even consider this idea but we realized it once we had the other pieces together like you know it's like a big jigsaw puzzle and you're you've got all these holes in it you're like oh the plan didn't even account for this whole side of the jigsaw puzzle like we had to put something there

15:59 Robert: Yeah, so Agile comes along and says, you know, you can use feedback for this. You can have the customer

16:04 on the team with you and as you're putting it all together they can say no I don't like this yes I do like that every week every two weeks and and evolve the system in the direction that the customer wants to go which also takes advantage of the fact that the customer doesn't really know what they want

16:21 So if you ask a customer for a spec,

16:24 well,

16:24 they'll give you one, but it's a lie.

16:27 It's a complete fabrication because they don't know what they want,

16:30 really.

16:30 Brad: Yeah.

16:30 Robert: But if you show it to them and they can guide it,

16:33 then it's a much better approach. Not perfect,

16:36 but it's a much better approach.

16:39 So, Brad,

16:40 you know.

16:41 I didn't start professionally until 95 and

16:44 Oh, okay.

16:44 I have always worked in online systems.

16:47 So like I'd never worked on a shrink wrap piece of software before.

16:51 And so even though we were still doing big water folly kind of things, there was just by the nature of the fact that we weren't having to put it on a disc or a CD or whatever and ship it to people meant we could.

17:05 even before the notion of agile existed,

17:07 we could kind of be a little more agile.

17:09 If there was a problem with it, we could go fix it.

17:12 Brad: Yeah.

17:12 Robert: Maybe not as fast as we wanted to.

17:14 So I've always,

17:14 so when the stuff that Bob and others were working on started to come along in the early 2000s, it was very natural.

17:21 It was just like, oh, this is just taking kind of the friction we've been feeling in terms of trying to build online software.

17:29 Really, I guess taking those shackles off, I guess, is kind of what it felt like.

17:33 There's an argument to be made that it was the beginning of the internet and the web that was really the catalyst for the change from the big heavy upfront plan to an iterative approach,

17:45 because everybody wanted to see that stuff on the screen.

17:48 And then everybody would start commenting about the stuff that was on the screen.

17:51 And that could have been the catalyst, probably was at the time.

17:56 You know, this is a little side quest,

17:58 but so in 1998, I was part of a team that launched this website called drugstore.com, which

18:04 I

18:05 ultimately

18:05 remember this. I bought stock in that.

18:07 I hope it did okay for you.

18:09 I remember we spent a while getting this thing built and we launched it.

18:14 And I remember the day we launched it or maybe the day after we launched it, people wanted changes to the website.

18:20 And I remember sitting with this guy,

18:23 his name was Zach Stralo,

18:24 and we didn't have any method for change. We only had a method for like getting it out there once. We didn't have any plan for like how are we going to.

18:32 make changes,

18:33 right?

18:35 figured out branching and source control and all that stuff but it was it was your point about how the internet brought that along resonates with me because people saw it and they were like oh that's not what we wanted okay so you said something about your book that i want to ask you said this is this book says what agile really is not what happens out there and so where do you see the where do you see the differences what's what do you see happening out in the world versus what the spirit of it is

19:01 Agile got...

19:02 completely invaded.

19:04 Hmm.

19:04 The space got invaded by the project managers.

19:07 And you could blame this on Ken Schwaber indirectly because he's the guy who came up with this idea of the certified scrum master.

19:16 Now, little story,

19:18 Ken came to me one day and said,

19:20 Bob,

19:20 I'd like to use one of your classrooms.

19:22 I was running a training company at the time. I had classrooms.

19:25 I'd like to use one of your classrooms and I'm going to teach this course.

19:28 First, I've never taught it before,

19:29 the certified Scrum Master course.

19:32 And I looked at him like cross-eyed and said,

19:34 well,

19:35 OK,

19:35 go ahead, Ken,

19:36 you can do that. And I thought it was a terrible idea.

19:39 It turned out that it was a great idea because tons and tons of people wanted to become certified scrum masters,

19:45 but not programmers.

19:47 It was all the project managers and the project managers invaded the space and they completely took it over. They took over the conferences.

19:54 They took over the messaging and literally pushed the programmers out.

19:59 Hmm.

19:59 Brad: Agile was started by a group of programmers,

20:02 and within about three or four years, the project managers had put the programmers off into a little cubicle somewhere and had taken over the entire messaging.

20:11 And it was a disaster.

20:13 It was just awful.

20:15 In the meantime,

20:16 you've got all these consultants out there who grabbed onto the word agile or scrum, and then they're adding adjectives onto the end of it or onto the beginning of it.

20:24 Yeah, so there's fast agile and there's special agile and there's stable agile and all these different consultants are pouring into the industry trying to differentiate themselves from each other and you end up with a absolute chaos,

20:37 which is kind of the way the world went.

20:40 And I wrote this book and the book is like.

20:45 Do you remember how this began?

20:47 You know, agile was a small idea about the small problem of getting a small team to do small things.

20:57 It's not some big idea.

20:59 We weren't trying to take over the world.

21:01 We just wanted to solve this one problem of getting a team of six or seven people to actually be able to work well together.

21:11 So that's.

21:12 That's what the book is. It just tells the same story I told you, but in a lot more detail.

21:16 And it outlines the disciplines and the procedures that we used at the time.

21:23 Robert: Something you just said sparked a totally different question on my mind, which is you talked about how it was a small idea for small teams doing small things.

21:31 Brad: Yeah.

21:31 Robert: And here's a tension that I feel a lot.

21:34 We're trying to be, on the one hand, you have just called the engineering team,

21:39 roughly speaking,

21:40 but that includes other people like designers and

21:41 Brad: product Yeah,

21:42 Robert: managers,

21:42 Brad: yeah

21:42 Robert: called the product development team.

21:44 They're wanting to be iterative and agile,

21:47 okay?

21:47 And then you have...

21:49 at least in the context i've worked which is within a company the business which wants to have some they want to have a roadmap they want to have a horizon of things that are going to happen and they want to know when they're going to happen and they want to know it and it's like those two things are at odds with each other of saying well let's just start programming and see what happens versus this is what we want to do for the next year or two or three have you what's your thoughts on that tension or how to reconcile those things

22:15 Thanks.

22:16 Brad: Have you ever been in a sales meeting?

22:19 CEOs sits there with all the sales guys and what does the CEO ask him?

22:23 What's the sales forecast,

22:25 guys? How is it all going to play out?

22:26 And they all give their estimates.

22:28 And then you turn around one quarter later and they're all completely different.

22:31 Right.

22:31 The job of managers is to manage that uncertainty.

22:35 And of course, they don't want the uncertainty. They'll do anything they can to avoid the uncertainty.

22:40 But it is their job to manage the uncertainty. That's why we have managers.

22:44 And the same is true in software.

22:46 So,

22:47 yes,

22:47 the managers in software want firm dates and they want firm specifications.

22:52 That doesn't mean they can get them.

22:54 And if you attempt to give them, you're lying.

23:00 Our industry has been punctuated with that kind of lying for decades,

23:05 right?

23:06 So some manager comes along and says,

23:08 okay, when's that module going to be done? We need it by next Tuesday.

23:12 And the developer says,

23:14 okay, I'll get it to you by next Tuesday. Well, they don't.

23:17 So that was a lie.

23:19 You know, and you know, and sometimes the developers will say, look, I can't get it by Tuesday. Maybe I could get it by the following Tuesday.

23:26 And then the managers, well,

23:27 will you at least try?

23:29 Which is a completely invalid question.

23:32 I mean, what is the guy doing? He's not trying.

23:34 What is he supposed to pull some magic beans out of his pocket and say, okay,

23:38 I'm going to try now.

23:40 I mean, it's almost insulting to say, will you at least.

23:43 at least try and yet that that kind of brow beating and that kind of imposition has an effect and you know developer says okay i'll try and the reason the developer says that is because he wants the manager to go away right he's telling a lie and he wants the manager to go away this is a big part of my message to developers right you never say you'll try you never give a date

24:08 You have a range of dates.

24:09 You make sure everybody understands it's always a probable variable, right? It's always an uncertain thing.

24:17 And then you put it back on the manager.

24:19 Manager, your job is to manage uncertainty.

24:21 And I'm giving you the amount of, I'm giving you the size of what I don't know.

24:25 So it could be two weeks, it could be three weeks, it's going to be somewhere in there.

24:29 Scott: I used to say, Bob,

24:32 if a developer gives you an estimate.

24:34 And in that estimate,

24:36 they use the phoneme two,

24:38 then they're just making it up. So they could say,

24:41 I'll get it to you tomorrow,

24:42 tomorrow,

24:43 I'll get it to you in two days, I'll get it to you in two weeks.

24:49 It's all just made up. And the giveaway is the phoneme two.

24:54 Brad: You asked a very fundamental question,

24:57 you know, how do you resolve the tension?

24:59 The answer is you don't.

25:01 There isn't any way to resolve the tension.

25:03 That is the tension of business.

25:05 And it's the tension of every facet of business.

25:08 Scott: And the reality is that waterfall doesn't solve this either,

25:12 right?

25:12 Brad: No,

25:13 Scott: This

25:13 Brad: we thought it did,

25:14 Scott: yeah,

25:14 this was the classic problem.

25:16 And I can't count the number of times that I've, I mean, less so now,

25:20 but, you know, you get maybe a non-technical executive who says,

25:25 I don't understand why.

25:28 the engineers can't give a better estimate right why are we doing this why are we doing this like uh two week sprints and we will see what we get at the end of the two week sprints and i think that that's the challenge that the reality is that these other heavyweight techniques that that claim

25:49 to provide certainty actually did not work like the track record those didn't also provide certainty right

25:55 Brad: No, no.

25:56 Scott: and

25:56 Brad: It's just that they delayed the knowledge of uncertainty until it was way too late.

26:00 Scott: which is even worse

26:01 Brad: Yeah,

26:01 Scott: which is even worse

26:02 Brad: even worse.

26:03 The great thing about Agile is that you know how screwed you are really early on.

26:08 The purpose of Agile

26:10 Robert: is the

26:10 Brad: to destroy hope.

26:11 Robert: I got to write that I mean the quotes of the purpose of Agile is to destroy hope

26:16 I have to write that down.

26:18 Scott: as early as possible okay so bob i'm gonna i'm gonna do a hard track here we've been talking about agile

26:27 And I'll do – I'll encant the AI.

26:31 Well,

26:32 I'll throw this out.

26:33 One of the movements that I see going on in AI – I feel like there is a classic battle of waterfall versus agile actually happening in the way that people are thinking about AI,

26:43 Brad: Yeah, yes,

26:44 Scott: right?

26:44 Brad: it is.

26:45 Yeah

26:45 Scott: And for example –

26:49 You know, there's a part there's a group there's a group of belligerents that are very adamant that we need very,

26:55 very high quality specifications up front and they have built tooling like spec kit and spec driven development and things like that before they hand it to the agents.

27:07 And then there's another group that I think are I'll call them a little bit more like the agile belligerents, but maybe we'll just call them like vibe coders where

27:15 Brad: Mm

27:16 Scott: they're

27:16 Brad: -hmm.

27:16 Scott: they're literally just just hitting the slot machine arm and just getting something random, seeing if they like it and then pulling it again.

27:24 And that's a pretty wide spectrum.

27:26 What say you,

27:28 Uncle Bob?

27:29 Where on

27:29 Brad: So, um...

27:30 Scott: the spectrum is there goodness and where in the spectrum is there pain and chaos just waiting to bite us?

27:38 Brad: So the lesson of agile still applies,

27:42 right?

27:42 The customer doesn't know what they want.

27:44 We don't really know how to give them what they want. We're going to have to move in little steps and validate at the end of each step and be able to course correct all the time. So that still applies,

27:56 which flies in the face of the big upfront plan.

27:58 So yes, you're right. There is a bunch of people out there saying the only way to deal with agents is to give them a great big spec up front.

28:04 front well that doesn't work right for the reasons that we just talked about on the other hand the vibe coding idea doesn't work either you cannot just sit and type at a at a an ai and said now do this now do that oh this is cool now do this because the ai will build um code upon code upon code upon code until it all collapses on itself and this is a problem we identified very early on in agile

28:29 Agile, right? Agile had three layers to it,

28:32 right?

28:33 There was the outlook.

28:36 disciplines,

28:37 the disciplines that looked out from the developers to the business.

28:41 And that was things like estimating and planning and continuous integration and so on.

28:47 And then there were the inner disciplines. These were the engineering disciplines,

28:51 test-driven development,

28:52 pair programming,

28:53 simple design.

28:54 They were extremely detailed and they altered the way a developer worked on a minute-by-minute basis.

29:01 It was a completely different way to work.

29:05 And that's what we're missing in the AI space,

29:09 it seems to me,

29:10 those interdisciplines. And that's where my focus has been the whole time.

29:14 How do we get these agents to be flexible enough to work in an agile way so that you can course correct quickly,

29:22 but also disciplined enough so that they're not piling slop upon slop upon slop?

29:27 up and building a tower to heaven that's going to collapse on itself and so a lot of the work I've been doing is along those lines trying to come up with a set of disciplines that the AIs themselves can follow not because of rules but because of tools tools that they must execute and and those tools tell them yes or no

29:51 And then the AIs have got to spin on those.

29:54 I've got to get the yes somehow.

29:56 And the yes is usually something like, I want my methods to be small.

30:02 I want there to be very little duplication. I want my modules to be under a certain size. I want the dependencies between modules to run in a certain direction.

30:13 All of the rules of architecture,

30:15 all of the rules of clean...

30:16 code and good and good design you can capture as a set of tools that the that the AIs will spin on and when they're done spinning you will have a reasonable approximation of good code of

30:34 Scott: I mean, those are all the same rules that you would apply to the human developers.

30:38 Brad: course of course except you can't

30:41 You can tell a human developer,

30:43 you know, keep your methods small.

30:45 If you tell an AI that they'll do that for the first 10 minutes and then they'll forget.

30:50 They just they cannot remember,

30:52 you know, the context window gets too big and it gets lost in the middle. And and the thing about AI agents is that they get super myopic.

31:02 They focus and they're really good at focusing.

31:06 But as they're focusing,

31:08 every other rule you ever told them just goes away.

31:12 Robert: Right.

31:13 Brad: If you let them, they will change tests that used to work just so that they can make the next thing work.

31:20 Robert: Yeah.

31:21 Brad: They will break features in order to make new features work.

31:24 They will do every horrible thing that can be done to code in pursuit of the current myopic goal.

31:31 And you've got to get them in the way of that and stop them from doing it.

31:34 Scott: Yeah.

31:35 Robert: Let me do that. Is that other agents getting in their way and looking at their work and giving them feedback

31:38 Brad: No,

31:39 Robert: is okay.

31:39 Brad: no tools,

31:40 deterministic tools,

31:42 programs

31:42 Robert: Okay.

31:42 Brad: that they can run that measure things.

31:45 Robert: Oh,

31:45 Brad: I

31:45 Robert: I see.

31:45 Brad: see.

31:46 Robert: So.

31:46 Brad: How much duplication is in this module,

31:48 right?

31:49 Get a module in there now to start looking at the lines of code and you can do that with a program. It's a real simple program.

31:55 Just look at look and find duplication.

31:57 eliminate the duplication the the agent is very good at eliminating duplication they're not good at finding it

32:04 Robert: So,

32:04 Brad: yes

32:04 Robert: for instance,

32:05 you would ask an agent to write some code and you would also say when you're done writing this code,

32:09 run these tools against what you wrote and ensure

32:11 Brad: yes

32:11 Robert: that it's essentially like a form of tests.

32:15 Brad: Yes, it's one of the tests,

32:16 right?

32:17 Robert: Yeah.

32:17 Scott: And a lot and these deterministic tools often are able to work essentially through static analysis of the code.

32:23 And therefore,

32:25 we know it's deterministic. We know that it will produce the same results every time it looks at the same section of code.

32:31 Brad: Yeah.

32:32 Scott: It's not it's not a it's not a token guessing approach. Right.

32:36 Which the LLMs are the transformers are it's deterministic.

32:40 Brad: Yeah, it's not stochastic. There's no probabilities involved,

32:43 right?

32:44 The tools are programs.

32:45 And I have the agents make the programs for me.

32:48 So

32:48 Robert: Yeah.

32:48 Brad: one of the metrics I really like is called CRAP.

32:51 And it was invented in 2007.

32:55 And there was a tool at the time called CRAP for J.

32:59 and for the Java environment.

33:02 And what it does is it measures cyclomatic complexity,

33:05 which is the number of pathways through a function.

33:08 And it combines that with the test coverage.

33:10 So it measures the test coverage of a function and it measures the cyclomatic complexity of the function.

33:16 And then it combines those two into a raw number.

33:21 And the number works like this. If you have 100% test coverage,

33:26 then your score is just the cyclomatic complexity.

33:30 If you don't have test coverage,

33:33 the score just skyrockets.

33:35 Right.

33:36 And I tell my so under the theory that a really complicated function that's not tested is really, really crappy.

33:44 Scott: Right.

33:44 Brad: So I have my agents bring that down to six.

33:48 No function can be above six.

33:50 Robert: Mm

33:51 Brad: And they're happy to write 12s and 20s and 84s, but then you run this tool and they're going,

33:57 oh, my God,

33:57 I got to get this. I got to get this down to six. And how do they do it? Well,

34:01 they've got to cover it. So they've got to write unit tests.

34:04 Scott: Yeah.

34:04 Brad: And then that's a writing unit test and they can bring it down a little bit, but it's still too big. Then they have to take the functions apart into a bunch of littler functions.

34:12 And this is all exactly what you want them to do.

34:15 Scott: And this is what you'd want a human developer to do as well.

34:17 Brad: Yes, you would.

34:19 But a human developer would do it more naturally, not under the whip of a tool.

34:26 The AIs need the whip.

34:28 Scott: Yeah.

34:28 Robert: Hmm

34:28 Scott: You kicked a hornet's nest on the Internet recently,

34:32 Bob,

34:33 when you were quoted as saying, or at least the way it's been repeated is,

34:40 I don't read the code anymore.

34:44 So,

34:44 Brad: Yeah, that's

34:45 Scott: yeah,

34:45 Brad: true.

34:46 Scott: so first of all, I'm curious to hear from you.

34:50 Why do you think that caused such a kerfuffle?

34:54 Why did that blow up the Internet?

34:57 Brad: Well,

34:57 there's a bunch of reasons.

34:59 Number one is if anybody's used an agent before.

35:02 And they look at the or just told ChatGPT to write code for them.

35:06 And then they look at the code and they're they're horror struck because a lot of times the code comes out really bad.

35:13 So if if that's what they're thinking,

35:17 if they're if they're thinking,

35:18 I'm just telling the agents to write code and I'm taking whatever the agents give me.

35:22 Well,

35:22 yeah, they should be horrified. They

35:24 Robert: Yeah.

35:24 Brad: should be horrified by that.

35:25 Then there's there's another faction.

35:28 And that faction is people who say,

35:30 my identity is writing code and you're telling me that that doesn't matter anymore.

35:39 Now, that's not what I'm telling them, but that's how they infer it.

35:43 Scott: Yeah.

35:43 Brad: And so they have there's this identity crisis.

35:46 And so they reject the idea.

35:48 No, no, we still have to look at the code. We still have to we are the owners of the code.

35:54 And I reject that.

35:57 I think, look,

35:57 these tools.

35:59 are so good, they're so productive,

36:03 there's got to be a way to take advantage of that productivity.

36:07 And the worst thing you could do would be to insert a human into the syntax loop,

36:13 because that's the thing we're bad at. We're bad at syntax,

36:17 right?

36:17 They're really good at syntax.

36:19 So let's get the agents to deal with the syntax problem,

36:24 and then we, the programmers,

36:26 can take one.

36:26 One step back, maybe a half a step.

36:29 Not much, but we don't have to look at the code.

36:33 We can look at the output of the tools.

36:36 We can look at the behavior of the system. We could look at the number of tests.

36:40 We can look at the coverage numbers.

36:42 We can also do very interesting things.

36:45 Agents are very good at introspection.

36:48 You can ask them questions about the structure of the code. And you can ask them leading questions.

36:56 And they can find nuance.

36:57 It's really cool to do this. And every once in a while, you have to kind of sit back and go,

37:02 holy shit, these things are really good.

37:05 Robert: Yeah.

37:05 Brad: And once you get them to focus,

37:08 they'll tell you what's wrong with the code they just wrote.

37:11 They will not apply that on their own, but they will tell you, oh, yeah,

37:15 these modules are too big.

37:16 And then you can direct them and you can say, OK,

37:19 you should split these apart.

37:21 I don't want the unit tests to be intimately connected to the code.

37:25 I want an API in between them. Oh,

37:27 yeah,

37:28 good idea. I'll put an API in there.

37:30 I don't want the I.O.

37:32 being called from the web page.

37:35 Oh,

37:36 yeah,

37:36 I can put up.

37:37 Scott: You

37:37 Brad: You know, all of those things that you and I would look at code and go, what the hell did the guy do that for?

37:44 You can still infer that and then direct the agents to do the right thing. So I like to pull back from the code a half a step.

37:55 I don't want to look at the code.

37:57 I don't want to look at the syntax because that'll slow everything down.

38:00 But I can still tell, you know, my spidey sense works.

38:03 I can still tell what's going on in there and then I can direct the agents to do the right things.

38:10 Robert: Yeah.

38:10 Brad: And that, so far, I mean, that has worked really well for me.

38:14 Robert: So you said something earlier that sometime in, say, the, well, it's early in your career,

38:19 I think maybe the late 70s, you switched from writing assembly to writing C.

38:24 Brad: Yes.

38:26 Robert: and one of the comments I've made sort of offhand to people in my world who are uncomfortable with not looking at the code, I said,

38:35 well,

38:35 you don't look at the assembly.

38:38 Right. You write code and don't look at the assembly.

38:40 Brad: Yep.

38:40 Robert: And I'm wondering,

38:41 and their response has been,

38:43 well, the difference between the code and the assembly is deterministic.

38:47 Right.

38:48 But,

38:48 Brad: No, it's not.

38:49 Robert: okay,

38:50 well,

38:50 Brad: I

38:50 Robert: this is what I wonder. I'm wondering if you've had this experience already that a lot of people are going through when you made the transition from writing assembly to writing C that others could learn from.

39:01 Brad: Oh, sure.

39:02 I mean...

39:03 But going from assembly to C,

39:05 you know, I wrote assembly for like 15 years.

39:10 Robert: Mm

39:10 Brad: So

39:10 Robert: -hmm.

39:10 Brad: I knew assembly language and I knew the machine and I knew that every bit in the machine,

39:15 I knew how it worked and how all the flags changed.

39:18 I knew the whole thing.

39:19 And then going to C,

39:21 you have to give that up.

39:23 This intimate knowledge of the machine,

39:25 you have to give up, you have to back away one little step and treat the language as if it's talking to some abstract machine that you sort of know how it works.

39:38 Enough so that you can get the program to do what you want,

39:42 but you've lost the intimate knowledge of the fact that there's this bit over there called the link that captures the overflow of the accumulator when you add too much stuff to it. All these funny little flags and address segments and all that stuff goes away. And so the...

39:59 Robert: The step up just to see is an abstraction.

40:03 And then you think,

40:04 well,

40:04 OK,

40:05 but it's deterministic. The compiler will generate deterministic code.

40:10 Will it really?

40:11 I mean, if it's deterministic, then the code it generated should be the same between different versions of the compiler.

40:18 But

40:18 Brad: Right.

40:19 Robert: that's not true.

40:19 And it should be the same if you run the compiler on a different operating system.

40:24 But that's not true.

40:25 Brad: Yeah.

40:26 Robert: Yeah.

40:26 Brad: And how many times have you seen a bug where a compiler bug or a compiler quirk where the exact same section of C code.

40:35 In a different place in the program produces completely different machine code and

40:40 Robert: And doesn't work.

40:41 Brad: doesn't work. Right.

40:42 Robert: Yeah.

40:42 Brad: It has exactly.

40:43 Robert: Yeah. Yeah. Oh, yeah. Sure. That happens. It's rare nowadays.

40:46 It was much more much more prevalent in the 70s.

40:49 Right.

40:50 So I actually in the very early days of my C career,

40:54 I would look at the assembly language that it produced and I was so horrified by it that I wrote.

41:00 There are programs that would correct the assembly language that was coming out of the compiler.

41:04 Brad: Right.

41:05 This is the point that I think the people that are sort of like saying like I can't trust the AI to write code when I look at it, the code is horrifying.

41:12 You just said it, Bob.

41:14 You used to look at the assembly code the C compiler would generate and you were horrified by it because you would have written the assembly code differently.

41:23 Robert: So I wrote a tool.

41:24 Brad: Yeah.

41:24 Robert: Interesting. I wrote a deterministic tool that would correct that problem,

41:27 just what I'm doing now.

41:28 History repeats itself.

41:30 This attitude is extremely old.

41:33 When Grace Hopper,

41:35 this is like 1952.

41:38 Grace Hopper decides that writing in binary is a really bad idea.

41:42 And wouldn't it be nice if we could have a slightly more abstract language, which she called a compiler.

41:50 And she called the idea of a compiler automatic programming.

41:54 Now, these compilers were impossibly primitive,

41:57 more primitive than even an assembly language.

42:00 It was just one tiny little step up above binary.

42:03 And the programmers at the time felt challenged and they rejected the idea.

42:09 Who's going to do,

42:10 I mean, we're the ones writing the code and now that thing's going to write the code?

42:13 What good are we?

42:16 Yeah.

42:16 And that has happened at every stage.

42:18 That happened during the OO revolution.

42:21 It happened during the Java revolution.

42:23 At every stage it happens.

42:25 There's a group of people who feel that they will be disenfranchised. Now they won't be,

42:31 but they feel that way because this skill that they have developed over a period of months or years is now looking like it's being devalued.

42:40 It's not,

42:41 but that's how it feels.

42:43 Yeah,

42:44 even setting the emotional and the identity part of it aside,

42:47 what I've learned here today amongst many things is there's a pattern we can follow, which you followed when you were moving from assembly to C and you talked about tools and deterministic evaluation of this stuff. And that's the same pattern we can follow today as we're abstracting one more level up, right? And then another 50 years when the world abstracts.

43:07 tracks another level up,

43:08 it's probably the same pattern we can follow again to make this work.

43:13 I had not anticipated this level.

43:16 As recently as two years ago, I was writing articles saying that we had plateaued.

43:22 There were going to be no new languages that were meaningful.

43:25 We explored the language space.

43:28 The processors weren't getting any faster.

43:30 The clock rates had plateaued out.

43:33 And that programmers in the future were going to be living on this plateau.

43:37 You know, I went up the roller coaster. I went up the exponential curve,

43:41 but the programmers from now on are going to be living on the plateau. I can't imagine how wrong I was. I did not anticipate this AI thing coming along.

43:51 And I started to smell it about a year ago.

43:56 And even then, I was not convinced.

43:57 I thought, no,

43:58 this is just, you know, this is horrible.

44:00 I ran a few experiments.

44:02 You know, I had I had a chat GPT. I told chat GPT to write a C program that would compute the 128th digit of pi and it went out in Java and it went out and it got math dot pi and it.

44:17 turn it into a string and got the 128 like okay you're missing something there dude i mean

44:26 Brad: that's fantastic

44:27 Robert: but

44:27 it

44:27 Brad: you

44:27 Robert: it

44:28 did

44:28 then

44:28 exactly

44:28 it

44:28 what you asked

44:29 Brad: did exactly what you asked right you probably said did you did you say calculate pi or did you say print the digits of pi out to 100

44:37 Robert: know i don't remember

44:41 Brad: That

44:41 Robert: Okay,

44:41 Brad: sounds like a lot of

44:42 Robert: but

44:42 Brad: it.

44:42 Robert: since about January and with the advent of the agents.

44:49 And some of the better models,

44:51 the early Grok model,

44:52 the early Claude model,

44:55 the early codex model,

44:57 these things have started to get pretty impressive.

45:00 And in the last couple of months, I mean, gee many Christmas,

45:04 the stuff that you can ask them to do,

45:06 the abstract way that you can communicate with them and still be precise enough to watch them work and correct them.

45:15 them as they go off off into never neverland it's just astounding it's amazing to me that we've we've gone this far and now it looks to me like the the whole sky is open sky's the limit here there's there's stuff that we're going to be doing in the next 20 years that we can't even think of right now it's like holy cow we're not on a plateau man

45:37 Well, let's ask that question in reverse.

45:40 When you were writing the article about being in the plateau a couple of years ago,

45:45 what

45:45 Yeah

45:46 were the things that were true at the edge of the plateau that weren't true when you started writing C in the late 70s? We might be able to learn where this AI is going if we say in 1977 we didn't think X was going to be true and look what happened and we thought there was a plateau there.

46:04 Well, actually,

46:05 I don't know if this is right or not, but clearly the online piece is something we didn't predict,

46:09 but I don't think that's actually the right space.

46:10 It's more like in the actual programming space,

46:13 I think, is where the question would be.

46:15 There were lots of hints about the online space,

46:18 even in the 60s.

46:20 IBM was on top of that really early on. They had the 3270 screens,

46:26 the green screens.

46:27 They had already invented an HTML-like.

46:30 unique language.

46:31 They'd already invented the distributed processing and the browser and server kind of model.

46:37 All of that had been done, but it was so vastly expensive that everybody kind of ignored it except for IBM and the people who could pay, you know, several million dollars for a system like that.

46:48 But the hints were there.

46:51 And the hints were there, even going from assembly language to C,

46:55 right?

46:56 It was easy to say, you know, it's going to get better than C.

46:59 And, you know, C++ came along just a few years later.

47:03 And when C++ came along,

47:05 you know, it was easy to see, you know, it's going to get better than C++.

47:08 Don't know how,

47:09 but it probably will.

47:10 And then Java comes along and people said,

47:12 well, that's not better.

47:13 And there's things about it that are better and things that aren't, but okay.

47:17 And then, you know, Ruby comes along and Closure comes along and Python comes along and you're OK,

47:23 yeah, we can see that's kind of a natural progression.

47:27 This is not a natural progression.

47:29 There was no way, at least for me,

47:31 there was no way for me to look at the state of the industry two years ago and predict this.

47:38 Now, other people were,

47:40 but I had no clue.

47:42 No, no, none at all.

47:44 In fact, I used to give lectures at the time and the lectures were there will never be a self-driving car.

47:50 I now own a self-driving car.

47:52 Brad: Yeah.

47:54 Robert: OK,

47:55 I was wrong about that one.

47:56 I could not foresee this one.

47:59 And it just came down the railroad tracks like a freight train.

48:04 Boy,

48:05 is it going fast right now.

48:06 It's

48:06 Brad: Yeah,

48:06 Robert: very exciting.

48:07 Brad: yeah, yeah.

48:09 And I think that I think that the breakthrough that that really happened in the last couple of years was just this this idea that we knew that transformers were really good at essentially generating a string of tokens,

48:24 basically predicting tokens.

48:25 That's like.

48:26 That's like transformers are fantastic at that.

48:28 And then the only question was how big how big the essentially the how big you could how many how many parameters you could get into it.

48:38 Robert: Yeah,

48:38 Brad: Right.

48:38 Robert: yeah,

48:38 Brad: And so

48:39 Robert: yeah, yeah.

48:39 Brad: the hyper the whole notion of the hyper scaling of like,

48:42 let's just get these to, you know, billions and billions of of of parameters in in the in the transformer that that seems to be the breakthrough that really.

48:52 Like all of a sudden.

48:54 The scale got to a point where now the things that come out of it can be really quite amazing.

49:00 Robert: You know, I was yesterday just looking at my website. Is this website's terrible?

49:05 And I used to maintain it by hand. It was written in closure and I would write the closure code and OK,

49:11 it would take me a day and I would do some stuff.

49:14 And I pointed my agent to it and I said, look at the repository of my website. And it came back like in.

49:20 five five seconds and said okay i understand that pretty straightforward you know okay and then i said okay now here over here are the scripts i use to deploy it and and it looked at that and said okay yeah i get that all right

49:33 What I want you to do now is get a thumbnail of all the books I've ever published and put them in a grid on my website.

49:40 Okay,

49:41 I'll do that. And then it deployed it and it's up on my screen.

49:46 And all of a sudden I'm in this mode.

49:49 that I'm very very used to but not on a website not on my website which is looking at the website I don't like that and it's back and oh I like that a lot better okay well okay now go out and get every tweet where I used the word morning bathrobe rant okay put them on the list it's all up and this is like you know two minutes

50:13 Two minutes, and all there's a list on my website of all my bathrobe brands.

50:18 Brad: Yeah.

50:18 Robert: And it searched the X place and found them all but links up there.

50:24 And it figured out how to do the deployment and it figured out how to modify the website stuff that it had never seen before.

50:32 I just pointed it at it. And the power of that is just so enormous.

50:37 Why in the world would anybody want to bog that down by staring at syntax?

50:43 Well, isn't that, I mean, to bring this full circle,

50:46 isn't that bring the promise of agile development true?

50:51 You were able to say to the agent, do this thing a few minutes later,

50:54 look at it and say,

50:55 hmm,

50:55 it's not exactly how I wanted it.

50:57 Could you adjust it this way?

50:59 Absolutely.

50:59 Right.

51:00 I think what happens to agile is that the, you know, we had iterations of two weeks and then some people said,

51:06 well,

51:06 we do one week. I think iterations are one hour now.

51:09 Brad: Ha!

51:09 Robert: Right.

51:09 Brad: And that's literally what you just said, Scott,

51:12 like last week.

51:13 You're like.

51:14 Robert: Well,

51:15 I've been trying through hook and crook to get our product managers and designers to actually sit down at the computer with the engineer.

51:26 to do the coding meaning the prompting just

51:29 The prompting, yeah.

51:30 just to do it right there and when when they do it it works and they like it a lot and it cuts out it cuts out a product manager writing a document and a designer writing you know sometimes the mock-up's useful because you can just feed the mock-up to the AI too but like it just cuts out a lot of these steps where you where you um you know lose understanding right and you

51:52 Because even if the people are there and they can just have an extremely high fidelity conversation with each other about what they want and,

51:58 Brad: Yeah.

51:59 Robert: you know, goes back to the pair programming stuff. It's like pair programming in a different way almost.

52:06 And I kind of to me, I kind of think that's the way it's going to go.

52:12 pass to go

52:12 Oh, I'm certain it is.

52:14 Brad: Yeah,

52:15 I've told you this story before,

52:17 Scott,

52:17 but I'll tell it for Bob's benefit.

52:19 One of the fractional CTO clients that I work with,

52:22 the team is a super high performance engineering team.

52:25 They were already,

52:26 before AI came on,

52:27 they were very high quality engineering. They had all these great quality,

52:31 all these automated quality gates,

52:32 really great layers of CICD where they could.

52:37 You know, like obviously developers had their local environments working,

52:40 they had ephemeral environments that would spin up every time a PR was made,

52:45 you know, they had staging, they had production,

52:47 they had all this automated gates.

52:49 And then once AI became practical,

52:53 they just like.

52:55 They just started accelerating,

52:57 you know, beyond scope that I could imagine, you know, like the thought experiment I like to say to people is imagine you hire a developer on day one of their job, they give you a 3000 line pull request,

53:09 right?

53:10 And you say, Oh,

53:11 I've got danger rules that don't let you have more than a 200 line PR.

53:14 And I was like, great.

53:15 So they give you 15 PRs of 200 lines,

53:18 you know, but the reality is you

53:20 You can easily start you and I challenge the teams to say like what you you can no longer read that code. You can know your old processes aren't going to work for you. So what processes are you going to have instead?

53:32 And the answer is, as you've been saying,

53:35 Bob,

53:35 it's tools. It's like get the tools that basically have the quality gates that are important to you that.

53:42 No,

53:43 you shall not pass unless this quality gate is met.

53:46 Robert: The agents will build those tools and they'll build them in an hour,

53:49 Brad: right? Yeah.

53:50 And the thing that's interesting is, so then in one of these teams,

53:55 the other thing I see people like panic is,

53:58 oh, if you've got production software,

53:59 you can't let non-developers write code for your production software.

54:03 Well,

54:03 this team, the CEO,

54:06 who has been a technologist, but is not a computer scientist.

54:09 computer scientist never classically trained.

54:11 In fact, I believe he's classically trained in music, right?

54:16 He's now writing code.

54:19 He's now building features that ship into production just as quickly as the developers because he's got all these quality gates that force whatever his agents generate.

54:31 It meets the same quality bar that the true developers on the team would have also generated.

54:37 I'm absolutely convinced that if you've got great quality gates,

54:43 and I love the ideas that you're bringing up, Bob,

54:46 about the tools like crap and things like that, those are even better layers.

54:51 But if you've got those great quality gates,

54:53 you really can.

54:55 Anybody can become a coder, right?

55:01 In the original sense of that,

55:03 I have an idea and I want to see the machine implement it.

55:07 Robert: So that's true.

55:08 There are insights that only an experienced developer can have when things start to go squirrely.

55:17 Brad: Yeah,

55:18 that's fair.

55:18 Robert: Right. So there's nothing wrong with the CEO or whoever he is typing prompts and getting features up.

55:25 But the guys who've been around the block a few times when they're watching the agents,

55:30 they'll start to smell things going wrong and nobody else is going to smell that.

55:36 And then you have to get in there and kind of say to the agents,

55:39 OK,

55:39 you know, move this over here,

55:40 move that over there. Don't do that thing you just did.

55:43 And that's fairly important still.

55:46 That may go away as the years go by.

55:50 Brad: Yeah.

55:51 Robert: The agents may get smart enough right now that they still do fairly dumb things that could be invisible.

55:59 And the tools don't catch.

56:01 Brad: That's fair.

56:02 I also think, by the way, this pulls on the thread that I think other people are asking,

56:08 which is how do we teach the junior engineers?

56:12 How do we teach them how to have that sense of smell,

56:16 that sense of code smell,

56:17 bad smells?

56:19 How do we teach them that?

56:21 I'm convinced that the answer I give is build as much as you can.

56:25 And

56:25 Robert: Yep.

56:25 Brad: use the agents to build stuff.

56:27 That's fine.

56:28 But read the code.

56:29 Don't don't be like Uncle Bob.

56:31 Read the code. And when you don't understand why the agent wrote the code that way, ask the agent why they wrote the code that way.

56:37 Right.

56:38 Like and I tell people like this is how I learned to program.

56:41 I read the code of other developers and I asked them to explain it to me.

56:45 And then I wrote code and had them critique it and asked them to explain their critiques to me, you know, and I think you can still do that even in a world where maybe the actual syntax to your point, Bob,

56:57 has been written by the agent.

56:59 Be curious about it and interrogate it.

57:03 Everything.

57:04 Interrogate everything.

57:05 Robert: And interrogation is a really good approach with the agents because they're very good at responding to interrogation.

57:11 The issue of how do you train new people coming into the industry is an important one.

57:18 And I don't know the answer to this.

57:20 One of the ideas I tried to promote a while ago was bring a guy in from school.

57:30 Um,

57:30 and treat them like an agent,

57:32 you know, give them tasks,

57:35 let them, let them do it, treat them just like an agent, run the tools on them, right? Okay,

57:40 you've written that code.

57:41 All right, now I'm going to run these tools on you and have him play all the different roles that the agents play.

57:47 Right. So there's a coder agent who writes the code.

57:49 There's a cleaner agent who cleans up the code.

57:52 There's an architect agent that restructures the code. Have him play all those roles over the course of, I don't know, a few months.

58:01 And that that might provide the insights that are necessary.

58:06 But I think it's going to be a really interesting problem,

58:09 an interesting issue over the next five years.

58:12 How do you bring new people into this industry and have them develop the insights that are going to be necessary to guide these agents who will,

58:22 without those insights,

58:23 run ripshot over you, run roughshot over you.

58:26 I don't think the industry is ready to adopt what I'm about to suggest,

58:31 but I actually think

58:33 the right model is more an apprenticeship model so recently we just did some work on our house and the company that did the work like there's three generations of carpenters that work on this there's there's the guy who taught the second group of guys who are now teaching the young guys there

58:53 Yep

58:54 was no book that was going to teach the young guys how to do it they just got to experience it doing it with the

59:01 you know they're I guess what's the the craftsman I guess there's an apprentice in the craftsman right kind of supervising and teaching and providing feedback and I don't think like from an industrial perspective industrial programming like it's not really prepared to have that happen but that's the only way I can see it working and which is really it's kind of just a flavor of pair programming if you think about it just pairing working with other people

59:23 It's an idea that's been circulated quite a bit over the last 20 years, the master journeyman apprentice model,

59:30 where you bring in apprentices,

59:33 they don't know anything,

59:34 you have a journeyman who's been there for two years, teach the apprentice,

59:39 and then the master supervises the journeyman. It's been around, there's a number of companies that have adopted that model.

59:46 Mm-hmm.

59:46 in order to train people and it works very well but it's expensive right because these guys don't hit the ground running if you're doing a consulting company for example you don't let the apprentices write code for customers

60:00 You just don't.

60:01 And the journeyman can do that.

60:03 And then the apprentices are doing internal work and exercises and things.

60:07 But it does produce the insights you're after.

60:13 It's just a very expensive model.

60:15 I think you're right in that that's a viable approach and it might be the approach we have to adopt.

60:23 Brad: Yeah

60:24 Robert: It's going to take some real change of mindset and change of heart from the biggest companies in our industry to start doing it that way.

60:31 This AI stuff ought to be changing an awful lot of minds.

60:35 It's true. It's true.

60:36 Scott: Yeah.

60:37 Robert: There

60:38 Well,

60:38 you go.

60:38 should we end on that,

60:39 Brad?

60:39 Yeah,

60:40 let's

60:40 It's the

60:40 end on

60:40 quote of

60:40 that.

60:41 the day.

60:41 This AI stuff ought to be changing an awful lot of minds is a good quote to end on.

60:46 Yeah.

60:47 Well,

60:47 thanks a lot for taking time,

60:50 Bob.

60:50 Oh, my pleasure.

60:51 It

60:51 My

60:51 was an

60:52 pleasure.

60:52 enjoyable conversation and I'll continue to be part of the crowd that says you're misunderstanding what Bob says when he says he's not reading the code anymore.

61:02 All right.

61:04 And yeah,

61:05 it was a pleasure meeting you.

61:06 Likewise.

61:06 Good to meet you guys too.

61:08 Awesome.

61:08 All right.

61:08 And what do we say, Scott,

61:10 to all our 60 listeners out there?

61:12 Smash that subscribe button,

61:14 rate and review,

61:15 tell all your friends, including your mom.

61:17 All right.

61:18 See you next week, Scott.

61:20 Bye,

61:20 Nice

61:20 mom.

61:20 to meet you, bob.

61:22 Bye-bye.

61:22 This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Hapta Gal.

61:28 Our theme song was AI generated by Brad.

61:32 Please follow us on all the social media platforms at HowManyCTOsPod.

61:37 You can find us on YouTube,

61:39 LinkedIn,

61:40 Instagram,

61:40 Facebook,

61:41 Threads, X,

61:42 TikTok,

61:42 and Patreon or at our website at HowManyCTOsPod.com.

61:47 And remember to rate, review, and subscribe on the podcast platform of your choice.

61:51 Thanks for listening.