Evolution of software architecture with the co-creator of UML (Grady Booch)

The entire history of software engineering is one of rising levels of abstraction. What we are witnessing now is the emergence of another level of abstraction, which provides us with extraordinarily powerful frameworks from which we can build systems. As I alluded to earlier, the architectural decisions that were front and center for us in the past are now embodied within these frameworks. This raises new decisions: What cloud service should I use? What messaging system should I use? What platform should I use?

That's the decision that involves many economic factors, not just software-related decisions. I believe the role of the architect has changed because I am now addressing systemic problems, not just software issues. Grady Booch is a trailblazer in software engineering. He built his first computer 57 years ago at just 12 years old and is recognized for his decades-long work in advancing the fields of software engineering and software architecture. He is the co-author of UML and originated the term and practice of object-oriented design.

He's an IBM Fellow, an ACM Fellow, and has been awarded several other prestigious awards for his work in software architecture. He is the author of six books and more than 100 technical papers on software engineering. In this conversation, we cover the first two golden ages of software engineering, how UML was created and why Grady disagrees with how it has evolved since version 1.0, how the practice of software architecture has changed over time, Grady's views on large language models, interesting stories such as how Grady was offered the position of Chief Architect at Microsoft but declined Bill Gates' offer, and much more. If you enjoy the show, please subscribe to our podcast on any podcast platform and on YouTube. It's safe to say I'm talking with a living legend in the field of software engineering, so welcome to the podcast.

Emphasis on living—I'm not done yet, yes. Absolutely. So to kick off, you're a Chief Scientist at IBM. That's a pretty fancy title. What does it mean to be a Chief Scientist at IBM?

That's a pretty fancy title. What does it mean, and what do you do? I'm curious to know. Well, there was a title. My business card said I was a free radical, but upper management didn't like that.

So I had to find something a little bit more tame. Actually, the more important title slash position is that of Fellow. There are, I think, 68 of us still active. No, 89 of us still active. And this has been out of 350 or thereabouts Fellows throughout the history of IBM.

So, we're a fairly rare breed. I was made a Fellow upon the acquisition of our company, Rational Software, back in 2003. The great thing about being a Fellow is that it's rather like having tenure, meaning we trust you, you've done good things, and we want you to continue doing those things. Let's give you the degrees of freedom to do that. As a Fellow, with my focus on software engineering and later on AI, I am given a lot of freedom to pursue what I think makes a lot of sense to trade toward, as Alan Kay would say, to "invent the future." In my journey, starting in 2003, I first stayed with the Rational division, but then quickly moved over to research because IBM's bureaucracy realized I was a person who worried about the next five to ten years, not just the next quarter.

And indeed, my very early work in research was focused on finding ways to automate the discovery of patterns within legacy software systems. This was something we were doing before the days of neural networks. It was interesting to see if we could discern the design patterns from the Gang of Four and elsewhere. Unfortunately, it never went anywhere because it was a challenging problem. Consequently, I began to work more in the architectural sense. I collaborated with many customers and had been doing that for decades, where I would be parachuted in, and the customer would say, "Come help me, Mr. Wizard, with this particular architectural problem."

And the exciting thing about it for me is that for many decades, I was engaged in projects across every conceivable domain. I'll pause there to say that roughly around the turn of 2010 is when I began to be drawn back into the space of AI. So, when you say you worked on legacy systems, what does a legacy system mean to you? Well, the moment you write a line of code, it becomes a legacy system until you throw it away.

So all code is, to some degree, a legacy system. Facebook is a legacy domain. Google is legacy. Heavens, even OpenAI has a legacy problem. The reality is that, as I often say, old code never dies.

You have to kill it. Once you have built something that's useful, then it's going to live on. Unless you have fully disposable code, there is some body of code that you have that represents something immutable—something that has a cost, something that carries some degree of technical debt. It may be very, very small. If you look at many of the classic organizations in the big financial space, these are groups that have been working with code bases since literally the 1960s. I had one engagement with the Internal Revenue Service in the United States because they've been trying to modernize their systems since the 1960s.

Now, let's go back in time. What was happening in the 1960s? States have been trying to modernize their systems since that decade. In the 60s, there was a rising population, an increase in Social Security, and many organizations were generating a significant amount of paperwork.

And so the banks and the government realized by the late to mid-1960s that there was simply so much going on that it couldn't be managed by hand. Why did banks used to close at 3 p.m.? Because they needed the time for humans to reconcile accounts. The IRS was very much like that. During the 1960s, there was a period of automation of human processes. Most of that was written in IBM 360 assembly language.

Zoom back to today: there is still code in the IRS system written in IBM 360 assembly language, running on emulators upon emulators upon emulators. This creates really difficult problems because some of that code embodies business rules that are embedded within the assembly language itself. So how do you change that? The answer is that you're faced with a real human problem: how do I transmogrify old code in COBOL assembly language so that it can work on modern technology? There's only so much you can do via emulation.

And then we consider that the government makes new business rules every year. How do you keep up with that? That's a real and present legacy problem. Facebook has the same issue, although their code doesn't date back as far. Google faces the same problem.

As well, OpenAI will soon face that problem. This episode is brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication, SKIM provisioning, and fine-grained authorization. That's where WorkOS comes in, making it fast and painless to add enterprise features to your app.

Their APIs are easy to understand, allowing you to ship quickly and return to building other features. WorkOS also provides a free user management solution called AuthKit, suitable for up to 1 million monthly active users. It's a drop-in replacement for Auth0 and comes standard with useful features like domain verification, role-based access control, bot protection, and multi-factor authentication (MFA). It's powered by Radix components, ensuring zero compromises in design. You receive limited customizations, as well as modular templates designed for quick integrations.

Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Vercel, and Perplexity. Check it out at WorkOS.com to learn more. That is WorkOS.com. This episode is brought to you by Savala. It's a true Heroku alternative where you can deploy applications, manage databases, and host static sites for free.

Savala is a platform designed for teams. With its preview and pipeline features, developers can collaborate on any stack while being assured of the security of the workloads from staging to production. Savala holds all the major security certifications that companies are typically looking for. Their application hosting offers automatic Git integration, Docker image deployments, optimal cost savings, vertical and horizontal auto-scaling, TCP proxy support, and optional private network connections for your databases. Their free static site hosting is perfect for landing pages, documentation sites, and more.

It also includes preview deployments for easier iterations and seamless teamwork. Civella features an easy-to-use interface, unlimited seats, no hidden tricks, and transparent usage-based pricing with enterprise cloud for DDoS protection for workloads of any size. Sign up and deploy today. Go to savala.com, that is savala with a double "l" dot com. When you say you were parachuted in to help a variety of different types of companies, can you give a sense of what types of companies you have worked with over the years and decades, assisting them with their architecture, legacy code, and tech debt? Every conceivable domain truly is included. I've had the opportunity to work with various sectors, including financial services and a lot of work in the defense sector.

In fact, to go way back in time, complex systems did not really start in the commercial realm; they began in the world of defense. The phrase I also use here is that all of modern computing was woven on a loom of sorrow. What we see in modern computing was born from World War II and the Cold War, particularly a system called SAGE, the Semi-Automatic Ground Environment, which emerged during the 1950s and was operational until the 1980s. This system, known as SAGE, was built in response to the Soviet threat of bombers flying over the Arctic and entering the United States before we had satellites and pervasive radar. This system precipitated the creation of what we call the software crisis.

It was what triggered the creation of the NATO conference later in that decade, in which a group of people came together from around the world to discuss how to address this problem. It was really at the peak of what I’d call the first golden age of software engineering. We have defense systems; I worked with a lot of real-time systems, everything from pacemakers to subway systems to, gosh, what else, CT scans and the like. Truly, you name a domain, and I’ve probably spent some time in it.

