Latest / Oxide and Friends / Software Engineering Past, Present, and Future with Grady Booch

Transcript

Software Engineering Past, Present, and Future with Grady Booch · Oxide and Friends

• 0:00
  Bryan Cantrill: Oh, there's another Grady with do have the other Grady with the hands up?
• 0:04
  Adam Leventhal: I just let I just let anyone named Grady join the stage.
• 0:08
  Bryan Cantrill: Noted for all the all the listeners.
• 0:10
  Adam Leventhal: Exactly. Kind of an I'm Spartacus moment.
• 0:13
  Grady Booch: You hear me now?
• 0:15
  Bryan Cantrill: We hear you now. Yes. Great. Welcome. It is it is great to have you here.
• 0:23
  Brady, you know, I Pierre Lamond is a is a famous venture capitalist and I 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 he informed me that legends are dead. And it was like literally my I'm like, okay. This is off to a very very bad start.
• 0:45
  So I am not going to call you a legend because I don't wanna 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
  Grady Booch: You're most kind. I've been called many things.
• 1:01
  Bryan Cantrill: Well, you are certainly a software engineering pioneer, and you have seen a lot. And I have to tell you, I was just getting to prepare for this conversation. I had pulled what I thought was a recent conversation. And as I was listening to him, like, wow, this is like this is 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 at him like, my God, was in 2014.
• 1:30
  And this conversation you had in 2014, have to tell you is aging very very well. You had a so because you've been you've been involved in you were talking about working with the Watson team and I kinda understanding what Watson had done at IBM. But of course, your history is a lot deeper than that. You were I mean, you go back to the you kinda came up as software engineering was coming up. I was gonna ask if your degree was in computer science or because you're the Air Force Academy or was your degree in because it almost predates certainly it predates Adam.
• 2:11
  It predates the computer science department at our alma mater. Grady, 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
  Grady Booch: So let's go way back in time. I built my first computer when I was 12. So we're talking, you know, mid sixties. Why did I do that? Well, I was a voracious reader then, still am now.
• 2:35
  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. Well, obviously, in the mid sixties, there weren't a lot of things around, not even the great circuits. Yeah.
• 2:56
  Bryan Cantrill: Right. So
• 2:57
  Grady Booch: 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.
• 3:15
  Bryan Cantrill: So Sorry. So 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 microprocessors certainly had not been invented. I just wanna 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
  Adam Leventhal: He's more of a software guy, Brian. Remember.
• 3:35
  Bryan Cantrill: Exactly. That's right.
• 3:36
  Grady Booch: 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. I decided software was where it was at. So here I was by that time, 1314, the summer thereof.
• 3:53
  So living in Amarillo, Texas, small town of a 150,000 people Yeah. 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 gonna hire a kid. But I knocked on the door of the IBM sales office.
• 4:11
  There's a sales guy that took me in. He nodded politely and then handed me a manual, a four tran four 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 Fortran to model the movement of two neutrons moving toward one another and increasing speeds of light or close close to the speed of light and calculating what the release of energy was. So that was my first program. I still have the punch cards for it, by the way. The guy took me under
• 4:52
  Bryan Cantrill: That's a that's a long way from scratch or whatever the the kind of the the modern equivalent is. That's that's very that's watching it. Adam, have you ever been to Amarillo?
• 5:01
  Adam Leventhal: Do you I don't know that I have.
• 5:02
  Bryan Cantrill: Okay. So air I mean I mean, Amarillo is is desolate. Right? I mean, It's fair to say Amarillo is like, it it you've got the you are in the Texas Panhandle. Yep.
• 5:14
  And, I mean, you are a long way from other things. It's remote. And It's
• 5:20
  Grady Booch: it's a helium capital. Yeah. Heal helium capital of the world. 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 eleven thirty computer, if I'm not mistaken. And he said, go to it. I taught myself how to punch cards. I taught my self debugging, and there we have it.
• 5:50
  Around that time, I decided, you know, what do I wanna do next? And so I was deeply into software Fortran at the time. We're gonna come back to the story of the the manual in a minute. But I then said, what are my two loves? Computers and space.
• 6:05
  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. 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 there was a bachelor of science. My first assignment after I graduated was at Vandenberg Air Force Base.
• 6:32
  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 I gosh. I I unveiled my political bent, didn't I?
