Clean Code: A Path to Better Programming

Join a high-level overview of best practices and wise words on how programming should be approached from Uncle Bob, author of “Clean Code,” and Allen Holub, software architect and agile coach. They cover some of the existing guides that can help you become a better programmer and explore how books and current trends are shaping the software landscape.

Intro 

Allen Holub: Okay. Hi, Bob.

Robert C. Martin: Hello, Allen. How are you?

Allen Holub: Good. How are you?

Robert C. Martin: Just fine.

Allen Holub: So we are tasked to talk about what are two old but classic books today? And it was interesting because I was reading through them in preparation for this, again. And I haven't read them since they came out. So it's been a while.

One of the things that I had to say looking through it is “Thank God” we don't have to deal with EJBs anymore and all of that stuff. But like a lot of the classic books, there's still certainly a lot of stuff in there that's just as relevant as it was the day you wrote the books. Particularly the Clean Code book is that I look at a lot of code, and clean is not a word that I would choose to describe the code that I'm looking at.

If you were to write the books again, what would you change?  

Allen Holub: I'm kind of curious as...if you were to write it again, how would you change it based on what's happening now as compared to what was happening then?

Robert C. Martin: Well, it's an interesting question. I might choose a different language. Martin Fowler rewrote the Refactoring book and he changed the language to JavaScript. I don't think I'd pick that language. Maybe I'd use Python or a language that's on the ramp-up, getting more and more popular. If I had my absolute druthers, I'd use Clojure because I think that's the language of the future.

Allen Holub: Yes. Clojure people always say that. They've been saying that for 10 years though, so.

Robert C. Martin: Hey, it's taken a while, but I think it's on its way up. But the principles in the book, I would not change much. This is one of the things that I focused on in all my books is to try and write about the things that don't change. There's a strategy with books that if you write about the stuff that changes a lot, you'll be able to sell a lot of books for a really long time. And then you just have to write another book and another book and another book.

I've taken the opposite approach. I want to write about the things that don't change over time so that they are relevant for a very long time. And I hope that the Clean Code book and The Clean Coder book and so forth have remained relevant over the last decade or so that they've been published.

Allen Holub: Well, they have, certainly at the level that they address the problems. You know, that's another question. Something else we can discuss is...one of the things that I respond to when I read all books that are basically eristics, books that are kind of rules, things to do, make things do right, is that they're very kind of context-specific.

In other words, when I look through your book, I'm saying, this is great if what you are is a programmer and you're looking at the code, but you're not looking at the architecture because it's all focused on starting with the code and refactoring and TDD and all this wonderful stuff that programmers should be doing, of course.

How to get developers to think from an architectural perspective?

Allen Holub: But I look at some of your advice, which is great advice, but some of those issues could be solved by thinking architecturally rather than thinking just in terms of the code, things like naming and that kind of stuff. So how do you fix that? How do you fix it on many levels? Both on how do you fix the architecture, but also how do you fix people not thinking enough about architecture. Well, there is that right.

I think about things like DDD. DDD has been around forever, but it's suddenly gotten popular again because of microservices.

Robert C. Martin: Is it microservices that did that?

Allen Holub: I think it was microservices that did that because people started saying, "Oh, microservices are bounded context," which is not true. But people started saying it anyway and all of a sudden people were reading about DDD because they read the microservices were bound in context so I must know what it is.

Robert C. Martin: At least something good came from microservices.

Allen Holub: Well, I'm not as negative on them as you seem to be, but the issue is that DDD is suddenly on the scene in a way that it wasn't before, which is a good thing because it gives us organizational principles that help make the code better, make it cleaner. It helps with a lot of stuff. It helps with names, it helps with everything.

The problem that I have often, though, is that when I come in as a consultant to a company, the programmers are not thinking architecturally at all. They're just thinking about the code that's in front of them and it limits them. It limits what they can do. It limits how much they can clean stuff up. There are limits everywhere and I would like to get rid of those and I don't know how to do it because people are really set in their ways.

Robert C. Martin: Well, there just aren't enough old coots like us.

