Oxide and Friends 2/2/2026 -- Software Engineering Past, Present, and Future with Grady Booch

10,614 words · about 42 min to read

0:00 Oh, there's another Grady with Did you hear the other Grady with hands up?

0:04 I just let I just let anyone named Grady join the stage. Noted for all the all the listeners. Exactly. Kind of an I'm Spartacus moment.

0:14 You hear me now?

0:15 We hear you now. Yes.

0:17 Right.

0:18 Uh welcome. It is It is great to have you here. Um, Grady, you know, I uh Pier Leand is a is a famous uh venture capitalist and I uh was an investor in Oxide and I made the mistake when I first met him of saying it was an honor to meet a legend and he he informed me that legends are dead and uh it was like literally my I was like, "Okay, this is off to a very very bad start." So, I am not going to call you a legend because I don't want to offend you, but I do view you should know that I I I do view you as legendary. So, hopefully that's I I know I'm on a knife edge here, but hopefully that's okay.

0:56 You're a most kind. I've been called many things.

1:01 Well, you are certainly a software engineering pioneer. Um, and you have seen a lot. And I have to tell you, I was I just getting to prepare for this conversation, I had pulled what I thought was a recent conversation. And as I was listening to it, I'm like, "Wow, this is like this is um kind of like there's kind of surprising that he's not tacking harder into deep learning given that it was in 2024." And then I look, I'm like, "Oh my god, it was in 2014 and this conversation you had in 2014, I have to tell you, is aging very, very well." you had a so uh because you've been you've been involved in uh you were talking about working with the Watson team um and kind of understanding what Watson had done at IBM. Um but of course your history is a lot deeper than that. Um you were uh I mean you go back to the you kind of came up as software engineering was coming up. I was going to ask if your degree

2:04 was in computer science or cuz you were at the Air Force Academy or was your

Building early computers and learning FORTRAN in the 1960s

2:07 degree in cuz it almost predates certainly it predates Adam it predates the computer science department at our alma mater. Um Grey, would you mind taking us all the way back to your undergrad years and and then your kind of your first encounters with software?

2:23 So let's go way back in time. I built my

1 Highlight · Building a computer and writing FORTRAN as a teenager

2:26 first computer when I was 12. So we're talking, you know, mid60s. Why did I do that? Well, I was a voracious reader then, still am now, and I remember going to the library one day and finding this book called Computer Design, which is basically a hardware book, and it described, you know, here's how mainframe computers were being built. I was I was immediately taken by it. And I said to myself, I need to build me one of these.

2:50 Well, obviously in the mid60s, there weren't a lot of things around, not even integrated circuits.

2:56 Yeah.

2:56 Right. So I I I did a self-study and then realized I could build these myself from individual transistors. And so my first computer today we call it more of a calculator with extended memory. I built around that age. I thought hardware was pretty cool but then I realized software is where it is at. Sorry. You So you built your own computer out of discrete logic as a as a teenager only because because the integrated circuit had really not yet been invented or microp processors certainly had not been invented. I just want to I'm just playing that back to you just so I can polish my own sense of inadequacy. Is that is is that correct?

3:33 He's more of a software guy, Brian, remember?

3:35 Exactly. That's right.

3:37 That is correct. I I could probably, you know, put a blindfold on and build a flip-flop from you out of four transistors, but that's another part of my life. Um, I decided software was where I was at. So, here I was by that time 13, 14, the summer thereof.

3:53 So, living in Emerald, Texas, small town of 150,000 people, I went and knocked on the door of everybody that had a computer. Of course, this was the time when IBM was the dominant manufacturer at the time. And obviously nobody was going to hire a kid. But I knocked on the door of the IBM sales office. There's a sales guy that took me in. He nodded politely and then handed me a manual, a 4R manual and said, "Go read this and come back to me." I expect he never imagined I would come back, but there I was the next week and I said, "I have written a program. I would like to run it." He was a little bit gobsmacked.

4:30 The program of course was your typical hello world problem. I was also into physics at the time and had written a program in forran to model the movement of two uh neutrons moving toward one another at increasing speeds of light or close close to the speed of light and calculating what the release of energy was. So that's was my first program. I still have the punch cards for it by the way. The guy took me

4:52 that's a that's a long way from scratch or whatever the uh the kind of the modern equivalent is. That's that's very

4:58 uh that's what

4:59 Adam [clears throat] you ever been to Amarillo? Do you

5:01 I don't know that I have. Okay. So, am I mean I mean Amarillo is the is uh I mean desolate, right? I mean great. It's fair to say Amarillo is like you've got the you are in the Texas panhandle

5:14 and I mean you are a long way from other things. Um it's remote and

5:20 it's the helium capital. Yeah. Helium capital of the world. Uh our main claim to fame is that it's home to the Pantex plant which is the place where nuclear triggers are assembled and disassembled. So, it's kind of a fascinating place.

5:33 So, anyway, I wrote the program. He got me time on the weekends on public services computer, which was an IBM 1130 computer if I'm not mistaken. And he said, "Go to it." I taught myself how to punch cards. I taught myself debugging. And there we have it. Around that time, I decided, you know, what do I want to do next? And so, I was deeply into software at Forran at the time. We're going to come back to the story of the the manual in a minute, but uh I then said, what are my two loves? Computers and space. And the great place to do that at the time was of course the Air Force Academy because they had an astrophysics program, bring me into space. They had a burgeoning computer science program and really one of the few undergraduate programs at the time.

6:18 So I went there and I got my degree, a bachelor of science in computer science. There was no such thing as computer science at the time, but it was a bachelor of science.