• 6:46
  Bryan Cantrill: Hey. You're you're all good. You're all I feel we need a separate time for it. So this is a a good time.
• 6:51
  Grady Booch: 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 Sagan's Cosmos about computing. 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 two and the Cold War, where the phrase I use is much of modern computing has been woven on a loom of sorrow.
• 7:23
  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. They were fusing together 40 different radar in real time around the world, And this was hard stuff. Hard then, is a bit hard now.
• 7:42
  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 AIDA program, because here we were in the midst of the software crisis, and as it was called the NATO conference
• 7:57
  Bryan Cantrill: 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 eighties, maybe late seventies. Wait. What is the We're
• 8:07
  Grady Booch: in the mid seventies. Mid to late seventies.
• 8:09
  Bryan Cantrill: Mid seventies. Okay.
• 8:10
  Grady Booch: Yeah. 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. Yeah. Right.
• 8:18
  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 a 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. Wow.
• 8:36
  Yeah. Yeah. So, anyway, I was called in to be involved with the AIDA 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, there was a system called SAGE, the semiautomatic ground environment, which is so much the predecessor of modern computing. Large distributed system.
• 8:58
  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 seventies, coined the term software engineering to distinguish herself from the hardware engineers who were around the time.
• 9:28
  She went on to work from Sage to be the main engineer for the Apollo 11 ground system, and indeed was the person, you've probably seen pictures of it, 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, etcetera. The Sage project consumed perhaps 30% according to some reports of all of the software engineers in The United States. Huge, huge project.
• 10:03
  And we learned a great deal from it. I'll jump ahead because I don't wanna spend all the time in my history. I wanna talk about some Yeah. Of
• 10:10
  Bryan Cantrill: Yeah. Yeah.
• 10:10
  Grady Booch: Yeah. So we we then, after I left for the Air Academy, started up Rational Software with two of my classmates in 1982. We were bought by IBM in 2003. I'm gonna put a bookmark there and tell you a Bill Gates story in a moment. And then the rest is history.
• 10:27
  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 February. That was probably the TED talk of which I spoke. Was I was in Yeah. Annoyed I was in yeah. Was annoyed at the book that Bostrom wrote and said, this sucks.
• 10:46
  And, Elon, you're adult. Bill, you're adult too. Let me tell you what I think. So there we go.
• 10:54
  Bryan Cantrill: Yeah. I was actually the it was on the Singularity podcast. Oh, Oh, yeah. 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.
• 11:06
  That you your TED talk, great. Yeah. I always feel like, oh god. I feel like I I wanna go listen to the speaker for another, you know, outside of the forty five seconds they've been allotted. Yeah.
• 11:16
  Yeah. So
• 11:17
  Grady Booch: Yeah. Ray and I got into it. I thought his ideas of the singularity. Well, the 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.
• 11:30
  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. A couple months after we we finished the deal, got a call. Hey, Grady.
• 11:45
  It's Bill. Come see me. So I flew up to Seattle. I'd done some things with him before. He sent me down in his office and said, you know, this is not public yet because we're talking, what, 2003, but I'm going to retire from Microsoft.
• 11:56
  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, you know, that's really that's really interesting. Let me think about it.
• 12:06
  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.
• 12:24
  And I'm happy that I did.
• 12:26
  Bryan Cantrill: Yeah. Yeah. I I because I mean, and you you only end in tears. It would have been, like, some it could have been your tears that it could have ended in. Or you're just like, this is just too yeah.
• 12:34
  Right.
• 12:34
  Grady Booch: 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.
• 12:47
  Bryan Cantrill: And it should be said just along the way. And I know I don't wanna necessarily dwell on the history, but I do think it's a it's germane for kinda what I wanna talk about in terms of the future of software engineering. That along the way, as you were trying to navigate the the the crisis, the software crisis of the late seventies, early eighties, You really were trying to to find ways for people to kind of up level their craft of software engineering. You were obviously in terms of modeling systems, UML was was your your co baby. It's certainly what a claim to fame.
• 13:19
  You developed when I when I where I came to know you, because I kinda came up in the nineties. I my first internet my first email address very much as an undergraduate in in 1992. I think they had just they had just gone to straight Internet instead of having both Internet and Bitnet. Right?
• 13:38
  Grady Booch: Yep. Right. Harpinet.
• 13:39
  Bryan Cantrill: Yep. Right. Exactly.