Allen Holub: Well, there is that.

Robert C. Martin: This is something I talk about a lot is the fact that the number of programmers in the world grows at an exponential rate, and that leaves the number of old people compared to the number of young people at an impossible ratio.

You have half the programmers in the world who have less than five years of experience. This continues to be true as long as we're growing at this crazy rate. That rate is going to have to slow down because there are only 8 billion people in the world and we're starting to get within a range.

Allen Holub: It's the vampire problem. If a vampire bites two people and they bite two people and they bite two people, eventually everybody's a vampire.

Robert C. Martin: And it doesn't take that long.

Allen Holub: It does not take that long. No.

Robert C. Martin: So, you know, I write books like this, and I wrote this one a long time ago. It is just full of this kind of stuff that you learn the hard way after 15, 20, 25 years. I kind of hope that it makes its way out to the younger folks because there aren't enough guys of our experience on teams directing those teams.

Allen Holub: But it's not just a number of programmers issue, it's also an age-ism issue and a youth culture issue. I see that out here. Admittedly, you know, I'm in the Valley so it's worse here than it is in a lot of other places, but there we are. It's an issue because there's a lot of reinventing the wheel happening all the time that didn't have to happen.

Robert C. Martin: Oh, sure. Yeah. Yeah. The age-ism and youth culture, how would you not have a youth culture if half the programmers always have less than five years experience. Everybody looks around and they say, "Well, everybody here is in their 20s. This must be a job for people in their 20s." And you got the one guy in the back who's 40 or the 1 guy in the back who's 50, who's sitting there going, you know, wait a minute, I've been doing this for an awfully long time. Why are you telling me this is youth culture? But of course, that's the people coming in.

Why would you read a book by Uncle Bob

Allen Holub: People are paying attention to your books.

Robert C. Martin: Well, I hope some of them are.

Allen Holub: I hope so. So there's wisdom in the books is that people are...so why is it that you'd be willing to read a book that has stuff in it written by an old coot and no offense because I'm one too.

Robert C. Martin: No.

Allen Holub: At the same time, you don't want the actual old coots around. It seems like an odd thing.

Robert C. Martin: I think you do want the old coots around, but like, you know, here's one that's what? 25 years now.

Allen Holub: Yes. But you know, even that starts...

Robert C. Martin: Is anybody reading this? Are any of the young kids out there reading "Design Patterns?"

Allen Holub: It's a good question.

Robert C. Martin: You know what I hear about design patterns? "Design patterns are an old idea that's now out of date because our modern languages take advantage of that." That's complete nonsense, absolute nonsense but I hear that over and over again.

Here's a book. I'm sure you're familiar with this one. Why doesn't anybody read this book? This is just full of good information. Tom DeMarco, "Structured Systems Analysis and Specifications." Great ideas in this book. Why doesn't anybody read this book? There's tons of information out there that's old and good.

Allen Holub: I wouldn't say it's old. I was just thinking about that in terms of...Fred Brooks came up the other day in a conversation and I'm going, "So here's a book that's really old," right, as Fred was writing...

Robert C. Martin: "The Mythical Man-Month."

Allen Holub: Yes, exactly. But with the exception of the chapter on punched cards, pretty much everything in that book is still relevant.

Robert C. Martin: I always keep them handy. You never know when you're gonna need one.

Allen Holub: Pretty everything in there is relevant and particularly Brook's law itself is relevant. People don't seem to get that. All of the no estimate stuff that people have such fits about, that's all in Fred Brooks, right? Fred is talking about how bad estimates are and how we shouldn't be basing our planning on estimates and stuff, back then.

That all seems to have gone by the wayside, which is really unfortunate but there are some evolutionary things. The other day I was talking to someone about the problem of design patterns in the context of simplicity and that the obvious negative of design patterns is that they're complex. They add some complexity to the system.

You had the fool-me-once-fool-me-twice rule in one of your talks or your books or something, which is applicable. I think one should do it as simple as possible and then add the patterns in the refactoring stage when it is all settled.