The James Webb Space Telescope currently uses the UML in its design. That's pretty cool if you think about it. Daniel Zeissner described a field evolving over the decades. You were clearly part of some key techniques that were invented and became commonplace. What was this experience like?

I alluded to a phase I called the "Golden Age of Software Engineering." This period encompassed the time of functional, or more accurately, algorithmic languages such as Fortran, COBOL, APL, Lisp, and the like. Although Lisp was somewhat of a multimodal language, the dominant way we decomposed systems was through algorithms. Consequently, we witnessed the rise of structured analysis and design techniques, which made a great deal of sense at that time.

This is where you had the Jordans, the Marcos, and Constantines, among others, because the presenting problem for software systems was that they were generally not distributed. They were largely monoliths. The question became: how could we build larger and larger systems that were sustainable and economically viable over time? The first golden age of software engineering began to change as we started to see the rise of distributed systems. Interestingly, this rise did not occur in the commercial world; it happened in the defense sector. The ARPANET was funded by the government, specifically DARPA.

I was, as I mentioned to you earlier, I got my first email address in 1979 when there weren't that many email addresses around. In fact, there’s a small story about that. When we had the ARPANET, I was teaching at the Air Force Academy at the time. We had a little mimeographed document that listed the email addresses of everybody in the world. At that time, there were only a few thousand people.

So we knew whoever, but who everyone was at the time was pretty cool to look back on. The first distributed systems were developing in that domain. Indeed, back at Vandenberg, I worked on a system called the Telemetry Integrated Processing System, which was a closed network of about 32 mini-computers. Mini-computers were starting to gain popularity. Consequently, the challenges of how to take a larger system and break it up into multiple distributed parts were beginning to emerge as a significant issue.

It hadn't reached the commercial sector yet. So, we in the industry began to see that there were limitations to what one could do with algorithmic decomposition. As a result, there were pressures all around to develop the next kinds of software: software that was distributed, real-time, multilingual, and capable of working on a variety of computers. I had to address all the normal aspects of distributed systems, which include the fact that they are going to fail at various times, along with communication issues and other related challenges.

So, it led to a realization that we needed to think about software in very different ways. The other thing that was happening in research was the rise of languages such as Simula and Smalltalk, which were looking at the world through fundamentally different lenses. Here we are again in the late 1970s, and, again, I was a twenty-something when I was asked by one of my former teachers at the Air Force Academy, "Say, Grady, would you help the Department of Defense figure out how to use this new programming language called Ada so we can apply it to modern software engineering techniques?" Now, why was the government worried about this? By that time, software was a real problem for the Department of Defense, and, in fact, for all of the federal government, because there were several thousand languages in use that had exploded. Fortran and COBOL were useful for some things, but not for all things.

And so there was a decision made to build one language to rule them all, and that was the Ada programming language. Ada was far ahead of its time. It was a language that was influenced by Simula, Smalltalk, and others, but it incorporated the concepts of abstract data types from Liskov, Guttag, and others. It also embraced the ideas of information hiding from David Parnas. All these concepts were very new at the time, but they are now part of the fundamental atmosphere in which we operate.

And so, as an industry, we really didn't understand the methodologies to make that work. Thus was born the Booch method. Here I was from 1979 until about 1981, going back and forth across the United States, helping the federal government and contractors try to apply this new language in new ways. This marked the beginnings of the second golden age of software engineering, in which it was not so much the complexity of the algorithms, but it became a systems engineering problem, dealing with distributed systems that were very new at the time.

And that was the essence of the Booch method. It was the things I learned about helping organizations architect systems with these new kinds of domains and new kinds of languages. Could you explain what the Booch method is? I understand it has to do with object-oriented programming, but coming from you, as the person who invented it, it would be nice to hear what it is and why it was important. Well, let's go back to Plato.

Talking about going way back. I wasn't around then, but I've read about him a little bit. There's this wonderful treatise he wrote, "The Dialogue," in which there's a debate about how one should best look at the world. Should I look at it as atoms or should I look at it as processes? The first golden age of software engineering was more focused on the processes, the algorithms.

But there's a parallel way of looking at the world, and that's by viewing it through the atoms, if you will, the classes and objects within them. So, yes, I was influenced by abstract data type theory, by Plato, and by a lot of other interesting philosophical concepts that were emerging at the time, which prompted us to look at the world in fundamentally different ways. The Butch method was really trying to codify that. How could we decompose systems, not based upon algorithms, but rather based on classes and objects? Again, that's where I was influenced by Liskov, Parnas, Dijkstra, and Hoare, among others—names that are probably unfamiliar to students these days, but who represented the theoretical underpinnings of the first and second generation.

The Booch method was essentially saying, "Hey, here’s a new way of thinking about the world." It suggested that we should not focus solely on algorithms but instead look at combining data and processes, along with algorithms, into one cohesive entity, which they referred to as classes. We did some things right, and we did some things wrong. I believe the things we did right were that classes make a lot of sense in terms of abstraction. What we did wrong was overemphasizing the concept of inheritance.

Inheritance was all about saving code because we could build generalizations and the like. However, that proved to not make much sense, as we ended up creating many disparate kinds of abstractions. That's okay. Fast forward to today, and people say, "What difference does it make?" The answer is that it's part of the very atmosphere in which you breathe, so you don't even think about it.

You look at Redis, and you may build things upon it, but if you analyze it closely, you're really dealing with a set of abstractions that Redis offers you. These abstractions are class-based, so they are integrated into the way of thinking about those kinds of systems. In short, the Booch method was about looking at the world not through algorithms, but instead through objects and classes. The last thing I'll mention is that one of the concepts the Booch method hinted at, which did not fully materialize in UML, was viewing systems from multiple perspectives.

Now we'll come back to that bit when I talk about Haleek Khrushetian. Just to clarify, because I, and most of us listening, started our careers long after the Butch method was invented for us, concepts like classes, variables, and inheritance are now pretty common and everyday things. But as I understand it, it wasn't like that back then, right? Could you talk us through what the environment and technology were like?

So, what made the Booch method so unique? New, interesting, or innovative. Well, let me go even further back to the 1950s and show you a parallel story. There was a time in the growth of algorithmic programming languages when the idea of a subroutine was considered controversial. Why?

Because making a function call added at least two or three more instructions, it was computationally expensive. Even function calls and decomposing something into subroutines were viewed as architectural aberrations, and people opposed them because they were seen as inefficient. Obviously, we now think that was a shortsighted perspective because we need these techniques for managing complexity. I believe a similar mindset existed in the early days of object orientation. People were employing object-oriented principles in algorithmic languages because, for instance, in COBOL, you would have constructs called "common."

Data areas. People would devise all this common data. As a matter of practice, but not language, you would say, "This data is used in this way by these algorithms," and vice versa. In fact, going back to that project I mentioned to you at Vandenberg Air Force Base with those 32 computers, on the side of every one of those computers, every day, we'd see a printout of the common data pool. It presented the abstractions right in your face because they changed regularly.

And so, people were trying to do algorithmic or object-oriented decompositions, but the languages didn't support it. There was a need to implement that kind of approach. Until the development of appropriate languages, there was no efficient way to bring those ideas together. The Booch method was very much a reaction to the demands of building software-intensive systems. It focused on examining classes, applying them with modern languages, and developing a methodology around them. Today, we take it for granted because our programming languages make it easy for us to do this.

It's just fascinating to think back on how revolutionary it was, especially when compared to how commonplace it is now. It's also interesting to consider that the things we invent today that are revolutionary will, in 20 years, become commonplace as well. Right? Exactly. One thing that you're known for, and which you've mentioned you're associated with, is UML. Could you share how this was created?

What was the goal of it back then? Who was involved? And what was the need that it was solving at the time? David Pérez, Ph.D.: In 1982, two of my classmates from the Air Force Academy, Paul Levy and Mike Devlin, were involved. Paul had been a roommate of mine at the Air Force Academy.