• 13:41
  Grady Booch: And then MillNet. Yeah.
• 13:43
  Bryan Cantrill: But I remember you forwarded the Bootsch components, which were the the the the kind of I would call before the c plus plus 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 kinda 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:08
  Grady Booch: Mhmm. Still is.
• 14:11
  Bryan Cantrill: 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, you know, early in on agile use and I you saw that revolution run its course one way or the other, I guess. Could I mean, we used to get your take out on that. And then now we're in this like crazy world.
• 14:35
  And do you feel like, is this the world that like, 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 take on our our arc where we are currently, but I would love to get your take on it obviously.
• 14:54
  Grady Booch: I would say that every age of software has been crazy and bizarre and wonderful simultaneously. 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.
• 15:23
  My career is over. It's gonna be replaced by computers. And I observed to them is that, no, be calm, take a deep breath. The entire history of software engineering is one of rising levels of abstraction. Let me explain why that's the case.
• 15:38
  Because you're right. I've been around this business for a while. I met Grace Hopper. I've met I still have the nanosecond 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.
• 15:52
  I've also I didn't meet Alan Turing, 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 wanna get down to it. I even oh, here here's in a funny other funny story. Jay Presper Eckert, I met as well because I taught his grandson at the Air Force Academy.
• 16:17
  So yeah. Wow. I told him how Jay spell
• 16:19
  Bryan Cantrill: Presper Eckert.
• 16:20
  Grady Booch: Wow. So that that dates things. Anyway, so Yeah. That's I
• 16:24
  Bryan Cantrill: mean, I feel like you you you're like, did you have any connection to Charles Babbage? I mean, this is like, you're really turning that's very impressive. Oh my god. Wow.
• 16:31
  Grady Booch: Charles was long gone by then. The the story with back to Fortran, the quick one is, remember that manual I said? Yeah. As part of the I was on the board of trustees of the Computer History Museum for about a decade, and I did a number of oral histories for folks. One of those I did was with John Bachus.
• 16:46
  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. Similarly, you know, why do we have software 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're the ones who take various static and dynamic forces and try to build reasonably optimal solutions to tend to those.
• 17:21
  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
  Bryan Cantrill: Yeah. And I agree. This is an extremely important point because this may unless 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 know, it's always like always the civil engineers that are like, you know, like, it's always the bridge building.
• 18:01
  And the and one one things I learned about bridge building is that when you when 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. Witness, Adam, 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. It looked a lot like a software project. So anyway, yeah, Grady, I just wanted so people don't take what you're saying for granted because what you're saying is extremely important that we yeah. Anyway, you were a very important part of of up leveling us.
• 18:35
  Grady Booch: There's a great x k c d 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. If somebody has said, if buildings were built the way if software were built the way I'm gonna 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, exquisitely 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 fungible, and that's exciting.
• 19:13
  And as I always tell people, it is both a privilege and a responsibility to be a software engineer because it's a privilege because we're changing the world. It's 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 earliest days of software, when we were dealing with, you know, mainframe computers, the fundamental problem was we wanna do calculations, mostly mostly mathematical. The problem is how do we get our machines to do what we're doing?
• 19:42
  This is the era of of the mark one and and 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, now we're in the realm of Grace Hopper, the one who was pioneering the ideas of compilers and high order programming languages that led to eventually COBOL and Fortran 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.
• 20:16
  We could think of these things, but the friction and the distance between the two, the cognitive distance is very, high. Thus, we are 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 seventies eighties, which is where I came out of the scene, I was very lucky because I came 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.
• 20:49
  All of a sudden, complexity was just exploding upon us, 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 Parnas' 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.
• 21:17
  I met with the, you know, the first generation folks, Larry Constantine, Ed DeMarco, Ed Jordan, Tom DeMarco, all those kind of folks. And so I kinda 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 gonna get kinda geeky. In it, there is a discussion about how does one view the world?
• 21:40
  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 similar 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.
• 22:06
  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 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 wanna do all the talking. But No.
• 22:27
  The question before I go on?
• 22:28
  Bryan Cantrill: 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.
• 22:48
  Like, was a I mean, Adam, you're a a SQL lover. But I think it's is that fair to say? Do you feel I am I being am I being short of a second?
• 22:55
  Adam Leventhal: I can understand why you say that.