6:28 My first assignment after I graduated was at Vandenberg Air Force Base. So my dream come true. There I was literally in space command before the orange cockwamble called it that. So here I was in space dealing with I Gosh, I I unveiled my political bet, didn't I?

6:47 You're all good. You're I feel we need a separate time for it. So this is all good.

Learning complex systems engineering in the military

6:51 Yeah. So, so there I became a project engineer and then a project manager. And the fascinating thing about this time and I'll give you a hint for some of the things I'm up to now. I'm working on a documentary about computing and its intersection intersection with what it means to be human. Imagine Carl Sean's Cosmos about computing. And I'm convinced that I'm convinced that one of the things one of the major influences upon modern computing is how it evolved from World War II and the Cold War or the phrase I use is much of modern computing has been woven on a loom of sorrow. And so in that time the largest and most complex systems were not being built by industry. They were being built by the military. We were building distributed systems that were fusing together 40 different radar in real time around the world. And this was hard stuff. Hard then still is a bit hard now. So I really cut my, you know, I learned a lot about how to deal with large complex systems from day one. I then got involved in the ADA program

7:52 because here we were in the midst of the software crisis and as it was called the NATO conference.

7:57 Yeah. Could you describe the software crisis a little bit because I think that this is a I mean the year now is we're in the very early 80s maybe late 70s. What what is the

8:07 We're in the mid70s. Mid to late 70s.

8:09 '7s. Mid70s. Okay. Yeah.

8:10 So, the the question I would ask all of your listeners is remember what year you got your first email address. Think through the answer. I got mine in 1979 when it was still the ARPANET. And at the time, we had a little book that listed the it was about maybe 100 pages that listed the email address of everybody in the world. Very cool to have. So I was on the ARPANET from the beginning.

8:36 Wow.

8:36 Yeah. Yeah. So um anyway uh I was called into be involved with the ADA program because of the so-called software crisis as it was named in the big NATO conference around the time. Remember height of the cold war uh there was a system called Sage the semi-automatic ground environment which is so much the predecessor of modern computing large distributed system. It's the first place where we had CRT displays as opposed to just terminals or just opposed to teletypes. It's that was a successor to the whirlwind computer out of MIT. And so we were dealing with human computer interface kind of things. That work was taken into the Sage system. And this becomes important because there's a woman that worked on Sage. Her name is Margaret Hamilton. and she is the one who in the 70s coined the term software engineering to distinguish herself from the hardware engineers were around the time. She went on to work from Sage to be the main engineer for the Apollo 11 ground system and indeed was the person you probably seen pictures of it uh

9:37 primarily responsible for writing the code for the lunar lunar lander. Anyway, what's a software crisis? The problem here is that you had tremendous demand for software and yet the inability to build it quickly enough, reliably enough, etc. The Sage project consumed perhaps 30% according to some reports of all of the software engineers in the United States. Huge, huge project and we

Turning down Bill Gates and shaping software design

10:03 learned a great deal from it.

10:05 I'll jump ahead because I don't want to spend all the time in my history. I want to talk about some things of course. Yeah. Yeah. Right. So, so we we then after I left for the Air Force Academy, uh, started up Rational Software with two of my classmates in 1982. We were bought by IBM in 2003. And I'm going to put a bookmark there and tell you a Bill Gates story in a moment. And then uh, the rest is history. The last six years, I've been working with a set of neuroscientists to better understand the architecture of the brain. And you referred back to something in 2014ish.

10:37 That was probably the TED talk of which I spoke. I was I was I was annoyed. I was Yeah, I was annoyed at the book that Boston wrote and said, "This sucks." And Elon, you're adult. U Bill, you're adult, too. Let me tell you what I think. So, there we go.

10:54 Uh yeah, it was actually the It was on the Singularity podcast was

11:00 I did listen to the TED talk. I gotta say whenever I listen to a TED talk I remind myself why I find TED talks as a format to be annoying the your TED talk great. Yeah. I always feel like oh god I feel like I I want to go listen to the speaker for another you know outside of the 45 seconds they've been allotted. Um so

11:17 yeah Ray and I got into it. I thought his ideas of the singularity well the the singularity's main value is it allows you to make clickbait articles and sell books. I think there's no substance in it whatsoever by any means. Um, let me quickly tell you a Bill Gates story since you're hearing a bit of my history. 2003, we were bought by IBM. Bill Microsoft had been bidding on us.

2 Highlight · Turning down Microsoft's chief architect offer from Bill Gates

11:39 Uh, couple months after we we finished the deal, got a call, "Hey, Grady, it's Bill. Come see me." So, I flew up to Seattle. I'd done some things with him before. Sat me down in his office and said, "You know, I this is not public yet because we're talking what, 2003, but I'm going to retire from Microsoft. And you know, Grady, I have two jobs. I'm CEO and I'm chief architect of Microsoft. I would like to give you the job of chief architect. I said, "Bill, that's really that's really interesting.

12:05 Let me think about it." For a couple of months, I went back and forth spending time with these tenants. And I came back to him and said, "Bill, I'm profoundly flattered, but you know, you have a very dysfunctional company, and I'm not the person to fix it." So, if I said yes, it would only end in tears. And so, I said no, and then continued on with IBM, and I'm happy that I did.

12:26 Yeah. Uh, yeah. I I cuz I mean and you only end in tears. It would have been like some it could have been your tears that it could have ended in. We were just like this is just too Yeah. Right.

12:34 It would have been a waste waste of my time. I'm I'm a lover not a fighter. They needed to have somebody they needed to have somebody come in and knock heads and I'm not that kind of person. So I've been very happy in research the last several years doing what I'm doing. And it should be said just along the way and I know I don't want to necessarily dwell on the history but I do think it's a it's gerine for kind of what I want to talk about in terms of the future of software