He was an economics major. Mike Devlin was a computer science major. Mike and I had a few classes together. The first time I ever met Mike was in an unarmed combat course, by the way. So, not your typical thing you find at colleges, but hey, you know, I was trained to be a warrior.

That's where I first met Mike, and I think he beat the stuffing out of me, if I'm not mistaken, in the pugil stick competition. But here I was at Vandenberg Air Force Base. Mike and Paul were up in the Bay Area. They were working at the Satellite Control Facility, and I engaged with them because they had one of the largest ADA projects that was going on. So I went up and helped consult on that project.

The two of them also went to Stanford. I swear there's something in the water at Stanford because they then connected with Art Rock and Hamburg and Quist, the two premier venture capitalists at the time. Art Rock and Hamburg and Quist were the key founders of Apple, and they also contributed to the funding of what became Rational Software. In '82, Mike and Paul got together with me and said, "Let's start a company." And we did; it was a company called Rational Machines Incorporated, whose intent was to build a software development environment for the newly emerging Ada programming language.

We saw that as an opportunity in which we could make piles of money. We built hardware at first because this was the time when many computers were becoming affordable. Sun Microsystems was coming into play, but none of them were powerful enough to do the kinds of things we were doing. So, Mike designed a system, and I helped build the methodology around using it.

It was a system called the R1000, and that was the dominant Ada system used around the world at the time. Well, around, I don't know, it would have been the early jump ahead a decade now. Here we are, the mid-90s. I was getting a little tired of doing that kind of stuff and branching out into other areas. I found that there was traction I was getting from the Booch method into the commercial sector.

I was giving a bunch of lectures at the time. At one point, there was a gentleman in the audience who asked a really insightful question. Afterwards, he and I met up; a guy by the name of Bjarne Stroustrup. It turns out Bjarne was working on a project called C with Classes, which was the predecessor to C++. The two of us got together and hit it off.

We found that we were doing very similar things together. In fact, it led to the two of us doing a lecture series around the United States, where I got to know him quite well. This was around the time he wrote his first book on C++. If you look at the first edition, you'll see he references a lot of my ideas. That was when my book on object-oriented design came out.

And I referenced his work a lot, too. So, oh, the Booch method and C++ kind of grew up together. I thought this was interesting, and I remember a particularly important meeting I had with Mike and Paul around that time. It was at the Red Carpet Club of United Airlines in Denver.

They met with me and said, "Hey, Grady, we're thinking of moving the company in the direction of embedded systems." I responded, "Well, good for you. I think that's a stupid idea because you're missing the commercial sector. Go off and have fun. I'm going to do different things." This gave them pause.

And I think they realized, wait a minute, maybe there is something here in the commercial space. We were finding that we were having challenges continuing to grow the business in just the defense sector, which is what led them to that. So they then made the decision, "Hey, let's take the Booch method and make it real." Thus began the development of a system called ROSS, Rational Object-Oriented Software Engineering, our first tool. The first prototype, by the way, I wrote in Smalltalk.

It was one wonderful system. I wish I had kept the source code for that around, but I remember making changes to it just literal minutes before we first did the demo. That's where we broke out from the defense sector into the commercial sector. It was a big hit because that was a time when many others were recognizing that object orientation was a good way of looking at the world, and C++ actually supported that. Well, that led to two things.

Not just commercial success on our part; we began to make a lot of money, acquiring other companies and filling out the software engineering life cycle. Can you tell us what Rational Software did to make this commercial venture a hit? Yes. Rational Software’s Rose, which stands for Rational Object-Oriented Software Engineering, was a personal productivity tool, if you will, that ran on an IBM PC. I think they eventually moved it to a number of other devices as well.

It ran under Windows in the first version, which basically allowed you to draw UML diagrams—not UML, but Booch diagrams—so that you could reason about and think critically about your design. We did a little bit of code generation, but it was primarily a design tool to help organizations conceptualize their designs. People used it effectively to document, specify, and build their systems. As a result, we started generating significant revenue from it.

And so we started acquiring companies. We bought a requirements company. Ed Jordan came to me and said, "Go look at these folks." We did. We bought a small company out of Cambridge called Pure Atria, which was led by a gentleman by the name of Reed Hastings.

Reed came to us. We bought his company, and he said, "You know, talking about the founder of Netflix?" Right? Yes. Yes. So we bought his company.

Yes, Reed realized he was a lousy CEO. So, he took his money and hung around for a few years, figuring out what he was going to do. Actually, that was a lot of the seed money that helped form Netflix. It is a small world in that regard.

So, at that time, at the peak of what we were doing in the late 1990s, IBM Rational was sort of dominating the space of software engineering because we had tools across every part of the development lifecycle. This is where the idea of incremental and irreducible software development came into play. Long before what we now call continuous integration and continuous deployment, we were already implementing those concepts with Rational Machine and our tools. We had pioneered those ideas because we had built incremental compilation tools and similar technologies. Thus, here we were in the 90s with a comprehensive set of toolsets around this approach.

But because this was clearly gaining traction in the marketplace, we weren't the only ones. We were seeing the rise of hundreds, if not a few thousand, companies that were beginning to try object-training kinds of things. This marked the beginnings of the second golden age of software engineering, featuring Pete Code, Constantine, Jordan, and Martin. We also had Ivar Jacobson and Jim Rumbaugh. It was a very vibrant time, with organizations striving to leverage these great tools.

We've got the ARPANET. We've got personal computers. How do we build software for them? The presentation of the problem was in software: What is the best way to design systems using this very robust and powerful set of tools we have at our disposal? In a rational and interesting space, we realized we were kind of dominating the market.

Let's keep going here. We hired Jim Rumbaugh, and the task Jim and I had was to combine his methodology, OMT (Object Management Technique), with mine. We were sort of the two leading ones at the time. Then we acquired Ivar Jacobson's company because both Jim and I were using what was known as the idea of use cases. Again, it was something that was part of the atmosphere; use cases were just something you thought about, but they were new at the time in the 90s.

They were an idea invented by Ivar in his work primarily at Ericsson. We were working together with Ivar on building software for base stations for the burgeoning cellular telephone networks—projects that were quite significant at the time. Here we have the three of us, brought together by Rational, with our task being to unify our methods. You could never have found three more different people.

I'm pretty amazed that we didn't end up with one of us in the hospital and one of us in jail. We were so very different. I won't go into further detail on that, except to say that I'm very proud of what we created.

And from that was born UML. So we decided that this is not just ours; we need to make it something that the whole world could use. We made the decision to release it to the Object Management Group, and this was the birth of UML 1.0.

I sort of drove most of that while working with Jim and the others. I wrote the primary document for it. Obviously, it was the three of us working together. I don't want to downplay their contributions; I want to give them complete credit, believe me. But after UML 1.0, I was emotionally exhausted and wanted to go off and do new things.

So I kind of walked away from it at the time. I want to pause and mention one other person who was important here—actually, two other people. The first was Philippe Khrushen. We realized that our work was so extensive that we couldn't just focus on the methodology and the notation.

So, Jim, Ivar, and I worked on the notation, which was the UML. Philippe primarily collaborated with some of Ivar's team on the methodology, and this led to the birth of the Rational Unified Process. Notice the emphasis on "Unified." Philippe introduced the crucial concept that we began to see hints of with the Bouch method: looking at the world through multiple points of view.

Philippe has this idea of the 4 plus 1 view model, which he developed from his work on building the Canadian air traffic control system, again, a very complex distributed system. Those ideas were eventually manifested in an IEEE, IEC, IOC standard 420020, an architectural description, which basically states that if you're looking at an architecture, you need to consider it from multiple points of view: use cases, logical view, process view, implementation view, and deployment view. This is a very important and profound concept. Another person who came into play was Walker Royce. Now, Walker is an interesting guy.