• 22:56
  Bryan Cantrill: 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 wanna go like later, and later we would go kind of revisit that abstraction, but the presence of that abstraction was really important. 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
  And I think that with I Grady, one of things I would actually be I would because I definitely came up when object orientation reached it, 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 I think
• 23:42
  Adam Leventhal: I think so. Because they were rewriting the operating systems core course at at Brown to be object oriented at the time.
• 23:49
  Bryan Cantrill: Object oriented. Everything was gonna be object oriented. Yeah. And it 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.
• 24:00
  Like, we always were like, okay. If a little abstraction is great, like, must let's write abstraction absolutely everywhere. That's right.
• 24:06
  Adam Leventhal: If if if opens if, object orientation is great in moderation, then used in excess, it'll be used better.
• 24:13
  Bryan Cantrill: It must be especially great in excess. If Java is good moderation, like, then the microprocessor should be in Java. It's like yeah. No.
• 24:20
  Grady Booch: Well, and remember the Intel I p I a p x four thirty two 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?
• 24:37
  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 Bjarnas Drewstrip. Bjarnas happened to show up in one of my lectures. He asked some really good questions.
• 25:00
  We talked afterwards, hit it off. And then this is before the time he had released C plus plus 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, didn't know one another. So the two of us went off and did a lecture series around The United States, and very much influenced each other's work if you look at his first edition thing.
• 25:21
  So I kind of grew up with c plus plus and vice versa. But now I would observe that we are in the third golden age of software engineering. It's not because of things like like Claude. I think we've been into it for a while. Why?
• 25:35
  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. Oh, I need to do some sort of messaging, then I'll use this package. I need to do this kind of UI thing. I'll use this.
• 26:00
  I need to do visualization. I'll use d three. So all of a sudden, the level of distraction has moved up for us. And now as a software engineer, a lot of what we end up doing or some people who build these, some people who 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.
• 26:20
  And then I would observe things like clod, 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. It moves up the level of abstraction and actually makes it possible for us and desirable for us to build more software.
• 27:01
  And therefore, the human is not disappearing. We've just moved up another ratchet of level of abstraction. So this is an exciting time, quite frankly.
• 27:09
  Bryan Cantrill: Absolutely agree. Absolutely agree. And I think that the and I I I love your analog with the compiler. I also think it's great that 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
  Grady Booch: Oh, yes. The the invention of COBOL. COBOL was invented because now we don't need programmers. Business people could write their own code. Well, how did that work out for you?
• 27:40
  Bryan Cantrill: Well, in SQL too. Right? I mean, SQL, the whole idea of SQL that was that you're making this so much more approachable, 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. Yes.
• 27:53
  Exactly. And so no, we are definitely and I I sorry. I I love that analogy. We are definitely seeing that for whatever it's worth. We are seeing that the and and, you know, Adam, did you catch the demos?
• 28:06
  I know you're out on Friday. Did you catch the demos?
• 28:08
  Adam Leventhal: Yeah. I I watched the the recording today.
• 28:10
  Bryan Cantrill: It wasn't it wild? Did.
• 28:12
  Adam Leventhal: So our our our colleague wrote 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 Adam, I
• 28:29
  Bryan Cantrill: 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, someone is gonna listen someone's gonna to this podcast as a recording is going to is gonna 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 Lua interpreter in CFS that you might not have been aware of.
• 28:49
  But yeah, using Quad then to actually go write these channel programs and in a way that was in a way that you just like didn't make it possible, but it made it so much faster that it would is not something we would have done. We would have waited because because this is basically working around the lack of a piece of functionality within ZFS.
• 29:11
  Adam Leventhal: A 100%. Especially, like, you you I mean, how else would you have the confidence to say, well, I've never used this language before. I've never heard of this subsystem before, but I
• 29:20
  Bryan Cantrill: don't know.
• 29:21
  Adam Leventhal: And I kinda have to get this done in the next two days or whatever. You just won't even start. Like, you you would know that it was impractical.
• 29:29
  Bryan Cantrill: Yeah. And we're and, you know, I I think also, Grady, because you're you're a a tooling like us. Mean, I our tooling is very deep in our marrow. We we, like you, are real tool makers. And one of the things that we are discovering is that Claude is being used by software engineers to make the tooling that they kinda wish they had on the spot.