12:55 engineering that along the way as you were trying to navigate the the the crisis the software crisis of the late '7s early ' 80s uh you really were trying to to find ways for people to kind of uplevel the craft of software engineering. you were obviously uh in terms of modeling systems, UML was was your your co-bab um certainly what a claim to fame. Um you developed um when I when I where I came to know you cuz I kind of came up in the '90s. Um I uh my first internet my first email address very much as an undergraduate in in 1992. Uh I think they had just they had just gone to straight internet instead of having both internet and bitnet.

13:38 Right.

13:38 Yep. Right. Harponet. Yep.

13:40 Right. Exactly.

13:41 And then Miln net. Yeah.

13:43 Um but um I remember you for the boot components um which were the the uh the kind of uh I would call before the C++ standard templates library. These were the kind of the components that were a demonstration of an embodiment of of how to use object-oriented design. And so you kind of you saw software navigate this crisis of like oh my god we don't know how to and I think it was still when I was coming up it still felt like software was in that crisis.

14:09 Still is.

14:11 Yeah. Yeah. So then I mean I think the thing that is I mean to to I guess kind of fast forward here I mean you've seen a lot of revolutions. you were I you know early in on agile uh you and you saw that that revolution run its course one way or the other I guess I be interested to get your take on that um and then now we're in this like crazy world and do you feel like is this the world that like yes this is the world that I saw a decade ago this world makes sense or or is this because it feels to me like we are on I mean it's it's delightful but bizarre is kind of my

Software engineering as an engineering discipline of rising abstractions

14:49 take on are are the where we are currently, but I would love to get your take on it. Obviously,

14:54 I would say that every age of software has been crazy and bizarre and wonderful simultaneously.

15:01 The rise of the internet, the rise of the personal computer, the rise of the mobile device, the rise of the cloud, every one of these represent points in time and points in change in the industry. And every one of them, interestingly, has reacted in very similar ways to what's happening here. I have a lot of people coming up to me saying, "Oh go my gosh, Grady, I have this existential crisis. My career is over. It's going to be replaced by computers." And I observe to them is that no, be calm. Take a deep breath.

15:32 The entire history of software engineering is one of rising levels of abstraction. And let me explain why that's the case. Because you're right, I've been around this business for a while. I met Grace Hopper. I met uh I still have the nancond she gave me. If you don't know the story I'm referring to, go Google Grace Hopper and David Letterman and there's this wonderful scene with her. Um, I've also I didn't meet Alan Turring, but I because he was dead by then, but when I was doing some work at the University of Manchester and and at Bletchley, I met some of the people who worked with Turing. So, I'm an old fart if you want to get down to it. I even Oh, here here's a fun other funny story. Uh Jay Presper Eert I met as well because I taught his grandson at the Air Force Academy. So yeah, while I told him

16:19 Per Eard. Wow.

16:21 So that that dates things. Anyway, so

16:24 yeah, that's I mean I feel like you you're like did you have any connection to Charles Babage? I mean this is like you're really turning that that's very impressive. Oh my god. Wow.

16:32 Charles was long gone by then. Uh the story with back to forran the quick one is remember that manual I said yeah it's part of the I was on the board of trustees for the computer history museum for about a decade and I did a number of oral histories for folks one of those I did with was with was with with John Bakus so I went out to visit him his wife had just died very sad story he actually died a few months later I think of a broken heart so I took that book with him and I explained the story and I've got a signature from John as well

16:58 anyway let's go back let's go back in time

17:01 um

17:02 ultimately you Why do we have solver engineering? And I mentioned Margaret. What was what was she trying to deal with? Engineering. I think we can legitimately calls our call ourselves an engineer because we are the ones who take various static and dynamic forces and try to build reasonably optimal solutions that tend to those. And when I say reasonably optimal, it deals with economic issues, legal issues, all these kinds of things. So it's not just the technology, it's the social and economic context in which they are born. This is true now. It is true as it was from the very beginning days of software.

17:37 Yeah. And I agree, this is an extremely important point because this may less this seem obvious to those younger. there was a I I feel a protracted period of time where software was really having to fight for its own legitimacy constantly hearing you're not actually engineering and we get you know always being referred to to you it's always the civil engineers that are like you know like it's always the bridge building and the and one of one of the things I learned about bridge building is that when you you build a bridge the way we build software where you build a bridge with a totally new design that has never been built before which is a better analog for software it has all the same problems of big software engineering.

18:16 Um, witness, Adam, the the the the self-anchored suspension bridge that we have here in the Bay Area, which is only the second of its type in the world and looked a lot like a software project. So, anyway, yeah, Granny, I just wanted to people don't take what you're saying for granted because what you're saying is extremely important that we Yeah. Anyway, you are a very important part of of upleveling us. There's a great X KCD cartoon of you see this little complex structure and one tiny thing in there of it's all supported by this. And that's what open source is is somebody who said uh if buildings were built way if software were built the way I'm going to get it backwards. If buildings were built the way software was built the first woodpecker that would come along would destroy civilization. We we build things that are astonishingly exquisitly complex and they're also fragile. And this is I think what makes it so exciting to work in this discipline because we work with the most fluid of materials, the most malleable, the most funible. And that's exciting. And as I always tell people, it is both a privilege and and and responsibility to

19:17 be a software engineer because it's a privilege because we're changing the world. It's a responsibility because we're changing the world. So if we think of ourselves as an engineering discipline, we weigh back different forces. And that that's a fundamental that applies to all of us. In the

The three golden ages of software engineering

