Latest / The Pragmatic Engineer / Software architecture with Grady Booch

Transcript

Software architecture with Grady Booch · The Pragmatic Engineer

0:00
SPEAKER_0: The entire history of software engineering is one of rising levels of abstraction.
0:04
SPEAKER_0: So what we're seeing here is the rise of another level of abstractions, which gives us all these extraordinarily powerful frameworks from which I can build systems and which as I alluded to.
0:15
SPEAKER_0: The architectural decisions that were front and center for us back then are now embodied in these.
0:21
SPEAKER_0: So now becomes a decision, what cloud service do I use?
0:24
SPEAKER_0: What messaging system do I use?
0:26
SPEAKER_0: What platform do I use?
0:28
SPEAKER_0: That's the decision which has a lot of economic decisions and not just software kinds of decisions associated with it.
0:35
SPEAKER_0: So I think the role of the architect in effect has changed because now I'm dealing with systemic problems, not just software problems themselves.
0:43
SPEAKER_1: Grady Booch is a trailblazer in software engineering.
0:46
SPEAKER_1: He built his first computer 57 years ago at just the age of 12 and is known for his decades-long work in advancing the field of software engineering and software architecture.
0:55
SPEAKER_1: He is the co-author of UML and has originated the term and practice of object-oriented analysis and design.
1:01
SPEAKER_1: He's an IBM fellow, an ACM fellow, and has been awarded several other prestigious awards for his work in software architecture.
1:07
SPEAKER_1: He's the author of six books and more than a hundred technical papers on software engineering.
1:12
SPEAKER_1: In this conversation, we cover the first two golden age 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 like how Grady was offered to be Microsoft's chief architect but said no to Bill Gates and a lot more.
1:34
SPEAKER_1: If you enjoy the show, please subscribe to our podcast on any podcast platform and on YouTube.
1:38
SPEAKER_1: It's safe to say I'm talking with a living legend in the field of software engineering.
1:43
SPEAKER_1: So welcome to the podcast.
1:45
SPEAKER_0: Emphasis on living.
1:46
SPEAKER_0: I'm not done yet.
1:47
SPEAKER_0: Yes.
1:48
SPEAKER_1: Absolutely.
1:49
SPEAKER_1: So to kick off, you're a chief scientist at IBM.
1:53
SPEAKER_1: That's a pretty fancy title.
1:55
SPEAKER_1: What does it mean and what do you do?
1:58
SPEAKER_1: I'm curious to know.
1:59
SPEAKER_0: Well, there was a time that 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.
2:08
SPEAKER_0: Actually, the more important title/position is that a fellow... There are I think 68 of us still active.
2:16
SPEAKER_0: No, 89 of us still active, and this has been out of 350 or thereabouts fellows throughout the history of IBM.
2:24
SPEAKER_0: So we're a fairly rare breed.
2:27
SPEAKER_0: I was made a fellow upon the acquisition of our company, Rational Software back in 2003.
2:33
SPEAKER_0: And the great thing about being a fellow is it's rather like having tenure, meaning we trust you done good things, we want you to continue doing things.
2:43
SPEAKER_0: Let's give you the degrees of freedom to do that.
2:46
SPEAKER_0: And so as a fellow and with my focus upon first software engineering and then later upon AI, I am given a lot of degrees of freedom to pursue what I think makes a lot of sense to try to, as Alan Kay would say, invent the future.
3:01
SPEAKER_0: So in my journey from starting at 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 10 years, not the next quarter.
3:18
SPEAKER_0: And indeed my very early work in research was looking at finding ways to automate the discovery of patterns within legacy software systems.
3:27
SPEAKER_0: This is something we were doing pre- neural network days, and it was interesting trying to see if we could discern the design patterns from the gang of foreign elsewhere.
3:37
SPEAKER_0: It never went anywhere because it was a hard problem.
3:43
SPEAKER_0: In the architecture sense of things, I worked with a lot of customers and I actually had been doing that for decades where I'd be parachuted in, the customer would say, "Come help me, Mr. Wizard, with this particular architectural problem."
3:58
SPEAKER_0: And the exciting thing about it for me is that for many decades I was engaged when projects across every conceivable domain, and I'll pause there to say that roughly around the turn of 2010-ish is when I began to be drawn back into the space of AI.
4:17
SPEAKER_1: So when you say you worked on legacy systems, what does a legacy system mean to you?
4:24
SPEAKER_0: Well, the moment you write a line of code, it becomes a legacy system until you throw it away.
4:29
SPEAKER_0: So all code to some degree is a legacy system.
4:32
SPEAKER_0: Facebook is a legacy domain.
4:34
SPEAKER_0: Google is legacy.
4:36
SPEAKER_0: Heavens, even OpenAI has a legacy problem.
4:40
SPEAKER_0: Because reality is that, as I often say, old code never dies, you have to kill it.
4:46
SPEAKER_0: Once you have built something that's useful, then it's going to live on.
4:50
SPEAKER_0: And so unless you have fully disposable code, there is some body of code that you have there that represents something immutable, something that has a cost, something that has some degree of technical debt to it.
5:04
SPEAKER_0: It may be very, very small.
5:06
SPEAKER_0: If you look at many of the classic organizations in the big financial space, these are groups who've been working with code bases since literally the '60s.
5:16
SPEAKER_0: 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.
5:24
SPEAKER_0: Now let's go back in time.
5:25
SPEAKER_0: What was happening in the '60s?
5:27
SPEAKER_0: Well, you had the rise of the population, the increase of social security and the like, and more and more organizations who were creating lots of paperwork.
5:38
SPEAKER_0: And so the banks and the government realized by the late to mid-'60s, there was simply so much going on, you couldn't do it by hand.
5:48
SPEAKER_0: Why did banks used to close at 3:00 PM?
5:50
SPEAKER_0: Because they needed the time for the humans to reconcile accounts.
5:54
SPEAKER_0: The IRS was very much like that.
5:57
SPEAKER_0: And so there was during the '60s this period of automation of human processes.
6:03
SPEAKER_0: And so most of that was written in IBM 360 assembly language.
6:08
SPEAKER_0: 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.
6:19
SPEAKER_0: But that creates really difficult problems because some of that code embodies business rules that are within the assembly language itself.
6:28
SPEAKER_0: So how do you change that?
6:29
SPEAKER_0: And the answer is you're faced with a real human problem of how do I transmogrify old code in COBOL assembly language so that it can work on modern technology.
6:41
SPEAKER_0: There's only so much you can do via emulation, and then we'd consider that the government makes new business rules every year.
6:49
SPEAKER_0: How do you keep up with that?
6:51
SPEAKER_0: That's a real and present legacy problem.
6:54
SPEAKER_0: Facebook has the same thing, although their code doesn't date back that far.
6:58
SPEAKER_0: Google has the same problem as well.
7:01
SPEAKER_0: OpenAI will soon have that problem.
7:04
SPEAKER_1: This episode is brought to you by WorkOS.
7:06
SPEAKER_1: If you're building a SaaS app, at some point, your customers will start asking for enterprise features like [inaudible 00:07:11], SCIM provisioning, and fine-grained authorization.
7:14
SPEAKER_1: That's where WorkOS comes in, making it fast and painless to add enterprise features to your app.
7:19
SPEAKER_1: Their APIs are easy to understand and you can ship quickly and get back to building other features.
7:25
SPEAKER_1: WorkOS also provides a free user management solution called AuthKit for up to one million monthly active users.
7:30
SPEAKER_1: It's a drop-in replacement for Auth0 and come standard with useful features like domain verification, rule-based access control, bot protection, and MFA.
7:39
SPEAKER_1: It's powered by Radix components, which means zero compromises in design.
7:42
SPEAKER_1: You get limitless customizations as well as modular templates designed for quick integrations.
7:47
SPEAKER_1: Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Vercel, and Perplexity.
7:54
SPEAKER_1: Check it out at workos.com to learn more.
7:57
SPEAKER_1: That is workos.com.
8:00
SPEAKER_1: This episode is brought to you by Sevalla.
8:02
SPEAKER_1: It's a true Heroku alternative where you can deploy applications, manage databases, and host static sites for free.
8:09
SPEAKER_1: Sevalla is a platform designed for teams.
8:11
SPEAKER_1: With its preview and pipeline features, developers can collaborate on any stack while being assured of the security of their workloads from staging to production.
8:20
SPEAKER_1: Sevalla holds all the major security certifications companies are typically looking for.
8:24
SPEAKER_1: Their application hosting offers automatic Git integration, Docker image deployments, hibernation for optimal cost savings, vertical and horizontal autoscaling, TCP proxy support and optional private network connections for your databases.
8:38
SPEAKER_1: Their free static site hosting is perfect for landing pages, documentation sites and more.
8:43
SPEAKER_1: It also includes preview deployments for easier iterations and seamless teamwork.
8:47
SPEAKER_1: Sevalla features an easy-to-use interface, unlimited seats, no hidden tricks and transparent usage-based pricing with enterprise level cloud for DDoS protection for workloads of any size.
8:58
SPEAKER_1: Sign up and deploy today.
8:59
SPEAKER_1: Go to sevalla.com.
9:01
SPEAKER_1: That is Sevalla with a double L dot com.
9:05
SPEAKER_1: When you say you were parachuted to help a bunch of different types of companies, can you give a sense of what types of companies you worked over the years, the decades to help with their architecture, their legacy code, their tech depth?
9:18
SPEAKER_0: Every conceivable domain truly is.
9:21
SPEAKER_0: I've had the opportunity to work with obviously the financials.
9:25
SPEAKER_0: I've done a lot of work in the defense sector.
9:28
SPEAKER_0: In fact, to go way back in time, complex systems were really not started in the commercial realm, but they really began in the world of defense.
9:38
SPEAKER_0: The phrase I also use here is that all of modern computing was woven on a loom of sorrow.
9:44
SPEAKER_0: 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 that came about during the '50s and indeed was operational till the 1980s.
9:59
SPEAKER_0: This was a system built in response of the Soviet threat of them taking bombers over the Arctic and coming into the United States before we had satellites in pervasive radar.
10:11
SPEAKER_0: And that was a system that precipitated the creation of what we call the software crisis.
10:18
SPEAKER_0: It was what triggered the creation of the NATO conference later in that decade in which a group of folks came together from around the world saying, "How do we attend to this problem?"
10:29
SPEAKER_0: And it was really at the peak of what I'd call the first golden age of software engineering.
10:35
SPEAKER_0: So we have defense systems.
10:37
SPEAKER_0: I worked with a lot of real-time systems, everything from pacemakers to subway systems to, gosh, what else, CT scans and the like.
10:52
SPEAKER_0: Truly, you name a domain and I probably spent some time in it.
10:57
SPEAKER_0: The James Webb Space Telescope currently uses the UML in its design.
11:02
SPEAKER_0: That's pretty freaking cool if you think about it.
11:06
SPEAKER_1: Jumping way forward, you've now been working with a lot of companies, been involved in a lot of projects and also influenced a lot of software architecture, the broader field.
11:17
SPEAKER_1: How would you describe the field evolving over the decades?
11:20
SPEAKER_1: You were clearly part of some key techniques invented and become a common place.
11:25
SPEAKER_1: What was this like?
11:27
SPEAKER_0: So I alluded to a phase I called the first golden age of software engineering.
11:32
SPEAKER_0: This is the realm of the time of functional, or not functional, but algorithmic languages such as Fortran and COBOL, APL, Lisp and the like, although Lisp was sort of a multimodal kind of language.
11:46
SPEAKER_0: But the dominant way that we decompose systems was through algorithms.
11:52
SPEAKER_0: And so you saw the rise of structured analysis and design techniques, which made a whole lot of sense at that time.
11:58
SPEAKER_0: This is where you had the Yourdons and DeMarcos and Constantines and the like, because the presenting problem for software systems was they were generally not distributed.
12:08
SPEAKER_0: They were largely monoliths.
12:10
SPEAKER_0: And how could we build larger and larger systems that were sustainable and economically interesting over time?
12:16
SPEAKER_0: Well, that first golden age of software engineering began to change as we started to see the rise of distributed systems.
12:25
SPEAKER_0: That rise again happened not in the commercial world but it happened in the defense world.
12:31
SPEAKER_0: The ARPANET was funded by the government, funded by DARPA.
12:36
SPEAKER_0: As I mentioned to you earlier, I got my first email address in 1979 when there weren't that many email addresses around.
12:45
SPEAKER_0: In fact, one small story there, when we had the ARPANET, I was teaching at the Air Force Academy at the time.
12:52
SPEAKER_0: We had a mimeographed document that listed the email address of everybody in the world.
12:59
SPEAKER_0: I think at that time there were a few thousand people, so we knew who everyone was at the time.
13:05
SPEAKER_0: It was pretty cool to go back.
13:08
SPEAKER_0: So the first distributed systems were happening in that domain.
13:11
SPEAKER_0: Indeed, back to Vandenberg, I worked on a system called the Telemetry Integrated Processing System, which was a close network of some 32 mini computers.
13:22
SPEAKER_0: Mini computers were [inaudible 00:13:23] be a thing.
13:24
SPEAKER_0: And so the problems of how do I deal with taking a larger system and breaking it up into multiple distributed parts was beginning to emerge as a problem, hadn't reached the commercial sector yet.
13:37
SPEAKER_0: So we saw the industry began to see that there were limitations to what one could do with algorithmic decomposition.
13:46
SPEAKER_0: And so there were these pressures all around to try to attend to the next kinds of software, software that was distributed, software that was real-time, software that was multilingual, software that worked on a variety of computers.
14:01
SPEAKER_0: And I had to deal with all the normal aspects of distributed systems, which is they're going to fail at various times and I've got communication issues and the like.
14:11
SPEAKER_0: So it led to a realization that we needed to think about software in very different ways.
14:16
SPEAKER_0: The other thing that was happening is in research, you saw the rise of languages such as Simula and Smalltalk, which we're looking at the world in fundamentally different lenses.
14:27
SPEAKER_0: So here we are again in the late '70s, and again, I'm what, a 20-something.
14:31
SPEAKER_0: I was asked by one of my former teachers at the Air Force Academy say, "Grady, would you go 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?"
14:45
SPEAKER_0: Now, why was the government worried about this?
14:48
SPEAKER_0: By that time, software was a real problem for the Department of Defense, actually for all of the federal government because there were several thousand languages in use that exploded because Fortran and COBOL were useful for some things but not for all things.
15:03
SPEAKER_0: And so there was a decision made to build one language to rule them all, and that was the aid of programming language.
15:10
SPEAKER_0: Ada was far ahead of its time.
15:12
SPEAKER_0: It was a language that was influenced by Simula and Smalltalk and others but used the ideas of abstract data types from Liskov and Galgen and others.
15:22
SPEAKER_0: It used the ideas of information hiding from David Parnas, all ideas that were very new at the time but frankly are part of the atmosphere in which we breathe right now.
15:32
SPEAKER_0: And so as an industry, we really didn't understand the methodologies to make that work.
15:38
SPEAKER_0: Thus was born the Booch method.
15:42
SPEAKER_0: Here I was in '79 till about '81.
15:46
SPEAKER_0: I was going back and forth across the United States helping the federal government and helping contractors try to apply this new language in new ways.
15:55
SPEAKER_0: And this was 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 problems, systems that were dealing with distributed systems that were very new at the time.
16:10
SPEAKER_0: And that was the essence of the Booch method.
16:12
SPEAKER_0: It was the things I learned about helping organizations architect systems with these new kinds of domains and new kinds of languages.
16:21
SPEAKER_1: Could you explain what the Booch method is?
16:23
SPEAKER_1: 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 explain what it is and why it was important.
16:37
SPEAKER_0: Well, let's go back to Plato, talking about going way back.
16:41
SPEAKER_0: I wasn't around then but I've read about him a little bit.
16:44
SPEAKER_0: There's this wonderful treatise he wrote, the dialogue in which there's a debate about how one should best look at the world.
16:53
SPEAKER_0: Should I look at it as atoms or should I look at it as processes?
16:59
SPEAKER_0: Well, the first golden age of software engineering was more focused upon the processes, the algorithms, but there's a parallel way of looking at the world, and that's looking at it through the atoms, if you will, the classes and objects within them.
17:14
SPEAKER_0: So yes, I was influenced by abstract data type theory, by Plato, by a lot of other interesting philosophical things that were coming together at the time of looking at the world in fundamentally different ways.
17:29
SPEAKER_0: So the Booch method was really trying to codify that.
17:33
SPEAKER_0: How could we decompose systems not based upon algorithms, but how do we decompose it based upon classes and objects?
17:41
SPEAKER_0: And again, that's where I was influenced by Liskov and Parnas and Dijkstra and Horan and the like, names that are probably unfamiliar to students these days, but they were representing the theoretical underpinnings of the first and second generation.
17:58
SPEAKER_0: The Booch method was basically saying, " Hey, here's a new way of thinking about the world."
18:03
SPEAKER_0: And so it said look, not at algorithms but look at combining data and processes, algorithms together in one thing, thereby classes.
18:15
SPEAKER_0: Now, we did some things right, we did some things wrong.
18:18
SPEAKER_0: I think the things we did was classes make a lot of sense in terms of abstraction.
18:22
SPEAKER_0: What we did wrong is we overemphasize the notion of inheritance.
18:26
SPEAKER_0: Inheritance was all about let's save code because we can build generalizations and the like.
18:33
SPEAKER_0: That proved to not make a lot of sense because we ended up doing lots of disparate kinds of abstractions.
18:39
SPEAKER_0: That's okay.
18:40
SPEAKER_0: Fast-forward to today and people say, "Well, what difference does it make?"
18:44
SPEAKER_0: And the answer is it's part of the very atmosphere in which you breathe, and so you don't even think about it.
18:49
SPEAKER_0: You look at Redis and you may build things upon it.
18:53
SPEAKER_0: But if you look at it, you're really dealing with a set of abstractions that Redis offers you, and those abstractions are class-based.
19:01
SPEAKER_0: So they're baked into the way of thinking of those kinds of systems.
19:05
SPEAKER_0: So in short, the Booch method was let's look at the world not through algorithms but instead through objects and classes.
19:11
SPEAKER_0: The last thing I'll mention is one of the things the Booch method hinted at that really did not catch full form into the UML was looking at systems through multiple points of view.
19:23
SPEAKER_0: Now, we'll come back to that in a bit when I talk about [inaudible 00:19:26].
19:27
SPEAKER_1: So just so I understand, because myself and most of us listening will have started our careers long after the Booch method was invented.
19:36
SPEAKER_1: For us, classes, variables, inheritance, that's pretty common, pretty everyday-
19:43
SPEAKER_0: Right.
19:43
SPEAKER_1: ... things.
19:43
SPEAKER_1: But as I understand, it wasn't like that back then, right?
19:49
SPEAKER_1: So could you talk us through the environment, the technology was like?
19:56
SPEAKER_1: So that what made the Booch method so new, interesting or innovative?
20:04
SPEAKER_0: Well, let me go even further back to the 1950s and show you a parallel story.
20:10
SPEAKER_0: There was a time in the growth of algorithmic programming languages where the idea of a subroutine was considered controversial.
20:19
SPEAKER_0: Why?
20:19
SPEAKER_0: Because doing a function call added at least two or three more instructions, which was computationally expensive.
20:29
SPEAKER_0: So even function calls and decomposing something into subroutines was viewed as an architectural aberration, and people opposed it because it was inefficient.
20:40
SPEAKER_0: Well, obviously we think, well, that was stupid because we need it for our management of complexity.
20:46
SPEAKER_0: The same thing I think was true back in the days of early object orientation.
20:51
SPEAKER_0: I mean, people were doing object orientation in algorithmic languages because you'd have these things in COBOL called common data areas.
21:01
SPEAKER_0: People would devise, here's all this common data, and as a matter of practice but not language, you would say this data is used in this way by these algorithms and vice versa.
21:12
SPEAKER_0: 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 here is the common data pool.
21:26
SPEAKER_0: And so it was the abstractions right in your face because they changed.
21:30
SPEAKER_0: And so people were trying to do algorithmic or object-oriented decompositions, but the languages didn't support it.
21:38
SPEAKER_0: There was a need to do that kind of thing.
21:40
SPEAKER_0: And until the languages came into play, there was no way to bring those ideas together efficiently.
21:46
SPEAKER_0: And so, yes, the Booch method was very much a reaction to the forces upon building software-intensive systems to look at classes, trying to apply it with modern languages and building a methodology around it.
22:00
SPEAKER_0: Today, we take it for granted because our languages make it easy for us to do this.
22:05
SPEAKER_1: It's just fascinating to think back how revolutionary it was and compare to just how commonplace it is.
22:12
SPEAKER_1: And also to think about how things that we invent today and that are revolutionary in 20 years, people will be like, "Oh, yeah, that's commonplace."
22:20
SPEAKER_0: Right, exactly.
22:22
SPEAKER_1: One thing that you're known for, and you also mentioned you're associated with it, is UML.
22:28
SPEAKER_1: But can you share how this was created?
22:31
SPEAKER_1: What was the goal of it back then?
22:33
SPEAKER_1: Who were involved and what was the need that it was solving at the time?
22:39
SPEAKER_0: Right.
22:39
SPEAKER_0: So in 1982, two of my classmates from the Air Force Academy, Paul Levy and Mike Devlin, Paul had been a roommate of mine at the Air Force Academy.
22:48
SPEAKER_0: He was an economics major.
22:50
SPEAKER_0: Mike Devlin was a computer science major.
22:52
SPEAKER_0: Mike and I had a few classes together.
22:54
SPEAKER_0: The first time ever met Mike was in an unarmed combat course, by the way.
23:00
SPEAKER_0: So not your typical thing you get at colleges, but hey-
23:03
SPEAKER_0: So, not your typical thing you get at colleges, but hey, I was trained to be a warrior.
23:06
SPEAKER_0: That's where I first met Mike, and I think he beat the stuffing out of me, if I'm not mistaken, in the pugilistic competition.
23:13
SPEAKER_0: Here I was at Vandenberg Air Force Base.
23:15
SPEAKER_0: Mike and Paul were up in the Bay Area.
23:20
SPEAKER_0: They were working at the satellite control facility, and I engaged with them because they had one of the first largest ADA projects that was going on.
23:28
SPEAKER_0: So I went up and helped consult with that project.
23:31
SPEAKER_0: The two of them also went to Stanford, and I swear there's something in the water at Stanford, because they then connected with Art Rock and Hambrecht & Quist.
23:40
SPEAKER_0: The two premier venture capitalists at the time.
23:44
SPEAKER_0: Art Rock and Hambrecht & Quist were the key founders to Apple, and they also contributed to the funding of what became Rational software.
23:52
SPEAKER_0: So in '82, Mike and Paul got together with me and said, "Let's start a company," and we did.
23:58
SPEAKER_0: It was this company called Rational Machines Incorporated, whose intent was to build a software developing environment for this new coming ADA programming language.
24:10
SPEAKER_0: We saw that to be an opportunity in which we could make piles of money, and we built hardware at first, because this was the time when many computers were becoming affordable.
24:24
SPEAKER_0: You had Sun coming into play here, but none of them were powerful enough to do the kinds of things, what we were doing.
24:30
SPEAKER_0: So Mike designed a system.
24:33
SPEAKER_0: I helped build the methodology around using the system.
24:36
SPEAKER_0: It was a system called the R1000, and that was the dominant ADA system used around the world for ADA at the time.
24:45
SPEAKER_0: Well, around, I don't know, would've been the early, jump ahead a decade now, here we are, the mid '90s, and I was getting a little tired of doing that kind of stuff and branching out in other places.
24:59
SPEAKER_0: And I found that there was traction that I was getting from the Booch method into the commercial sector.
25:07
SPEAKER_0: I was giving a bunch of lectures at the time, and at one time there was a gentleman in the audience who asked a really insightful question, and afterwards he and I met up.
25:18
SPEAKER_0: A guy by the name of Bjarne Stroustrup.
25:21
SPEAKER_0: And it turns out Bjarne was working on a thing called C with Classes, which was the predecessor to C++.
25:28
SPEAKER_0: The two of us got together, we hit it off.
25:31
SPEAKER_0: We found that we were doing very similar things together, and 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.
25:41
SPEAKER_0: And this was around the time he wrote his first book on C++.
25:45
SPEAKER_0: If you look at the first edition, you'll see here, references a lot of my ideas, and that's when my book on Object-Oriented Design came out, and I reference his work a lot too.
25:54
SPEAKER_0: Oh, the Booch method and C++ kind of grew up together.
26:00
SPEAKER_0: Well, I thought this was interesting, and I remember a particularly important meeting I had with Mike and Paul around the time, it was at the Red Carpet Club of United Airlines in Denver, and they met with me and said, "Hey, Grady, we're thinking of moving the company in the direction of embedded systems."
26:19
SPEAKER_0: And I said to them, "Well, good for you.
26:21
SPEAKER_0: I think that's a stupid idea, because you're missing the commercial sector.
26:25
SPEAKER_0: Go off and have fun.
26:26
SPEAKER_0: I'm going to do different things."
26:28
SPEAKER_0: That 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.
26:43
SPEAKER_0: And so they then made the decision, "Hey, let's take the Booch method and make it real."
26:49
SPEAKER_0: And this was the beginnings of a system called Rose, Rational Object-Oriented Software Engineering, our first tool.
26:56
SPEAKER_0: The first prototype, by the way, I wrote in Smalltalk, it was a wonderful system.
27:01
SPEAKER_0: I wish I had kept the source code for that around, but I remember making changes to it just literal minutes before we did the first demo.
27:10
SPEAKER_0: And so that's where we sort of broke out from the defense sector into the commercial sector.
27:16
SPEAKER_0: And it was a big hit, because that was the time when I think lots of others were recognizing object orientation was a good light way of looking at the world, and C++ actually supported that.
27:28
SPEAKER_0: Well, that led to two things, not just commercial success on our part.
27:33
SPEAKER_0: We began to make lots of money and we began acquiring other companies and we started filling out the software engineering life cycle.
27:41
SPEAKER_1: Can you just tell us what Rational Software did, this commercial thing that was a hit?
27:46
SPEAKER_0: Yep.
27:47
SPEAKER_0: So Rational Software, the Rose, Rational Object-Oriented Software Engineering, was a personal productivity tool, if you will, that ran on an IBM PC.
27:57
SPEAKER_0: It also ran on, I think we eventually moved it to a number of other devices.
28:03
SPEAKER_0: It ran under Windows in the first one that basically allowed you to draw UML diagram, not UML, but Booch diagrams so that you could then reason about and think about your design.
28:15
SPEAKER_0: We did a little bit of cogeneration, but really it was just a design tool to help organizations think about their designs, and people use it quite well to document and specify and build their systems.
28:29
SPEAKER_0: Now we started making lots of money off of it, and so we started acquiring companies.
28:35
SPEAKER_0: We bought a requirements company.
28:38
SPEAKER_0: Ed Yourden came to me and said, "Go look at these folks."
28:40
SPEAKER_0: We did.
28:41
SPEAKER_0: We bought a small company out of Cambridge called Pure Atria, which was led by a gentleman by the name of Reed Hastings.
28:49
SPEAKER_0: Reed came to us and we bought his company and he said, "You know"-
28:52
SPEAKER_1: And we're talking about the founder of Netflix, right?
28:54
SPEAKER_0: Yes, yes.
28:54
SPEAKER_0: So we bought his company-
28:56
SPEAKER_1: Small world.
28:58
SPEAKER_0: Yeah, Reed realized he's a lousy CEO.
29:01
SPEAKER_0: And so he took his money, hang around for a few years figuring out what he was going to do, and actually that was a lot of the seed money that helped form Netflix.
29:09
SPEAKER_0: It is a small world in that regard.
29:12
SPEAKER_0: At that time, at the peak of what we were doing by the late 1990s, IBM Rational was sort of dominating the space of software engineering, because we had tools across every part of the development life cycle.
29:25
SPEAKER_0: And this is where the ideas of incremental and iterative software development came into play, long before today what we call continuous integration and continuous deployment.
29:34
SPEAKER_0: We were already doing that with a Rational machine in our tools.
29:37
SPEAKER_0: We had pioneered those ideas, because we had built incremental compilation tools and the like.
29:43
SPEAKER_0: So here we were in the '90s and we had a whole set of tool sets around this, but because this was clearly gaining traction in the marketplace, we were at the only ones and we were seeing the rise of hundreds if not a few 1000 companies that were beginning to try to do object-oriented kinds of things.
30:02
SPEAKER_0: And this was the beginnings of the second golden age of software engineering where you had Pete Code and Constantine back again and Yourden again, and Martin.
30:13
SPEAKER_0: We had Ivar Jacobson and Jim Rumbaugh.
30:17
SPEAKER_0: And so it was a very vibrant time where organizations were trying to say, "Gosh, we've got these great tools.
30:24
SPEAKER_0: We've got the ARPANET, we've got personal computers, how do we build software for it?"
30:29
SPEAKER_0: So the presenting problem was in software, what is the best way to design systems using this very, very robust, very powerful set of tools we have at our hands.
30:42
SPEAKER_0: And so Rational being in a very interesting space, we said, "We're kind of dominating the market.
30:49
SPEAKER_0: Let's keep going here."
30:51
SPEAKER_0: So we hired Jim Rumbaugh, and the task Jim and I had was to combine his methodology, OMT, object management technique, with mine.
30:59
SPEAKER_0: We were sort of the two leading ones at the time.
31:01
SPEAKER_0: Then we bought Ivar Jacobson's company, because both Jim and I were using what was the idea of use cases.
31:07
SPEAKER_0: Again, talk about something that's part of the atmosphere.
31:10
SPEAKER_0: Use cases are just something you think about, but they were new at the time in the '90s.
31:15
SPEAKER_0: They were an idea invented by Ivar in his work primarily at Ericsson.
31:20
SPEAKER_0: And so we were working together with Ivar on building software for base stations for the burgeoning cellular telephone networks, which were a thing back at the time as well too.
31:33
SPEAKER_0: So here we have the three of us who were brought together by Rational, and our task was let's unify our methods.
31:40
SPEAKER_0: Now, you could never have found three very different people.
31:45
SPEAKER_0: I'm pretty amazed that we didn't end up with one of us in the hospital and one of us in jail.
31:50
SPEAKER_0: We were so, so very different.
31:52
SPEAKER_0: And 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 the UML.
32:01
SPEAKER_0: So we decided this is not just ours.
32:04
SPEAKER_0: We need to make it something that the whole world could use.
32:07
SPEAKER_0: We made the decision to release it into the object management group, and that was born, UML 1.0.
32:14
SPEAKER_0: I sort of drove most of that working with Jim and Ivar.
32:17
SPEAKER_0: I wrote the primary document for it.
32:19
SPEAKER_0: Obviously it was the three of us working together.
32:21
SPEAKER_0: I want to give them complete credit, believe me.
32:25
SPEAKER_0: But after UML 1.0, I was emotionally exhausted and want to go off and do new things.
32:31
SPEAKER_0: So I kind of walked away from it at the time.
32:33
SPEAKER_0: I want to pause and mention one other person who was important here, actually two other people.
32:38
SPEAKER_0: The first was Philippe Kruchten.
32:40
SPEAKER_0: So we realized that our work was so big we couldn't just do the methodology and the notation.
32:45
SPEAKER_0: So Jim, Ivar and I worked on the notation that was the UML and Philippe worked primarily with some of Ivar's people on the methodology, and this was born the Rationally Unified Process.
32:59
SPEAKER_0: Notice the emphasis upon unified.
33:01
SPEAKER_0: Philippe brought to the table the very important idea that we've begun to see hints at with the Booch method, and that is looking at the world through multiple points of view.
33:11
SPEAKER_0: Philippe has this idea of the 4+1 view model, which he grew from his work with building the Canadian air traffic control system.
33:19
SPEAKER_0: Again, a very complex distributed system.
33:22
SPEAKER_0: Those ideas were eventually made manifest in IEEE, IEC, IOC standard 420020 on architectural description, which basically says, "If you're looking at an architecture, you have to look at it from multiple points of view, use cases, logical view, process view, implementation view and deployment view."
33:41
SPEAKER_0: And that's a very important and profound piece.
33:45
SPEAKER_0: The other thing that came into play, another person that came into play was Walker Royce.
33:51
SPEAKER_0: Now, Walker's an interesting guy.
33:53
SPEAKER_0: You talk about a small world, his father, Win Royce, who I had the pleasure of working with when he was at Lockheed at the time, Win Royce was the gentleman who wrote the paper on Waterfall lifecycles, and his son was basically working on spiral models in the Booch method.
34:12
SPEAKER_0: Win was misunderstood, because he was not endorsing Waterfall methods.
34:16
SPEAKER_0: He said, "That's a stupid idea."
34:18
SPEAKER_0: In fact, look at Parnas' paper, A Rational Design Process, Why and How to Fake It.
34:23
SPEAKER_0: It's from that.
34:24
SPEAKER_0: The Rational Software name came out of, by the way, which says, "At one level it looks like Waterfall, inside, no, it's what today we would call Agile."
34:33
SPEAKER_0: So here we are, what, the late '90s, early 2000, UML 1.0 was in the bag, and that was the life of Grady at the time.
34:44
SPEAKER_1: Hey, developers, we've all been there.
34:46
SPEAKER_1: It's 3:00 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.
34:59
SPEAKER_1: That's why Chronosphere 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.
35:09
SPEAKER_1: With just one click, DDX automatically analyzes all spans and dimensions related to a service, pinpointing the most likely cause of the issue.
35:17
SPEAKER_1: Don't the troubleshooting drag you into the early hours of the morning, just DDX it and resolve issues faster.
35:24
SPEAKER_1: See why Chronosphere was named a leader in the 2024 Gartner Magic Quadrant for observability platforms at chronosphere.io/pragmatic.
35:33
SPEAKER_1: That is chronosphere.io/pragmatic.
35:38
SPEAKER_1: And do I understand correctly that the goal of UML was to describe a system?
35:44
SPEAKER_1: So when I think back to college with UML, we have the different boxes of different classes.
35:50
SPEAKER_1: We have the arrows between them.
35:53
SPEAKER_1: They describe relationships depending on the type of the arrow is.
35:57
SPEAKER_1: And when you look at this whole diagram, you get a sense of the structure of the software you're building.
36:04
SPEAKER_0: Yes.
36:05
SPEAKER_0: So if you look at the very first line of the UML 1.0 standard, I believe it says something to the effect, the UML is a visual language intended to reason about, visualize, specify, and document the artifacts of a software intensive system.
36:22
SPEAKER_0: It says nothing about it being a programming language.
36:24
SPEAKER_0: In fact, I voraciously pushed back against that.
36:28
SPEAKER_0: It was a language meant to think about and reason about a system, to think about the world in object-oriented ways, particularly in ways that you looked at it through multiple points of view.
36:40
SPEAKER_0: DevOps today, by the way, is simply an amalgamation of deployment and implementation views, but we didn't call it back that way then.
36:47
SPEAKER_0: We looked at it from those kinds of views.
36:49
SPEAKER_0: And that's really where UML 1.0 was.
36:52
SPEAKER_0: It was meant to be, how do I think about these things?
36:55
SPEAKER_0: How do I reason about them?
36:57
SPEAKER_0: And I always intended for, you'd write a UML diagram and you'd throw most of them away.
37:03
SPEAKER_0: Now, unfortunately, many people didn't do that.
37:06
SPEAKER_0: And 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 the UML very precise.
37:17
SPEAKER_0: We want to turn it into a programming language."
37:19
SPEAKER_0: And that was, I think, a profound mistake.
37:23
SPEAKER_0: 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.
37:32
SPEAKER_0: And the emphasis then was upon not using it to reason, but to generate code and to reverse engineer.
37:39
SPEAKER_0: Now, the reverse engineering, I can get, that makes a lot of sense, but turning into a programming language was a mistake.
37:45
SPEAKER_0: And I think that began the decline of the UML, because people were using it in the wrong ways.
37:50
SPEAKER_0: At its peak, UML probably had a 20 to 30% penetration in the marketplace, which is pretty cool if you think about it.
37:59
SPEAKER_0: And so I'm proud of looking at the systems in which it was used, but most of all, I'm proud of the fact that it helped people think of building software in different ways.
38:09
SPEAKER_1: So when you say at a peak it had 20 to 30% usage, does this mean that about 20 to 30% of commercial developers were using it at the time?
38:19
SPEAKER_1: And what time was this?
38:21
SPEAKER_1: Around what time?
38:22
SPEAKER_0: Yeah, here we're talking around 2000 plus or minus a few years.
38:28
SPEAKER_0: Remember that Microsoft was big in the midst of this as well too, that they actually worked with us to take our Rose product and make it a part of Visual Studio.
38:39
SPEAKER_0: So we had a team that was working up 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.
38:51
SPEAKER_0: So yeah, we're talking around 2000 or so.
38:55
SPEAKER_0: But what else happened in that timeframe?
39:01
SPEAKER_0: So the ARPANET had moved over to the internet.
39:03
SPEAKER_0: We were beginning to see companies in the late 1990s move on to the internet, which was great, but there was a challenge there.
39:11
SPEAKER_0: There was first, how do I even build systems for distributed work in the web and how do I make money off of it?
39:19
SPEAKER_0: What does those systems look like?
39:21
SPEAKER_0: And so that's why Microsoft was interested, because we were helping their customers move from the PC to distribute the systems.
39:29
SPEAKER_0: But on the other hand, there was also a lot of hype that the internet is going to improve your sex life.
39:36
SPEAKER_0: It's going to do all these kinds of things.
39:38
SPEAKER_0: It was just totally over investment in that space.
39:41
SPEAKER_0: So a little after the millennium, we saw a backlash and there was this great downturn in the marketplace where people had built things and realized they weren't necessarily economically sustainable.
39:59
SPEAKER_0: So now we are here in 2003, IBM and Microsoft were still using our tools heavily because they were important for their customers.
40:09
SPEAKER_0: IBM and Microsoft both bid for us, and I think IBM won some bid of $2.7 billion to buy Rational.
40:14
SPEAKER_0: And so we went over to IBM and became part of it.
40:25
SPEAKER_0: And that made sense because at that time there were 3,500 of us in 14 countries.
40:30
SPEAKER_0: 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.
40:38
SPEAKER_0: Now, one other story I'll tell before I pause again.
40:43
SPEAKER_0: Here I was, IBM had acquired us.
40:46
SPEAKER_0: They made me a fellow immediately, which had never happened before.
40:50
SPEAKER_0: It usually takes years of being part of IBM.
40:53
SPEAKER_0: And a couple of months after I got a phone call that said, "Hey, Grady, it's Bill, come visit me."
40:58
SPEAKER_0: So I went up and flew up to-
41:00
SPEAKER_1: Bill Gates, right?
41:01
SPEAKER_0: Bill Gates, yeah.
41:02
SPEAKER_1: Wow.
41:02
SPEAKER_0: I'd done some things with Bill before.
41:04
SPEAKER_0: And so Bill was at the time still CEO of Microsoft.
41:07
SPEAKER_0: I said, "Hey, Bill."
41:08
SPEAKER_0: Took me into his office.
41:09
SPEAKER_0: We had a 30-minute meeting scheduled.
41:12
SPEAKER_0: We ran for two hours, much to the annoyance of his staff, and 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.
41:24
SPEAKER_0: And Grady, I've got two roles.
41:26
SPEAKER_0: I'm CEO, and I'm chief architect of Microsoft.
41:30
SPEAKER_0: I'd like to give you that job of chief architect for Enterprise."
41:35
SPEAKER_0: And so I said, "Bill, that's very interesting."
41:38
SPEAKER_0: And so I said, "Give me a little time."
41:41
SPEAKER_0: And I went around and met all of his main reports.
41:46
SPEAKER_0: Most importantly, Ballmer never met me, and that was a red flag.
41:50
SPEAKER_0: And it was around the time too I realized that Microsoft was a particularly nasty company.
41:58
SPEAKER_0: You had the Office group and you had the Windows group that just couldn't stand one another.
42:04
SPEAKER_0: So I eventually came back to Bill through his hiring folks and said, "Bill, I'm flattered, but you know, you have a profoundly dysfunctional company and I'm not the one to fix it.
42:16
SPEAKER_0: So Bill, thank you.
42:17
SPEAKER_0: But no, thank you."
42:18
SPEAKER_0: 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.
42:25
SPEAKER_0: So I stayed at IBM and it was a good decision to make.
42:28
SPEAKER_0: It would've been a bad decision for me to go.
42:30
SPEAKER_1: And there's this cartoon about Microsoft created by a software engineer cartoonist, Manu Cornet about the organizations of Microsoft, the two organizations, and they're holding guns against one another.
42:45
SPEAKER_0: Yeah, yeah.
42:46
SPEAKER_0: That's what it was.
42:47
SPEAKER_0: They needed somebody to knock it.
42:49
SPEAKER_0: I'm a lover, not a fighter, and I was not the guy to break things up.
42:53
SPEAKER_1: Wow, what a story.
42:56
SPEAKER_1: So I studied UML in college, and to this date, it's part of several college curriculums, but interesting enough in the industry, I've just not really seen it used for anything, at least the companies that I worked at and the startups and scale-ups and large companies I work with.
43:17
SPEAKER_1: I kind of see a resistance to using it when it's brought up, claiming that it's too formal.
43:22
SPEAKER_1: Because we do use architecture, right?
43:24
SPEAKER_1: We use boxes and arrows and we diagram.
43:28
SPEAKER_1: I'm curious to know, we talked about how UML was used by 20, 30% of the industry at some point, but what happened in your view?
43:37
SPEAKER_0: So this leads us to contemporary architecture, that I've got a shelf full of books on architecture, both in the older ones and new ones.
43:47
SPEAKER_0: And if you look at what a lot of people speak of as software architecture today, I think it's reasonable and sound, and there's good stuff there.
43:55
SPEAKER_0: But in many of the kinds of systems these architects talk about, the architectural decisions have largely been made for you.
44:02
SPEAKER_0: I'm going to build a system that requires message passing.
44:05
SPEAKER_0: Well, let's go find RabbitMQ or whatever, Redis or whatever I need.
44:15
SPEAKER_0: The architectural decisions have been made for you.
44:18
SPEAKER_0: So a lot of the activities of contemporary architects is simply taking very large frameworks and components and weaving them together, which is a very noble and wonderful thing to do.
44:30
SPEAKER_0: They also represent systems like Meta and [inaudible 00:44:34] in particular.
44:34
SPEAKER_0: They have grown their architecture and system over a few decades now, and the stuff they're building on top of it is largely evolving and building upon those APIs, which does not require the deeper kinds of architectural thinking.
44:51
SPEAKER_0: So I use this, let me give you an image here of a three axis system.
44:57
SPEAKER_0: Along one axis you have levels of ceremony.
45:04
SPEAKER_0: If I'm a startup, then it's just my other people's money and no one else's.
45:10
SPEAKER_0: And heck, I can write disposable software and if I fail, I'll just go find another venture capitalist.
45:16
SPEAKER_0: Of course, I'm not going to worry about any kinds of degree of ceremony, because just build it.
45:21
SPEAKER_0: Go hire some brilliant people and make it happen.
45:23
SPEAKER_0: That's wonderful.
45:25
SPEAKER_0: 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, about half a billion, half a trillion dollars, you bet you're going to use more ceremony, because you have to have degrees of accountability.
45:43
SPEAKER_0: So that's one axis.
45:45
SPEAKER_0: The next axis is that of risk.
45:50
SPEAKER_0: So if I build a system and says, "Oh, if I fail, so-and-so's not going to find their Grindr match, big deal."
46:00
SPEAKER_0: On the other hand, if I fail and somebody-
46:03
SPEAKER_0: Scale.
46:03
SPEAKER_0: On the other hand, if I fail and somebody dies, that's a problem, and you're going to use a more disciplined architecture.
46:08
SPEAKER_0: The third axis is that of complexity.
46:11
SPEAKER_0: If I build a system that people have done again and again, then heck, I don't need anything.
46:15
SPEAKER_0: Heavens, this is where prompt engineering comes into play.
46:19
SPEAKER_0: I go build an app just by building prompts, because we built these things.
46:23
SPEAKER_0: I don't need no stinking UML for that thing.
46:26
SPEAKER_0: On the other hand, if I'm building something that I've never built before, let's say I'm building, not an LLM, but I'm building a constellation of LLMs work together and I want to weave them together with non-neural systems, then you begin to think about architecture, and that's what the UML comes into play.
46:44
SPEAKER_0: There's a sweet spot for a tremendous amount of software development going into place that doesn't need the UML and does not need any kind of thing like that.
46:54
SPEAKER_0: But on the other hand, you go a little further out in that three dimensions, and yes, there are people all over the place using UML.
47:02
SPEAKER_0: I mentioned the James Webb Space Telescope.
47:04
SPEAKER_0: I still work with financial companies who are doing that, where the risk, the complexity, the ceremony is sufficiently high that it demands a bit more formalism.
47:15
SPEAKER_1: So do I understand it correctly that you're saying that software architecture has changed from the 90s and 2000s when systems were new, architectures were new, software architecture was still a lot more novel.
47:30
SPEAKER_1: And if we look at venture funded startups and big tech today, what we see is, one, they're just not as risky, if they fail, big deal.
47:42
SPEAKER_1: And then two is we can use a lot more software that's out there and been architected and we can, for example, use Redis as a cache, and it is there.
47:52
SPEAKER_1: It works.
47:53
SPEAKER_1: We don't need to think too much about it.
47:55
SPEAKER_1: And then the third is that there's a lot of startups who just don't need ceremony.
47:59
SPEAKER_1: Basically, they don't need audits, they don't need formality.
48:02
SPEAKER_1: They can just go like, all right, let's just do it however we want to.
48:08
SPEAKER_1: We don't need that kind of audibility.
48:10
SPEAKER_1: Do I understand that these are the changes that are in play with software architecture?
48:16
SPEAKER_1: And is this why some of these formal methods are just not as popular with startups and scale-ups?
48:21
SPEAKER_0: Yes, in fact, I think it goes to the root of the economics of software development.
48:26
SPEAKER_0: Let's go back to the first age of software.
48:29
SPEAKER_0: First golden age.
48:31
SPEAKER_0: The machines were far more expensive than the humans.
48:35
SPEAKER_0: And so it required one to do some thinking before I even got to the machine because machine time was very, very expensive for me.
48:43
SPEAKER_0: And so yes, algorithmic decomposition, structured analysis, design techniques made a lot of sense because we needed that kind of optimization.
48:53
SPEAKER_0: If you move to contemporary times, computational resources are like water to a fish.
49:02
SPEAKER_0: They're available to anybody.
49:04
SPEAKER_0: I've got on my desk behind me, I've got my own personal cloud of four Nvidia single board computers, which has more processing power that existed in the world in the 1970s, and that's pretty amazing.
49:20
SPEAKER_0: That's a few thousand dollars there.
49:22
SPEAKER_0: And so the economics have changed vastly such that you don't need to think about it so much because heck, it becomes disposable.
49:32
SPEAKER_0: AI is, I think, is also changing that because it allows me to build things where I don't even have to think about design.
49:39
SPEAKER_0: Heck, I don't even have to think about software.
49:41
SPEAKER_0: I just prompted for those things to build something, and one-offs, and once I'm done, I throw it away.
49:47
SPEAKER_0: So in that sense, it comes back to the economics, but there will continue to remain a class of software that's new, unique, breaking new ground, that still requires that kind of architectural thinking.
50:00
SPEAKER_1: And 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're doing it, and they're doing this to catch those really, really edge cases that only happen in one in a billion, one in a trillion, but I think at their scale, this is a regular reoccurring event.
50:28
SPEAKER_1: And I found it fascinating how some of these methods are making their way back.
50:33
SPEAKER_0: Yeah.
50:35
SPEAKER_0: Well, let me set aside formal methods in a moment because it turns out that's a different topic for which I have some experience and opinions.
50:43
SPEAKER_0: But go back to Amazon, you go to their websites and they have a whole language around architecture.
50:49
SPEAKER_0: Microsoft does as well too around Azure.
50:51
SPEAKER_0: It's the way I describe an architecture in Amazon.
50:55
SPEAKER_0: It's those, they're blocky diagrams.
50:57
SPEAKER_0: It says, hey, I'm going to build this kind of thing and here's my particular notation for it.
51:01
SPEAKER_0: And furthermore here, there are some examples.
51:03
SPEAKER_0: So even Amazon and Microsoft have recognized that architecture plays a role, but there are enough times people have done these kinds of things that says, oh, you want to build this kind of system, then you want to use these services.
51:17
SPEAKER_0: In fact, here are some examples for it you can find on our website.
51:21
SPEAKER_0: 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.
51:35
SPEAKER_0: And this is a representation of, I think the maturation of our business.
51:40
SPEAKER_0: We move from algorithms which everyone can use to design patterns to now architectural patterns which Amazon and Microsoft have codified themselves.
51:50
SPEAKER_0: So let me switch over now to formal methods.
51:54
SPEAKER_0: Formal methods have always been a thing.
51:56
SPEAKER_0: However, formal methods in my experience have been a niche part of every software intensive systems because formal methods only go so far in what domains they can cover.
52:08
SPEAKER_0: And so you'll see is what your example described, Microsoft began using formal methods in their drivers to validate the correctness of their things, but they didn't-
52:22
SPEAKER_1: Their hardware driver?
52:23
SPEAKER_0: With their hardware.
52:23
SPEAKER_0: Exactly.
52:23
SPEAKER_0: Yeah.
52:24
SPEAKER_0: And that was an important move forward.
52:26
SPEAKER_0: I've been with projects that use things like, I've got this system in which people might die.
52:31
SPEAKER_0: Let's run a formal analysis upon it.
52:33
SPEAKER_0: The thing is though, that those formal methods don't deal with real world things because they don't deal with space and time.
52:41
SPEAKER_0: They deal with functionality.
52:43
SPEAKER_0: So I have always found formal methods to be of use, but only for parts of a system and never as a driver of the architecture itself.
52:53
SPEAKER_1: Speaking of software architecture, these days, the role software architect is not really popular anymore, at least of the likes of startups and big tech.
53:03
SPEAKER_1: Instead, we do have architects, but they're increasingly called staff engineer, principal engineer, distinguished engineer.
53:10
SPEAKER_1: The architecture is, and they do still do architecture, but there's a different focus on it.
53:17
SPEAKER_1: Now, you were there when software architecture was created, when the first software architects were created as a role.
53:25
SPEAKER_1: Can you tell us how you've seen this role be created and then evolved throughout the decades?
53:33
SPEAKER_0: So two things influenced my understanding of the space versus I didn't really call myself an architect, but I helped people design the systems they were building.
53:44
SPEAKER_0: I was heavily influenced by a dear friend of mine, Mary Shaw.
53:47
SPEAKER_0: She's a professor at Carnegie Mellon.
53:49
SPEAKER_0: I think she won the National Medal of Honor under Obama, if I'm not mistaken.
53:53
SPEAKER_0: And she wrote this really profound book called Software Architecture in which she began the first exposition of architectural patterns.
54:03
SPEAKER_0: Mary's this delightful human being.
54:06
SPEAKER_0: And that's when I began to understand the formalizations of what architecture could be.
54:11
SPEAKER_0: And the other thing that influenced me was architecture from other domains, particularly civil engineering and the like.
54:17
SPEAKER_0: In the defense world, there's also shipbuilding architecture and airplane architecture and the like.
54:24
SPEAKER_0: So the term architecture is one that's very well respected outside the software engineering world.
54:31
SPEAKER_0: Ignore the title for a moment, and let's go back to first principles.
54:35
SPEAKER_0: What is it at all?
54:37
SPEAKER_0: And you've probably heard me say this, all architecture is design but not all design is architecture.
54:43
SPEAKER_0: Architecture represents the set of significant design decisions that shape the form and function of a system where significant is measured by cost of change.
54:53
SPEAKER_0: So software architecture and architect has this horrible emotional baggage around it.
55:00
SPEAKER_0: So think of it as it's all about making decisions.
55:03
SPEAKER_0: What are the decisions that shape my system?
55:06
SPEAKER_0: As an architect, that's what I'm doing as the project manager or whatever.
55:12
SPEAKER_0: I'm also about making decisions.
55:14
SPEAKER_0: But one subtle difference is that it's no longer just the decisions about the shape of the software, but it's the shape of the system itself where it embodies itself in the physical world, where the other systems and humans themselves as well.
55:30
SPEAKER_0: That's what it is.
55:30
SPEAKER_0: It's all about decision process.
55:33
SPEAKER_1: And have you seen this role change?
55:36
SPEAKER_1: Did you see a golden age of companies where they were employing software architects that were empowering them to turn out design?
55:46
SPEAKER_1: I'm seeing a bit less of this.
55:48
SPEAKER_1: I'm curious, are you seeing something similar?
55:50
SPEAKER_1: Is this just a bubble that we're seeing?
55:53
SPEAKER_1: Just because you seems you're embedded in a lot of different companies.
55:58
SPEAKER_0: There's another sound bite I'll give you, which is that the entire history of software engineering is one of rising levels of abstraction.
56:06
SPEAKER_0: So what we're seeing here is the rise of another level of abstractions, which gives us all these extraordinarily powerful frameworks from which I can build systems.
56:16
SPEAKER_0: And which as I alluded to, the architectural decisions that were front and center for us back then are now embodied in these.
56:23
SPEAKER_0: So now it becomes a decision, what cloud service do I use?
56:27
SPEAKER_0: What messaging system do I use?
56:29
SPEAKER_0: What platform do I use?
56:30
SPEAKER_0: That's the decision which has a lot of economic decisions and not just software kinds of decisions associated with it.
56:41
SPEAKER_0: So I think the role of the architect in effect has changed because now I'm dealing with systemic problems, not just software problems themselves.
56:50
SPEAKER_1: Have you heard about the role called solutions architect?
56:53
SPEAKER_1: I think it was created maybe 10 years ago, and it's about people who are doing cloud architecture.
57:01
SPEAKER_1: It's fascinating, it's this role specific to the cloud.
57:04
SPEAKER_1: And as you said, they make economic decisions.
57:08
SPEAKER_1: What services do I use?
57:09
SPEAKER_1: Do I use AWS, GCP?
57:11
SPEAKER_1: If I use AWS, do I use EC2 or do I use another service?
57:17
SPEAKER_0: And that's why it's a systemic issue.
57:19
SPEAKER_0: You're generally, if you're a startup, you're going to hire somebody who's done that before, who knows where the skeletons are buried, who knows what the cost of these things are.
57:29
SPEAKER_0: And so that you'll hire those kind of folks because they'll accelerate you, because they've made those decisions and they sort of know in the shape of what you're building now what decisions next make sense.
57:40
SPEAKER_0: And they are systemic decisions because they have economic and long-term associated consequences to them.
57:46
SPEAKER_1: One thing comes up with software architecture is migrations.
57:51
SPEAKER_1: I do notice most large companies are being hurt by long-running migrations.
57:57
SPEAKER_1: And these migrations usually happen thanks to software architecture changing, for example, from going from monolith to microservices or changing technologies, for example, going from Note to Go or upgrading major versions of frameworks, for example, one version of Angular to the other one.
58:11
SPEAKER_1: How do you think software architecture and migrations are connected, and why do you think software migrations are just so darn hard and they don't seem to be going away?
58:22
SPEAKER_0: They are.
58:23
SPEAKER_0: Migrations will plague us until the heat death of the cosmos, I believe, because ...
58:30
SPEAKER_1: They're just really hard.
58:31
SPEAKER_0: ... you're always building economically viable software, but then the technology is changing out from under you that compels you to consider migrating.
58:42
SPEAKER_0: Consider the migration from monoliths from the 60s, 70s, 80s, to all of a sudden economically we had mini computers and now distributed systems, you're still not going to use an iPhone and put everything up in the mainframe.
58:59
SPEAKER_0: But those changes compel you to consider an architecture that better balances where the processing takes place.
59:06
SPEAKER_0: If all of a sudden I can begin to do edge inferencing on my devices, that's going to be something that's going to change architectures as well.
59:14
SPEAKER_0: So there are always these changes both in the hardware as well as societal changes, if you will, that impact the structure of my systems that are the forces that impel me, compel me to do this migration.
59:30
SPEAKER_0: But why is it hard?
59:33
SPEAKER_0: Well, another sound bite I'll give you is that the code is the truth, but the code is not the whole truth.
59:40
SPEAKER_0: There is so much that is outside of the code that represents design decisions, their rationale, why I chose this versus why I didn't choose that, subtle things as to why did I name things this way because of its impact that is long understood, long misunderstood.
1:00:01
SPEAKER_0: And so while the code may be the truth, the problem with moving migrations is that you lose, there's a loss of information, and it's difficult to try to recreate those design decisions just from the code.
1:00:16
SPEAKER_0: The people who wrote that initial code you're trying to move, they've probably cashed out or they've died or some combination of, and so you don't really know why those decisions were made.
1:00:29
SPEAKER_0: And so you're working a little bit in the dark.
1:00:32
SPEAKER_1: Yeah, you're mentioning people have died, and I don't think we usually think about that, but I guess when you're thinking about systems that are 40, 50 years old, that is the reality of some of them.
1:00:45
SPEAKER_0: What will the Linux kernel look like when Linus eventually retires?
1:00:50
SPEAKER_0: How will it drift?
1:00:53
SPEAKER_0: Because he has provided a firm and much needed hand upon the conceptual integrity of that system, and that's what the chief decider makes.
1:01:04
SPEAKER_0: He or she is the one that provides that conceptual integrity.
1:01:09
SPEAKER_0: And when that person is gone, then you naturally see drift and that's inevitable.
1:01:15
SPEAKER_0: It's entropy.
1:01:17
SPEAKER_0: Software, all software exhibits some degrees of entropy without adding that kind of force to it.
1:01:26
SPEAKER_1: One thing that is very relevant today in terms of technologies and architecture is AI.
1:01:32
SPEAKER_1: This technology is here, it's revolutionary, it is disruptive.
1:01:36
SPEAKER_1: Now you've been in the industry for closer to 50 years.
1:01:40
SPEAKER_1: If you look back, how do LLMs and AI compare to the industry to pass innovations and events?
1:01:48
SPEAKER_1: Because for many of us in the industry, for those of us who've been for 20, 30 years or so, LLMs do seem like the biggest change of software.
1:01:58
SPEAKER_1: But when you look back, have you seen something that was comparable in terms of impact or the pace of change?
1:02:06
SPEAKER_0: That's a great question.
1:02:07
SPEAKER_0: Yeah.
1:02:08
SPEAKER_0: The first I think was just the realization that I could build distributed systems as opposed to putting all of my processing on one.
1:02:19
SPEAKER_0: That was a change that rattled everything in the way we built systems.
1:02:25
SPEAKER_0: So at the point in time that all of a sudden I could have a network of mini computers, and then eventually that carried on to microcomputers and devices at the edge, like phones themselves.
1:02:38
SPEAKER_0: But that transition in the growth of mini computers was seismic that I don't think people understood the full implications of until much later because it required us to rethink the way that we put systems together.
1:02:52
SPEAKER_0: So we saw there the rise of a great degree of uncertainty.
1:02:57
SPEAKER_0: We didn't know how to build these systems.
1:03:00
SPEAKER_0: I have messaging across them, do I use RPC?
1:03:04
SPEAKER_0: Do I use something else?
1:03:06
SPEAKER_0: What do I use to communicate?
1:03:08
SPEAKER_0: Do I use shared memory?
1:03:10
SPEAKER_0: And so there was this period of exploration that we didn't know about until it finally we realized, oh, these are the common ways that work.
1:03:16
SPEAKER_1: And can you remind me around what time this was?
1:03:19
SPEAKER_1: Was this around the 80s?
1:03:21
SPEAKER_1: Was it around the 90s?
1:03:23
SPEAKER_0: There was the late 70s because here you had, well, let's go back way in history.
1:03:30
SPEAKER_0: There was the thing called, gosh, what's the name of it?
1:03:35
SPEAKER_0: I'm drawing a bit of a blank here.
1:03:37
SPEAKER_0: But here we are in the late 60s, early 70s in which mainframes were roaming the earth.
1:03:45
SPEAKER_0: But even then, it was a realization that these machines were sometimes being underutilized.
1:03:51
SPEAKER_0: And so there was born the formation of the first time-sharing systems.
1:03:56
SPEAKER_0: The next thing that happened around the same time were systems such as Whirlwind, which came out of the Lincoln Laboratories, which was beginning to take machines and touch them to the real world.
1:04:07
SPEAKER_0: So all of a sudden now you had real-time computing.
1:04:09
SPEAKER_0: So you had this confluence of two very interesting things.
1:04:12
SPEAKER_0: You had large machines in which we were beginning to develop time-sharing kinds of operating systems and then machines off to the side that were touching the real world.
1:04:22
SPEAKER_0: These came together in really the rise of mini computers, particular digital equipment corporation and the like, where miniaturization, which frankly came about because of the investment the Department of Defense was making in semiconductors, making it economically interesting to have a computer that could sit on your desktop that one or two people could use full time.
1:04:46
SPEAKER_0: So it took kind of the ideas of the embodiment of things like Whirlwind and then the distributed systems we were people building.
1:04:55
SPEAKER_0: Now all of a sudden I could take these things and I could start building them together.
1:04:59
SPEAKER_0: And that's what was happening in the mid to late 70s that we saw the rise of those distributed systems.
1:05:05
SPEAKER_0: One last thing, there was the rise of client-server systems where you saw dumb terminals.
1:05:11
SPEAKER_0: That's what IBM was doing at the time, the green screens talking to mainframes.
1:05:15
SPEAKER_0: But the rise of those new machines meant I could move some of the processing off to the edge as opposed to leaving it to the model.
1:05:22
SPEAKER_0: Those are the forces that led us to rethinking about systems.
1:05:26
SPEAKER_1: So do I understand correctly that programmers at the time, they were used to working on these large computers and distributed computing came in?
1:05:36
SPEAKER_0: Absolutely.
1:05:37
SPEAKER_1: And it just completely changed the dynamics.
1:05:40
SPEAKER_1: So youngsters came in, they started to embrace this distributed computing.
1:05:46
SPEAKER_1: Existing programmers, they kind of stick to what they knew what was efficient on the mainframe, was that what it was like?
1:05:53
SPEAKER_0: It was, and then when you had things like TCPIP and HTML and all those things around it, all of a sudden we now had a vocabulary.
1:06:01
SPEAKER_0: We now had mechanisms that we could bind these things together.
1:06:05
SPEAKER_0: So I would not say that LLMs are as pervasively as important as the rise of distributed systems, but there's a parallel to it.
1:06:16
SPEAKER_0: The second thing I'd say that is sort of similar to that is the rise of GPUs, which came from the gaming industry because there they were solving a very different problem.
1:06:26
SPEAKER_0: How do I deal with more photorealistic things in my games?
1:06:32
SPEAKER_0: And we realized it's all matrix multiplications.
1:06:35
SPEAKER_0: So Nvidia began to move into that marketplace, and we had the rise of GPUs, which dominated that space.
1:06:41
SPEAKER_0: And it wasn't until Andrew Ng came and said, wait a minute, those GPUs used for gaming use the same kind of mathematics as do our deep learning kind of things.
1:06:52
SPEAKER_0: And poof, all of a sudden we had this perfect storm of lots of data, powerful hardware and the rise of interesting algorithms, back propagation and the like.
1:07:03
SPEAKER_0: So it was a perfect storm.
1:07:05
SPEAKER_0: So yes, this is an exciting time.
1:07:07
SPEAKER_0: There's no doubt that large language models are interesting, but we must be careful and we'll go into that in a moment.
1:07:16
SPEAKER_1: So let's go into that.
1:07:18
SPEAKER_1: I'd love to hear your candid thoughts about LLMs, their applicability, the innovation and the trade-offs that they come with.
1:07:26
SPEAKER_0: Well, so to set the stage before people worry that I'm just pontificating about things I know nothing about.
1:07:35
SPEAKER_0: I alluded to at the very beginning that, and here I was 12, 14, whatever, I was interested in what was burgeoning becoming AI at the time.
1:07:45
SPEAKER_0: That has always kind of stuck with me.
1:07:48
SPEAKER_0: And in what would've been, I've always pursued and interested in that space.
1:07:55
SPEAKER_0: And it wasn't until IBM drew me back to it around the time of Watson that I began to make it a full-time thing.
1:08:03
SPEAKER_0: So David Ferrucci, who led the development of Watson, had called me in and said, hey, Grady, I'm going to give this lecture.
1:08:12
SPEAKER_0: I can't do it.
1:08:12
SPEAKER_0: Would you do it for me?
1:08:13
SPEAKER_0: And I said, David, happy to do so, but only on the condition that I can choose the topic.
1:08:18
SPEAKER_0: And the topic I chose is what is the architecture of Watson Jeopardy?
1:08:23
SPEAKER_0: And as it turns out, nobody had documented it.
1:08:27
SPEAKER_0: 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.
1:08:36
SPEAKER_0: It's not a neural network system.
1:08:37
SPEAKER_0: It turns out to be a pipeline architecture that through a pipeline, brought together a number of statistical systems.
1:08:45
SPEAKER_0: AI at the time was all about predictive statistical methods, not neural networks and methods and knowledge engineering.
1:08:53
SPEAKER_0: And so I documented the architecture that caught the eye of IBM management, and it's for the first time I really documented an AI architecture.
1:09:01
SPEAKER_0: So IBM-
1:09:02
SPEAKER_1: And for those of us who don't know-
1:09:03
SPEAKER_0: ... and AI architecture. So IBM-
1:09:03
SPEAKER_1: And for those of us who don't know, this was in Jeopardy!
1:09:05
SPEAKER_1: This was the IBM computer that played the game Jeopardy!
1:09:08
SPEAKER_1: and won, if I remember.
1:09:12
SPEAKER_0: It won.
1:09:12
SPEAKER_0: Yeah.
1:09:12
SPEAKER_0: We beat all the humans in that space.
1:09:15
SPEAKER_1: At the time, this was in mainstream media, in the press everywhere, and this was shown as an example of an AI system that can outperform a human on a very human task, which is this popular show Jeopardy!
1:09:28
SPEAKER_0: Yeah, right.
1:09:29
SPEAKER_0: 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.
1:09:40
SPEAKER_1: Garry Kasparov.
1:09:41
SPEAKER_0: Garry Kasparov, yeah.
1:09:45
SPEAKER_0: Yeah.
1:09:45
SPEAKER_0: We did that through brute force methods, then Watson Jeopardy!
1:09:50
SPEAKER_0: came along, beating humans in natural language processing at the time.
1:09:55
SPEAKER_0: IBM had already been doing things in that space with a system against statistical systems.
1:10:01
SPEAKER_0: We eventually sold it to Nuance and the like, but we were pretty dominant in the space of natural language processing.
1:10:08
SPEAKER_0: IBM Watson Jeopardy!
1:10:10
SPEAKER_0: was the peak of that.
1:10:12
SPEAKER_0: IBM asked me, "Hey, Grady.
1:10:14
SPEAKER_0: This is cool stuff.
1:10:15
SPEAKER_0: We're going to commercialize this.
1:10:17
SPEAKER_0: Would you please help us do a study as to what IBM should do with this?"
1:10:22
SPEAKER_0: I led a study for about a year in cognitive systems.
1:10:26
SPEAKER_0: What should IBM do?
1:10:28
SPEAKER_0: Now, this was interesting because I study what Watson was doing.
1:10:32
SPEAKER_0: I looked at what was happening in the marketplace.
1:10:34
SPEAKER_0: Here we were, what, 2010-ish or thereabouts?
1:10:38
SPEAKER_0: A little bit later.
1:10:39
SPEAKER_0: It was that decade.
1:10:40
SPEAKER_0: I made it very clear to IBM management, "This is pretty cool, but be careful because there are things we know it can't do."
1:10:50
SPEAKER_0: I was very clear to our management that be careful about hyping it.
1:10:54
SPEAKER_0: Well, I remember in my meeting with Jenny when I was doing the briefing about the project.
1:11:01
SPEAKER_0: Jenny was the CEO at the time.
1:11:03
SPEAKER_0: She asked me a question.
1:11:05
SPEAKER_0: One of the VP stepped in and started talking over me and said, "Well, yada, yada," and I politely said to him, "Well, thank you, but I think you're wrong," and I went on to explain to him.
1:11:16
SPEAKER_0: Now, if I were not a fellow, I'm sure I would've been fired on the spot.
1:11:20
SPEAKER_0: But as a fellow, I got to say things like that.
1:11:23
SPEAKER_0: Now, they did not invite me to join the Watson group, so I was happy with that.
1:11:28
SPEAKER_0: I worked off into the side, but it's sort of an "I told you so" that there were things that we can't do and, by God, we can't do them.
1:11:38
SPEAKER_0: I was working in the underground for several years and I'll get to the answer of your question in a moment, but it explains why I can say something meaningful.
1:11:48
SPEAKER_0: I was kind of an outsider.
1:11:49
SPEAKER_0: I was kind of doing my own thing inside IBM.
1:11:51
SPEAKER_0: And then we had a team down in Austin who had been approached by Hilton Hotels who said, "We'd like to build robotic concierge for our hotels," and so we chose some robots from Aldebaran, a company out of south of France.
1:12:07
SPEAKER_0: They built these three-foot tall robots called Pepper and smaller ones called NAO and they built a robotic system.
1:12:15
SPEAKER_0: It was kind of cool.
1:12:16
SPEAKER_0: It was a question and answering system based on Watson technology, but there was something missing out of it.
1:12:23
SPEAKER_0: The team came into me and said, "Grady, would you please help us out?"
1:12:26
SPEAKER_0: So I did.
1:12:27
SPEAKER_0: I helped them prove the architecture.
1:12:28
SPEAKER_0: 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.
1:12:37
SPEAKER_0: And so we began to be involved with them and I thought this is all great, because I can get back to my space routes.
1:12:45
SPEAKER_0: They had a system called the Robonaut 2, which was a humanoid robot that, at the time, was on the International Space Station.
1:12:53
SPEAKER_0: A beautiful piece of engineering.
1:12:56
SPEAKER_0: NASA was exploring the idea of human robotic interactions for the space mission of Mars.
1:13:04
SPEAKER_0: 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?"
1:13:14
SPEAKER_0: Because we want to do hard things.
1:13:15
SPEAKER_0: We realized it was the mission of Mars because they had two interesting use cases.
1:13:19
SPEAKER_0: The first is because of the speed of light issues, you couldn't rely upon mission control on the ground.
1:13:25
SPEAKER_0: You had to take it with you.
1:13:27
SPEAKER_0: This was the HAL problem.
1:13:29
SPEAKER_0: We needed to build a HAL minus the kill all the humans use case, which for some reason NASA didn't want that use case.
1:13:37
SPEAKER_0: I don't know, but it's their choice.
1:13:39
SPEAKER_0: The second is, at the time, NASA wanted to put robots on the surface of Mars to help astronauts build their scientific experiments and build their habitats and the like.
1:13:52
SPEAKER_0: I remember one afternoon I'd sat down and said, "I know how to architect this."
1:13:57
SPEAKER_0: This would've been around 2014.
1:14:00
SPEAKER_0: I built a neural-symbolic architecture we called SELPH and it used the ideas of Marvin Minsky's Society of Mind together with Rodney Brooks's notion of subsumption architectures together with Hofstadter's ideas of strange loops.
1:14:17
SPEAKER_0: Those three came together forming this self architecture, which we then built.
1:14:23
SPEAKER_0: We experimented with NASA for a while to build some software behind the Robonaut to do things like, " Hey, robot, here is a scientific process.
1:14:34
SPEAKER_0: Go do this or go clean these filters," which is a common station keeping activity.
1:14:40
SPEAKER_0: We were actually building the software that allowed humans to interact with it and also serve as question answering things.
1:14:47
SPEAKER_0: That led us to Soul Machines, a company out of New Zealand.
1:14:50
SPEAKER_0: They were an offshoot of the work that John Cameron had done in the movie, the... Shoot, what's the one he's done?
1:15:00
SPEAKER_0: He's done a trilogy of them now, that he had this great technology where you put cameras on the artist and it would measure their muscle movements.
1:15:10
SPEAKER_0: They took that, they built a neural model of human musculature, and they had the great hardware for it, but they had no software.
1:15:17
SPEAKER_0: So we helped them in that regard.
1:15:18
SPEAKER_0: We then also worked with a company called Woodside, an oil and gas company out of Australia, because they had a problem similar to NASA.
1:15:28
SPEAKER_0: They were building systems for oil rigs, which is a very dangerous environment.
1:15:32
SPEAKER_0: They wanted to build cooperative robots just like NASA was doing.
1:15:36
SPEAKER_0: Here we were with this system called SELPH that was frankly a neuro-symbolic system.
1:15:41
SPEAKER_0: It had neural pieces but also symbolic pieces based upon those three architectural decisions.
1:15:46
SPEAKER_0: It was pretty cool.
1:15:47
SPEAKER_0: At its peak, I had 35 people working on this, but then we recognized IBM was across six laboratories, I should mention, around the world, which made it possible for me to live and work out of Maui, Hawaii, which is where I still am.
1:16:01
SPEAKER_0: But then IBM recognized IBM's Watson was bleeding cash, so they fired everybody.
1:16:07
SPEAKER_0: Again, being a fellow, they didn't fire me, so I continued in that space.
1:16:12
SPEAKER_0: But that was my exposure to the first set of new kinds of architectures.
1:16:18
SPEAKER_0: For about six years now, I had been working with a set of neuroscientists to try to understand the architecture of the organic brain.
1:16:27
SPEAKER_0: Rather than software kinds of things, I've been studying things like cortical columns and the loops that exude in the hypothalamus.
1:16:36
SPEAKER_0: I've been looking at architecture from the lens of a software architect into these kinds of organic systems.
1:16:43
SPEAKER_0: That now leads us finally back to your question, what do I think about large language models?
1:16:49
SPEAKER_0: The answer is they're pretty freaking cool.
1:16:52
SPEAKER_0: However, they are, by the very nature of their architecture, unreliable narrators.
1:16:58
SPEAKER_0: That's what I say politely.
1:17:00
SPEAKER_0: If I'm going to be impolite, I will say they allow us to build that global scale bullshit generators because clearly they are stochastic parrots.
1:17:13
SPEAKER_0: 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 it through the corpus of the internet.
1:17:31
SPEAKER_0: That, I think, is back to the perfect storm.
1:17:33
SPEAKER_0: We have large language models based upon data and the algorithms and the hardware that allow us to build these coherent kinds of things, but, again, we have to be careful.
1:17:44
SPEAKER_0: Gary Marcus and I have been voracious and consistent critics of Sam and others who are saying, "We're just on the cusp of AGI."
1:17:53
SPEAKER_0: Well, I think that diminishes the elegance of what AGI actually is within our humans.
1:18:01
SPEAKER_0: It diminishes what the beauty of what our human intelligence is.
1:18:05
SPEAKER_0: Frankly, we're not going to get there by scaling.
1:18:08
SPEAKER_0: We've already seen... We're hitting limitations upon it.
1:18:13
SPEAKER_0: Elon, whom I've gotten into as well on the internet a number of times on his particular views of the world on AGI, he's been promising full self-driving for years now.
1:18:25
SPEAKER_0: We're not going to get there because those kinds of models are simply... They're the wrong architecture.
1:18:32
SPEAKER_0: If I've got to build a nuclear power plant to build my systems, I'm probably doing the wrong architecture.
1:18:40
SPEAKER_0: Yes, I think there are valid use cases for large language models, but we have to be careful because they are indeed dangerous.
1:18:49
SPEAKER_0: Yann blocked me on Twitter, because at the very beginning of their work, Galactica, I called him out on it and said, "Yann, this is great stuff, but do you realize the implications?"
1:19:00
SPEAKER_0: And he simply dismissed them.
1:19:02
SPEAKER_0: I kept calling him out.
1:19:03
SPEAKER_0: He got tired of me doing so and eventually blocked me, but this is another "I told you so."
1:19:08
SPEAKER_0: We were seeing the joys and the dangers of large language models.
1:19:13
SPEAKER_1: Just to double click on this, it sounds you're saying that large language models by themselves will not get us to AGI, but do I understand that if we combine it with other tools like neural nets or neural symbiotic systems, we can actually get closer to these intelligence systems?
1:19:32
SPEAKER_1: And if we take this example that you just said, a robot on Mars that is able to clear filters and follow instructions, what do you think we would need to get to that type of intelligence?
1:19:44
SPEAKER_0: Right.
1:19:45
SPEAKER_0: And I even add to this, if you look at cultures such as Japan where you have an aging population, a shrinking population, the US is very much in this place, you have tremendous need for elder care.
1:19:57
SPEAKER_0: The robotic use case and not just the full humanoid robotic use case comes into play.
1:20:03
SPEAKER_0: There are clear and present needs for these kinds of things as well, too.
1:20:07
SPEAKER_0: Yes, there are lots of great use cases.
1:20:11
SPEAKER_0: I've always believed this to be a systems engineering problem, which is why if you go back to the architecture itself, that's why I've been focused upon neural symbolic systems.
1:20:22
SPEAKER_0: Now, let me get a little philosophical for the moment.
1:20:26
SPEAKER_0: I'm pretty sure you're sentient.
1:20:28
SPEAKER_0: I can't guarantee it, but I'm just guessing that you are and you're not some amazing large language model.
1:20:35
SPEAKER_0: And why would I think that?
1:20:36
SPEAKER_1: That's a fair guess.
1:20:37
SPEAKER_0: It's a fair guess.
1:20:38
SPEAKER_0: Why do I believe that?
1:20:39
SPEAKER_0: It's because I have a theory of mind about you that, through multimodal ways and my interactions with you, I have a theory that says you're sentient.
1:20:50
SPEAKER_0: You're someone who has its own agency, who has your own feelings and behaviors and needs and the like, and that's cool.
1:20:57
SPEAKER_0: You're not a robot.
1:21:01
SPEAKER_0: The human mind has evolved over millennium to develop that through an architecture that, yes, it's a neural in nature, but on the one hand, artificial neurons are a shadow... Not a shadow.
1:21:15
SPEAKER_0: They're an echo of a whisper of what organic neurons are.
1:21:20
SPEAKER_0: They are a small, small piece of it.
1:21:22
SPEAKER_0: Furthermore, if you look at the architecture of large language models, which is you observed are relatively simple, there's a simple layering to them which ignores the exquisite complexity of the human mind.
1:21:36
SPEAKER_0: We have, in our cerebral cortex, cortical columns.
1:21:41
SPEAKER_0: We have tens of millions of them.
1:21:43
SPEAKER_0: They're, in humans, about seven layers deep.
1:21:46
SPEAKER_0: Reptiles have them as well too.
1:21:47
SPEAKER_0: They're a bit smaller.
1:21:48
SPEAKER_0: Those are the ones that appear to be the place our [inaudible 01:21:52] work, where we build the predictive models of the world, but we also have places where emotions and other decision-making take place among these entangled architectures associated with the thalamus and the like.
1:22:06
SPEAKER_0: Furthermore, we have other things going on with it appears to be our hormonal system that appear to be other ways of message passing within our neural networks.
1:22:18
SPEAKER_0: In that same regard, large language models are interesting, but they also are a whisper of a shadow of, I think, what reality is.
1:22:28
SPEAKER_0: Where the next level is, and Gary and I have observed we're reaching diminishing returns on what scale can do, the OpenAI folks and Elon believe scale will continue for a long, long time.
1:22:40
SPEAKER_0: Gary and I are saying, "No, we're reaching a limit there.
1:22:43
SPEAKER_0: You need to think about it in other ways."
1:22:45
SPEAKER_0: That brings us back to those architectures.
1:22:47
SPEAKER_0: The last thing I'll mention is, at the very beginning, you talked about me being involved with embodied cognition.
1:22:53
SPEAKER_0: That brings me back to my roots again.
1:22:55
SPEAKER_0: What is embodiment?
1:22:57
SPEAKER_0: It's building systems that are in and of the world that respond to the world and act in the world.
1:23:04
SPEAKER_0: Large language models are largely unit model.
1:23:06
SPEAKER_0: They work through text, maybe static images woven together through video and the like, but they're very sensory sparse.
1:23:16
SPEAKER_0: Our minds and our intelligence have grown because they've been embodied in the world.
1:23:22
SPEAKER_0: In that regard, I think there are many kinds of intelligence that exist, but our human intelligence grew because of our embodiment, and it's going to require some fairly complex architecture to get that.
1:23:33
SPEAKER_0: That's why I've been studying human architectures for six years because I don't know enough about them.
1:23:38
SPEAKER_0: Let's see if that influences the way I build software architectures.
1:23:42
SPEAKER_1: As closing, you previously tweeted something really interesting around this, and I'll quote this.
1:23:47
SPEAKER_1: You tweeted, "We need a standard way of visualizing the architecture, as well as the activity of LLM, and to generalize any artificial neural network, sort of a UML for AI."
1:23:56
SPEAKER_1: Now, this was a year back.
1:23:58
SPEAKER_1: Have you seen anything happen here?
1:24:00
SPEAKER_1: And why do you think LLM architecture is so important?
1:24:04
SPEAKER_0: In fact, I have both thoughts and I have seen movement.
1:24:09
SPEAKER_0: Internally, I've been helping out with providing a little bit of architectural adult supervision in our large language model work.
1:24:18
SPEAKER_0: I've been trying to figure out what's the way to visualize the kinds of things we're doing.
1:24:22
SPEAKER_0: Turns out it's still very UML-like that these are now boxes that are systems under themselves and their message passing systems along the way.
1:24:30
SPEAKER_0: I'm trying to figure out the best ways to do that.
1:24:34
SPEAKER_0: As you may know, just this week, AlphaFold released its source code and waits publicly.
1:24:41
SPEAKER_0: I'm jumping on that and I'm going to use that as a basis of, "Can I describe the architecture of AlphaFold 3 using some UML delivery?"
1:24:51
SPEAKER_0: Stay tuned.
1:24:52
SPEAKER_0: I think there's work to be done in that regard.
1:24:56
SPEAKER_1: What advice would you have for software engineers who are just starting out the software industry?
1:25:01
SPEAKER_1: There's plenty of recent graduates who find themselves in a chilly job market.
1:25:04
SPEAKER_1: There's a threat of what feels like AI tools changing how we do software engineering.
1:25:09
SPEAKER_1: You've gone through a lot of cycles of innovation in software engineering.
1:25:13
SPEAKER_1: What advice do you have for those starting out to set them up for a successful software engineering career?
1:25:19
SPEAKER_0: Indeed.
1:25:19
SPEAKER_0: When Copilot and ChatGPT came out, I received a flood of messages from folks saying, "My gosh, have I chosen the wrong career?
1:25:28
SPEAKER_0: Because you're not going to need developers at all."
1:25:31
SPEAKER_0: You'll always need people who make informed decisions no matter what the language is.
1:25:37
SPEAKER_0: Software engineering, again, is one of rising levels of abstraction.
1:25:40
SPEAKER_0: It's just that our tools have changed.
1:25:43
SPEAKER_0: I learned to program in assembly language.
1:25:46
SPEAKER_0: People today are going to be learning in programming with languages that are at a much higher level of abstraction.
1:25:53
SPEAKER_0: The advice I'd give such folks is twofold.
1:25:57
SPEAKER_0: Don't worry.
1:25:59
SPEAKER_0: Don't be afraid.
1:26:00
SPEAKER_0: There's always going to be some really cool work for you to do there.
1:26:05
SPEAKER_0: In fact, I would say it's quite the opposite.
1:26:07
SPEAKER_0: This is an exciting time because there is so much opportunity, so many cool tools, so much computational resources that, in many ways, you're limited only by your imagination.
1:26:22
SPEAKER_0: What I encourage people to do is to first learn as much as you can.
1:26:26
SPEAKER_0: Second, don't get stuck in just one domain.
1:26:31
SPEAKER_0: You need to become an expert in some space, but the world of computing is vast.
1:26:37
SPEAKER_0: Find some space that nobody's in right now and go make a name for yourself there, because there are lots of those kinds of places there for you.
1:26:45
SPEAKER_0: The third thing I'd advise is go have some fun.
1:26:48
SPEAKER_0: I mean, my gosh, the toys we have at our disposal, they're amazing and wonderful and cheap.
1:26:55
SPEAKER_0: There's so much a single person can do at so low expense to go change the world.
1:27:03
SPEAKER_0: I'd like to also close by saying I'm not done yet either.
1:27:07
SPEAKER_0: I'm having a tremendous amount of fun.
1:27:09
SPEAKER_0: And in addition to the things I told you in studying the human brain and working with large language models, there are two projects that I'm engaged in that I've been working with for a long time now.
1:27:21
SPEAKER_0: The first is I've been trying to write a book on software architecture.
1:27:25
SPEAKER_0: I'm glad I did not write it because I know so much more now than I did before.
1:27:31
SPEAKER_0: This is a different architecture book, rather than saying, "Here's how you do it."
1:27:36
SPEAKER_0: I've been working with a number of companies to document their as-built architectures, so I'd like to put AlphaFold in it.
1:27:44
SPEAKER_0: Photoshop is in it.
1:27:45
SPEAKER_0: What's the architecture of Photoshop?
1:27:46
SPEAKER_0: What's the architecture of a climate monitoring system?
1:27:51
SPEAKER_0: What's the architecture of Wikipedia?
1:27:54
SPEAKER_0: I'm trying to document the as-built architecture of systems that people use today that they may never have thought about.
1:28:02
SPEAKER_0: The idea of being is that there are many different architectural styles.
1:28:07
SPEAKER_0: Let me expose you to them because you may have studied only one particular one.
1:28:12
SPEAKER_0: The world is a vast one.
1:28:14
SPEAKER_0: The second is I was heavily in-
1:28:16
SPEAKER_1: And just to confirm, this is the Software Architectures Guidebook, right?
1:28:20
SPEAKER_0: Yeah.
1:28:20
SPEAKER_0: The Software Architecture Handbook.
1:28:21
SPEAKER_1: Handbook.
1:28:23
SPEAKER_0: Handbook.
1:28:23
SPEAKER_0: Which my long-suffering editor has been patient with me for literally a decade now and it's something I hope to finish before I die.
1:28:32
SPEAKER_0: The second book is I was on the board of trustees for the Computer History Museum for about 10 years and we'd hired a new CEO.
1:28:40
SPEAKER_0: He came to me and said... He had been at PBS.
1:28:42
SPEAKER_0: We had a conversation and said, "Hey, John, why don't you do a documentary like Carl Sagan's Cosmos?"
1:28:49
SPEAKER_0: He paused and said, "Well, Grady, why don't you be our Carl?"
1:28:52
SPEAKER_0: I said, "I'm no Sagan, but that's an intriguing idea."
1:28:55
SPEAKER_0: I've been on a journey to do a documentary and I'm writing a book about computing and the human experience, which looks at the history of computing and what it means to be human.
1:29:08
SPEAKER_0: I'm looking at what does computational thinking look like?
1:29:12
SPEAKER_0: How has computing changed the individual, society, nations?
1:29:16
SPEAKER_0: How has it changed science and the art and religion and such?
1:29:21
SPEAKER_0: Ultimately, it asked the question, "In the presence of computing, what does it mean to be human?"
1:29:26
SPEAKER_0: That's the larger project I'm working on right now, which I hope to finish up also before I die.
1:29:33
SPEAKER_1: Let's wrap up with some rapid questions.
1:29:35
SPEAKER_1: I'm just going to ask and then just shoot.
1:29:37
SPEAKER_1: You don't need to think too much about it.
1:29:39
SPEAKER_1: What was the first programming language that you used?
1:29:42
SPEAKER_0: Fortran.
1:29:43
SPEAKER_1: Fortran.
1:29:45
SPEAKER_1: What project did you commit most recently and what language did you use in it?
1:29:50
SPEAKER_0: Most recently, my own language, my own project, SELPH.
1:29:54
SPEAKER_0: Python.
1:29:55
SPEAKER_1: Python.
1:29:56
SPEAKER_1: What do you do to recharge from doing software engineering related work?
1:30:00
SPEAKER_0: I live in Maui.
1:30:01
SPEAKER_0: I wake up.
1:30:02
SPEAKER_0: That's enough.
1:30:03
SPEAKER_1: Yep.
1:30:04
SPEAKER_1: Enviable place and also answer.
1:30:07
SPEAKER_1: What are two books you would recommend for those who would like to understand more about software architecture?
1:30:12
SPEAKER_0: Mary Shaw's book, Software Architecture.
1:30:14
SPEAKER_0: I'd read that one.
1:30:16
SPEAKER_0: Other books kind of pale in comparison, but I'd start there.
1:30:19
SPEAKER_1: Well, thank you very much, Grady, for being on the show.
1:30:22
SPEAKER_1: This was really interesting and fascinating.
1:30:24
SPEAKER_0: It was a pleasure.
1:30:24
SPEAKER_0: Thank you for having me.
1:30:26
SPEAKER_1: Thanks to Grady for this great conversation.
1:30:28
SPEAKER_1: You can find ways to contact Grady in the show notes below.
1:30:32
SPEAKER_1: If you enjoy this podcast, please subscribe in your favorite podcasting platform and on YouTube.
1:30:36
SPEAKER_1: For some additional takeaways from our conversation, please see the show notes.
1:30:40
SPEAKER_1: Thank you and see you in the next one.