• 29:51
  And that is so the the it's this kind of very important bank shot in terms and people are still, of course, are using it for the 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 you viewing it like a compiler revolution. That's not at all a surprise.
• 30:20
  But I think there's a domain of software engineering that finds that surprising.
• 30:23
  Grady Booch: I 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 chicken wire and multiple locations. And so no great surprise that using things like Claude to help you refactor it, reorganize it, automate it, makes a whole lot of sense. So, yeah, I I don't have particularly complicated pipeline, 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 some 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 shine in those circumstances.
• 31:13
  Bryan Cantrill: Would and it's interesting to your point about us writing more software. Like the that would you know, because when people think like, okay, more so like what does that mean exactly? It's like, 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 case or my immediate organization. And now all that stuff becomes possible And
• 31:49
  Grady Booch: It's very important you mentioned 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. You know, 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 the 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.
• 32:52
  Disposable software means you've got systems which the economic cost of replacing it approaches zero. Durable systems, those are one in which the risk is higher, in which the cost change is higher, and therefore, you gotta find a balance where you are in this for every organization.
• 33:08
  Bryan Cantrill: 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. Yep. I mean, but still using software that that I wrote, we wrote, you know Yep.
• 33:18
  Now Adam, Jesus, twenty plus years ago. Yeah. And the so the 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. And that was like, that was an overshoot and it wasn't actually meaningful.
• 33:48
  But it's 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 gonna be I feel it's gonna be omnipresent. Don't feel like that's that's right up there with World War two being stressful, Adam. I feel
• 34:06
  Adam Leventhal: it's stressful. One of one of Brian's famous observations. Yeah.
• 34:08
  Bryan Cantrill: But deep deep thoughts out of Lockside and Friends.
• 34:11
  Adam Leventhal: But but I I mean, Grady, to your point, like, similar to the compiler having an impact to every software engineer and all software being written. 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
  Grady Booch: Yeah. Change is hard for everyone. Absolutely. Absolutely. This is a time of still incredible experimentation.
• 34:40
  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 demonstrably 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 is looking at the world in a very different way than I am.
• 35:07
  Bryan Cantrill: 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 Yep. It it is it's kind of too easy to stoke that fear. And it makes it really hard to be level headed in light of that fear.
• 35:25
  Yep. So I actually do think that we we need to be more level headed on a lot of this stuff. What what would be so your advice to because I I get this a lot. You must get it a lot too of young people who are like, gotta mention software engineering, but it feels like the glory days have kinda passed us, which I disagree with. I I agree with you.
• 35:45
  I think our our our best days are ahead and 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 experience.
• 36:08
  What what's your take on that?
• 36:10
  Grady Booch: 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 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.
• 36:25
  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
• 36:34
  Bryan Cantrill: Hitchhiker's got the galaxy. Yeah. Yeah. I gonna say Right. You know, was listening to a podcast where you casually dropped in a reference to an SNL spoof ad from the seventies of
• 36:44
  Grady Booch: Oh, yeah. End of floor wax.
• 36:47
  Bryan Cantrill: Bingo. And I was like, I boy, I still admire the courage to drop that one in casually, and obviously, I'm with you, and I but I literally the even the millennials don't know who Dan Aykroyd is, let alone the Zoomers. I've got no idea. I saw
• 37:01
  Grady Booch: There are some 8,000,000,000 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. I'm I'm just I'm just doing what I enjoy, and I I love doing software, and I love talking about it.
• 37:19
  I've forgotten your question or
• 37:20
  Bryan Cantrill: where we were. It somewhere between dessert topics and floor waxes. What is the advice that you would have for young people in terms of the domain?
• 37:31
  Grady Booch: I'll give you a story from another domain. Frank Gehry, 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 says some the work he did was only made possible because of things like AutoCAD.
• 37:58
  Why did AutoCAD happen? 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.
• 38:26
  And now people could start building railroads and boilers and and 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. This same thing is happening in software right now. That we have some tools that are allowing us to unleash our creativity and get us our imagination closer to what we wish to build, executable artifacts by reducing the cognitive distance between those two by raising levels of abstraction.
• 38:57
  So my advice to folks is look like Frank Gehry, the fundamental still applied with him. You deal with forces, you deal with static and dynamic kind of things. Those are the fundamental metals metals for software engineering. Pretty simple. I'll give you some some sound bites.