19:31 earliest days of software when we were dealing with you know mainframe computers the fundamental problem was we want to do calculations mostly mostly mathematical. The problem is how do we get our machines to do what we're doing? This is the era of of the Mark1 and uh and uh the Iliac. It's not the Iliac but the ENIAC and the like. As we began to decouple the things that made the machines work and the hardware itself.

19:57 Now we're in the realm of Grace Hopper, the one who was pioneering the ideas of compilers and higher order programming languages that led to eventually Cobalt and Forran and the like. Why do we do that? We needed a change in levels of abstraction because working at the assembly language level or the machine language level simply was not very effective for us. We could think of these things but the friction and the distance between the two, the cognitive distance is very very high. Thus we were now subtly in the first golden age of software engineering. That first golden age is best characterized by algorithmic abstractions. Meaning we're taking mostly mathematical things getting our machines to do it. In the 70s 80s, which is where I came into the scene, I was very lucky because I came in at the right place at the right time. The world was changing because now, as I mentioned, back in Vandenberg, we were dealing with systems that were larger, real time, distributed. All of a sudden, complexity was just exploding upon us.

20:52 And the early abstractions were insufficient to do what we're doing. There were glimmers of excitement though with languages such as simula, with ideas such as abstract data types and partners' ideas of information hiding. The role I was given with ADA was to say Grady, we built this language for the Department of Defense. Go figure out how to best use it. And so I was actually commissioned to go off and figure out some software engineering techniques. I met with the, you know, the first generation folks, Larry Constantine, Ed DeMarco, Ed Ed Jordan, Tom DeMarco, all those kind of folks. And so I kind of learned from them, but I realized there's something different. There is a wonderful dialogue by Plato. That's the one that really inspired me. This is going to get kind of geeky. In it, there is a discussion about how does one view the world? Should you look at it through the things or should you look at it through the movement? And the answer is both. But it occurred to me that's the way we should look at software through the things themselves. And of course the

21:53 simulative folks had done that. And thus I was on this mission to say oh let's try designing it through objects and classes not just through algorithms. I was one of many but I just happened to have a a platform and a voice and reasonably articulate and then we built a business around this kind of thing. So that was the beginning of the second golden age of software engineering because the fundamental problem was increasing complexity, increasing size

Overshooting abstractions led to mistakes like excessive inheritance

22:17 of systems. We need new abstractions to help us reduce our cognitive load and build these things. So I'll pause there for a moment because I don't want to do all the talking but

22:26 no the question before I go on. No, no, that that makes total sense. And I think that the and I I now like very curious because the kind of the next turns of that of the development of some of those abstractions because I mean the abstractions I I I I think that the some of these abstractions that we developed along the way became a very important as just demarcation boundaries like SQL was a I mean Adam you're a SQL lover but I think it's is that fair to say do you feel am I being am I being

22:55 I can understand why you say that. Yeah. There we go. That's exactly. But I mean that's an extremely important abstraction to develop because it allowed us to take these these two big concerns and actually separate them. We may want to go like later in later we would go kind of revisit that abstraction. But the presence of that abstraction was really important. So the you know the presence of the operating system as an abstraction allowing us to have application software that was totally divorced from from the hardware.

23:28 Um and I think that Grey one of the things I would actually be I would because I definitely came up when object orientation reached it I I think at its zenith. Adam you can I mean you're you were a couple years behind me. Is that right? is because I think

23:42 I think so because they were rewriting the operating systems course at at Brown to be uh object-oriented at the time.

23:49 Object orient everything was going to be object-oriented and it was one of these things where it's like the the successful abstraction. It's we in software we seem to never be able to turn the abstraction dial exactly correctly. Like we always like okay if a little abstraction is great like we must abstraction absolutely everywhere.

24:06 That's right. If if if open if uh object orientation is great in moderation then used in excess it'll be even better.

24:13 It must be especially great in excess. If Java is good in moderation like then the microprocessor should be in Java. It's like no

24:20 and remember the Intel IPAX 432 is basically putting eight on a chip. We overshot things especially with the use of inheritance. That was a mistake. But the idea of abstracting things where you had the data and the operations together as a cognitive unit that was essential. But what happened? It disappeared as it should because the best things like that should move into the atmosphere. This is around the time the UML came to be because I recognized that languages were were textual languages were good but we thought about things at a different level of abstraction. This is also around the time that I connected with Bjarn Strrip. Barjarn happened to show up in one of my lectures. He asked some really good questions. We talked afterwards, hit it off. And then this is before the time he had released C++. He had just written a paper called C with classes. I wrote my object-oriented design paper. We were actually published in the same journal at the same time.

25:13 Didn't know one another. So the two of us went off and did a a lecture series around the United States and very much influenced each other's work if you look at his first edition thing. So I kind of grew up with C++ and vice versa. But now I would observe that we are in the third

The third golden age shifts abstraction to packages and platforms

3 Highlight · The third golden age of software engineering and higher abstractions

25:28 golden age of software engineering. It's not because of things like uh like claude. I think we've been into it for a while. Why? Because the abstraction has shifted again. With the rise of distributed systems, with the rise of the internet and primarily with the rise of packages and platforms, all of a sudden we're not dealing with building systems out of levels of classes. We're dealing with levels of whole frameworks.

25:54 Oh, I need to do some sort of uh messaging, then I'll use this package. I need to do this kind of UI thing, I'll use this. I need to do visualization, I'll use D3. So, all of a sudden, the level of abstraction has moved up for us. And now, as a software engineer, a lot of what we end up doing are some people who build these, some people maintain them, but systems engineering is largely figuring out what those right pieces are and orchestrating them so they work well together. That's the third golden age in which we're in. And then I would observe things like claude.