You talk about a small world. His father, Wynn Royce, whom I had the pleasure of working with at that time, was a gentleman who wrote the paper on waterfall life cycles. His son was basically working on spiral models and the Booch method. Wynn was misunderstood because he was not endorsing waterfall methods.

He said, "That's a stupid idea. In fact, look at Parnas's paper, 'A Rational Design Process: Why and How to Fake It.' It's from that the name Rational Software came about, by the way. It says that, at one level, it looks like—well, inside, no, it's what we today would call agile. So here we are. Here we are in the late '90s and early 2000s, when UML 1.0 was in the bag, and that was the life of Grady at the time."

Hey Developers, We've all been there. It's 3 AM and your phone blares, jolting you awake. Another alert. You scramble to troubleshoot, but the complexity of your microservices environment makes it nearly impossible to pinpoint the problem quickly. Iconosphere is on a mission to help you take back control with Differential Diagnosis, a newly distributed tracing feature that takes the guesswork out of troubleshooting.

With just one click, Ddx automatically analyzes all spans-eye dimensions related to a service, pinpointing the most likely cause of the issue. Don't let troubleshooting drag you into the early hours of the morning. Just Ddx it and resolve issues faster. See why Chronosphere was named a leader in the 2024 Gartner Magic Quadrant for observability platforms at chronosphere.io/pragmatic. That is chronosphere.io/pragmatic. Do I understand correctly that the goal of UML was to describe a system? When I think back to college with UML, we had the different boxes for different classes, and we had the arrows between them that describe relationships depending on the type of arrow. When you look at this whole diagram, you get a sense of the structure of the software you're building. Yes.

So, if you look at the very first line of the UML 1.0 standard, I believe it states that UML is a visual language intended to reason about, visualize, specify, and document the artifacts of a software-intensive system. It says nothing about it being a programming language. In fact, I have fervently pushed back against that notion. It was a language meant for thinking—thinking about and reasoning about a system, and contemplating the world in object-oriented ways, particularly in ways that allow you to consider it from multiple points of view.

DevOps today, by the way, is simply an amalgamation of deployment and implementation views, but we didn't call it that back then. We looked at it from those kinds of perspectives. And that's really where UML 1.0 was. It was meant to be about how I think about these things and how I reason about them.

And I always intended for, you know, you'd write UML diagrams and you’d throw most of them away. Now, unfortunately, many people didn't do that. In the move from UML 1.0 to 2.0, there was a faction of individuals and companies who said, "No, we want to make UML very precise. We want to turn it into a programming language." I think that was a profound mistake.

I never intended the UML to be a programming language, but the net result of that was to make the UML much more complex—much larger. The emphasis then was on not using it to reason, but to generate code and to reverse engineer. Now, I can understand the reverse engineering aspect; that makes a lot of sense. However, turning it into a programming language was a mistake. I believe that decision marked the beginning of the decline of the UML because people were using it in the wrong ways.

At its peak, the UML probably had a 20 to 30% penetration in the marketplace, which is pretty cool if you think about it. It influenced the systems in which it was used, but most of all, I’m proud of the fact that it helped people think about building software in different ways. So when you say that at its peak it had 20 to 30 percent usage, does this mean that about 20 to 30 percent of commercial developers were using it at the time? And around what time was this? Yes, we’re talking around 2000, plus or minus a few years. Remember that Microsoft was significant during this period as well; they actually worked with us to integrate our Rose product into Visual Studio. We had a team working in Seattle to make that happen.

And it was a major selling point for Microsoft at the time because it actually helped their customers build more complex software. So, yeah, we're talking around 2000 or so. But what else happened in that timeframe? The answer is, the internet was evolving. The ARPANET had transitioned to the internet, and companies were beginning to move online in the late 1990s, which was great. However, there was a challenge: how do I build systems for distributed work on the web, and how do I make money off of it? What do those systems look like? That was why Microsoft was interested; they were helping their customers move from the PC to distributed systems. On the other hand, there was also a great deal of hype, claiming that the internet would improve your sex life and do all sorts of wonderful things. It led to a significant overinvestment in that space.

A little after the millennium, we saw a backlash, and there was a significant downturn in the marketplace. Many people had built things and realized they weren't necessarily economically sustainable. Now, here we are in 2003. IBM and Microsoft were still using our tools heavily because they were important for their customers. Both IBM and Microsoft bid for us, and I think IBM won a bid of $2.7 billion to buy Rational.

And so we went over to IBM and became part of it. That made sense because, at that time, there were 3,500 of us in 14 countries, and we had reached almost a billion in revenues, which was pretty extraordinary for a company around that time. But it was time to be absorbed. Now, one other story I'll tell before I pause again: Here I was, IBM had acquired us.

They made me a fellow immediately, which had never happened before. It usually takes years of being part of IBM. A couple of months later, I got a phone call. It said, "Hey, Grady, it's Bill. Come visit me."

So I went up and flew to see him, Bill Gates, right? Bill Gates, yeah. I've done some things with Bill before. At that time, Bill was still the CEO of Microsoft. He said, "Hey, Bill," and took me into his office.

We had a 30-minute meeting scheduled, but it ran for two hours, much to the annoyance of his staff. He sat down and said, "Grady, it's not public yet, but I'm going to be moving out of my role at Microsoft because I want to do other things. And Grady, you know I've got two roles: I'm CEO and I'm Chief Architect of Microsoft."

I'd like to give you the job of Chief Architect for Enterprise. So, I said, "Bill, that's very interesting." I asked for a little time to think it over, and then I went around and met all of his main reports. Most importantly, Balmer never met me.

And that was a red flag. It was around that time that I realized Microsoft was a particularly nasty company. You had the Office group and the Windows group that just couldn't stand each other. Eventually, I went back to Bill through his hiring team and said, "Bill, I'm flattered, but you know, you have a profoundly dysfunctional company, and I'm not the one to fix it. So, Bill, thank you, but no thank you."

I think I used something to the effect of, "It would only end in tears for both of us if I accepted, so let's move on." So, I stayed at IBM, and it was a good decision to make. Accepting would have been a bad decision.

There's a cartoon about Microsoft created by a software engineer and cartoonist, Manu Kornet. It depicts the two organizations within Microsoft holding guns against one another. Yes, that's where it was; they needed someone to knock it down.

I'm a lover, not a fighter. And I was not the guy to break things up. What a story. Yeah, so I set up a ULMN call.

And to this date, it's part of several college curriculums. But interestingly enough, in the industry, I've just not really seen it used for anything—at least not in the companies where I worked, as well as the startups and scale-ups and large companies I collaborate with. I kind of see a resistance to using it when it's brought up, with claims that it's too formal. After all, we do use architecture, right? We use boxes and arrows, and we create diagrams.

I'm curious to know, you know, you talked about how UML was used by 20-30% of the industry at some point, but what happened in your view? This leads us to contemporary architecture. I've got a shelf full of books on architecture, both older and newer ones. If you look at what many people refer to as software architecture today, I think it's reasonable and sound, and there is good material available. However, in many of the types of systems these architects discuss, the architectural decisions have largely been made for you. For example, if I'm going to build a system that requires message passing, I might just go find RabbitMQ or Redis or whatever I need.

The architectural decisions have been made for you. As a result, much of the work of contemporary architects involves taking large frameworks and components and weaving them together, which is a very noble and wonderful endeavor. These frameworks also represent systems like Meta and Dutt, in particular. They have developed their architecture and systems over several decades, and the projects they are building on top of these architectures largely evolve from those APIs, which do not require the deeper types of architectural thinking. Let me illustrate this with an image of a three-axis system.

Along one axis, you have levels of ceremony. If I'm a startup, then it’s just my money and no one else's. And heck, I can write disposable software, and if I fail, I'll just go find another venture capitalist. Of course, I'm not going to worry about any degree of ceremony because I'll just build it. I'll go hire some brilliant people and make it happen.

