The third golden age of software engineering – thanks to AI, with Grady Booch

Some people worry that AI writing surprisingly good code could mean the end of software engineering, but Grady Bouche disagrees and says that we are entering the third golden age of software engineering. Grady Bouche is one of the founding figures of software engineering as we know it. He co-created UML, pioneered object-oriented design, spent decades as an IBM fellow, and has witnessed every major transformation this industry has undergone since the 1970s. In today's conversation, we discuss the three golden ages of software engineering and what history teaches us about surviving and thriving through major technology shifts, why coding has always been just one part of software engineering, and why the human skills of balancing technical, economic, and ethical forces are not going anywhere. Grady's direct response to Dario Aymoday's prediction that software engineering will be automated in 12 months, spoiler, he does not hold back, and many more. If you want to understand that the massive change that AI is bringing has, in fact, happened before, and not just once, this episode is for you. This episode was presented by StatSig, the unified platform for flags, analytics experiments, and more. Check out the show notes to learn more about them and our other season sponsors. Grady, it's great to have you back on the podcast again. Thanks for having me. Aloha. So, touching a little bit on the history of software engineering, you've said many times before that the entire history of software engineering is one of rising levels of abstraction. Can you walk us through the key inflection points that help us understand this? And then, of course, tie it into how AI is all tying into this. Well, the very term software engineering did not come to be until Margaret Hamilton was probably the first to anoint it. She, at the time, had just left the manned orbiting laboratory project. She was working on the Apollo program. And she was one of the very few people who were software developers in a sea of mostly men who were the hardware structural engineers. And she wanted to come up with a phrase that distinguished herself from the others. So she began using the term software engineer. And I think we can rightfully give her the claim to the first one that coined that. There were others that followed. Most notably, people talk about the NATO conference on software engineering. And when the organizers established that, which was actually a few years after Margaret's work, they did so as kind of a controversial name, not unlike how the term artificial intelligence was named controversially for its first conference on the West Coast. So there were others that followed. And after a period of time, it kind of stuck. And I think what it meant, the essence of what Margaret and others were doing, is to say, there's something engineering-ish about it in the sense that ours is a field that tries to build reasonably optimal solutions. You can't have perfect solutions that balances the static and dynamic forces around them, much like what structural, electrical, chemical engineers do. In the software world, of course, we deal with the medium that is extraordinarily fungible and elastic and fluid. And yet we still have the same kinds of forces upon us. Here, we've got the forces of the laws of physics. You can't pass information faster than the speed of light, which is kind of annoying in some cases, but hey, we'll have to live with it. There are issues about how large we could build things, largely constrained by our hardware below us. There are constraints we have on the algorithmic side of things. We may know theoretically how to do something, such as the Vertabri algorithm, which was essential to the creation of cellular phones. For the longest time, we didn't know how to implement it, but there was indeed a calculable solution. Similar stories with regards to fast Fourier transform. We knew the theory, but until Fourier transforms could be turned into something computational, we couldn't progress. And there are also other constraints upon us, not just these scientific ones and the computer science ones, but constraints such as the human ones. Can I get enough people to do what I need to do? Can I organize teams doing what I want to do? Ideally, the largest team size you want for software is zero. Well, that's not very practical. The next best one is one, and then it kind of grows from there. And there are projects that simply are of a certain scale that you cannot conceive of them being done by a small group of people. I mean, why do any of the large projects we have have a cadre of folks in them? It's because the footprint of these systems and their enduring economic and social importance is so great, you can't rely upon just an individual. That software must endure beyond them. And increasingly, as software moves into the interstitial spaces of the world, we have the legal issues, such as we see with, you know, digital rights management. But I think more importantly and overarching, the ethical issues. We know how to build certain things, but should we build them? Is it the right thing for us to do in our humanity? So these are the collection of things that are in a way, well not in a way, but absolutely are the static and dynamic forces that weigh upon a software engineer. And that's why I can say we are engineers because much like the other kinds of engineers, we build systems that balance those forces. And we do so in a medium that is absolutely wonderful. So that's software engineering. Now, I mentioned in our last call, there are certain ages of software engineering. And I think as we look from the lens of looking backward, there are at least two identifiable major epics in software engineering. In the earliest days, there was no software because what we did was simply managing our machines. And the difference between the hardware and the software was completely indistinguishable. You know, putting plugs in a plug board as was happened with the ENIAC. Is that programming? Well, yes, but there's not really software there. It's something else. And it wasn't until our machines came to the point in late 40s, early 50s, that we began to find a difference for them. Most of this software written at that time was bespoke. Well, really all of it was. And virtually all that software was tied to a particular machine. But the economics of software was such that we love these machines. We'd like them to be faster, but gosh, we put a lot of investment in the software itself. Is there a way to decouple these kinds of things? We talk about the recent history of our world. The term digital was not coined until the late 40s. The term software was not done until the 50s. And so even the acknowledgement that software was an entity unto itself was just about in my lifetime, which is frightening to think about. Yeah, like 70, 80 years ago. Wow. Yeah, yeah, exactly. So this is, this, we're an astonishingly young, young industry. If you were to take Carl Sagan's cosmic calendar and put software in it, we would be in the last few nanoseconds of that cosmic calendar. It would be less than a blink of an eye. But at any rate, as software began to be decoupled from hardware itself, then folks such as Grace Hopper and others were beginning to realize that this is a thing that we could treat as a business and an industry, as an institution unto itself. So the earliest software of course was, as it was software itself, was assembly language, which was very much tied to the machine. And jumping ahead a little bit, as IBM came along in the 60s, recognizing that there was a way to establish a whole architecture of machines with a common instruction language, then it was possible to preserve software investments and yet decouple it from hardware in a way that I could improve my hardware without throwing away the software. Once that realization happened, which was both an engineering decision, a business decision, and overall an economic decision, then the floodgates opened up. And all of a sudden we had a lot more software that could be and needed to be written. This was the first golden age of software engineering, in which we had software was an industry unto itself. And so the essential problems that world faced were problems of complexity. Complexity in that we were building things that were, you know, difficult to understand, that we're trying to manipulate our machines in some cunning ways. But it was complexity that by today's standards was, you know, laughably simple. We could, you know, this is the equivalent of hello world. But they were problems that were hard unto themselves. And so because we were so coupled to the machines, the primary abstraction used in the first golden age of software engineering was that of algorithmic abstraction, because that's what our machines did. Most of our machines were meant for mathematical kinds of operations. And so as was done in Fortran, it was a matter of building our software that could do formula translation. So that was the realm and the problems faced by the first generation. And then this first generation, like in timeline, where would you put it roughly? Timeline, I'd put it in the late 40s to the late 70s or thereabouts. And that's what dominated that timeframe. So the figures you would see would be Ed Yorden, Tom DeMarco, Larry Constantine. This is when ERP, sorry, not entity relationship ideas came about. And so these ideas of that kind of abstraction poured over not just to software, but also into the data side of things as well. This was an extraordinarily vibrant period of time in software engineering, in which we had the invention of flowcharts, for example, which were an aid to thinking about how to construct these kinds of systems. You saw a division of labor where you had people who would analyze the system, people who would then program it, people who would key punch the solutions, people would operate the computers. And again, this was largely driven by economic reason, because the cost of machines were far greater than the cost of the humans involved in them. So a lot of what was happening was done to optimize the use of the machines, which were very, very rare resources. The lesson in this, as we'll see coming back in the next generations, is that these forces, much like with software engineering itself, have shaped the very industry of software and economics, and the whole social context also influences them. So in the first generation, it was largely focused upon mathematical needs and the automation of existing business processes. So what you had happen is that you would have businesses that have literal floors of offices with people doing accounting and payroll and like that. And this was the low hanging fruit, because now all of a sudden we could accelerate those processes and actually improve their precision by pulling the human out of it and automating it. So the vast amount of software written during that time was business and mathematical and numerical kinds of things. Now this is an important thing, because while this was the focus, this was not the only kind of thing, because you saw in the periphery, or shall I say, from the point of view of a person who was a programmer in that time, it looked to them as the dominant places was in the IBMs, the insurance companies, the banks and the like. There was a lot of work going on outside that world in the defense industry as well. We saw people moving software and hardware into our machines of destruction, into our aircraft, into our missiles. We saw it moving into weather forecasting. We saw it moving into medical devices itself. So while the concentration was the things that the general public would see, a lot of stuff happening around the edges as well. I would say in the first golden age of software engineering, there was this central push of algorithmic abstractions into business and numerical things, but the real innovation was happening in that fringe. In particular, it wasn't in business cases, but it was in defense cases, because Russia was the clear and present threat for us at the time, in which there was a need to build distributed systems of real-time nature. Most of the systems I've talked about thus far were not real-time. And so we saw the rise of experimental machines such as Whirlwind. We saw the work in the mother of all demos, which was experimentation of various human interface kinds of things, which was not the center of gravity of software development at the time, with the things on the fringes. We saw researchers such as David Parnas, who were coming on the scene, C.A. O'Hara, Dijkstra, and others, were beginning to look at the formalisms of these systems and looking at treating software development as actually a formal mathematical activity. Grady just mentioned formal methods and formal mathematics in software engineering. Being able to verify that software does what it should has been a problem since the early days of software engineering. And this leads us nicely to our season sponsor, Sonar. As we're living through what Grady might call the third golden age of software engineering, AI coding systems generate code faster than we ever thought was possible. This rapid code generation has already created a massive new bottleneck at code review. We're all feeling it. All that new AI generated code must be checked for security, reliability, and maintainability. A question that is tricky to answer though, how do we get the speed of AI without inheriting a mountain of risk? Sonar, the makers of Sonar Cube, has a really clear way of framing this. Vibe, then verify. The vibe part is about giving your teams the freedom to use these AI tools to innovate and build quickly. The verify part is the essential automated guardrail. It's the independent verification that checks all code, human and AI generated, against your quality and security standards. Helping developers and organizational leaders get the most out of AI while still keeping quality, security, and maintainability is high on the main themes of the upcoming Sonar Summit. It's not just a user conference. It's where devs, platform engineers, and engineering leaders are coming together to share practical strategies for this new era. I'm excited to share that I'll be speaking there as well. If you're trying to figure out how to adopt AI without sacrificing code quality, come join us at the Sonar Summit. To see the agenda and register for the event on March 3rd, head to sonarsource.com slash pragmatic slash Sonar Summit. With this, let's get back to Grady and treating software development as a form of mathematical activity. And you saw the rise of, I said, distributed in real-time systems, primarily in the defense world. So from Whirlwind, it begat a system called SAGE, the Semi-Automatic Ground Environment, which came about during the 50s and 60s. And indeed, the last one was decommissioned, I think, in the 1990s. This was based upon the threat of Russia. This is pre-missiles. Russia would send a fleet of bombers over the Arctic and invaded the United States. So thus was born the DEW line, the Distance Early Warning System across Canada. And all that data was then fed into a series of systems called SAGE, the Semi-Automatic Ground Environment. This system was so large, it consumed, according to some reports, easily 20 to 30% of every number of software developers in the United States at the time. That's a lot of folks. But remember, back in the time, there were maybe only a few tens of thousands of software developers, but this was the biggest project. Basically, the military was the biggest spender in research and moving the industry forward, right? Because they had to. Absolutely correct. They had to, because it was a clear and present threat. And so a lot of the innovation was happening to the defense world. As I think I pass this phrase on to you in the documentary I'm working on on computing, I use the phrase that there are two major influences in the history of computing. One is commerce. We've talked about the economics already. And the second is warfare. And thus I claim, and I think there's much defense for it, much of modern computing is really woven upon the loom of sorrow, referring back to Descartes' loom. So yeah, a lot of the things we take for granted today, like the internet, like micromanagerization, this all came from government funding in these cases. So we owe a lot to the Cold War. This phase, was this still the first golden age or we passed the first golden age? These are the things happening in the first golden age. But what I'm pointing out is there was sort of a center of mass to it, but lots of things happening on the edge that were driving software out from its primary roots. So let's recap here. In the first golden age, you had the focus primarily upon mathematical and business kinds of applications. And the primary means of decomposition was an algorithmic abstraction. We looked at the world through processes and functions, not so much through data. But on the fringe, we had organizations, use cases that were pushing us beyond. something like that, which was an attempt to remove the number of languages that exist and try to reduce it to one language that ruled them all. Now, what was interesting is that you saw at this time, there was a lot of interesting research that was feeding into it, the work of abstract data types from Galgen and the ideas of information hiding from Dave Parnas, separation concerns, the ideas, today we would call it clean programming, a clean coding, but it's the ideas of literate programming from Knuth. So these kinds of things were bubbling away in the late seventies and early eighties, and Ada was a little bit of a push to make that happen on a big scale. No other industry or company could really do it because they didn't have the exposure or weight or gravitas or economic powerhouses, US military at the time did. At the same time, you had some interesting work going on in laboratories like at Bell, which had begot C and Unix and the like, which was becoming incredibly important, but there was this crazy researcher at the time by the name of Bjarne Stroustrup, who was saying, wow, you know, this is kind of cool, but hey, let's take some of these ideas from Simula, I should mention Simula, which was the first object-oriented language, and let's see if we can apply them to C because, you know, C's got problems with it. Let's see if we can move about. So what was happening in the background in academia and in these fringes was the realization that we needed new kinds of abstractions, and it wasn't just algorithmic abstractions, but it was object abstractions. Turns out there's an interesting history behind that dichotomy. There is a discourse in Plato about that very kind of split in which he has, he has a dialogue between two people who are, you know, talking about how I look at the world, and one of them says, we should look at the world in terms of its processes. This is the ancient Greek philosopher from like before Christ. That guy, that Plato, he brought up some parallel ideas. He brought up the ideas of the dichotomy of looking at the world for two lenses. The very Plato whose work has now been banned in certain U.S. universities because he was so radical, right? But, but in one of these dialogues, he observed that one of the writers said, Oh, we have to look at the world through, through the processes, how things flow. And the other one said, no, no, no. We have to look at them through things. And this is where the idea of atoms came about. The very term atom came from Greek terms and that terminology. So the idea of looking at the world and looking at, and looking at the world or basically abstractions is not a new one. But people like Parness and others and the designers of Simula said, wait a minute, we can apply these ideas to software itself, and we can look at the world, not just through algorithmic abstractions, but we can look at them through object abstractions. Now there's another factor that came into the place, and this is where the inventor of Fortran came into be. After Fortran, he went off and he did this at IBM, of course, he, he was made a fellow and he went off and said, this was fun, but I want to do something else. And he said, let's, let's look at a different way of programming. And it was the idea of functional programming, which was looking at the world through mathematical functions, stateless kinds of things. So there was work here. We are talking, what in the seventies now. In which, uh, the ideas of functional programming came to be, I had a chance to interview him a few, a few months before he passed away and I asked him, you know, why did functional programming never make the big time? And his answer was because functional programming makes it easy to do hard things, but it makes it an astonishingly impossible to do easy things. Yeah. So, so functional programming has a role. There's no doubt. And I think its foundations were laid at the time by John, but even today it has a role, it has a niche, but it hasn't become dominant because of that very same edict. So at any rate, so here we are at the sort of end of the first golden age of software engineering and moving into the second, what were the forces that led us into that first off it was growing complexity. Grady just mentioned how growing complexity was a force pushing the industry into a new golden age of software engineering. Fast forward to today and software complexity keeps growing, growing and growing in part, thanks to AI generating a lot more code, a lot faster. And this brings us nicely to our season sponsor, WorkOS. WorkOS provides the primitives that make it easy to make your app enterprise ready. But under the hood, there's so much complexity that happens. I know this because I recently took part in an engineering planning meeting at WorkOS called the Hilltop Review, an engineer walking through their proposed implementation. In this review, we discussed how to implement authentication for customers when their users authenticate across several platforms using WorkOS. For example, what should happen if a user logs out on the mobile version, should they stay logged in in the web version? What about the other way around? We covered 10 plus similar questions. The answer as I learned goes down to, it depends what the customer using WorkOS wants. The WorkOS team walks through edge cases I had no idea existed and then turns those decisions into configurable behavior in the admin panel. So customers choose the right trade-offs for their product and their users without having to build and maintain all of this logic themselves. But this is not always enough. And when customers have unique needs, the WorkOS engineering team often works with them directly to figure out how to solve their very specific problem. They then generalize these solutions so they become part of the platform for everyone. After this planning session, I have a newfound appreciation for just how much complexity WorkOS absorbs so product and engineering teams don't have to. The same planning goes into all WorkOS products and customers get all the benefit. Learn more at workos.com. And with this, let's get back to Grady and how the second golden age of software engineering came about. Well, as I mentioned, growing complexity, difficulty of building software fast enough and building big enough software. And I would add to this, the things that came about in the defense world, which were the desire and an obvious value in building systems from a distributed kind of way. Now come on to the scene because what was happening around that same time is the fruits of micro-miniaturization came to be, and it led us to the personal computer. This was because of transistors, right? And, and the breakthroughs in, in like electronics and, and. Precisely. And, you know, this too was a vibrant time because you had, you know, you had hobbyists who could put these things together and, and build them from scratch and there were no personal computers at the time. Was this the first time that hobbyists could actually like meaningfully get their hands on it in, in the history of computing really? I think at scale, yes. You had, you had hobbyists such as Pascal back at his day, who decided that his father was so tediously working over his accounting that Pascal built a little machine for him. So there was hobbyist work at that time, no doubt about it, but in terms of scale and also remember post-World War II, you had the addition of, especially in the United States, you had more disposable income, which made it possible for hobbyists to actually do these kinds of things. And then lastly, you had the military who was producing integrated circuits and transistors, and all of a sudden, especially in Silicon Valley, you could go down to Fry's or the Fry equivalent, which was before Fry's and buy these things, they were just, they were there. And so it enabled people to play and play is an important part in the history of software. So you had this wonderful thing happening in I'd say the late seventies and early eighties, which was a vibrant time of experimentation. There's a delightful book called what the Dormouse said, which posits that the rise of the personal computer was also tied together with the rise of the hippie counterculture, and so this, this drive toward, you know, power to the people and, you know, let's, you know, love like make love, not war, these kinds of things, this is the era of Stuart Brand, the era of, of the Murray pranksters and the like, and that led to things like the well, which was the very first social network, which was today. We call them bulletin boards, which grew up in, in Silicon Valley. Quick aside, Stuart, just a lovely fellow. He was actually mentioned as one of the Murray pranksters in, uh, in the book about, uh, about them. He's still on the scene and he's just released a wonderful book called maintenance part one, which looks at the problems of systems software as one of and the problems of maintenance associated with them. Anyway, here we are. Um, late seventies, early eighties. Uh, also a very vibrant time because there's a lot of cool stuff that could be done. Yeah. And it's Stripe Press is publishing this actually. So, uh, I'll, I'll leave a link in the show notes below. It looks like a really nice book and Stripe Press is known to produce excellent quality. So I'm actually excited to look into this. Yeah. It's a great, great book. So the realization was that we now had the beginnings of theories of looking at the world, not through processes, but through objects and classes. We had the, the demand pull of distributed systems, the demand pull from trying to build more and more complex systems. And so there was also this perfect storm that really launched that second golden age. And that's frankly, where I came onto the scene. I was just in a lucky place at a lucky time. Um, I was at the time working at Vandenberg Air Force Base on, uh, missile systems and space systems. Uh, there was a envisioned, uh, military space shuttle and I was part of that program as well. It was great. It was a fun place to be. Cause we'd have launches like twice a week. It was pretty cool. You'd run up and say, wow, look at that. It was, it was pretty wild. At the building in which I work, I had to evacuate whenever there was a building, ever a launch, because it was a Titan launch. The Titan launch pad was really close to us. And if it had blown up on the light launch pad, it would have, it would have blown up our building, which would have been really annoying. So yeah. And one other, one other quick story. You could always tell when it was the secret launches going off the secret spy satellites, because there were two main clear indications. The first is all the hotels would fill up because you'd have the contractors come in. And second, the day of the launch, the highway nearby where you could see the launch would fill up with people to watch it. So there were no secrets. In that world. So here we are late eighties. Uh, the, the world was poised for a new way of looking at the world. And that was object-oriented programming and object-oriented design. So how does that differ from the first generation? It differs in the sense that we approach the world at a different layer of abstraction. Rather than just looking at the data, which was this raw lake out here and the algorithms we have to manipulate them, we bring them together into one place. We combine the, the objects and the, and the, uh, processes together. And it worked, my gosh, it'll label us to do things we could not do before. It was the foundation for a lot of systems, uh, go out to the computer history museum and go look at the software for, for MacWrite and MacPaint. It was written in object Pascal, one of the early object-oriented programming languages, one of the most beautiful pieces of software I've seen. It's, it's well-structured, it's well-organized. And in fact, much of the design decisions made in it, you still see persistent systems such as Photoshop today. Uh, they still exist, which is an interesting story unto itself about the lifetime of software. So looking at software through the lens of object proved to be very effective because it allowed us to attack software, the software complexity problem in a new and new and novel way. And so much like the first golden age, this was also a very vibrant time. And I would say the, the eighties and nineties where you had people such as the three amigos, me, Ivar Yarkasin, uh, and, uh, Jim Rumbaugh, you had Pete Code, you had Larry Constantine was back on the scene, uh, Ed Yorden was back on the scene. Uh, a lot of folks who were saying, let's look at software, not from processes, but from objects and think about it. Now, this was great. We made some mistakes. There was an overemphasis upon the ideas of inheritance. We thought this would be the greatest thing. Uh, that was kind of wrong, but the idea of looking at the world from classes and objects, it was kind of built in. And so what began to happen, this was also an economic thing is it's people started building these things. All of a sudden we saw the rise of platforms. Now there was precedence for this because in the first golden age of software, people started, you know, building the same kinds of things over and over again. The idea of collecting processes, collecting algorithms that were commonly used, like, you know, how do I manipulate a hard drive or a drum? How do I write things to a teletype? How do I, you know, put things on a screen, uh, these kinds, how do I sort these kinds of algorithms could be codified. And so the first ideas of, if you will, packaging them up into reusable things came into be, this is when, at least in the, the, the world of, uh, business systems, IBM share came to be share was a customer, uh, organized group that literally shared software among one another's totally free. And this was in the first golden age, right? This first golden age. Right. So this was kind of like a primitive or like, I mean, looking back a more primitive way of just like packaging stuff into like, yeah, related, may that be sorting algorithms or, or as you said, IBM, IBM was literally distributing just like functions and things like that. IBM wasn't doing it. It was perfect. It was completely public driven. IBM supported it, but it was, yeah. So the point is this was the earliest open source software. So the ideas of open source existed. And remember too, in the economics of software and hardware, back in the time, software was pretty much given away free by the main manufacturers. IBM did not charge for software until later in the later 60s, 70s, they realized, my gosh, we can make money and they decoupled software and hardware and started charging you for it. But in the earliest days, there was this vibrant community of people who could say, you know, gosh, I've written this thing, go ahead and use it. That's fine. No problem. So open source was, was late at that time. And the same thing began to happen in the second golden age in which we saw much like the rise of operating systems, the rise of open source software, the same phenomena applied in the second golden age, but now it was a new layer of abstraction. Oh, I want to have now a new library for, you know, writing to these new fangled CRTs. Here it is no competitive value in me having it, but by gosh, it enables me to build some really cool things. You can have it too. So open source laid its roots, took its ideas from the first golden age, applied itself in the second golden age, but a different kind of abstraction. Lurking in the background, speaking of economics was the rise of platforms. Cause now all of a sudden these libraries are becoming bigger and bigger. And as we moved to distributed systems, there was the rise of back then we called it service oriented architectures. There was this need of, you know, we had HTML and the like we could, you know, pass links back and forth. But there was some crazy folks that said, wouldn't it be cool if we could do things like, you know, share images. And that was one of the things that Netscape allowed, which was, they produced this addition to HTML that allow you to put images. Wouldn't it be cool if we could pass messages back and forth via HTML? So all of a sudden the internet became via HTML protocols, HTTP protocols became a medium at a higher level of abstraction for passing information and, and processes around, but there was a need to package it up. So thus was born service oriented architectures, SOAP, the service oriented architecture, service oriented protocols, all that the predecessors to what we have today, and this was laying the foundations in the second golden age for the, the beginnings of the platform era, which is, you know, what Bezos and, and others have really brought us to where jumping ahead in our current age, where you have these islands, which are sort of formed by all sorts of APIs around them. But it was in the second golden age is they were being born. And when you say platforms, what do you mean when you say the rise of platforms? What, how do you think of a platform? AWS would be a good one. A Salesforce would be another one. And with this, let's get back to the Y2K event that Grady was talking about. You know, and then nothing happened and you're like, okay, it was just a hoax. So anyone who went through there, uh, like kind of learned to like not trust these predictions, but you're right. Like knowing what, no, there was so much work, right. To make sure that that overflow did not like hit at the wrong place. Yeah. So here we are mentally put yourself in the first, uh, first decade of the 2000s is a fun place because, well, yeah, the, there was the crash, but still so much fun stuff to do so much great software to be written. We were still only limited largely by our imagination. Now I'm going to pause for a moment and backfill with some history that I hadn't mentioned. We've been talking about software in general. There was a parallel history going on in AI in which we saw also some generations. The first golden age of AI was in the forties and fifties, where you had people such as Herbert Simon and Newell and Minsky in particular. The focus there was upon, gosh, we could build intelligence artificially using symbolic methods. So this was the first golden age, first great age of AI. And the ideas of neural networks were tried. The thing they built was the snark, which was the first vacuum tube artificial neuron. It took like five vacuum tubes to make a single neuron. And there was a report coming out of the UK at the time that said, we're spending a lot of money here, but by gosh, it doesn't work. And so the first golden age ended when they realized you can't really build anything interesting. And furthermore, neural networks are a dead end, largely a dead end because we didn't have the computational power to do them. We didn't have the algorithmic concepts, the abstractions to know what to do with them once we had them at scale. The second golden age of AI was really in the eighties when you had people like Falkenbeim come along and say, hey, there's another way of looking at it. And it's looking at it through rules. Thus was born the idea of machine learning. Things like my sin and the like came upon the scene, but there too, we saw the AI winter come about. By the way, there was an interesting rise in hardware at the time. The Lisp machine, the thinking machine were all built during this time, vibrant periods of time of a, of computer architectures. So you see these kind of feeding into one another, but ultimately it failed because they didn't scale up. Once you got beyond a few hundred, if then statements, we simply didn't have a means of building inference engines that could do anything with them. So here we are an exciting time again to first decade of the two thousands. AI was kind of, you know, back in the back rooms, we still had a lot of cool things to do and more and more distributed kind of systems. Plus fueling that also was the fact that software was now in the hands of individuals through personal computers. So the demand for software was even greater. I would claim, and this may be a little controversial. We are in the third golden age of software engineering, but it actually started around the turn of the millennium. It's not, it's not now, but it's then. And the first indication of the rise of it is we saw a new rise in levels of abstraction from individual components of our software programs to whole libraries and packages. That were part of our platform. Oh, I need to do messaging. Well, I'm not going to do that on my own machine. I can go out to this library, which does messaging. I need to manage this whole chunk of data. Let's, you know, use Hadoop or something like that. It wasn't around the time, but the seeds where it was growing. So we again saw a growth and levels of abstraction from just simple programs to now subcomponents of systems. And that was the next great shift that happened and our methodologies and our languages and all that began to follow. So the third golden age, we've been in for several years already and not to get ahead of ourselves, what's happening with AI assistance and the like in the coding space is in many ways, a reaction to the growth of those kinds of things, because we want to accelerate their use. We want to, we have so many of those kinds of libraries out there and not enough people to know about them. We want to accelerate the use of them by having aides that help us do so. So that's the context in which I put AI agents, such as cursor and chat TPT and, and that they are in a way, a follow on to the forces that have already led us to this third golden age. So we are now in a very vibrant time, but the problems are different from the first and second generations. What are the problems now? First, it's problems of we have so much software, how do we manage it? And we have to deal with issues of safety and security. Can somebody sneak in something that I can't trust? How do I defend myself against that? It is so easy to inject something in the software supply chain. How do I prevent the bad guys from putting stuff inside there? How do I defend against it? The whole history behind stuck necks and the like is a good one to show, you know, espionage and software. And so all of a sudden the human issues that we had for much of the history of software, we were insulated about because it was so much part of civilization. These human issues became front and center, clear and present for our world. And the other element is to the economic issues of it. We had now companies that were too big to fail. What would happen if a Microsoft were to go under? What would happen if a Google were to go under? They're so economically important to the world that the things they do, they sneeze and some part of the world catches a cold. And so the problems we have now in this third golden age of software are different than they were than the first and second generations, but equally as exciting. And then last, we have the ethical issues. Because I can do this kind of software, it is possible for me to track where you are in every moment of the day. I can do that. Should I do that? Some will say, yes, I should, because it's, you know, it's a good thing for humanity. Others will say, not so sure about that. So I like how you laid it out. It's very interesting, especially through both your experience and also sharing the history that I think a lot of us don't really reflect on, which is how it all started. And just honestly, how young it is. I mean, you know, like 70 or 80 years can be long depending on how old you are. But it is, it's not even a generation or it's barely a generation. It's a couple of generations. Yeah. But one thing that I'm seeing across the industry right now, which feels very like this setup makes sense. But one thing that kind of feels it contradicts it for a lot of software engineers today is there seems to be an existential dread that is especially accelerating, especially over the winter break. What happened over the winter break is before the winter break, these AI LLMs were pretty good for autocomplete. Sometimes they could generate this or that. And over the winter break, I'm not sure if you played with some of I have with the new models. They actually generate really good code to the point that I'm starting to trust them. And as far as the history of software has been, my understanding is that software developers have written code and it's a hard thing to do. And a lot of us, you know, it takes years for us to learn and to be excellent at it even longer. And so a lot of us are starting to have this really existential crisis of, OK, well, the machine can write really, really good software code, first of all, like WTF. And how did this happen over the last few months? And then the question is, what next? It feels that it could shake the profession because I feel coding has been so tightly coupled to software engineering and now it might not be. You know, looking at, I guess, you know, like taking a breathe out first and looking through both the history and what is your take on what's happening right now? Well, let me say that this is not the first existential crisis the developers have faced. Tell us more. They have faced the same kind of existential crisis in the first and the second generation. So that's why I look at this and say, you know, this too will pass when I talk to people who are concerned about it. Don't worry. Focus upon the fundamentals because those skills are never going to go away. I had a chance to meet Grace Hopper. She was just a delightful, you know, fireplug of a woman. Just amazing, amazing thing. For your readers, go Google Grace Hopper and David Letterman. And there's this, she appeared on the David Letterman show and you'll get a sense of her personality. We're going to link it in the show notes below. She, of course, is the one who recognized that it was possible, here we are in the fifties, that it was possible to separate our software from our hardware. This was threatening to those who were building the early machines because they said, you know, gosh, you could never build anything efficient because you have to be tied so closely to the machines and many in that field, and they wrote about it, expressed concerns that, you know, this is going to destroy what we do. And it should have. So we had here the beginnings of the first compilers. The same thing happened with the invention of Fortran, where people were saying, gosh, you know, we can write tight assembly language better than anybody else, better than any machine can kind of do. But that was proved wrong when we moved up a level of abstraction from the assembly language to the higher-order programming languages. And so you had a set of people who were similarly concerned and distressed by the changes in levels of abstraction because they recognized that the skills they had in that time were going to go away and they were going to be replaced by the very thing themselves created. Now you didn't see as much of a crisis because there weren't that many of us back in that timeframe. We're talking, you know, a few thousands of people. Now we're talking millions of people who ask quite legitimately the question, what does it mean for me? So I've had, as I'm sure you have had, a number of, you know, especially young developers come up to me and say, Grady, what should I do? Am I choosing the wrong field? Should I, you know, do something different? And I assure them that this is actually an exciting time to be in software. Because of the following reasons, we are moving up a level of abstraction, much like what happened in the rise from machine language to assembly language, from assembly language to higher-order programming languages, from higher-order programming languages to libraries. The same kind of thing happened. And we're seeing the same change in levels of abstraction. And now I, as a software developer, I don't have to worry about those details. So I view it as something that is extraordinarily freeing from the tedium of which I had to do, but the fundamentals still remain. As long as I am choosing to build software that endures, meaning that I'm not going to build it and I throw it away. If you're going to throw it away, do what you want. That's great. And I see a lot of people using these agents for that very purpose. That's wonderful. You're going to go off and automate things you could not have afforded to do today. And if you're a single user for it, then more power to you. This is the hobbyist era and the hobbyist side of software, if you will. Much like we saw in the earliest days of personal computers, where people have built these things. Great stuff. Great ideas will come from it. I like the comparison. Yes. Yeah. Great ideas will come from it. You know, people will build skills. We'll do things we could not have done before. We'll automate things that were economically not possible, but they're not going to endure necessarily. But still, we will have made a valuable impact. And I guess just like in the first era where personal people could buy it, you will have people come into the industry who have honestly nothing to do with it. And they might bring amazing ideas, right? Like back then, you know, a school teacher might have bought a personal computer today. I just talked to my neighbor upstairs, an accountant. She has instructed ChatGPT to build some Apps Script to help their accounting teams process a bit better because she knows how that thing works. Nothing to do with software, but now creating their own personal throwaway software, by the way. Yes, absolutely. The same parallels. And I celebrate that. I encourage it. I think it's the most wonderful thing, which is why we are in this vibrant period. In the early days of the personal computer, the very same thing happened. You found artists drawn to, especially the PC and the Amiga at the time. You found gamers who realized, I've got a new medium for expression that I did not have before. And that's why it was a very vibrant time. The same thing is happening. And so much of the lamenting of, oh, gosh, we have an existential crisis, are those who are narrowly focused upon their industry, not realizing that what's happening here is actually expanding the industry. We're going to see more software written by people who are not professionals. And I think that's the greatest thing around because now we have software, much like in the counterculture era of the personal computer, the same thing is happening today as well. I like what you're saying. However, one thing that I also pay attention to, one person I pay attention to is Dario Amodei, the CEO of Antropic. And the reason I pay attention to him is I tend not to pay attention to CEOs, but he actually said about a year ago, he said something interesting. He says he thinks most code will be generated by AI, about 90% of it, maybe in a year and then more. And we thought that's silly. And then he was right. And code was generated. Yes. And now he said another thing interesting. That sounded interesting. But the next one sounds scary. He said, I quote, software engineering will be automatable in 12 months. Now, this sounds a lot more scarier for reasons we know. Coding is a subset of software engineering. But he said this. What is your take on this? And you've had a strong response already. So I have one or two things to say about it. So first off, I use Cloud. I use Anthropic's work. I think it's my go-to system. I've been using it for problems with JavaScript, with Swift, with PHP, of all things, and Python. So I use it. And it's been a great thing for me, primarily because, you know, there are certain libraries I want to use. Google search sucks. Documentation for these things suck. And so I can use these agents to accelerate my understanding of them. But remember also, I have a foundation of at least one or two years of experience in these spaces. Okay. A few decades where I sort of understand the fundamentals. And that's why I said earlier that the fundamentals are not going to go away. And this is true in every engineering discipline. The fundamentals are not going to disappear. The tools we apply will change. So Dario, man, I respect what you're saying. But recognize also that Dario has a different point of view than I do. He's leading a company who needs to make money. And it's a company who he needs to speak to his stakeholders. So outrageous statements will be said like that. I think he said these kinds of things at Davos, if I'm not mistaken. It was very recent, yes. And I'd say politely, well, I'll use a scientific term in terms of how I would characterize what Dario said and put it in context. It's utter bullshit. That's the technical term because I think he's profoundly wrong. And I think he's wrong for a number of reasons. First, I accept his point of view that it's going to accelerate some things. Is it going to eliminate software engineering? No. I think he has a fundamental misunderstanding as to what software engineering is. Go back to what I said at the beginning. Software engineers are the engineers who balance these forces. So we use code as one of our mechanisms, but it's not the only thing that drives us. None of the things that he or any of his colleagues are talking about attend to any of those decision problems that a software engineer has to deal with. None of those we see within the realm of automation. His work is primarily focused upon the automation at the lowest levels, which is, I would put, akin to what was happening with compilers in these days. That's why I say it's another level of abstraction. Fear not, oh developers, your tools are changing, but your problems are not. There's another reason why I push back on what he's saying. what I wanna do, so go do it for me. So that's why I say these kinds of tools are another shift in the levels of abstraction because they're reducing the distance from what I'm saying in my English language to the programming language. Last thing I'll say is that, you know, what do we call a language that is precise and expressive enough to be able to build executable artifacts? We call them programming languages. And it just so happens that English is a good enough programming language, much like COBOL was, in that if I give it those phrases in a domain that is well enough structured, it allows me to have good enough solutions that I, who know those fundamentals, can begin nudging and cleaning out the pieces. That's why the fundamentals are so important. And speaking of history rhyming, one thing that happened in both the first age and the second golden age, or as we jumped abstractions, or every time we had an abstraction, is some skills became obsolete, and then there was a demand for new skills. For example, when we are from assembly level, the skill of like knowing how the instructions set of a certain board and knowing how to optimize it, that became obsolete in favor of thinking at a higher level. In this jump right now, where I think it's safe to say we're going from, we do not need to write any more code and the computer will do it pretty good and we'll check it and tweak it, what do you think will become obsolete and what will become more important as software professionals? Great question. The software delivery pipeline is far more complex than it should be, that, my gosh, just getting something running is hard if you have no pipeline. If you're within a company such as a Google or a Stripe or whatever, you have a whole, you have a huge infrastructure about around them. A custom one, yes. Yeah, a custom one, yes. And so there is low hanging fruit for the automation of those. I mean, I don't need a human that fills in the edges of those kinds of things. By the way, I'm talking about, in effect, infrastructure as software. It's not just raw lines of code. So this is low hanging fruit where we could begin seeing these agents that say, hey, I want you to go, gosh, I don't know, spin up something for this part of the world. I don't want to write the code for that stuff because it's complex and messy. I'd rather use an agent that helps me do it. So there's a case where I think you're gonna have the loss of jobs in those places where it's messy and complex because the automation has clear economic and, frankly, value in terms of security. That's a place where people are gonna need to re-skill. In the building of simple applications and the like, well, I think people who had skills and saying, I want to build this thing for iOS or whatever, they're gonna lose some jobs because, frankly, people could do it just by prompting it. That's great. That's fine because we've enabled a whole nother generation of folks to do things that professionals did in the past, exactly what happened in the era of PCs themselves. What should these people do? Move up a level of abstraction. Start worrying about systems. So the shift now, I think, is less so from dealing with programs and apps to dealing with systems themselves. And that's where the new skillset should come in. If you have the skills of knowing how to manage complexity at scale, if you know as a software engineer how to deal with all of these multiple forces, which are human as well as technical, your job's not gonna go away. If anything, there will be even greater demand for what you're doing because those human skills are so rare and delicate. So you mentioned the importance of having strong foundations and you've previously said, I'm actually quoting you, the field is moving at an incomprehensible pace for people without deep foundations and a strong model of understanding. What foundations would you recommend people to look at, both students, people who are at university studying or looking for their first job, and also software professionals who now actually want to go back and strengthen those foundations, that will be helpful. I find my happy place, if you will, my sweet space that I retreat back to when I'm faced with a difficult problem, back into systems theory. Go read the work of Simon and Newell in the sciences of the artificial. There's a whole set of work that's come out on complexity and systems from the Santa Fe Institute. It's those kinds of fundamentals of system theory that ground me in the next set of things in which I went to build. I think I mentioned to you in one of our previous discussions, I was doing some really interesting work on NASA's mission to Mars. We were faced with an issue of saying, hey, we want to have people go off on these long missions. We want to put robots on the surface of Mars. And so I was commissioned to go off and think about that for a while. And in effect, I realized NASA wanted to build a HAL. You'll notice I've got a HAL above me here. This is, I'm a great one for history. This is my sort of domiciles that passes behind me. If you know the history behind the sort of domiciles, the King Domiciles, he was always kept humble because at his throne, there was a sword right above him on a thread. So he felt, you know, constantly, you know, unease. And this is why I have HAL behind me as well. For some reason, NASA didn't want to kill all the astronauts use case. Don't understand why, but we threw that one kind of out. But if you look at the problems there, this is a systems engineering problem because you needed something that was embodied in the spacecraft. Much of the kind of software we have today in AI is disembodied. The cursor, the copilot's in like, they have no connection to the physical world. So our work was primarily in embodied cognition. Around the same time, I was studying under a number of neuroscientists trying to better understand the architecture of the brain. And here's where the fundamentals of that came together for me, because I began to realize there are some certain structures we see in systems engineering that I can apply to the structure of these really large systems. Taking ideas of Marvin Minsky's Society of Mind, which is a way of systems architecting multiple agents. We're in agent programming now, which I think people are just beginning to tap upon how those things apply. They need to go look at systems theory because that problem has been looked at with multiple agents already. Go read Minsky's Society of Mind, you'll see some ideas that will guide you there in dealing with multiple agents. The ideas from Bayer's of, which was manifest in early AI systems, such as hearsay. The ideas of global workspaces, blackboards and the like, another architectural element. The ideas of subsumption architectures from Rodney Brooks. His was influenced by biological things. If you look at a cockroach, a cockroach is not a very intelligent thing, but we know there's not a central brain in it and yet it does some magnificent things. We have been able to map the entire neural network of the common worm. We're not flush with evil worms running around the world. There's something else going on there, but biological systems have an architecture to them. So to go back to your question, by looking at architecture from a systems point of view, from biology, from neurology, from systems in the real world, as Herbert Simon and Newell did, this is what's guiding me to the next generation of systems. And so I would urge people looking at systems now, go back to those fundamentals. There is nothing new under the sun in many ways. We've just applied them in different ways. Those fundamentals in engineering, they're still there. And then as closing, you gave some really good recommendations to read, to ponder, to educate yourself and get ideas that will probably be useful in this new world, especially as we're gonna have a lot more agents, for example, like I now just heard that agents will be part of Windows 11, an operating system, so they will be everywhere. But looking back at the previous rises of abstractions and also the previous golden ages, the people who did great at the start of a new golden age or at the start of a new abstraction, even if they were not amazing at the previous one, what have you seen those people do? And based on this historical lesson, what would you recommend if we were just to kind of copy successful things that people did? Because I feel this is an opportunity as well, right? We have this rise of abstraction, a lot of people will be paralyzed, but there will be new superstars being born who will be basically riding the wave and they will be the experts of agents, of AI, of building these new and complex, a lot more complex systems that we could have done before. So as I alluded to earlier, the main thing that constrains us in software is our imagination. Well, actually that's where we begin. We're actually not constrained by imagination. We can dream up amazing things. And yet we are constrained by the laws of physics, by how we build algorithms and the like, ethical issues and the like. So what's happening now is that you are actually being freed because some of the friction, some of the constraints, some of the costs of development are actually disappearing for you, which means now I can put my attention upon my imagination to build things that simply were not possible before. I could not have done them because I couldn't have raised a team to do them. I couldn't have afforded that. I could not have done it because I couldn't have had the reach in the world as I did before. So think of it as an opportunity. So it's not a loss. It'll be a loss for some who have a vested interest in the economics of this, but it's a net gain because now all of a sudden, these things unleash my imagination to allow me to do things that were simply not possible before in the real world. This is an exciting time to be in the industry. It's frightening at the same time, but that's as it should be. When there's an opportunity where you're on the cusp of something wonderful, you should look at the abyss and say, you can either take a look and say, crap, I'm gonna fall into it, or you can say, no, I'm going to leap and I'm going to soar. This is the time to soar. Grady, thank you so much for giving us the overview, the outlook, and for a little bit of perspective. I personally really appreciate this. And I hope I offered some hope as well. I think you definitely did. This was a really inspiring episode. Thank you, Grady. One thing that really struck with me was when Grady pointed out that developers have faced this exact existential crisis before, multiple times, in fact. When compilers came along, assembly programmers thought their careers were over. When high-level languages emerged, the same fear ripped through the industry. And each time the people who understood what actually was happening, that it was just a new level of abstraction, they came out ahead. This historical lens is something that I think we often miss when some of us are caught up in the day-to-day anxiety of new AI capabilities. I don't think we're at the end of software engineering, and neither does Grady. We're at the beginning of another chapter, and if history is any guide, it's going to be a pretty exciting one. If you found this episode interesting, please do subscribe in your favorite podcast platform and on YouTube. A special thank you if you also leave a rating on the show. Thanks, and see you in the next one.