• 39:12
  All architecture is design, but not all design is architecture. Architecture represents significant 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 abstractions that are crisp, this is coupling and cohesion. You want to build them as simple as possible. And that's kind of it.
• 39:45
  That's the fundamentals in which we do, if 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 me ends all of these.
• 39:59
  Bryan Cantrill: And do you do you worry at all? I mean, I I don't know that I do, but one thing that is, you know, part of what drives us to those simple but elegant powerful abstractions. Right? And 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.
• 40:25
  And the the I don't know that I'm nervous about this or not, but part of the reason that we're 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 I'd love to get
• 40:56
  Grady Booch: your take on. 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. Let's look back to other sciences like physics or mathematics. The Euler equation, e to the I pi I pi plus one equals zero. I look at that and I just shiver in ecstasy because it represents it it represents my gosh.
• 41:19
  From Saturday night live to Euler's equation. We're all over the map here. Welcome back
• 41:22
  Bryan Cantrill: friends. To This is your right your right on brand.
• 41:25
  Grady Booch: That's right. So so what does that mean? That represent impression is thing from which we can now generate other things. So in science, we look at the data, we try to compress it by building its abstractions. Once we have those abstractions, we can move forward.
• 41:42
  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 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.
• 42:05
  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 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 bullshit you or not.
• 42:23
  As I've often said, large language models are at best, they are are unreliable narrators at worst bullshit jet fuel. I tweeted about this, but my experience with with these LLMs has been 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 because there's not my reality. Yeah. And that's okay.
• 43:02
  And so you've got to be very careful about using them in a in a guided way. 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 before I'm those 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.
• 43:23
  So 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.
• 43:36
  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 eighteen hundreds, 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 in mention.
• 44:07
  So 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
• 44:18
  to increase
• 44:19
  their power. Yeah. That's what I worry
• 44:20
  Bryan Cantrill: about. I know. I told him it's like, 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 societally for Right.
• 44:35
  You know, for eons. And I know it's like it's it's fun to think about the kind of the robots rising up against us, but it's actually and actually for me, it's like personally I mean, I would kinda love that just because I would love to go to battle on behalf of all humanity against the robots and find all of their, know, speculative execution vulnerabilities and so on. It could be just like I think But it's like it's it's it's a fantasy. It's not like But so Grady, this point about abductive reasoning is really really good. I mean, I haven't heard it phrased exactly that way, but God that really you're you're exactly right.
• 45:10
  I mean, is the kind of that that's the bit that is missing that you are always gonna rely on. And in part because like they, you know, our colleague who worked on this thing that Adam described of the the the Lua interpreter generate the Rust program that generate the Lua to be interpreted as a channel program in CFS. One of the things that he commented is like, you know what I love about these things? They're kinda down for whatever. Like there's no there's no sense of like, wait, why are we doing this?
• 45:36
  Or like is wait, I think there's a better way to do this. There's like, nope, sounds great. Like, let's go. Let's go. I've already written two thirds of it.
• 45:44
  Let's go. Do you want me to roll it? 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, reconstructing my blown brain on your point about abductive reasoning because I think it's a very important point.
• 46:00
  Grady Booch: In so far as we surrender ourselves to these kinds of abstraction, that's where the danger lies. We must not, you know, abandon our humanity in the midst of it, which I'm gonna put in a plug. This is why I've been trying to do this documentary. Think Carl Sagan'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 the public sense because a lot of fear, a lot of, you know, fear mongering and and FOMO going on here.
• 46:27
  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. I am actually excited by what the future offers for us.
• 46:41
  Bryan Cantrill: Yeah. That is I think just very important and uplifting. I think it dropped in the right link to computing the human experience is the the the work that you've got. Because I I think this is great by the way. The idea of the of I mean, the story of computing, it is we have created so much plenty, so much prosperity with computing.
• 47:04
  We are I, you know, I I I as I have told people like the I read a terrific book on the history of the bi rotor combine called Dream Reaper by Craig Canine. 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. Because without agricultural technology, you and I and everyone else except for the king are in the fields. Yep.
• 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 concomitant fear that comes with it. And and sometimes that fear is very justified as it certainly was with nuclear weapons or nuclear power. And and and maybe that's it's humanity's overshoot that justifies that fear. But how do we kind of counteract that fear that was because I share your optimism. Both see the fears.
• 48:00
  You say the fear won't get you onto Fox News.