26:23 They are a a symptom of that golden age. We've had a need to increase the velocity and reduce the friction so they come in at the right time. Not unlike what happened with the generation of case tools in the second generation, second golden age. Not unlike the rise of compilers and higher order languages in the first generation. Now what does it mean? And I've often said this. I believe things like COD and the like will change the nature of software engineering just as much as did the rise of compilers.

26:54 It moves up the level abstraction and actually makes it possible for us and desirable for us to build more software and therefore the human is not disappearing. We've just moved up

27:05 another ratchet of level of abstraction. So this is an exciting time quite frankly.

27:10 Absolutely agree. Absolutely agree. And I think that the and I I love your analog with the compiler. I also think it's great that and I think it's also especially great for younger software engineers, Grady, to hear that over your career you've had people approaching you being like it feels like the domain is like the invention of the compiler means that I have nothing to do anymore or the you know

27:30 Oh yes, the invention of Cobalt. Cobalt was invented because now we don't need programmers. Business people could write their own code.

27:39 Well, how did that work out for you? and SQL too, right? I mean SQL the whole idea of SQL that was that you making this so much more approach and which it was of course I mean SQL made it way easier to query a database which just allowed us to do a lot more databases.

27:53 Yes.

27:53 Um exactly

27:54 and you know we are definitely and I I love that analogy. Um we are definitely seeing that for whatever it's worth. We are seeing that the and and uh you know Adam did you catch the demos on I know you were out on Friday. Did you catch the demos?

28:08 Yeah, I I watched the the recording today. And wasn't it wild?

28:12 Very cool. So our our our colleague uh wrote uh a language that they don't know Lua to use a subsystem that they've never used before or heard of before which was an embedded Lua use in ZFS to do some mission critical use. It was it was

28:29 Adam I just love that right now there is someone doing their dishes. Not right now. Actually, in the future, because this is like right now, right now, some lawyer is going to someone who's going to listen to this podcast as a recording is going to is going to like dry their hands and hit the pot and rewind and be like, "Did I just hear that there's a Lua interpreter in CFS?" Yes, dear listener, there's a interpreter in CFS that you might not have been aware of. Uh but yeah, using Claude then to actually go write these channel programs and in a way that was in a way that you just like it Claude didn't make it possible but it made it so much faster that it was it was just not something we would have done. We would have waited because cuz this is basically working around the lack of a piece of functionality we need in CFS

29:11 100%. especially like you I mean h how else would you have the confidence to say well I've never used this language before and I've never heard of this subsystem before but I don't know and I kind of have to get this done in the next two days or whatever

29:25 uh you just wouldn't even start like you you would know that it was impractical

29:29 yeah and we're and you know I I think also Gdy because you're you're a a tooling like us I mean our tooling is very deep in our marrow we we like you are real toolmakers And one of the things that we are discovering is that claude is being used by software engineers to make the tooling that they kind of wish they had on the spot. And um that is so it's this kind of very important bankshot in terms and people are still of course are using it for to for all the the ways that it's being used elsewhere. But I think that for infrastructure software in particular, what we're finding is that we're able to use this stuff to really increase our level of rigor. And I think that that's a bit which is not a surprise if you view it in the context of what you're describing you viewing it like a compiler revolution. That's not at all a surprise. But I think there's a domain of software engineering that finds that surprising. I

30:23 I think they do find it surprising. Infrastructure software is perhaps some of the most fragile stuff I've ever seen. It it runs on spit and chicken w chicken wire in most organizations. And so no great surprise that using things like claude to help you uh refactor it, reorganize it, automate it makes a whole lot of sense. Uh so yeah, I I don't have particularly complicated pipelines, so that's not where my primary use case is.

30:48 I've been using it for some Swift, some Python, some PHP, some uh some uh JavaScript, and it's been great for me. But the notion of using it for tooling to automate those things, every software developer builds their little nest around themselves of all their creature comforts. And when you move that to the organization at large, Claude and its ilk shine in those circumstances.

31:13 Well, and I just think to your point about us writing more software like that, you know, because when people think like, okay, more soft like what does that mean exactly? It's like well what it means is that the software there is software that a lot of software that's not written because it doesn't it can't economically pay for itself. it it's it's the tooling that is like god I would love to have this tool but it's kind of a one-off tool or it it might not be useful beyond my immediate use

Economics dictate software design and durable code

4 Highlight · Economics dictate software design and durable code

31:42 case or my immediate organization and now all that stuff becomes uh possible and

31:49 it's very important you mention the notion of economics because I think economics has driven a lot of software engineering if you look back in the first golden age the cost of our machines was much higher than the cost of our programmers and therefore everything in the processes like waterfall was in order to optimize the dominant cost which was the machine. So if if you had a high cost for machines and you do your work up front by the way the same phenomena happened in Russia of all things after the after the Soviet Union collapsed and we saw this flood of amazing engineers coming into the marketplace. What happened?

32:25 Machines were very very scarce in the Soviet Union. And so the developers there honed their skills to be able to do things on paper and in their heads before they even touched a machine. We don't do that anymore because the economics have utterly reversed. The cost of preparing is actually so high you just sit in front of a machine and do something. Now this leads us to the distinction of disposable software and durable software. Disposable software means you've got systems which the economic cost of replacing it approaches zero. Durable systems those are one in

33:00 which the risk is higher in which the cost of change is higher and therefore you got to find a balance where you are in this for every organization.

33:09 Yeah. And the software we're making just to be clear is really of that durable. I mean that's where I've spent my career is in that I mean still using software that that I wrote we wrote you know now Adam Jesus 20 plus years ago. Um and so really but I I think that there's a lot I think that like unlike I think not every revolution has affected every use of software equally and I do feel that like I mean because I you know I I came up in when at Java was was everywhere and was going to be used for absolutely everything. Um, and that was like that was an overshoot and it wasn't actually meaning was like I actually think that claude is it's it's not an overshoot to say that it affects quite literally everybody at every layer of the stack at some layer that or the ability to have LLM assisted software engineering is going to be I feel it's going to be omnipresent. I don't feel like that's a that's right up there with World War II being stressful. Adam, I feel right one of Brian's famous observations. Yeah.