But a lot of people don't get that subtlety and they'll read something like Clean Code where you're talking about open-closed for example, but that pulls into design patterns. It pulls in command and it pulls in strategy and it pulls in dependency injection and all this stuff that adds complexity to the system.

Ways to learn faster

Allen Holub: The biggest problem that I see when I look at code when I come in as a consultant, is that it's all way too complicated. Half of it doesn't do anything and half of what's left used to do something, but nobody looks at it anymore. And there are all these code-solving problems that never happened because somebody thought they might happen.

Robert C. Martin: You mean, it looks like a whole bunch of kids who've been tearing through the place and making a mess.

Allen Holub: It does but, you know, a lot of it comes from the old waterfall thinking that it's expensive to make changes, so we want to try and think of everything in advance.

Robert C. Martin: Certainly that.

Allen Holub: We need to fix that. And the stuff that we're talking about is kind of complicated in a way because there's a subtlety to it, there's nuance. It's not just a bunch of rules that you followed by rote. It requires thought and it requires understanding. And so how do you develop that? How do you get people to develop it?

Robert C. Martin: These are the long-term questions, "How do you solve world hunger?" Did you ever take a martial art?

Allen Holub: Yes.

Robert C. Martin: Oh, good. I did too. And the way our instructors taught us is on the first day, they would have us on the mat and they would teach us one move, in my case it was jujitsu. So they would teach me one move, Hakkō-ryū, the escape from the opening. Okay. You're going to do that.

And they would have us repeat it and repeat it and repeat it and go home and practice it, come back, repeat it, repeat it, repeat it. When they thought we had gotten that move, they would add another move. This just would continue for a year or a year and a half. By the time you were ready to have a belt increase, and then they'd add more and more and more, and eventually, it got to the point where you've got a black belt.

During this entire time, it's all this rote repetition of these moves that you focused on for months, learning and perfecting. Then you get the black belt and everything changes. And all of a sudden it's, now we expect you not to do any of that. Now we expect you to integrate.

You have just begun, you are now a student and you may now integrate, and we don't want you doing those moves anymore. We want you to figure out from the situation you're in, what context and how to use what you've learned to escape or dominate the situation. And that's when true learning really begins.

We have an industry where you get kids that graduate from college, all they've learned is three of the 50 moves they need and they're thrown into the environment where they have to write code. That's all that comes out is those three moves. 

There's nobody to help them learn the other moves and there's nobody to help tell them that the real goal here is to get those moves so well under your skin that you can begin to integrate them.

So you were talking about the nuance, you were talking about the complexity. That takes time to learn, time to get good at. A programmer really doesn't get into that level of the thought process for the first 10, 15 years in my experience. Maybe it took me that long.

Allen Holub: It can go fast. I'm a big, big mob programming fan, ensemble programming kind of guy.

Robert C. Martin: Mob programming. Good idea.

Allen Holub: Yes. And one of the reasons I like it is because it helps shorten that curve a little bit because you're collaborating, hopefully, with at least a few people that really know what they're doing and I think some of it rubs off.

Or even, even if you only know three things, the other people in the mob know three different things. So as you start working together collaboratively, you all start learning the things that the other people learn and it all goes a little bit faster, but I'm still seeing a lot of resistance to that. Mob programming is like one of those things where, when I do a mob programming workshop, I come in and everybody's going, "I don't know. This can't possibly work." And by the end of the week they're going, "How could we ever have been programming without doing this?"

But making that transition is hard. People have to experience to really kind of get it to the point where they're willing to try it. 

It gets us back to the, how do you make the problem of the changes, right, is that the bunch of kids in the room, they think everything's perfect and management is fighting against them. Some manager's going, "Five people sitting around watching one person work. We can't have that, can we?" And it's a hard problem. I guess I think about this because this is my life, it's trying to convince people to do things that they ought to be doing but they aren't and resist.

Robert C. Martin: I've been through that mill so many times, you're trying to convince, trying. That's why, you know, why I'm an author.

