Code with Jason
Code with Jason
321 - Uncle Bob Martin
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
In this episode I talk with Bob Martin about his work with programming languages using AI, the essence of software engineering, and why understanding epistemology matters for developers. We also explore dependency inversion and the benefits of a robust test suite.
Links:
Snail Mail Newsletter Pitch
SPEAKER_00Hey, it's Jason, host of the Code with Jason podcast. You're a developer. You like to listen to podcasts. You're listening to one right now. Maybe you like to read blogs and subscribe to email newsletters and stuff like that. Keep in touch. Email newsletters are a really nice way to keep on top of what's going on in the programming world. Except they're actually not. I don't know about you, but the last thing that I want to do after a long day of staring at the screen is sit there and stare at the screen some more. That's why I started a different kind of newsletter. It's a snail mail programming newsletter. That's right. I send an actual envelope in the mail containing a paper newsletter that you can hold in your hands. You can read it on your living room couch, at your kitchen table, in your bed, or in someone else's bed. And when they say, What are you doing in my bed? You can say, I'm reading Jason's newsletter. What does it look like? You might wonder what you might find in this snail mail programming newsletter. You can read about all kinds of programming topics like object-oriented programming, testing, DevOps, AI. Most of it's pretty technology agnostic. You can also read about other non-programming topics like philosophy, evolutionary theory, business, marketing, economics, psychology, music, cooking, history, geology, language, culture, robotics, and farming. The name of the newsletter is Nonsense Monthly. Here's what some of my readers are saying about it. Helmut Kobler from Los Angeles says thanks much for sending the newsletter. I got it about a week ago and read it on my sofa. It was a totally different experience than reading it on my computer or iPad. It felt more relaxed, more meaningful, something special and out of the ordinary. I'm sure that's what you were going for, so just wanted to let you know that you succeeded. Looking forward to more. Drew Bragg from Philadelphia says Nonsense Monthly is the only newsletter I deliberately set aside time to read. I read a lot of great newsletters, but there's just something about receiving a piece of mail, physically opening it, and sitting down to read it on paper that is just so awesome. Feels like a lost luxury. Chris Sonier from Dickinson, Texas, says just finished reading my first nonsense monthly snail mail newsletter and truly enjoyed it. Something about holding a physical piece of paper that just feels good. Thank you for this. Can't wait for the next one. Dear listener, if you would like to get letters in the mail from yours truly every month, you can go sign up at nonsense monthly dot com. That's nonsensemonthly.com. I'll say it one more time. Nonsense Monthly dot com. And now without further ado, here is today's episode.
Meet Bob Martin Uncle Bob
SPEAKER_02Thank you. Good to be with you.
SPEAKER_00Good to have you here. So you're a man who needs no introduction, but you know, not everybody uh has heard of you, I'm sure. So for any listeners having the pleasure of meeting you for the first time, can you give a little intro?
SPEAKER_02A little intro, oh boy. Um, so yeah, Bob Martin. Some people call me Uncle Bob, um, author of many, many books. Uh, one of them is Clean Code, so that's probably the most notorious of them all. I've been a programmer since um 1968. Something like that. Good long time. Um, probably five and a half, six decades at this point. Um, written tons of code, written lots of languages, all kinds of different systems, uh, from financial to flat shop floor control games and computational geometry, and god knows what else. Uh yeah, that's that's who I am. And and now I'm an author, and I I used to travel the world and yell at people. Now I yell at people through the screen.
SPEAKER_00Okay. Uh you you're, I believe you're a pilot, also, is that right?
SPEAKER_02Oh, yes, yes. You can see the little airplane up there in the corner there. That's uh my son-in-law actually made that or ordered that uh wrought iron sculpture, which is very similar to my airplane. I fly a uh a Cirrus SR-22, which looks a lot like that, and it gets me from place to place. I purchased it uh like right before COVID because I was I was flying everywhere at that at that point. I wanted to get off of the commercial airlines. And then during COVID, it was a godsend because the uh the local airports behaved normally, like there was no COVID. So we would fly all over the place, we would visit our grandkids and stuff. The the airplane was a great tool during that period.
SPEAKER_00You ever hear about uh Sam Walton in the early days of Walmart? He got a pilot's license because a big thing with Walmart early on is he needed to scout out locations for new Walmarts, and so he bought him, he got himself a pilot's license and he would just fly around and look at spots, and that made me think, man, that would be pretty neat to to have my own plane. It sounds like it is.
SPEAKER_02It is, it's it's an expensive hobby, um, you know, but it it has its uses.
SPEAKER_00Yeah, yeah.
AI Agents Building A Language
SPEAKER_00Um anyway, uh uh I've been watching from afar what you've been up to with AI and stuff like that, and I found it pretty interesting. Um, my friend shared a tweet of yours that that particularly uh caught my attention. Uh I might get this wrong, but like I think you like built a language using AI in like a couple days or something like that. Something like that.
SPEAKER_02Yeah, I had I had several projects going on at the same time. So I had you know one agent over here working on project A and another agent over here working on project B. And and while they were doing whatever they were doing, I thought, wouldn't it be interesting to ask an agent what the perfect language for it would be and uh have it run under the JVM. And so I just started that. It was just kind of a lark. Uh, and it it turned into a uh a several day uh very part-time uh exercise just to see what it would produce. And it did, it made something, you know. I had to work with it through a number of prompts and so on, but yeah, it did. It made a nice little language, uh, very Lisp-like. Um, the the the agents seemed to prefer uh terse syntax. Uh and uh then I did a few experiments. I compared it against languages like Clojure and Java and a few other languages, and uh it turned out to be awful. Yeah, you know the the the language it likes the most right now is Clojure.
SPEAKER_00Okay. Yeah. Um yeah, I had Dave Thomas on the show a while back, and he told me that he did something which I thought I I thought was interesting and really smart. He asked the agent, um, how can I code in a way that would make it easier for you to understand the code?
SPEAKER_02Yeah, that's the question, right?
SPEAKER_00Yeah, yeah. Um, so so that you know, to me that seemed like a similar approach, uh, catering to the agent.
SPEAKER_02I don't know how wise it is to ask the AI for their preferences. I'm not sure they actually have preferences. Um, I did ask it, uh, you know, can you create a language that would minimize tokens? And I said, sure. And we talked we went down that rat hole for a while. And then on an offhand part of the discussion, it just happened to mention, you know, that's not the most efficient way for me to work. Sometimes I need more more tokens to think clearly. Oh, okay. Okay, well, whatever, dude. I don't I don't know how it's it's a weird thing.
LLM Limits And Explanations
SPEAKER_00Right. It's a weird kind of intelligence, uh, or maybe we should say like pseudo-intelligence. Um, because it's not, you know, it it's not doing real uh epistemology. So in the last few years, I've gotten really into epistemology, and I've learned about um Karl Popper and his um his epistemological views and stuff like that. And there's a question of what is what is knowledge and what is science and stuff like that, um, and and how do we acquire knowledge? And I used to think that you know you you make an observation, uh, the next day you make a similar observation, similar observation again, and it's like, okay, I've seen this a lot of times, this is how it tends to go. So that's that's probably a good, you know, the sun comes up every day.
SPEAKER_01Yeah.
SPEAKER_00And so we can predict that the sun will come up tomorrow because it came up a bunch of times before. But that's not a valid way of thinking, and that's not why the sun's gonna come up tomorrow. We know the sun's gonna come up tomorrow because we have an explanation for how the solar system works. It's all about explanations. And LLMs don't have explanatory knowledge, they only have statistical prediction, and so there's there's weird limitations to their intelligence.
SPEAKER_02I think there are some limitations, although they they do seem to think rather deeply and infer some surprising insights. It's it's very it's fascinating to watch them as they chat their way up the scroll window, right? And you just listen to their comments or read their comments as they go by. Mostly you're just skimming them because it goes by so fast you can't actually read them all. But you know, you get this chain of thought that's going by, and and it's it's pretty interesting. They don't have long-term memory. Um, you know, if they if they see an event like the sun rises, and then the next day they see that event, um, they're probably in a different context window and they can't associate them. Right? If they see if they see an event and then a minute later they see the same event, then they can associate them because that's in their memory. Uh, but so it's a really weird kind of memory they've got. They've got really big short-term memory and almost no long-term memory. And humans are kind of the opposite. We've got really big long-term memory, but our short-term memory is is ridiculously small.
SPEAKER_00Especially mine. Well, um, yeah, you know, I think I think the problem with today's AI is that it didn't evolve. I I'm uh I'm I'm of the growing opinion that if and when we achieve AGI, we're gonna have to evolve it, not design it.
SPEAKER_02Well, I wouldn't say it didn't evolve. Certainly there were uh selection forces put upon it, although they were they were artificial selection forces. Uh it did not evolve on the savannah trying to survive while being hunted by lions. Uh, on the other hand, it certainly evolved through the agency of a bunch of uh very smart people who put this thing together and saw it fail this way and saw it fail that way, and eventually tuned it to what it is today. And that that I am sure will continue. I I'm not even convinced I know what AGI is. You know, what does that even
Memory Agency And Defining AGI
SPEAKER_02mean? Um the one the one thing these things don't have yet is any kind of ambition, any kind of self-agency. They do not sit around and think, what should I do next? They're not doing that. In fact, when you're not prompting them, they're not doing anything.
SPEAKER_00Right.
SPEAKER_02They're they're a complete vacuum. So that's a big difference. Um now it'll be interesting someday, probably very soon, someone's gonna close that loop and get these things to start thinking on their own about gee, what should I do next? How should I how should I continue? What is my mission in life? Yeah, that'll be an interesting day.
SPEAKER_00Yeah. Yeah. You know, why do people do anything? Um, the only reason we do anything is uh for for biological reasons because we evolved to do that. Like, why do we want money? Um, well, we want money and status and power and stuff. Well, men want those things because you can attract a better mate that way. Um, and like everything we you know, I don't need a nice car, like a relatively new car. I could drive a crappy car. Um, but I feel like uh an emotional need to drive a newer car. Um that's that's just biology driving me to do that. There's no reason to do that. And so an AI has no reason to do anything. And so again, I feel like either we'll have to evolve it or we'll have to like artificially inject it with these uh animalistic motives.
SPEAKER_02Humans are driven by a profit motive, right? And the profit motive is really, really simple. It's all based on energy, right? The energy you exert must be less than the energy you produce, otherwise you die. Therefore, we are driven to produce more energy than we consume, than we consume. That allows us to uh survive long term, build families, and then there's this whole motivation to apply that energy to better circumstances so that we can produce even more energy. The uh you could look at the uh the growth of civilization, especially in the 20th century, but through most of it, as a way to amplify the amount of energy produced by uh through the amount of energy exerted, right? And and nowadays it's astronomical, right? The amount of energy a single human produces is enormous compared to what it was, say, 200 years ago. We've gotten to the point now where you know you walk up to a switch and the lights all come on, and you know, I drive a car that has a battery storage of over a hundred kilowatt hours, you know. And I just drive it around, you know, for whatever reason. Uh the amount of energy at our disposal as humans is enormous, and energy is wealth, energy is profit. So, you know, people who complain about the profit motive don't quite understand what the profit motive is. It's all about energy.
SPEAKER_00Yeah, um, I've I've been experimenting with artificial life for the last several years. Yeah, yeah. Um, and I realized relatively recently that like energy, okay. So it it's I I've found it hard to create anything that behaves in ways that are all that interesting. Um it it in in order to create interesting behavior, there has to be like something on the line. Um you you have to there has to be a price to be alive. Um and I realized that kind of the currency of the universe is energy, and so something my artificial world is gonna have to have is it's gonna have to have a fixed amount of energy and um competition for that limited amount of energy, and there's kind of I don't know, I I'm not gonna try to get the physics terms right and stuff like that, but there's kind of like free energy that's just there moving around for the taking, and then there's like stored energy in food, and you have to grab the food to get to energy and stuff like that. Um, but there is a
Energy Entropy And Artificial Life
SPEAKER_00constant tendency to disorder, you know, uh second law of thermodynamics. Um energy tends to spread out more evenly over time. And when energy is spread out evenly, it's unlikely to be doing anything useful. It's only when energy is concentrated that it's doing useful work and it's movement from a from an area of high energy to an area of low energy when the useful work happens, and every living organism um has to fight off entropy. You have to take the um, you know, the universe is constantly trying to kill you, and you have to swim upstream to uh to to stay alive.
SPEAKER_02Certainly that's true. I mean, you know, and I use the term energy. We really should have been talking about entropy, but I don't want to get too deep into the weeds of the physics of the of the situation. But yes, we're always we are always in this interesting battle because the only way to do work is to increase entropy. So all of us are agents of disorder, but we we accomplish that. We have to create more disorder than order, but we accomplish that by creating an awful lot of order, and then we survive in that order, and we hope that the disorder kind of permeates out into the universe without doing too much harm. Mostly as infrared radiation, okay.
SPEAKER_00Yeah, but uh when you're uh if if you're an organism, uh you're you're eating and you're creating org order within yourself, because you are a system, and then you're excreting uh waste and heat and stuff like that, because the the total amount of entropy in the system stays the same. So if it's increasing in one area, if it's decreasing in one area to create order, then it increases everywhere else. I think this is a great segue to bring it back to programming.
Entropy Meets Software Engineering
SPEAKER_02Okay, because I can do this for all day long. We can talk science all day.
SPEAKER_00Well, I think there's you know, uh, this is to me, this is not just uh undisciplined BS or something. Like these are deep fundamental truths of the universe that apply to everything, including programming, so you can learn these things and then profitably come back and apply them to programming. Like I think entropy applies to a software system for sure, right?
SPEAKER_02Yes. Through a very interesting agency.
SPEAKER_00Yeah. Um, so uh uh I don't know, sometimes I think about the inevitable decay of a software system, and as the complexity of the system grows, um, it never maybe there's local exceptions, but it never really gets cheaper to maintain as as the system grows. All you can do is stave off the inevitable uh decline into disorder uh a little bit more. You you can make it giz get less maintainable less quickly, I think.
SPEAKER_02Correct. Yeah, that that has been the goal for uh many, many decades, right? How do we stave off the plunge into chaos? Uh and that's I mean, that's what software engineering is. Software engineering is the the bulwark we build against that pludge plunge into chaos, and it's and it's not easy, not not uh not a uh a simple problem to solve. Uh we are the agents of disorder. You know, it is our fingers on the keyboards that cause the disorder in the systems that plunge towards chaos. And so we are the only solution to that. We have to apply disciplines and structures that keep that system well enough organized for us to continue working in it. The factors that that uh confound that are the fact that our customers and the environment out there want all kinds of features, they want all kinds of behaviors that are not closely associated. You know, not only does this thing do your taxes, but it'll also sweep your floors. And it's very Difficult to organize that kind of a structure into something that is easy to maintain.
SPEAKER_00Yeah. Right. And to me, uh okay. I was gonna make a statement, but first let me ask a question instead. Um not to put you on the spot, but I feel like after, you know, five decades of programming, you might be ready for this question. Um what is programming?
What Programming Really Is
SPEAKER_02Programming is the management of detail. Intense, horrible, nasty, icky detail. We we programmers are detail managers. We deal with all the details that nobody else wants to deal with. They've been trying to get rid of us for uh seven decades, and they can't because they don't want to you they don't want to deal with the details, and for some strange reason, we have the personality defect that makes us want to focus on detail. We love it. Yeah, we'll get in there and go, oh, this is really cool. Look, if I just flip this one bit, whoa, it goes off in that direction. We get very excited about it. What for whatever reason, you know, and I see the little lights blinking back there?
SPEAKER_00Yeah.
SPEAKER_02Yeah, okay, that's a mock-up of a PDP 8, you know, back from my childhood when we when we programmed on these machines. And uh my buddies and I were all high school kids, and we got jobs as programmers at the age of 17 and 18, because the Service Bureau down the road wanted cheap programmers, come to you imagine that. Uh, and we would build these systems that were fairly complicated for the day, all in assembly language, and we could diagnose them by staring at those blinking lights. We could watch the blinking lights, and the pattern of the lights would tell us what was going on inside the machine. Yep. That's that's who we are, right? We we are detail organizers. That's that's any any other function that we do, the fact that we code is irrelevant, right? We manage details. That's that's why the whole AI thing is not going to get rid of programmers. Because there's a group of people who really love detail. And and they're those are the programmers. We're the ones that are going to be writing the prompts and looking at, you know, watching the stuff scroll by on the screen. And did you see that go by on the screen? That looked like a binary search. Prompt that in there. We are going to be the ones dealing with that level of detail for the foreseeable future.
SPEAKER_00Right. Yes. Um, I I'm not surprised whatsoever that you, you know, get that. A lot of people don't understand this aspect of programming. Like the the the complexity and excruciating detail and stuff like that, the the place where that stuff resides is in reality. And the only reason programs are complicated is because the programs uh have to have have to kind of match the reality that they're like, for example, um, I built a scheduling system for a doctor's office. Uh, like many scheduling systems, they needed indefinitely recurring appointments. So we had to have not just uh what you might call concrete appointments where it happens one single time at 9 a.m. on a Monday, but there also had to be these kind of abstract appointments where it happens at 9 a.m. on Mondays, uh, but no particular Monday. Um so that when you look at the calendar for any particular week, it says, give me all the concrete appointments, and then look for any recurring appointments whose patterns make it show up on this particular span of time. That complexity is in reality, you know. Oh, there's no way around that.
SPEAKER_02And no one
Modeling Reality Without The Noise
SPEAKER_02will ever be happy with any solution you provide. There will always be some exception that worms its way out. Well, I didn't know it was gonna do that. The rules that we put in there. Yeah, but it shouldn't do that. You should you should put a safeguard against that. Well, okay, I'm gonna do that, but then this other thing is gonna leak out. There's no way to there's no way to take reality and corral it into a nice little box. All kinds of stuff always leaks out, which is part of the fun of programming.
SPEAKER_00Yeah, and to me, um, a big part of it is searching for a maximally elegant model that that um, you know, all models are wrong, some are useful, um, but but finding a model that fits reality well enough um and isn't uh needlessly convoluted and hard to work with. I find that very satisfying.
SPEAKER_02Yeah. The US tax law will confound you on that one. Ha!
SPEAKER_00I bet. Um but it it it reminds me of what scientists do. You know, like I I've talked before about um scientists endeavored to explain the motions of the planets, and the ancient Greeks assumed that the that the orbits of the planets were perfect circles. Um and they assumed that the uh the Earth was at the center of the universe, and so they came up with models based on that. The models were perfectly reasonable. Perfectly reasonable. I probably couldn't have come up with any model for the motion of the planets if I was equipped with what they were. Um and and their models were predictive, they gave they gave the right answers, but the model so happened to be wrong and it was convoluted. They had you know the the the orbits and then epicycles on the orbits, yeah. And then epicycles. Yeah, exactly.
SPEAKER_02Yep, and then which is just a foyer foyer distribution of of the actual orbit, right? Add enough circles together and you can get any waveform. Uh and then it was Johannes Kepler who finally you know did measurements on the on the position of Mars for years. Okay, did math, horrible math, pens and paper, trying to fit circles. He couldn't fit a circle. He started he started other shapes and he finally found ellipses work pretty well. Okay, and so he said, Okay, well, it must be an ellipse. And then he was able to publish the most accurate almanacs predicting the eclipses and the movement of the planets and stars, uh, and made a fair bit of money because he had a good almanac.
SPEAKER_00I did not know that.
SPEAKER_02Yeah. Um science can turn into profit.
SPEAKER_00Yeah, so they they came up with a uh in a model that was both simpler and more correct, and there's something just really satisfying to me about that. And you know, I have and you have, and uh I'm sure, and a whole bunch of people have, gone through experiences where you model your program in some certain way, trying to meet some domain, and it feels a bit uncomfortable, and then one day something snaps into place, and it's the equivalent of going from geocentrism to heliocentrism, and your model is both more accurate and simpler.
SPEAKER_02Those moments occur to me most often in the shower.
SPEAKER_01Mm-hmm.
SPEAKER_02Right. You sleep on the problem, you wake up in the morning, and all of a sudden, with the water running on you, your brain goes, Oh, how about this idea? I don't know why it works that way, right? Or driving home. Uh from work, you get in the car, you're driving home, and about halfway home, you go, Oh, and then you have to turn around and go back. Yep. Uh for some reason, if you take your the the focus of your brain off the topic, move it to the side, something is still going on back here. There's some process running, diagnosing and thinking things through, and then when it gets to a solution, it pops it up to the front of your head and you go, whoa, wow, I hadn't thought of that before. And then you have to turn the car around and go continue your debug session.
SPEAKER_00Yeah, yeah. I don't know why that works the way it is.
SPEAKER_02Um I don't think that's the way AIs work, though.
SPEAKER_00You do oh, right, right. Yeah.
SPEAKER_02Well, I don't think they suddenly wake up with an insight.
SPEAKER_00Right. Yeah, an AI never emails you at three in the morning and they're like, hey, check this out.
SPEAKER_02Yeah.
SPEAKER_00It'd be neat if they did. Yeah. Um, okay, so I want to I want to ask you something on the topic of modeling, because I think maybe not everybody is is quite on the same wavelength yet. Um, and and maybe not everybody has the same picture in their head as as we do, assuming that you and I even have the same picture in our head when we talk about a model. So to you, what what is modeling in programming?
SPEAKER_02Oh well, for me, modeling is a an organization of similar behaviors connected through relationships. Um, so I I look at I look at systems as a bunch of autonomous little bits, sort of like processes, although I don't usually break them up into processes. But yeah, little little bits of behavior isolated from each other but connected minimally through uh some very well disciplined dependencies. That's how I look at models. Um I can model a system up from the lowest level details to very high level abstractions, uh, and then I can organize those abstractions nicely and try and keep the order of the of the relative code or modules uh nicely organized so that they don't communicate too much.
SPEAKER_00Interesting. Man, um that is so differently from how I think about like that's all consistent with the way that I think about it. It's just such a different answer than I would give if somebody asked me what's a model. Um I I don't think I have an eloquent, eloquent explanation off the top of my head, but I often give some kind of analogy, like the solar system model, or like one that I like is a uh like a subway map, because a subway map is inaccurate, you know, it's it's distorted. Um it's it's it's spatially distorted,
Abstraction Layers With Highway Maps
SPEAKER_00but it's it's not made to be it, it's it's not a satellite photograph of the terrain, you know. That's not what you need when you're going from one subway stop to another. You just need to know the sequence of the stops. You don't even necessarily care how far apart they are, you just need to know the sequence. And so that's a a good model or uh an example of a of a model that uh throws away information, and it's uh even more useful than it would be if it were more accurate and complete.
SPEAKER_02Yeah, absolutely true. So the modeling that I'm talking about is is very much like that. It is a map of the of the structures of the system with a whole bunch of detail ripped out of it, right? So that you can fit it in your head. The the subway map, the London tube map, for example. You can fit that, well, you can fit the algorithm in your head, and the exact map, I don't think you can, but you can fit the way it works into your head, and you don't have to deal with what's really going on underneath the ground, which is vastly more complicated than what's on that map. And that's the same with a uh a map of a system. I've got a bunch of components out here, they communicate along these lines. I don't know what the details inside those components are, I don't know what all the exceptions to the communication paths are, but I know generally how the system is going to work. So it's a model of system behavior. And then, of course, uh the actual code breaks all those rules.
SPEAKER_00And do you think about it? I'm sure you do, uh, but I don't want to put words in your mouth. Uh, do you think about it in layers? Like there's layers of abstraction, similarly to how if I'm going on a road trip from uh Grand Rapids to Chicago, let's say, uh, maybe I want a high-level road atlas when I'm on my way there. Let's pretend it's the 90s. Um, and then once I once I get to Chicago, then maybe I want a detailed street map. But the the street map would be useless to me when I'm on my on my journey. It's only when I get there that I'm interested in that lower level of detail. And unlike the subway map, you know, there's only one level to the subway map. Like you just don't care about those other details ever. Whereas with the trip from Grand Rapids to Chicago, you do care you care about different levels of detail at different times.
SPEAKER_02The highway system is a very good example of a model, right? Because once you're on the highway system, you can forget about everything that's around you, all the little villages and hamlets and stop signs and stoplights, all that's off site off your plate. All you have to deal with is the nodes on this network, right? Until you leave the highway system, and then suddenly you're plunged into a whole different level of complexity. You got stop signs to deal with, and stoplights, and and all and these weird cars going in all kinds of different directions. Um, so that's another example of that kind of model. The the highway system is a physical model of a necessary abstraction.
SPEAKER_00It's a physical model of a necessary abstraction.
SPEAKER_02Yeah. You can't get from place to place by worming your way through all the stop signs from you know from California to Chicago. Right? You can't even conceive of that. People used to do it, but they would do it with trial and error. Uh, the the highway system is a vast abstraction, right? Most of the highways will take you in the wrong direction to some degree. Right? So if I want to get to California, if I want to get to San Francisco from here, I actually have to go south a great deal. Even though I would prefer to go due west, I have to go south for a good long time. And I've got to worm around. But it is far more efficient for me to be on that highway system because I can get to where I need without a lot of horrible detail impinging on me in every second. And it's fast. All the of the removal of all that detail means I can go at expressway speeds. Right? So that's a very interesting trade-off, right? We get rid of the detail and we can become more efficient until we absolutely need the detail. And we can take that that abstraction and make it physical. And that's exactly what we do in software. High-level modules are physical implementations of high-level abstractions, right? We get rid of all the detail out of those modules. Those modules don't even think about detail, right? They're just trying to organize the highest level stuff. And the code that we used to write in there, that the agents will now write, will not deal with all that low-level detail. That one of the first rules of a good architecture is that the high-level modules do
Dependency Inversion Made Practical
SPEAKER_02not know about the low-level modules. They have no connection to the low-level modules at all. Low-level modules talk to high-level modules, high-level modules never talk to low-level modules.
SPEAKER_00I am so glad that you said that because that's specifically one of the things that I wanted to talk to you about. Um, that is that's probably a principle that a lot of people have arrived at independently. Yeah. I kind of like vaguely over the years arrived at that same uh same idea that that makes sense for uh uh the way that I put it is uh specific things should know about general things, but general things shouldn't know about specific things. Yeah, I like your wording better, but um I I I I searched for so long trying to find like, is there a name for this principle? The the closest thing I could find was the dependency inversion principle. Uh it is that the same thing?
SPEAKER_02Uh that is the yeah, the dependency inversion principle got its name because in order to get um high-level modules to be independent of low-level modules, you need to invert dependencies because they do need to call them. High-level modules need to call down to low-level modules, but you don't want them depending on the low-level modules, so you have to turn that dependency around, invert the dependency so that the low-level module can depend on the high-level module, even though the high-level module calls the low-level module. So I it got its name because there was an inversion of the source code dependency against the flow of control. Flow of control goes down towards detail, uh, but the source code dependency goes up towards abstraction.
SPEAKER_00Interesting. Okay, so I I I'm I'm not following completely yet. Let me let me um give an example. So I kind of followed this this principle. I'll bring up my scheduling system again. Um, there were appointments, but also other kinds of things, like blocked off periods for vacations and stuff like that. Um and so I needed something more general. I called it a schedule item. Um, but I didn't want to have to always say, like, okay, I have my hands on a schedule item. Let me go look through these all all the possible kinds of things this schedule item could be. Is it an appointment? Is it a block? What that that seemed really bad to me. Um, so I I I made the dependency go the other direction where an appointment has a schedule item, and the appointment knows about the schedule item, but not the other way around. A block knows about a schedule item, but not the other way around. Um but I don't feel like I had instances where where where, for example, the schedule item would have to call the appointment or something like that. And in general, like I'm having trouble thinking of instances where the the higher level thing would have to call the lower level thing. So I'm trying to understand what I have missing.
SPEAKER_02You just described an inheritance hierarchy, right? Typical kind of inheritance hierarchy where you've got a schedule item as the base class, and then you've got appointments and other kinds of scheduled items derived from that. And the the high level high-level policies hold on to the low-level detail. They've got uh appointments, they've got the derivatives of the schedule item, but they don't know about them. They hold on to those objects. They don't know what those objects are.
SPEAKER_00Sorry, can we be more specific?
SPEAKER_02Through the high-level interface of the schedule item. That's how I would organize that. There's a million different ways to organize that. In an object-oriented language, that's how I would organize that. And then the schedule item would have a bunch of methods in it that aren't implemented, and the lower level, lower level items derived from them would implement those methods. And that way the source code dependency goes up towards the high-level thing, but all the calls go down.
SPEAKER_00Okay. Okay.
SPEAKER_02That's kind of what OO is all about, right? That's why that's why object orientation was so interesting to me anyway. A lot of other people had different views of what OO was, but when I got my hands on object-oriented languages, the thing that made the most sense to me, the thing that impacted me the most, was that I had a physical way within the language to isolate high-level policy from low-level detail. I could get that dependency perfect without jumping through the weird hoops that you would have had to jump through in a language like C, or worse, Fortran. Yeah, that which dates me a lot.
SPEAKER_00Um can can you kind of capture what you feel is the the essence of OLP? We're we're like taught so often that um the central principles are um abstraction, polymorphism, inheritance, and encapsulation.
What OO Is Actually For
SPEAKER_00Yeah. Um I've come to feel that like those four aren't all of like equal stature. And some of them are a lot more essential than others, but I'm curious your take.
SPEAKER_02Well, uh so yeah, they usually they they talk about three things or maybe four, right? Encapsulation, inheritance, and polymorphism. Encapsulation we had uh better in C. C was a perfectly encapsulated language, right? There were ways to organize your header files and implementation files in ways that uh nothing could leak out, right? So that was perfect. We had to compromise that when we went to an OO language. C came along and had to make certain compromises which broke encapsulation. So I don't think of OO as an encapsulation boundary, it's kind of a soft, a softer encapsulator. Inheritance, uh, inheritance is a kind of thread. Throwaway relationship. They created it back then. It was a thing in Simula. It came in from there to C. It sort of came into Smalltalk. Java and C sharp both kind of fiddled with it a little bit. But it's primarily a relationship to preserve typing. For statically typed languages, which is where all those languages grew up, you need this relationship that says this type is abstract and this type down here is derived from it. In languages like Ruby and Smalltalk and Clojure and dynamically typed languages, that relationship just goes away. It's completely irrelevant. Nobody needs to have an inheritance relationship. So I don't count that as part of OO either. The big thing that OO did for me was it it made um the polymorphic dispatch really cheap and safe. Prior to that, if we had wanted to do polymorphic dispatches, and we did, you know, back in the 60s and the 70s, we invented device independence, right? Because we did not want our high-level programs to know exactly what devices they were using. So we understood this a long time ago, but the mechanism that we had to employ to get that involved all kinds of horrible pointers to functions and weird initialization functions. And if anybody did it wrong, the whole system collapsed. OO came along, and in the in the languages, all of that became trivial and safe. All of a sudden, you could have, you know, polymorphic dispatch that was easy to do, utterly trivial, and you could reorganize your dependencies so that low-level things depended on high-level things, and high-level things could be independent. That was the big revelation, the big benefit of OO. And I know, but there's all kinds of people who are yelling now, yeah, functional is better than OO. OO is so 90s. No, no. The whole notion of dependency inversion is still critically important to any good architecture.
SPEAKER_00Um there's a couple couple things I wanted to to bring up also. Okay, so mental note, I wanted to uh to bring up testing. Um testing is yeah, um, but there was something before that on
Tests As The Bulwark Against Rot
SPEAKER_00the I don't remember what it was, so I guess I guess testing it is. Um I heard from someone something you said, so it's probably a game of telephone, but uh you would rather if if you could have an application and either have the test suite deleted and keep the application code, or have the application code deleted and keep the tests, you would rather have the latter than the former.
SPEAKER_02Yes. This actually goes back to a uh a panel discussion in the year 2000 or 2001. It's right at the beginning of the agile movement. And and as part of the agile movement, there was a a sub-thread, which was the testing movement. You know, this massive idea of writing unit tests so thoroughly that the system is, you know, 95% covered. That was a big goal back then. Could we get it above 90? Whoa. Um, and the the panel discussion was this there are two discs back when we had discs. Uh there are two disks. One contains the production source code for your system, the other contains the unit test for your system. One of those two disks has just crashed. Which do you hope it was? That was the premise of the panel discussion. And the obvious answer is that oh, well, I hope it was the tests that crashed because they'd still have the production code. And then the conversation ensued. And the conversation was fascinating, right? I can recreate the production code by one by one getting all those tests to pass. Not a trivial job, but the behavior of the system is encoded in those tests. And so there is a straight pathway from getting back to the production code from the unit tests. There is no pathway to go from the production code back to the tests. It's a trapdoor function. It's easy to go one direction, it's very hard to go the other direction, right? And so just from that point of view, the panel decided, well, probably be better if the production code disc crashed, that way we could recreate it, although that would take a lot of effort. And then the second layer of the discussion, which happened much later at a different time, which was this if I don't have a suite of tests that I trust, this production code is going to rot and it's going to rot quickly. Because everybody's going to be in there adding features and fixing bugs, and they will have nothing to back them up. They're going to be worried that they're going to break things. So they will do things in the most pragmatic and horrible way to get things to work and they will degrade the code. We've seen this happen over and over and over again. But if you have this suite of tests, then all of a sudden the programmers are free to be uh much more friendly to the code because they can try something and then run the test. Ooh, that didn't work. Maybe we should do it this way and said, Oh, that did work. So when you have a suite of tests, you prevent the code from rotting. The programmers can actually do the things that will keep that bulwark against the plunge into chaos. But if you don't have the tests, plunge into chaos, you will. And that was the end result of that.
SPEAKER_00I'm so glad I asked that question. That is that that is gold. Um okay, follow-up question. Um I have come to believe, you know, in in trying to teach testing and and uh doing testing myself and encountering people's attitudes toward it and stuff like that. Uh I've come to believe that most programmers don't uh I'll I'll just say what I'm thinking at the risk of being uncharitable. Um they they they don't understand the benefits of testing. Like if if you if you ask most people like what's the number one benefit of writing tests, they would say something that's very different from what I would say. But I'm I'm curious for you, what are the top, you know, the top benefit or maybe the top couple benefits of having tests and doing testing?
SPEAKER_02There's a whole bunch of benefits, most of which are ancillary. The primary motivation for having a suite of tests is to prevent the plunge into chaos. If I have a suite of tests, I can keep the code clean. I can keep the structure clean. I can do what I need to do to maintain an ordered structure that is easy to maintain, because I'm not afraid that I'm going to break it. If I don't have the tests, then I then I am afraid of the code. I'm afraid of every action I take in the code. Whatever I do might break it. It might break it in surprising and weird ways that are only discovered a week after I deploy, right? And so I'm really conservative and I have to do things that are ugly to protect myself. That's the motivation. That's that's why we have done tests to allow us to keep the system clean. That's why we have tests. And by the way, if you're doing AI, you better be doing a lot of testing.
Testing When AI Writes Code
SPEAKER_02Right. Because those those agents are pragmatic as hell. They'll go in there and rip that code all seven ways to Sunday.
SPEAKER_00Right. And don't assume that the agent is gonna write very good tests without your help, because in my experience, it it absolutely won't.
SPEAKER_02Oh no, it's just it's as pragmatic with the tests as it is with the code. No thought, no, no architectural thought, nothing, nothing about that will be applied unless you insert yourself into the agent's thought process. I do that real simply. I just watch the stream of of stuff go by as it scrolls by, and I can see it's doing something stupid here, and I'll stop it. I say, okay, now you got to separate those things. Like just now, just uh uh an hour ago before you called me up, right? I asked one of the agents to modify a tool. And I wanted it to add a command line argument. And the the the agent made this offhand remark, said, huh, there's no separate module for the command line processor, so I'm just going to add it in line. And I thought, what? There's there's no separate module for the command line processing. Okay, let's add another module and we'll separate the command line processor from the rest of the app, and you can communicate the command line arguments through a nice little map.
SPEAKER_00Yeah. So it can be like you're always it can be contemptibly lazy and undisciplined sometimes. Um I I do want to make sure that I mention um the the the primary motivation that I hear most often for writing tests is to make sure the code works. Like for our new features going out. We we have to test it to make sure it works. And that's like it's not wrong, but like they're they're really missing the essence of it.
SPEAKER_02You test it to make sure it works, of course. Right. Uh, and there's a whole a whole series of tests that you should write along those lines, primarily acceptance level testing. Right. You'd like to have the customers involved with that. You'd like to have the the users involved with the statements that drive the acceptance level testing of the system. But way below that, there is this I'd I'd I'd I'd phrase it the way accountants do, right? If you're going to be creating a complicated network of calculations and and figures on spreadsheets, the way accountants do, you better say everything twice. You better have two sets of books that are complementary to each other, and they follow separate mathematical pathways, but then they unify on the balance sheet with a a sum of zero. And that's what test-driven development really is. From the point of view of a programmer, it is the double entry bookkeeping for keeping the code self-consistent. It's not so much making it work because you it might not work. The feature might be might be defined incorrectly. You might be encoding the wrong behavior, but you are encoding self-consistency because you are you are doing it in two entries, one on the test side, one on the production code side. And that makes it much easier to debug when the customer does come back and say, Well, that's wrong. Oh, well, here's the test, here's the code. I see how this went off, and we need to modify it appropriately.
SPEAKER_00And when I'm adding a new feature to an application, my my new change constitutes the tiniest fraction of the whole system. And it's like, yes, I want my new thing to work, but like I'm far more concerned with everything else. Like, that's my main concern is I want everything else to still work when I when I put out this new thing.
SPEAKER_02It's not going to be fun when you make a little simple change and you break something over here that nobody thought would ever break.
SPEAKER_00Right. Right.
SPEAKER_02Um that's how you lose confidence in the software team. Every time I fix something, it breaks over here. These guys don't know what the hell they're doing anymore.
SPEAKER_00There's so many more things I want to ask you about and talk about, but sadly we're just about out of time. Um, you just came out with your second edition of Clean Code, which I have bought
Clean Code Second Edition Wrap
SPEAKER_00and not read, not read yet, but I'm looking forward to it. Um, can you tell us about that and just anything else that you want to share before we go?
SPEAKER_02Well, I it so the first book came out what 16, 17 years ago. Uh so it's fairly long in the tooth from an age point of view. The principles inside are still perfectly valid, but it was all in Java, it was all you know at in the in the realm of the just past the dot-com revolution, right? 10, eight years past that. Uh, and a lot has happened since then. And a lot of ideas in my mind have shifted or crystallized better. So I thought it was time for a good rewrite. Actually, it was my publisher's idea. You should do a second edition. My my first reaction was, I'm not I'm not doing that. And then I thought, well, you know, maybe I should, because there is a lot of things that have shifted around. So I decided to redo it. It's almost a complete rewrite. Uh, there's a couple of chapters that are uh heavily modified, but the rest of them it's it's just a full rewrite. And I incorporated a lot of different languages into it. So I think there's some Python and some Go and some, I don't know, there's a whole bunch of different languages, which by the way, I had an AI help me do. Uh and I brought in uh a few other experts, you know, and I had a lengthy debate with John Austerhauit, which is published in the book on different different ideas of method size and comments and so forth. Uh, and I thought it it's uh probably the right time for a restatement uh and a clarification of a whole bunch of things, just in time for the AI revolution.
SPEAKER_00Yeah, and I was surprised there's even there's stuff about AI in this book. Yeah. Um, okay, well, we will put that in the show notes, of course. And Bob, thanks so much for coming on the show. Been fun. You need to talk more science. Indeed.