That's wonderful. On the other hand, if, let's say, I'm doing something like, I don't know, building the next generation intercontinental ballistic missile system, which uses about, I don't know, half a billion to half a trillion dollars, you bet you're going to use more ceremony because you have to have degrees of accountability. So that's one axis. The next axis is that of risk.

So if I build a system and say, "Oh, if I fail, so-and-so is not going to find their grinder match. Big deal." On the other hand, if I fail and somebody dies, that's a problem. In that case, you're going to use a more disciplined architecture. The third axis is that of complexity.

If I build a system that people have done again and again, then heck, I don't need anything. Heavens, this is where prompt engineering comes into play. I can build an app just by creating prompts because we have developed these things. I don't need any stinking UML for that. On the other hand, if I'm building something more complex, engineering comes into play.

I can build an app just by creating prompts because we've developed these tools. I don't need any cumbersome UML for that. However, if I'm working on something I've never built before—let's say I’m not building a single language model, but rather a constellation of language models that work together, and I want to integrate them with non-neural systems—then it’s time to consider architecture, and that’s where UML comes into play. There is a sweet spot in software development where a significant amount of work can be done without relying on UML or similar tools.

But on the other hand, if you go a little further out in that three-dimensional space, you'll find people all over the place using UML. I mentioned the James Webb Space Telescope. I still work with financial companies that are doing that, where the risk, complexity, and ceremony are sufficiently high that they demand a bit more formalism. So, do I understand it correctly that you're saying that software architecture has changed from the 90s and 2000s, when systems and architectures were new? Software architecture was still a lot more novel back then. If we look at venture-funded startups and big tech today, what we see is, first, that they are just not as risky; if they fail, it's not a big deal. Secondly, we can use a lot more software that's already out there and has been architected. For example, we can use Redis as a cache, and it is available and functional without requiring us to think too much about it.

And then the third point is that there are a lot of startups that simply don’t need ceremony-based processes. Basically, they don’t require audits or formality. They can just say, "All right, let's do it however we want to." They don’t need that level of accountability.

Do I understand that these are the changes that are in play with software architecture? And is this why some of these formal methods are just not as popular with startups and scale-ups? Yes. In fact, I think it goes to the root of the economics of software development. Let's go back to the first age of software.

During the Golden Age, machines were far more expensive than humans. It required a great deal of thought before even accessing the machine, as machine time was very, very costly for me. Therefore, algorithmic decomposition and structured analysis design techniques made a lot of sense, as we needed that kind of optimization. In contemporary times, however, computational resources are as abundant as water to a fish; they are available to anyone.

I've got on my desk behind me my own personal cloud of four NVIDIA single-board computers, which has more processing power than existed in the world in the 1970s. That's pretty amazing! That's a few thousand dollars there. The economics have changed vastly, such that you don't need to think about it so much because, heck, it becomes disposable. I think AI is also changing that because it allows me to build things where I don't even have to think about design.

Heck, I don't even have to think about software. I just prompt for those things to build something and one-offs. Once I'm done, I throw it away. So in that sense, it comes back to the economics. However, there will continue to be a class of software that is new, unique, and breaking new ground, which still requires that kind of architectural thinking. It's interesting because, just recently, I read how Amazon is using formal methods for AWS S3.

They're publishing a blog post detailing how they are doing it. They are doing this to catch those really, really edge cases that only happen one in a billion, one in a trillion. But at their scale, this is a regular recurring event, and I found it fascinating how some of these methods are making their way back.

Yeah. Well, let me set aside formal methods for a moment because it turns out that's a different topic for which I have some experience and opinions. But going back to Amazon, if you visit their website, you'll find they have a whole language around architecture. Microsoft has something similar regarding Azure. That's how I would describe an architecture in Amazon.

It's those, you know, they're blocky diagrams. It says, "Hey, I'm going to build this kind of thing, and here's my particular notation for it." Furthermore, there are some examples. Even Amazon and Microsoft have recognized that architecture plays a role, but there are enough times people have done these kinds of things.

It says, "Oh, you want to build this kind of system? Then you want to use these services. In fact, here are some examples you can find on our website." So, without them really acknowledging it, Amazon and Microsoft view architecture as still important, but there are enough patterns that one doesn't have to go through the process of rediscovering those, because I can build those things. This is a representation, I think, of the maturation of our business. We have moved from algorithms, which everyone can use, to design patterns, and now to architectural patterns, which Amazon and Microsoft have codified themselves. Now, let me switch over to formal methods. Formal methods have always been a thing.

However, in my experience, formal methods are a necessity in every part of software-intensive systems. Formal methods can only cover specific domains. For example, Microsoft began using formal methods in their drivers to validate the correctness of their interactions with their hardware. That was an important move forward. I have been involved in projects where we said, "I have this system in which people might die; let's run a formal analysis on it." The issue, however, is that those formal methods do not account for real-world elements because they don't consider space and time.

They deal with functionality. I have always found formal methods to be useful, but only for parts of a system and never as drivers of the architecture itself. Speaking of software architecture, these days, the role of software architect is not really popular anymore, at least in startups and big tech. Instead, we have architects, but they are increasingly called staff engineer, principal engineer, or distinguished engineer. The architecture still exists, and they do still engage in architecture, but the focus has shifted.

Now, you were there when software architecture was created, when the first software architects emerged as a defined role. Can you tell us how you've seen this role develop and evolve throughout the decades? Two things influenced my understanding of the field: I didn't really call myself an architect, but I did help people design the systems they were building. I was heavily influenced by a dear friend of mine, Mary Shaw. She's a professor at Carnegie Mellon.

I think she won the National Medal of Honor under Obama, if I'm not mistaken. She also wrote a really profound book called "Software Architecture," in which she provided the first exposition of architectural patterns. Mary is just a delightful human being, and that was when I began to understand the formalizations of what architecture could be. Another influence on me was architecture from other domains, particularly civil engineering and the like.

In the defense world, there is also shipbuilding architecture, airplane architecture, and similar fields. The term "architecture" is one that is very well respected outside of this organization, particularly in the engineering world. Ignoring the title for a moment, let's return to first principles. What is architecture, after all?

And you've probably heard me say this: all architecture is design, but not all design is architecture. Architecture represents the set of significant design decisions that shape the form and function of a system, where "significant" is measured by the cost of change. Software architecture, and the role of an architect, often carries a lot of emotional baggage. Therefore, think of it as being all about making decisions.

What are the decisions that shape my system? As an architect, that's what I'm doing. As the project manager or whatever, I'm also involved in making decisions. However, one subtle difference is that it's no longer just about the decisions regarding the shape of the software; it's about the shape of the system itself, where it manifests in the physical world alongside other systems and humans. That's what it is.

It's all about the decision-making process. Have you seen this role change? Did you witness a golden age of companies employing software architects who empowered them to churn out designs? I'm noticing a decline in this trend. I'm curious about your thoughts.

Are you seeing something similar? Is this just a bubble that we're observing? It seems that you're embedded in a lot of different companies. Here's another soundbite I’ll share with you: the entire history of software engineering is one of rising levels of abstraction. What we're witnessing here is the emergence of another level of abstraction, which provides us with extraordinarily powerful frameworks for building systems. As I alluded to earlier, the architectural decisions that were at the forefront for us in the past are now embodied in these frameworks.

So now it becomes a decision: which cloud service do I use? What messaging system do I choose? That's the decision that involves many economic considerations, not just software-related choices. I believe the role of the architect has changed significantly because I am now dealing with systemic issues, not just software problems themselves.

Have you heard about the role called Solutions Architect? I think it was created maybe ten years ago. It's fascinating and specific to the cloud, as these professionals focus on cloud architecture. As you mentioned, they make economic decisions about what services to use—whether to go with AWS or GCP, for example. If they choose AWS, they might decide whether to use EC2 or another service. This leads to systemic issues. Generally, if you're a startup, you'll want to hire someone who has experience in this area—someone who knows where the pitfalls lie and understands the costs associated with these services. Hiring these kinds of professionals can accelerate your progress because they've already made similar decisions and can guide you in determining what choices make sense for the infrastructure you're building.