Allen Holub: Well, I don't try and convince them, you can't convince them.

Robert C. Martin: And you're right, you can't convince. You can demonstrate, you can exhort, you can encourage, and a few people will get it. A few people will learn and they will follow.

Then what you've done, you consultant you, is you have started a war inside that organization. And there's suddenly a group of people that has one set of values that are opposed to another group of people who have a different set of values and they cannot coexist. Somehow or another, they either have to learn from each other or there's going to be a divorce.

And that's something I've watched over and over again is, you know, the people that I teach and exhort will either eventually become the only people in the team or they will flee the team. And I don't think it works any other way. Sometimes you can get, and you wonder how a captain, a ship's captain gets the entire crew to act in unison. How do they do that? How does the military manage to pull this off?

Allen Holub: Well, there are Marquet books. You read Marquet's books.

Robert C. Martin: I haven't read Marquet books.

Allen Holub: You should have. "Turn the Ship Around" is a great book. He was a submarine captain. So it was a small group. I don't know if you can expand that out to business size, but it was. a team of what, 50 or 60 in a submarine.

Robert C. Martin: That's still a pretty good-sized group.

Allen Holub: It's a good-sized group, but it's not like an enterprise with 6,000 people. And he basically empowered everybody. He said I can't tell you how to do your job. You know how to do your job better than I do, so I'm not gonna tell you what to do. I'm going to give you a strategic directive and you guys figure out how to make that work. And it did pull everybody together. Everybody felt empowered, they felt like they were part of a bigger thing rather than being ordered around. And really, I think helped them a lot.

And you know what, I do see that social thing happening in groups too. I hate open offices, but in one of the big open offices I was working in, we were TDD and mob programming and that kind of stuff and I was talking about creating your own workspace and the team took me seriously. They literally went out and bought a couch and they bought a big monitor and they pointed down on a desk right in the middle of this open office.

So they had this lounge area where they were sitting, doing their mob programming, staring at the giant monitor, and people would walk by and they said, "What are you guys doing?" And gradually I was watching that infuse out into the rest of the organization as they explained themselves and people looked at it and they said, "Oh, that's interesting."

So it's not a war, it doesn't have to be a war. Instead, it can be a sort of...if it's a good idea, the good idea tends to spread unless there's somebody at the management level working hard to make it not spread.

Robert C. Martin: Well, I've seen that one. But what you were just talking about reminded me of something that happened to me about 20 years ago when we were very early on doing Agile consulting. One of the things that we would do is would advise our client before we ever came out to do the teaching of test-driven development and pair programming and all that stuff. Before that, we'd say, "You've got to get your programmers out of offices and into a room set up with tables," and we'd give them a kind of standard layout, and they would do that.

Then we'd get this phone call...and it happened more than once. We'd get this phone call and then the managers would say, "Things are so much better now. People are actually getting things done and they're collaborating and they're talking to each other." And, "Okay, yeah. If you get people talking to each other and working together, they tend to work things out pretty well."

But on the other hand, I also participated in a number of events like that, where there was a subgroup of programmers, in one case, who were literally sabotaging the rest of the team because they could not tolerate the value shift and probably because it was depriving them of some status that they had previously had. So they were literally laying plans to sabotage what was going on. Once we discovered it, well, they weren't at that company anymore.

Allen Holub: That's the way it has to go. The people complain about that, right, is they say, "Oh, but if we're going to be Agile, we're going to have to get rid of these people that are not willing to be Agile." Then I go, "Well, yeah." And they're going, "But we can't do that." And there's tension in there too.

One of the things that I recommend to bigger clients is that if you're really gonna try and do this whole Agile thing, you've got to provide an out for the people that don't want to do that's humane. Say, "We're going to find you another job. You don't have to worry about it. We'll even pay you until you find another job. You obviously can't work here, but we're not gonna make your lives miserable. We'll find something that you can do."

Remote working

Allen Holub: Things go much easier than when you have a bunch of middle managers fighting tooth and nail for any kind of agility because it damages their status and they don't want to do it. It's a big deal. But, you know, I also worry about this in the context of remote because remote, it doesn't have to be, but it can be very isolating.