34:08 But deep thoughts out of side and friends.

34:11 But but I mean Grady to your point like similar to the compiler having an impact to every software uh engineer and all software being written. Uh you know I think that that that feels obvious now but maybe felt scary at the time you know maybe felt like it was threatening people's livelihoods and and the amount of software that would be written but it turned out that just much more software was written.

34:35 Yeah. Change change is hard for everyone. Absolutely. This is a time of still incredible experimentation. Speaking of overreach, I believe people like Sam and Dario of Anthropic, they have vastly overreached. I bashed Dario many times on on Twitter and he's making the claim that, you know, software engineering is dead. I think he's demonstrally wrong in every dimension of the word wrong. But remember, he's a person who is trying to sell a business and increase their stock price. So, he is he's looking at the world in a very different way than I am.

35:07 I I I it's true. I also feel it's not very helpful to just generally be stoking fear about these things because there's already ambient fear just from change. And it it is it's kind of too easy to stoke that fear. Um and it makes it really hard to be levelheaded in light of that fear. Um so I actually do think that we we need to be more levelheaded on a lot of this stuff. What would be so your advice to because I I get this a lot. You must get it a lot too of young people are like got to mention software engineering but it feels like the glory days are kind of past us. Um which I disagree with. I I agree with you. I think our our our best days are ahead and it's exciting time in terms of though I I just as like a compiler did not chase assembly language out of the undergraduate curriculum, right? We still learn assembly and it's still important even though no one is expected to write things in assembly. It feels to me like those fundamentals are as important as ever in in a kind of an undergraduate kind of computer science

36:08 experience. Way what's your take on that?

36:10 Absolutely. By the way, being level-headed makes sense, but the problem is it won't get you on Fox News. It won't get you, you know. So, that's the problem. So, there are voices like mine who are saying, you know, and maybe I'm just the old sage saying, take a deep breath. Life is good. Life's more wonderful than you realize. Don't panic and carry your towel with you if you remember that that analogy. So from from the galaxy, right?

36:37 Yeah. You know, I was listening to a podcast where you casually dropped in a reference to an SNL spoof ad from the 70s of the

36:46 popping into bingo. And I was like, I boy, I so admire the courage to drop that one in casually. And obviously I'm with you. And I but I literally even the millennials don't know who Dan Akroyd is, let alone the Zoomers have got no idea. Anyway, I so I

37:01 there are some 8 billion people in the world, the vast majority of of them have no idea who I am. There's some small percentage who would wish I would be dead. So I'm happy with that. That's fine. Uh I'm I'm just I'm just doing what I enjoy and I I love doing software and I love talking about it. Uh I've forgotten your question or where we were.

37:22 So sorry it was somewhere between dessert topics and floor waxes.

37:26 What is the advice that you would have

Fundamentals remain essential despite revolutionary tools

37:28 for young people in terms of the domain?

37:31 I'll give you a story from another domain. Uh Frank Giri, brilliant architect, civil architect. He's passed away. He is one of the leading architects of this generation and he's done things like the Disney concert hall which was just an extraordinary soaring soaring building. It speaks to you. It it says some

37:52 the work he did was only made possible because of things like AutoCAD. Why did AutoCAD happen?

38:00 We saw a revolution in the way people could design buildings because now you could model them in three dimension. you could actually test them in software against wind shear, earthquakes and all this. So it's tools like that that unleash creativity that simply were not possible before. The same thing happened at the at the peak of the or the beginnings of the industrial revolution where all of a sudden we had a mass production of iron and the like and now people could start building railroads and boilers and and and uh and bridges and lots of them failed because we didn't understand the the science behind it. But it enabled us to build more things eventually once we got it. The same thing is happening in software right now that we have some tools that are allowing us to unleash our creativity and get us clo our imagination closer to what we wish to build executable artifacts by reducing the cognitive distance between those two by raising levels of abstraction. So my advice to folks is look at Frank Gary

39:00 the fundamentals still applied with him. You deal with forces, you deal with static and dynamic kind of things. Those are the fundamentals. Metals for software engineering. Pretty simple. Uh I'll give you some some sound bites. All architecture is design. But not all design is architecture. Architecture represents ificant designs that shape the form and function of a system where significant is measured by cost of change. to do those kinds of design decisions that are meaningful within this engineering context. You want to focus upon raising your level of abstraction, build good abstractions, build uh abstractions that are are crisp. This is coupling and cohesion.

39:40 You want to build them as simple as possible. And that's kind of it. That's the fundamentals in which we do. We build our stuff and the language changes underneath it. But if you if you rely upon those things that's the essence of engineering for mess all of these

39:59 and do you do you worry at all I mean and I don't know that I do but one thing that is um you know part of what drives us to those simple but elegant powerful abstractions right the ideal abstraction for us is one I always felt that elegant is the highest praise for a software engineer it's something that you you know that you've got a an abstraction that is both at once minimal but powerful and sufficient and the the I don't know that I' nervous about this or not but part of the reason that we're dri driven towards elegance is because of the the limits of of kind of human cognition and if you if you have something that can absorb more complexity it may move you away from simple abstractions do you worry with LLM authored abstractions may have unnecessary complexity. I mean, is that a again, I'm not even sure that I have this concern, but I would love to get your take on.