And they are systemic decisions because they have economic and long-term associated consequences. One important aspect of software architecture is migrations. I have observed that most large companies are negatively impacted by long-running migrations.

And these migrations usually happen due to changes in software architecture, such as transitioning from a monolith to microservices or switching technologies, for example, from Node.js to Go, or upgrading major versions of frameworks, like moving from one version of Angular to another. How do you think software architecture and migrations are connected? Why do you think software migrations are so challenging and seem to persist? I believe they will continue to be a significant issue until the heat death of the cosmos.

Because you're always building economically viable software, the changing technology compels you to consider migrating. Take, for example, the migration from monoliths in the 1960s, 1970s, and 1980s, until we suddenly had mini computers and distributed systems available economically. You’re still not going to use an iPhone and put everything on a mainframe, but these changes prompt you to consider an architecture that better balances where processing takes place. If, all of a sudden, I can begin to do edge inferencing on my devices, that's going to change architectures as well. There are always these changes, both in hardware and in societal factors, that impact the structure of my systems. These are the forces that impel and compel me to undertake this migration.

But why is it hard? Well, another soundbite I'll give you is that the code is the truth, but the code is not the whole truth. There is so much that exists outside of the code that represents design decisions, their rationale, and why I chose one approach over another—subtle factors that influenced naming conventions and other impacts that are often overlooked. While the code may be accurate, the challenge with moving migrations is that you lose important information. It's difficult to recreate those design decisions based solely on the code. The individuals who wrote the initial code you are trying to migrate may have either moved on, retired, or even passed away, leaving a gap in understanding the context behind their choices.

So, you don't really know why those decisions were made, and you're feeling a little bit in the dark. You're mentioning that people have died, and I don't think we usually think about that. However, when you're considering systems that are 40 or 50 years old, that is the reality for some of them. What will the Lennox kernel look like when Linus eventually retires? How will it evolve? He has provided a firm and much-needed hand on the conceptual integrity of the project.

Of that system. And that's what the chief decider makes. He or she is the one that provides that conceptual integrity. When that person is gone, you naturally see drift, and that's inevitable.

It's entropy. All software exhibits some degree of entropy without adding that kind of force to it. One thing that is very relevant today in terms of technology and architecture is AI. This technology is here; it's revolutionary and disruptive. Now, you've been in the industry for closer to 50 years.

If you look back, how do Large Language Models (LLMs) and Artificial Intelligence (AI) compare to past innovations and events in the industry? For many of us who've been in the industry for 20 or 30 years, LLMs do seem like the biggest change in software. However, when you reflect on the past, have you seen anything that was comparable in terms of impact or the pace of change? That's a great question. Yes.

The first, I think, was just the realization that I could build distributed systems as opposed to putting all my processing on one system. That was a change that rattled everything in the way we built systems. At that point in time, I suddenly realized I could have a network of mini-computers. Eventually, that carried on to microcomputers and devices at the edge, like phones themselves.

But that transition in the growth of mini-computers was seismic, and I don't think people understood the full implications until much later because it required us to rethink the way we put systems together. We saw a significant rise in uncertainty because we didn't know how to build these systems. I had questions about messaging across them: Do I use RPC? Do I use something else?

What do I use to communicate? Do I use shared memory? There was a period of exploration that we didn't know about until we finally realized, oh, these are the common ways that work. Can you remind me around what time this was? Was this in the 80s?

Was it around the '90s? There was also the late '70s. Because here you had... Was this around the '80s? Was it around the '90s?

It was the late 70s. To understand it better, let's go back a bit in history. There was something called—gosh, what's the name of it? I'm drawing a bit of a blank here. But here we are in the late 60s and early 70s, when mainframes were roaming the earth.

But even then, it was a realization that these machines were sometimes being underutilized. Thus, the formation of the first time-sharing systems was born. Around the same time, systems such as Whirlwind, which emerged from the Lincoln Laboratories, began to connect machines to the real world. Suddenly, real-time computing became a reality. This led to a confluence of two very interesting developments.

You had large machines in which we were beginning to develop time-sharing types of operating systems, alongside machines that interacted with the real world. These elements came together with the rise of minicomputers, particularly at Digital Equipment Corporation and similar companies, where miniaturization—largely driven by the investment the Department of Defense was making in semiconductors—made it economically viable to have a computer that could sit on your desktop, usable by one or two people full-time. This progression took the ideas embodied in systems like Whirlwind and combined them with distributed systems being built at the time. Suddenly, it became possible to take these components and start building them together.

And that's what was happening in the mid to late 70s: we saw the rise of distributed systems. There was one last thing: the rise of client-server systems, where we saw dumb terminals—that's what IBM was doing at the time with the green screens—communicating with mainframes. However, the emergence of those new machines meant I could move some of the processing to the edge instead of leaving it all to the mainframe. Those were the forces that led us to rethink systems. So, do I understand correctly that programmers at that time were used to working on large computers, and when distributed computing came in, it completely changed the dynamics?

So, youngsters came in and started to embrace this distributed computing, but existing programmers stuck to what they knew was efficient on the mainframe. Was that what it was like? It was. Then, when things like TCP/IP and HTML emerged, all of a sudden, we had a vocabulary. We had mechanisms that allowed us to bind these things together.

So I would not say that large language models (LLMs) are as pervasively important as the rise of distributed systems, but there's a parallel to it. The second thing I'd say that is sort of similar to that is the rise of GPUs, which came from the gaming industry, where they were solving a very different problem: how to handle more photos and create more realistic elements in games. We realized it all comes down to matrix multiplications. As a result, NVIDIA began to move into that marketplace.

And we had the rise of GPUs, which dominated that space. It wasn't until Andrew Ng came and said, "Wait a minute, those GPUs used for gaming use the same kind of mathematics as our deep learning techniques." And poof, all of a sudden, we had this perfect storm of lots of data, powerful hardware, and the rise of interesting algorithms, backpropagation and the like. So it was a perfect storm. Yes, this is an exciting time.

There's no doubt that large language models are interesting, but we must be careful. We'll discuss this in a moment. I would love to hear your candid thoughts about LLMs, their applicability, the innovation they bring, and the trade-offs that come with them.

Well, to set the stage before people worry that I'm just pontificating about things I know nothing about, I alluded to this at the very beginning. When I was 12 or 14, I was interested in what was burgeoning into AI at the time. That has always stuck with me, and I've consistently pursued and remained interested in that space. It wasn't until IBM drew me back to it that I truly reengaged with it.

Of Watson, I began to make it a full-time endeavor. David Ferrucci, who led the development of Watson, called me and said, "Hey, Grady, I'm going to give this lecture, but I can't do it. Would you do it for me?" I replied, "David, I'd be happy to do so, but only on the condition that I can choose the topic."

The topic I chose is: What is the architecture of Watson Jeopardy? As it turns out, nobody had documented it. Being an expert in the architecture space, I sat down with David's team for several months and documented the as-built architecture of Watson Jeopardy. It's not a neural network system; it turns out to be a pipeline architecture that, through a pipeline, brings together a number of statistical systems.

AI at the time was all about predictive statistical methods, not neural networks or knowledge engineering methods. So, I documented the architecture, which caught the eye of IBM management. It was the first time I really documented an AI architecture. For those who don't know, this was in relation to Jeopardy.

This was the IBM computer that played the game "Jeopardy!" and won, if I remember correctly. It won. Yes, it beat all the humans in that space. At the time, this was covered in mainstream media, in the press, everywhere. It was shown as an example of an AI system that can outperform a human in a very human task, which is this popular show, "Jeopardy!"