I look at Hunter Irrigation when this all first came up or the team first came up or mob programming. And they're still...they were 100% mobbing shop. It's six or eight teams mobbing 100% of the time and they all went remote and they're all still doing it. They're all just mobbing every day. They're just doing it on Zoom instead of doing it physically in the space.

And that works, but there's not much space there for new ideas to infuse out to the organization as a whole in a remote world because you don't see the whole organization, you just see the team that you're working with. So it can be very limiting.

I see these trends now, DHH talking about all remote all the time for everybody, and that can be very limiting. I worry about that. There's a siren call of not commuting, but on the other hand, I worry about that in terms of the organization's growth.

Robert C. Martin: The virtual connection is adequate for some things, but it deprives you of so much human contact and so much interpersonal stuff that can really only be done face-to-face. I'm with you. I agree. There's something limiting about it and I fear that we are going to go through a decade of very sterile collaboration. I'm not quite sure what the word is.

Allen Holub: I'm seeing it happen both ways. I'm seeing both, I don't want to use the word introvert because people use it wrong, but there's a class of programmers that just don’t like to be around other people, which has nothing to do with introversion. So just to get this term straight, but they love the whole, I'm going to work at home, remote for the rest of my life and I don't ever want to talk to anybody.

Meanwhile, there are a bunch of incompetent managers going, "Oh, we can take all of this money we're spending on offices and we can make our employees spend that money instead, therefore saving us money. Is that they have to like set up an office and do all this stuff that we would normally have to pay for, but we don't. So that's great because we don't have to pay them money anymore. We don't have to pay money to set up their offices anymore."

So you put these two things together and it seems deadly to me. I worry about that. People talk about productivity while at the same time doing everything they can to prevent it from happening.

Robert C. Martin: Because they don't understand where the productivity comes from. Perfectly reasonable to sit there and say, "Well, you know, I don't need a parking space. I don't need parking lots. I don't need all of this infrastructure. Everybody can work from home. We don't even need a building anymore." And it seems like you're saving a lot of money, but you don't know what the cost is.

And by the way, that's the same thing that happened 20 years ago with offshoring. All of a sudden, "We're just gonna...we're gonna have people in X country and people in Y country, they're all gonna write this code and it's all gonna come here and it's gonna be perfect."

Allen Holub: That worked out well.

Robert C. Martin: That worked out pretty well.

Allen Holub: But it took 10 years, 15 years for it to wear off.

Robert C. Martin: That's the fear. That's the fear. Another 10 years and all started by this COVID thing. We're gonna be living with the echos for a good long time.

Allen Holub: Yes. Is there a way to fight back? How do you fight back against it?

Robert C. Martin: Well, I mean, you and I are sitting having this discussion and if there's a bunch of people listening to it, maybe they're going to put a little thought into this. Like, well, you know, maybe we should have people come back to the office every once in a while and actually look at each other's eyes, smell each other.

Allen Holub: Actually eat the pizzas.

Robert C. Martin: There's this effect of staring at a screen and the effect is a lot like being behind the wheel of a car looking at the windscreen. It's a lot easier to call someone an idiot when you're holding onto the wheel of the car looking through the windscreen. If you're on Zoom, all you have to do is kind of mute for a second and say something under your breath and then unmute. And that is a weakening of the interpersonal connection.

Allen Holub: Yes. I just don't know how to make that point. It's also exhausting, at least it is to me. I've been having to do a lot of Zoom teaching and I can't go for more than half a day before everybody was so exhausted that they can't absorb anything anymore.

Robert C. Martin: But here we are, it's a year into this COVID thing and I have literally not been on a commercial aircraft since last March. Now I own my own airplane so I can flit around a little bit, but you know, a commercial aircraft I haven't been on.

I got an invitation from a college in Michigan about two months ago to come out and give a talk. And so I hopped in my plane and I flew out, it was a real quick flight, and all of a sudden I'm on stage and I'm talking face-to-face with a group of programmers, and it was just wonderful.