40:57 There's a lot to unpack in your question because you're now attending to some interesting philosophical issues about the rise of artificial intelligence in general. Um, let's look back to other sciences like physics or mathematics, the oiler equation, e to the i pi + 1 equals zero. I look at that and I just shiver in ecstasy because it represents it represents my gosh from Saturday Night Live to Oilers's equation. We're all over the map here friends. This is you're right. You're right on brand.

41:25 That's right. So So what does that mean? That that represents from which we can now generate other things. So in science we look at the data we try to compress it by building it abstractions. Once we have those abstractions we can move forward. The same thing is happening in software itself. We are trying to build abstractions and it's difficult because there is no perfect abstraction. It depends upon the context and the other forces you've got around you. But we eventually have within our our uh our quiver of the kinds of abstractions we know that work. This is and we know when we're off. This is the idea of code smells. It doesn't quite fit what my abstraction is. It just just doesn't feel right. and an experienced engineer will know those kinds of things. But

LLMs are unreliable narrators incapable of abductive reasoning

42:12 here's the problem with large language models. If you're not somebody who has experienced those, if you don't have that within your skill, then you don't know if it's going to you or not. Uh, as I've often said, large language models are at best they are uh they are unreliable narrators. At worst Jeff Hale Seattle I tweeted about this but my experience with with these LLMs has been uh they they're good if you kind of guide them view them as an intern who is very energetic won't shut up won't go to sleep but my gosh they need some guidance because they will often do make mistakes they'll inject errors that they don't even know because they're not my reality. Yeah, and that's okay. And so you've got to be very careful about using them in a guided way. Um, and especially for very critical things, I always keep an air gap between my large language model and my production code. I will look at it

43:13 before I'm it in before I let the LLM does it. If however, your mileage may vary because every organization has different risk and so that's okay. So

5 Highlight · Large language models lack abductive reasoning

43:23 I'm not I'm not shunning people. But here's where you get back to the fundamental things. Large language models are architecturally incapable duct reasoning. Let me say that again. They're incapable of abductive reasoning. Abductive reasoning is the production of theories from data. They can do induction. They can do deduction, but they're architecturally incapable of doing the other because there's no theory from which they can build. Good example of this is if I trained an LLM on all the scientific literature up to the mid 1800s, an LLM would never have discovered cells and viruses because it simply was outside their training data and any extrapolation which is what LLMs can do would be anion. That's why we have to be careful with these things and that's why I'm also not worried about them. I'm not worried about the rise of super intelligence. I am I am worried about the rise of billionaires who wish to use these things to increase their power.

44:19 That's what I worry about.

44:21 I know I told it's like um unfortunately like the thing you need to fear is like it's much more mundane. It's like people with with with like too much money who are racist and sexist. I mean it's like it's the same thing that like we same thing we've been battling society for, you know, for eons. Um, and I know it's like it's it's fun to think about the kind of the robots rising up against us, but um, it's actually uh, and actually for me it's like personally I mean I would kind of love that just because I would love to go to battle on behalf of all humanity against the robots and find all of their, you know, speculative execution vulnerabilities and so on. I think it would be just but it's like it's it's a fantasy. It's not.

44:59 But Granny, this point about abductive reasoning is really really good. I mean because I I I haven't heard it phrased exactly that way, but God that really you're you're exactly right. I mean that is the kind of that that's the bit that is missing that you are always going to rely on and in part because like they you know uh our colleague who worked on this thing that Adam described of the the Lua interpreter generate the Rust program that generate the Lua to be interpreted as a channel program in CFS.

45:29 One of the things that he commented is like, you know what I love about these things? They're kind of down for whatever. Like there's no there's no sense of like, wait, why are we doing this? Or like is wait, I think there's a better way to do this. There's like, nope, sounds great. Like, let's go.

45:42 Let's go.

45:43 I've already written twothirds of it. Let's go. Do you want me to And which is what makes them powerful, but also makes them limited. And as you I mean I just anyway I I'm I'm kind of like I I I'm I'm kind of uh reconstructing my blown brain on your point about abductive reasoning because I think it's a very important point in so far as we surrender ourselves to these kinds of abstractions. That's where the danger lies. We must not you know abandon our humanity in the midst of it which I'm going to put in a plug. This is why I've been trying to do this documentary.

46:13 Think Carl Sean's Cosmos but about the intersection of computing and what it means to be human. So, this is a great time to try to bring this in the public uh the public uh sense because a lot of fear, a lot of, you know, fear-mongering and and FOMO going on here. But, you know, stepping back from it, having seen a few things in my lifetime, I'm not I'm not concerned except in so far as humanity has its own issues, uh I am actually excited by what the future offers for us.

46:42 Yeah, that is I think just very important and uplifting. Um I think I dropped in the right link to computing the human experience. Um is the the the work that you've got because I I think this is great by the way. Um the idea of the of I mean the story of computing it is we have created so much plenty so much prosperity with computing. Um we are I you know I I as I have told people like the I read a terrific book on the history of the birotor combine uh called dream reaper by Craig Kanine that was also a history of agricultural technology and I think every technologist should learn the history of agricultural technology so they can have appreciation for why they're not in the fields today. Um because without agricultural technology you and I and everyone else except for the king are in the fields

47:32 and it is like ultimately technology has given and but I feel like with every one of these revolutions there is this this kind of conccommittent fear that comes with it and and sometimes that fear is very justified as it certainly was with nuclear weapons or nuclear power and um and I mean maybe it's it's humanity's overshoot that justifies that fear but how do we kind of counteract that fear? fear that we because I share your optimism uh both see the fears you say the fear won't get you onto Fox News

48:03 right

48:03 um sorry the absence of fear the coolheaded the be calm as you said won't get you onto Fox News