Yeah, right. It was part of the trajectory IBM had been on in that space because, before that, we had Deep Blue, which beat the leading chess player at the time, Garry Kasparov. Garry Kasparov, yeah, yeah. So we did that through brute force methods.

Then Watson Jeopardy came along, beating humans in natural language processing at the time. IBM had already been working in that area with a system based on statistical methods, which we eventually sold to Nuance and similar companies. However, we were quite dominant in the field of natural language processing, and IBM Watson Jeopardy represented the peak of that achievement. So, IBM asked me, "Hey, Grady, this is cool stuff. We're going to commercialize this. Would you please help us conduct a study on what IBM should do with this?"

I led a study for about a year in cognitive systems. What should IBM do? This was interesting because I studied what Watson was doing. I looked at what was happening in the marketplace. Here we were, around 2010 or thereabouts, a little bit later.

It was that decade. I made it very clear to IBM management that this is pretty cool, but be careful because there are things we know it can't do. I was very clear to our management to be cautious about hyping it. Well, I remember in my meeting with Jenny when I was doing the briefing about the project.

Jenny was the CEO at the time. She asked me a question. One of the VPs stepped in and started talking over me, saying, "Well, yada, yada." I politely said to him, "Thank you, but I think you're wrong," and I went on to explain my perspective.

Now, if I were not a fellow, I'm sure I would have been fired on the spot. But as a fellow, I get to say things like that. They did not invite me to join the Watson group, so I was happy with that and worked on the other side. You know, it's sort of an "I told you so" situation; there were things we can't do, and by God, we can't do them. I was working in the underground for several years, and I'll get to the answer to your question in a moment, but this explains why I can say something meaningful.

So I was kind of an outsider. I was doing my own thing inside IBM. Then we had a team down in Austin that had been approached by Hilton Hotels, who said, "We'd like to build a robotic company concierge for our hotels." So we chose some robots from Aldebaran, a company from the south of France. They built these three-foot tall robots called Pepper and smaller ones called Nao.

And they built a robotic system, which was kind of cool. It was a question-and-answer system based on Watson technology, but there was something missing from it. The team came to me and said, "Grady, would you please help us out?" So I did; I helped them refine the architecture. We actually installed it in a few Hilton hotels.

But as it turns out, just down the road from that team was the Johnson Space Center. So we began to be involved with them, and I thought this was all great because I could get back to my space roots. They had a system called the Robonaut 2, which was a humanoid robot that, at the time, was on the International Space Station—a beautiful piece of engineering. NASA was exploring the idea of human-robotic interactions for the mission to Mars.

So, the group of us sat down and said, "What would be an interesting design problem for us to explore that would propel us to look at hard problems?" Because we want to do hard things. We realized it was the mission to Mars, as there were two interesting use cases. The first is that, because of the speed of light issues, you couldn't rely upon mission control on the ground; you had to take it with you.

This was the HAL problem. We needed a new mission control to build a HAL minus the "kill all the humans" use case, which, for some reason, NASA didn't want. I don't know, but it's their choice. The second issue was that at the time, NASA wanted to put robots on the surface of Mars to help astronauts build their scientific experiments and habitats, among other things.

So I remember one afternoon, I sat down and said, "I know how to architect this." This would have been around 2014. I built a neurosymbolic architecture we called "Self," which incorporated the ideas of Marvin Minsky's Society of Mind, Rodney Brooks's notion of subsumption architectures, and Hofstadter's ideas of strange loops. These three concepts came together to form the Self architecture, which we then developed. We experimented with NASA for a while to create software for Robonaut 2, doing things like saying, "Hey, robot, here is a scientific process."

Go do this or go clean these filters, which is a common station-keeping activity. We were actually building the software that allowed humans to interact with it and also serve as question-answering tools. That led us to Soul Machines, a company out of New Zealand. They were an offshoot of the work that John Cameron had done in the movie. The shoot, what's the... what's the one?

He's completed a trilogy of projects now, utilizing great technology that involves placing cameras on the artist to measure their muscle movements. They developed a neural model of human musculature and had excellent hardware for it, but lacked the software, so we assisted them in that area. We also collaborated with a company called Woodside, an oil and gas company from Australia, because they faced a problem similar to NASA. They were building systems for oil rigs, which are very dangerous environments.

And so they wanted to build cooperative robots, just like NASA was doing. Here we were with this system called CELF that was, frankly, a neural symbolic system. It had neural components, but also symbolic pieces, based upon those three architectural decisions. It was pretty cool. At its peak, I had 35 people working on this.

But then we recognized that IBM had operations in six laboratories around the world, which made it possible for me to live and work out of Maui, Hawaii, where I still reside. However, IBM soon realized that Watson was bleeding cash, so they fired everyone. Fortunately, as a fellow, they did not let me go. I continued to work in that space, and that was my exposure to the first set of new kinds of architectures.

For about six years now, I have been working with a set of neuroscientists to try to understand the architecture of the organic brain. Rather than focusing on software-related concepts, I've been studying things like cortical columns and the loops that exist in the hypothalamus. I have been assessing architecture through the lens of a software architect in relation to these organic systems. This finally leads us back to your question: What do I think about large language models? The answer is that they are pretty cool.

However, they are, by the very nature of their architecture, unreliable narrators. That's what I say politely. If I'm going to be impolite, I will say they allow us to build those global-scale nonsense generators because they are clearly stochastic parrots. They do not reason. They do not understand.

But they do produce some very coherent results because they allow us to navigate a latent space that has been made very complex through training on the corpus of the internet. So that, I think, is back to the perfect storm. We have large language models based on data, algorithms, and the hardware that enable us to build these coherent kinds of outputs. However, we must be careful. Gary Marcus and I have been voracious and consistent critics of Sam and others who claim we are just on the cusp of AGI.

Well, I think that diminishes the elegance of what AGI actually is in humans. It diminishes the beauty of our human intelligence. Frankly, we're not going to achieve it by simply scaling up; we've already seen that we're hitting limitations.

Elon, whom I've engaged with online multiple times regarding his particular views on AGI, has been promising full self-driving capabilities for years now. We're not going to reach that goal because those kinds of models are simply different; they have the wrong architecture. If I have to build a nuclear power plant to develop my systems, I’m probably using the wrong architecture. So, yes, I believe there are valid use cases for large language models, but we must be cautious because they can indeed be dangerous.

Jan blocked me on Twitter because, at the very beginning of their work on Galactica, I called him out on it. I said, "Jan, this is great stuff, but do you realize the implications?" He simply dismissed them, and I kept calling him out. He got tired of me doing so and eventually blocked me. But this is another "I told you so." We have seen the joys and the dangers of large language models. So, just to clarify, it sounds like you're saying that large language models by themselves will not lead us to AGI.

But do I understand that if we combine it with other tools, like neural networks or neural symbiotic systems, we can actually get closer to these intelligent systems? If we take the example you just mentioned— a robot on Mars that is able to clear filters and follow instructions—what do you think we would need to achieve that type of intelligence? I would also add that if we look at cultures such as Japan, where there is an aging population and a shrinking workforce, and the United States, which is very much in a similar situation, there is a tremendous need for elder care. Therefore, the use case for robotics, not just in the context of fully humanoid robots, becomes relevant. There are clear and pressing needs for these kinds of solutions as well.

So yes, there are lots of great use cases. I've always believed this to be a systems engineering problem, which is why, if you go back to the architecture of self, I've been focused on neurosymbolic systems. Now, let me get a little philosophical for a moment. I'm pretty sure you're sentient. I can't guarantee it, but I'm just guessing that you are, and you're not just some amazing large language model.

And why do I think that? It's a fair guess. And why do I believe that? It's because I have a theory of mind about you. Through multimodal ways and my interactions with you, I have formed a theory that says you are sentient. You are someone who has your own agency, feelings, behaviors, needs, and the like.