I forgot what this is like. I forgot what it's like to look at people in the eye and see their responses and have person-to-person feedback. And so I'm just chomping at the bit so that this can start again because I think it's very harmful the way we're doing it now. It's the way it had to be done, but it's harmful.

Allen Holub: I need to get people to hire me to do that. I used to have a plane, I don't know.

Ethics of being a programmer

Allen Holub: So is there anything you want to talk about? I've been sort of driving things. Do you want to drive for a while? What do you want to talk about?

Robert C. Martin: Let me tell you what I'm up to. Let's see. So, yeah, so I didn't write "Clean Architecture" a while ago. What else did I write not too long ago? Oh, yeah. Let's see. I don't think I have it up here. Let me look over here. So, yeah, there it is. I do these Zoom things and then I get a bunch of books out and I leave them in a pile. So I wrote this one not too long ago.

Allen Holub: Oh, I didn't even know that one existed

Robert C. Martin: "Clean Agile." This is a rant. This is me. The old curmudgeon telling all the young kids to get off his lawn. I walked through all the agile principles, one by one, saying, you know, "This is how we did it 20 years ago. This is how it still should be done today. And all this stuff that everybody's trying to do, probably not a great idea."

Anyway, that's the old man yelling at everybody about Agile. 

I'm in the midst of another book now, which is going to have the title...I think it will be "Clean Craftsmanship." That's a book about disciplines, ethics, and standards. Discipline, standards, and ethics in that order.

It tries to climb the hierarchy, you know, saying, okay, we start with disciplines. Of course, test-driven development is one of them is a big one. Refactoring, simple design, things like that. And then climb up another level to the standards. What is it that the executive expects?

We talked about the ship captain, the submarine captain. How do you get the crew to behave as a unit? And you said, okay, well, you empower them to solve the problems, but you give them the problems to solve. You set the expectations.

So the standards are the expectations. How do we expect a software developer to behave? And then once I've got that all spelled out, then I go through the ethics. What are the ethics of being a programmer? That may be the last book I write unless I write a book on Clojure.

Allen Holub: That will have a huge market.

Robert C. Martin: Maybe it will, "Clean Clojure." It might sell really well. Who knows?

Allen Holub: All right. It looks like we're at a good stopping point, so we should probably stop. It's been a pleasure.

About the authors

Uncle Bob has been a programmer since 1970. He served as the Master Craftsman at 8th Light inc, is co-founder of the online video training company: cleancoders.com, and founder of Uncle Bob Consulting LLC.

He is an acclaimed speaker at conferences worldwide, and the author of many books including: "The Clean Coder", "Clean Code", "Agile Software Development: Principles, Patterns, and Practices", and "UML for Java Programmers".

He is a prolific writer and has published hundreds of articles, papers, and blogs. He served as the Editor-in-chief of the C++ Report, and as the first chairman of the Agile Alliance.

Allen Holub, (allen@holub.com) is an internationally recognized software architect and Agile coach. Allen speaks all over the planet about these topics and agile-friendly implementation technology like microservices and incremental/evolutionary architecture. He provides in-house training and consulting as well. He excels at building highly functional Lean/Agile organizations and designing and building robust, highly scalable software suitable for agile environments. He's worn every hat from CTO to grunt programmer.

Allen is widely published. His works include 10 books, hundreds of articles in publications ranging from Dr. Dobb’s Journal to IBM DeveloperWorks), and video classes for agilitry.com (Agility with Allen) and for Pluralsight (Swift in Depth, Picturing Architecture, Object-Oriented Design), LinkedIn Learning (Architecture Fundamentals, and Domain-Driven Design), and O’Reilly (Design Patterns in the Real World).

If you'd like to bring Allen in-house for consulting or training work, set up a chat at https://holub.com/chat to discuss your needs.

Recommended talks

The Scribe's Oath • Robert "Uncle Bob" Martin

War is Peace, Freedom is Slavery, Ignorance is Strength, Scrum is Agile • Allen Holub