48:08 how do we counteract that fear

48:10 yeah dumerism especially in the AI space gets you a lot of press and that's why you know I I go headto-head with folks such as Ray Kurtzswwell and the like who nice guy I met him I think he's off base with regards to his predictions that's fine I think Elon as well too. Well, I've got a lot of issues with Elon, but that's one of them in that regard and and Sam and the list on. It's not I hate a lot of people. I hate people who are selfserving narcissist who are trying to push their agenda and not listening to the world. There are more than a few of those unfortunately at the moment. Um, so, you know, how do I balance this kind of thing? I think the answer is all of life and all of humanity is an extraordinary journey and we happen to be present you and I and everyone that's listening happen to be present at an exquisite time in human history where we have the capability to turn our imagination as long as we live with the laws of physics turning those things into reality that is tremendous. we've

49:12 never had in our history of humanity the kinds of materials to do we want to do here. That is wonderful. But it's also frightening because the kinds of things we can produce, it's not frankly unlike the creation of nuclear weapons because we know that it's going to change things and it's primarily going to change the balance of power. That's what software does. So how do we counter it? The answer is, you know, keep up with the fundamentals. Go off and try to build good things that are useful. uh be apply your own ethics to this. Do you want to be somebody who works for Doge and helps write software to pull information from the IRS gained illegally and to try to find immigrants? Hey, if you want to do that, great. But you got to apply your own ethics to it. So this is where the human factor comes into play. You have a choice as a software developer to do great things or do not such great things. And you have a chance, a choice to contribute to the advancement of humanity in that regard. You are part of

50:13 a wonderful place in time and you have wonderful skills to do things no one ever could have done before your generation. I mean that's uplifting for me.

50:23 Yeah, totally. absolutely uplifting and I I think that in just reinforcing the importance of those fundamentals I also so you have also seen many waves many economic waves where you've seen many I mean we we we've all seen but you you especially I mean there was a a big software boom and bust in the 80s that definitely predated me but you very much lived through um at rational right on the and then obviously the dot boom and bust we um the great recession the And so you've seen this kind of like economic dial kind of you know where people are coming into the domain not because they were trying to you know build their own computer in the 60s and Amarillo but because they think it's like well this is like a path to to solely a path to prosperity.

51:11 Yeah. Yeah.

51:11 I mean I I think it's kind of I mean I hate to say this but I think it's better for the domain when the dial is turned off of frenzy. I think when we are I mean is that

51:21 Yeah. Oh I I agree with you. Absolutely. But hey, you know, all life is a frenzy. And so, you know, don't get caught up in the the tidal wave of that malstrm. That's a mixed metaphor. You know what I mean? Uh, you know, and try to be calm in the middle of it because you can't control those waters around you. But my goodness, you can build some great things out of them along the way. Hey, quick aside here. I just noticed the time. I do have a hard stop here coming up really quickly. you and I and this gang, we could probably talk for a few more hours, but but unfortunately I I do have a bit of a hard stop here. So, could we maybe start winding it down here?

51:59 The Let's wrap it up. Absolutely. So, can I actually just ask for um do you have any book recommendations for We We got a bunch of readers here. Um what are

Classic texts provide enduring lessons for systems engineers

6 Highlight · Essential book recommendations for systems engineers

52:07 some books along the way that really changed your thinking? Um

52:11 in my library, I have in my library I have about 6,000 books. I'm I'm an old school guy. I prefer physical books. I'd recommend the following. For the systems engineers, go read Herbert Simons, The Sciences of the Artificial. Go also read Systematantics by John G. Go reread again um uh uh gosh, it just popped out of my head. I see the cover.

52:36 The Mythical Man month, of course.

52:38 I was going to say Mythical Man. Yeah. Yeah. Yeah. Absolutely.

52:40 Yeah. Yeah. Go read uh Refactoring. Um you know, those come to mind. Those are the ones that come to mind.

52:49 Those are great recommendations. Grady, thank you so much. Thank you for all that that you have done and are doing for software engineering as a craft and a discipline.

52:58 I'm not dead yet.

53:00 That's right. Um the I Yeah, Monty Python. I I got we got to explain all these things to the young here. Um

53:09 but um thank you so much.

53:11 They can Google it.

53:12 There you go. and and thank you to for I think uh taking on some of these uh these loudmouths online and um I I don't think they always realize who you are when you're speaking to them and you're not the kind of the type to wave your credentials around but um on behalf of software engineers, thank you very much.

53:29 You're most Thank you for having me. This is the most fun I've had with my clothes on all day.

53:36 All right. Thank you very much, Grady. Appreciate it. Bye,

53:39 guys. Um

53:40 All right, Adam. Well, there you go. That's um

53:44 just relieved that he had his clothes on for for this episode.

53:46 Well, just just for today though. I mean, yesterday there was, you know, so we'll take it. Uh but thank you very much everyone. And so we um we've got a couple episodes out there cooking that we're um excited about. Um and I know we'll be we'll be kind of in and out for these next couple weeks, but um look forward to I think we got some exciting episodes Adam.

54:05 Yeah. Um, we we have um we na we we our our our colleague Ry nailed a gnarly compiler bug on a P4 compiler bug on Friday night. Um and definitely my I mean my I think I think my first thought was thank god we're going to live. Um but my second thought immediately following that was like this is great because we got we we got an episode we can have content. Oh thank god for the content. We got some good content coming up. So, um, exciting stuff coming up.

54:36 Um, awesome. Uh, thank you very much. Hey, I defy anyone to play this episode at greater than 1.0x. By the way, if you got through this episode at at at 1.5x or faster, let us know. We'll send you a t-shirt.

54:49 All right. Thanks everyone. 13 next.