• 48:02
  Grady Booch: Right.
• 48:03
  Bryan Cantrill: There are that's where the absence of fear. The cool headed, the be calm, as you said, won't get you onto Fox News. Yes. How do we counteract that fear?
• 48:10
  Grady Booch: Yeah. Dubarism, especially in the AI space, gets you a lot of press. And that's why, you know, I I go head to head with folks such as Ray Kurzweil and the like, who nice guy. I met him. I think he's off base with regards to his predictions.
• 48:24
  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 like hate a lot of people.
• 48:35
  I hate people who are self serving narcissists 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. 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.
• 49:10
  That is tremendous. We've never had in our history of humanity the kinds of materials to do what 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?
• 49:33
  The answer is, you know, keep up with the fundamentals. Go off and try to build good things that are useful. 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 to try to find immigrants? Hey.
• 49:54
  If you wanna do that, great. But you gotta 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 a wonderful place and time, and you have wonderful skills to do things no one ever could have done before your generation.
• 50:21
  I mean, that's uplifting for me.
• 50:23
  Bryan Cantrill: 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 because even there was a there software boom and bust in the eighties that definitely predated me, but you very much lived through that rational right on the and then obviously the .com boom and bust. We the great recession.
• 50:53
  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 sixties in Amarillo, but because they think it's like, what? This is like a path to to solely a path to prosperity.
• 51:10
  Grady Booch: Yeah. Yeah.
• 51:11
  Bryan Cantrill: I mean, I I think it's kinda 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 Yeah.
• 51:22
  Grady Booch: 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 maelstrom. But it's a mixed metaphor.
• 51:32
  You know what I mean. You know, 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.
• 51:47
  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
  Bryan Cantrill: Let's wrap it up. Absolutely. So can I actually just ask for, do you have any book recommendations for we we got a bunch of readers here? What are some books along the way that really changed your thinking?
• 52:11
  Grady Booch: 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 Simon's the sciences of the artificial.
• 52:25
  Go also read Systematics by John Galt. Go reread again. Gosh. It just popped out of my head. I see the cover.
• 52:36
  The Mythical Man Month.
• 52:38
  Bryan Cantrill: I was just saying Mythical Man Month. Yeah. Yeah. Yeah. Absolutely.
• 52:40
  Grady Booch: Yeah. Go read, refactoring. You know, those come to mind. Those are great recommendations.
• 52:50
  Bryan Cantrill: 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
  Grady Booch: I'm not dead yet.
• 52:59
  Bryan Cantrill: That's right. The alright. Yeah. Monty Python. Don't know, but I I I got we got to explain all these things to to the youngsters here.
• 53:08
  Adam Leventhal: That's great.
• 53:09
  Bryan Cantrill: But Oh, thank you. They
• 53:11
  Grady Booch: can Google it.
• 53:12
  Bryan Cantrill: There we go. And and thank you too for, I think, taking on some of these, these loudmouths online. And 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, on behalf of software engineers, thank you very much.
• 53:29
  Grady Booch: You're most kind. Thank you for having me. This is the most fun I've had with my clothes on all day.
• 53:36
  Bryan Cantrill: Alright. Thank you very much, Grady. Appreciate it. Bye, guys. Alright.
• 53:40
  Adam, well, we go. That's
• 53:43
  Adam Leventhal: I'm just relieved that he had his clothes on for for this episode.
• 53:46
  Bryan Cantrill: Well, just just for today though. I mean, yesterday there was, you know, this so. I will take it. But thank you very much everyone. And so we we've got a couple episodes out there cooking that we're excited about.
• 53:58
  And I know we'll be we'll be kind of in and out for these next couple weeks, but look forward to I think we got some exciting episodes, Adam. Yeah. We have we we we our our our colleague, Rye, nailed a gnarly compiler bug on a p four compiler bug on Friday night. And definitely my I mean, my I think I think my first thought was thank God we're gonna live. But my second thought immediately following that was like, this is great because we got we got an episode.
• 54:29
  Okay. Can have content. Oh, thank God for the content. We got some good content coming up. So exciting stuff coming up.
• 54:37
  Awesome. Thank you. Hey, I defy anyone to play this episode at greater than one point zero x by the way. If you got through this episode at at at 1.5 x or faster, let us know. We'll send you a t shirt.
• 54:49
  Alright. Thanks everyone. Talk to you next time.