And that's cool. You're not a robot. The human mind has evolved over millennia to develop an architecture that is, yes, neural in nature. However, artificial neurons are not a shadow; they are an echo of a whisper of what organic neurons are.

They are a small, small piece of it. Furthermore, if you look at the architecture of large language models, which, as you observed, are relatively simple, there is a simple layering to them that ignores the exquisite complexity of the human mind. In our cerebral cortex, we have cortical columns. We have tens of millions of them, and in humans, they are about seven layers deep.

Reptiles have them as well. They're a bit smaller. Those are the ones that appear to be the place, our homunculus work, where we build the predictive models of the world. But we also have areas where emotions and other decision-making processes take place, among these entangled architectures associated with the thalamus and similar structures.

And furthermore, we have other things going on with what appears to be our hormonal system that seem to represent other ways of message passing within our neural networks. In that same regard, large language models are interesting, but they also represent only a whisper of a shadow of what I think reality is. Gary and I have observed that we are reaching diminishing returns on what scale can achieve. The OpenAI team and Elon believe that scale will continue for a long time, but Gary and I are saying no; we are reaching a limit there.

You need to think about it in other ways. That brings us back to those architectures. The last thing I'll mention is that, at the very beginning, you talked about me being involved with embodied cognition. That brings me back to my roots again. What is embodiment?

It's building systems that are in and of the world, that respond to the world and act in the world. Large language models are largely unmodeled. They work through text, maybe static images woven together through video and the like, but they're very sensory sparse. Our minds and our intelligence have grown because they've been embodied in the world.

In that regard, I think there are many kinds of intelligence that exist. But our human intelligence grew because of our embodiment. It requires some fairly complex architecture to achieve that. That's why I've been studying human architectures for six years, because I don't know enough about them. Let's see if that influences the way I build software architectures.

As a closing remark, you previously tweeted something really interesting regarding this, and I'll quote you: "We need a standard way of visualizing the architecture as well as the activity of LLMs, and to generalize any artificial neural network—a sort of UML for AI." Now, this was a year ago. Have you seen any developments in this area? Why do you think LLM architecture is so important?

In fact, I have both thoughts, and I have seen movement. So internally, I've been helping out by providing a bit of architectural adult supervision in our large language model work. I've been trying to figure out the best way to visualize the kinds of things we're doing. It turns out it still resembles UML in that these are now boxes that are systems in themselves, and they're message-passing systems. So I'm trying to determine the best ways to represent that. As you may know, just this week, AlphaFold released its source code and weights publicly.

I'm jumping on that, and I'm going to use it as a basis to describe the architecture of AlphaFold 3 using some UML deliverables. So stay tuned. I think there's work to be done in that regard. As for advice for software engineers who are just starting out in the software industry, there are plenty of recent graduates who find themselves in a challenging job market. Here are some tips: 1. **Build a Portfolio**: Create projects that showcase your skills and interests. This could be anything from personal projects to contributions to open-source software. 2. **Network**: Attend industry meetups, conferences, and connect with professionals on platforms like LinkedIn. Networking can open doors to job opportunities. 3. **Keep Learning**: The tech industry is always evolving. Stay updated with the latest trends and technologies through online courses, tutorials, and reading relevant materials. 4. **Apply Broadly**: Don’t limit yourself to job postings that perfectly match your skills. Apply to a variety of positions to increase your chances of getting noticed. 5. **Prepare for Interviews**: Practice common coding problems and system design interviews. Platforms like LeetCode and HackerRank can be helpful for this. 6. **Be Persistent**: It might take time to land your first job, so stay persistent and keep improving your skills in the meantime. 7. **Seek Internships**: Consider internships or contract work to gain experience that can help you transition to a full-time role later on. Remember, the beginning of your career can be challenging, but with persistence and the right approach, you can find your place in the software industry.

There's a thread of what feels like AI tools changing how we do software engineering. You've gone through a lot of cycles of innovation in software engineering. What advice do you have for those starting out to set them up for a successful software engineering career? Indeed, when Co-Pilots and ChatGPT came out, I received a flood of messages from folks saying, "My gosh, have I chosen the wrong career? Because you're not going to need developers at all." You will always need people who make informed decisions, no matter what the language is.

Software engineering, again, is one of rising levels of abstraction. It's just that our tools have changed. I learned to program in assembly language. People today are going to be learning programming with languages that are at a much higher level of abstraction. So the advice I’d give to such folks is twofold.

Don't worry. Don't be afraid. There's always going to be some really cool work for you to do there. In fact, I would say it's quite the opposite. This is an exciting time because there is so much opportunity, so many cool tools, and so many computational resources that, in many ways, you are limited only by your imagination.

And so what I encourage people to do is to first, learn as much as you can. Second, don't get stuck in just one domain. You need to become an expert in some space. But the world of computing is vast. So find a space that nobody is in right now and go make a name for yourself there, because there are plenty of those kinds of opportunities available for you.

And the third thing I advise is to go have some fun. I mean, my gosh, the toys we have at our disposal are amazing, wonderful, and affordable. There's so much a single person can do at such a low expense to change the world. I'd also like to close by saying I'm not done yet either. I'm having a tremendous amount of fun.

And in addition to the things I mentioned regarding studying the human brain and working with large language models, there are two projects that I am currently engaged in and have been working on for a long time. The first is that I have been trying to write a book on software architecture. I'm glad I did not complete it, as I know so much more now than I did before. This is a different kind of architecture book; rather than simply instructing, it focuses on documenting the as-built architectures of several companies I have been collaborating with.

So I'd like to include AlphaFold in it. Photoshop is included. What is the architecture of Photoshop? What is the architecture of a climate monitoring system? What is the architecture of Wikipedia?

So I'm trying to document the as-built architecture of systems that people use today, which they may never have thought about. The idea is that there are many different architectural styles. Let me expose you to them, as you may have studied only one particular style. The world is a vast one. The second point is that I was heavily... This is the Software Architectures Guidebook, right?

Sure! Here it is with correct capitalization and spelling: "Yeah, the Software Architectures Handbook, which my long-suffering editor has been patient with me for literally a decade now. It's something I hope to finish before I die. The second book is about my time on the Board of Trustees for the Computer History Museum for about ten years. We hired a new CEO, and he came to me and said he had been to PBS. We had a conversation, and he said, 'Hey, John, why don't you do a documentary like Carl Sagan's Cosmos?'"

He paused and said, "Well, Grady, why don't you be our Carl?" I responded, "I'm no Sagan, but that's an intriguing idea." So I've been on a journey to create a documentary and write a book about computing and the human experience, which examines the history of computing and what it means to be human. I'm exploring questions like: What does computational thinking look like? How has computing changed individuals, societies, and nations?

How has it changed science, art, religion, and such? Ultimately, it asks the question: in the presence of computing, what does it mean to be human? That is the larger project I'm working on right now, which I hope to complete before I die. Now, let's wrap up with some rapid-fire questions. I'm just going to ask, and then you can shoot your answers.

You don't need to think too much about it. What was the first programming language that you used? Fortran. Fortran. What project did you commit code to most recently, and what language did you use in it?

Most recently, my own language, my own project self: Python. Python. What do you do to recharge from doing software engineering-related work? I live in Maui. I wake up.

That's enough. Yep. An enviable place. And also, to answer your question: What are two books you would recommend for those who would like to understand more about software architecture?

Mary Shaw's book, "Software Architecture," is one I would recommend. Other books kind of pale in comparison, but I would start there. Well, thank you very much, Grady, for being on the show. This was really interesting and fascinating.

It was a pleasure. Thank you for having me. Thanks to Grady for this great conversation. You can find ways to contact Grady in the show notes below. If you enjoyed this podcast, please subscribe on your favorite podcasting platform and on YouTube.

For some additional takeaways from our conversation, please see the show notes. Thank you, and see you in the next one.