#90 - Clean Craftsmanship - Robert C. Martin (Uncle Bob)

[00:01:52] Episode Introduction

Henry Suryawirawan: Hello to all of you, my friends and listeners. Welcome to the Tech Lead Journal podcast, the show where you can learn about technical leadership and excellence from my conversations with great thought leaders out there. And today is our episode number 90! We are getting really closer, just 10 more episodes to reach the 100th episode milestone. For those of you who have been following me and this podcast for a while now, thank you so much for your continuous support and for listening to the episodes. You are one of the main reasons that gives me the energy to deliver new episode week in, week out. And I hope to be able to continue doing this and deliver a lot of learning contents for all of us.

And for those of you who are listening to Tech Lead Journal for the first time, don’t forget to subscribe and follow the show on your podcast app and social media on LinkedIn, Twitter, and Instagram. And if anyone wants to contribute to the creation of this podcast, support me by subscribing as a patron at techleadjournal.dev/patron.

Today, I am really, really excited to share my conversation with one of the great thought leaders in the software industry. When I started my professional career, I used to read and watch a lot of his great work, such as Clean Code, Clean Coder, and his Clean Code video series. And I grew a lot by learning from those resources in my early career. And I still continue reading every new Clean series book published in the last few years. So it felt quite surreal to finally have a chance to talk to him personally for this episode, but this is really one of the most fun episodes that I’ve had in the podcast. As many of you would have already known by now, my guest for today’s episode is Robert C. Martin, who are more widely known as Uncle Bob. He’s the co-founder of cleancoders.com, an acclaimed speaker at conferences worldwide, prolific author of multiple best-selling books, and one of the authors of the Agile Manifesto.

In this episode, Uncle Bob shared some insights from his latest book, “Clean Craftsmanship”. He first started by sharing his view on the current major challenge of the software development industry, that as a young discipline, it suffers from the state of perpetual inexperience, amid the exponential acceleration of demand for new programmers while not having enough highly experienced programmers to impart valuable knowledge and experience from their journey, which then drove Uncle Bob writing this book to help define the disciplines, standards and ethics for establishing software craftsmanship. Uncle Bob then touched on the five key disciplines of clean craftsmanship, specifically focusing on two main disciplines, which are test-driven development and refactoring. After covering the disciplines, Uncle Bob also described a few essential standards and ethics of clean craftsmanship, such as never ship s**t, always be ready, do no harm, and estimate honestly.

I’m super thrilled having this conversation with Uncle Bob, diving deep into clean craftsmanship, and the 3 essential things as part of that craftsmanship, which are the disciplines, standards and ethics, which I believe if all of us try to adhere to, the software industry will continue to mature towards a better future, especially in the current era of software eating the world. If you enjoy this episode and find it useful, please share it with your friends and colleagues who may also benefit from listening to this episode. Leave a rating and review on your podcast app, and share your comments or feedback about this episode on social media. It is my ultimate mission to make this podcast available to more people. And I need your help to support me towards fulfilling my mission. Before we continue to the conversation, let’s hear some words from our sponsor.

[00:06:53] Introduction

Henry Suryawirawan: Hello everyone. Welcome back to another new episode of the Tech Lead Journal podcast. Today I am really, really excited actually. My guest today, I think most of you would have known him. He is widely known as Uncle Bob, Robert C. Martin is in the show today. Before we start, actually, I just want to say, Uncle Bob, you have been one of my heroes in the software development world. In my early career, actually, I read a lot of your books, “Clean Code”, “Clean Coders”, whatever blogs and even your Clean Coders series, the videos. I watched a number of the episodes. So I’m really, really pleased to have this chance to have a conversation with you today and learning from your story and experience.

[00:07:29] Career Journey

Henry Suryawirawan: I know that many people would have known you by now. But before we start, I always like to ask my guests to actually share their story, their journey, or maybe any turning points or highlights in their career.

Uncle Bob: Um, gee whiz, I got involved with computers at the age of 12. My mother bought me a little plastic computer. I have it over here. Well, there it is. A little plastic computer and it’s got a little readout with ones and zeros on it. There’s three bits in here and they can go back and forth, the one and zero.

Henry Suryawirawan: It looks pristine.

Uncle Bob: It is the original. It is my original. So it’s 57 years old. It’s not functioning at the moment because the rubber bands that I have up here are old and rotten. But otherwise, you could program it to count in binary or count down or add two bits or subtract two bits, solve a number of logic puzzles. I was very fascinated by this machine at the age of 12. And so I taught myself how to program it, which required that I learned Boolean algebra and learned about state machines and learned about logic, and that set me on the path to becoming a programmer. So I started very early. The year was 1964. Good long time ago. My father noticed my interest, and he somehow managed to get me books on Fortran and COBOL and PL-1. A suite of languages that was popular at the time. And I just devoured those books. I read them and tried to understand them. I wrote lots and lots of software that I could not execute, because I didn’t have a machine. But I still wrote it in pencil on paper. You know how, when you’re a preteen or a teenager, you can really focus on things. I got pretty focused on that stuff.

My father figured out a way for my friends and I to visit the digital equipment sales office, where they had some PDP-8s and PDP-10s just sitting there on the floor of the sales office. So those people would allow me to come in on weekends and play with their computers. My friends and I would sit there and we would toggle in programs into a PDP-8 and make it execute, and we learned how to edit programs on paper tape using a Teletype. There was an awful lot of that stuff that I was doing. I got my first job as a programmer, probably at age 16. It was a temporary summer job. Wrote a little bit of assembly language code for a Honeywell H200. Got my first full-time job as a programmer at age 18. Writing some COBOL and then very rapidly after that assembly language in an old mini computer called a Varian 620/F. So you don’t need to know all that, but it gives you a background of where I came from very early on with very low level machines.

Henry Suryawirawan: Thanks for sharing your story and actually the toy that got you into all this. It’s really fascinating and you still have that toy, right? So 57 years ago. So that is really a monumental toy, I believe. I always like devouring your content, either your books or maybe your videos. You actually gave some history an overview of what actually happened long time ago, maybe before I was born even. So I always appreciated those stories. Thanks for sharing your story at the beginning of this episode.

Uncle Bob: Sure.

[00:10:53] Clean Craftsmanship

Henry Suryawirawan: So Uncle Bob, you have written a number of books but today we are going to cover mostly from your latest book, which is titled “Clean Craftsmanship: The Disciplines, Standards, and Ethics”. I think if I’m not mistaken, you have been writing this even long ago, maybe through blog posts and some of the webinars and conferences that you did. But maybe if you can give us some overview of what are the reasons that now actually you wrote this book.

Uncle Bob: Clean Craftsmanship. The book is a culmination of a lot of topics. So I’ve started writing books in 1995, 1994. I wrote books about software design, object-oriented design. I wrote a book in 2002, which was “Agile Software Development: Principles, Patterns, and Practices”. That really brought all of the design principles and all the practices and design patterns altogether in a nice, neat little bow. And then I started writing books like Clean Code. And that was a difficult book for me to decide to write. Because who am I to tell anybody what clean code is? I’m just a programmer. But I figured somebody has to write this book. So I wrote it with the caveat at the beginning that, you know, this is my way. I do it this way. You don’t have to do it this way. It’s just, you know, after 50 years of programming, maybe you want to listen to what I have to say.

As I was writing that book, there were a whole bunch of topics I wanted to talk about, but they didn’t fit into that book. Because Clean Code is a very technical book and I wanted to talk about all the non-technical things. So I had a whole bunch of topics I wanted to talk about. Once I published Clean Code, I wrote the Clean Coder. It just kind of spilled out, right? All this stuff that was stuck in my brain just kind of spilled out at the Clean Coders. All the non-technical things about being a programmer. Like what do you do? When you go to work, you’ve just had a big fight with your significant other, you cannot get your brain to focus on code. How do you deal with that? That’s the kind of stuff that’s in that book. How do you estimate? How do you deal with managers? All that stuff.

I wrote that book and then I started to get this idea that we needed to address Agile. The Agile community had begun in like 1999 and the Manifesto was signed in 2001, and then all the consultants jumped in and they kind of “corrupted” – not the right word, but they got involved and they stretched the whole discipline out, and I thought it’s time for a reboot there. So I wrote the “Clean Agile” book as a way to just reset and describe what Agile was and how we got there and why we got there and where we should go. And as I was writing that book, I thought, well, there’s a whole bunch of other things I want to say about this, but they’re not really tied to agile. They’re more about the notion of craftsmanship. I put all those topics aside, and then when I was done with Clean Agile, I thought, okay, I’ve got to write this craftsmanship book. The craftsmanship book was kind of an odd mixture of deeply technical topics, very technical topics. Having to do a test-driven development and refactoring. And then also, this kind of pull back to say, okay, we need some standards and we need some ethics to try and balance this whole thing out.

A programmer is a deeply technical person but has to be governed by non-technical concepts, including standards and ethics. So that book kind of ties all of those things together into a nice, neat little bow. If you read that book, it starts out really technical. It’s probably one of the most technical books I have written. In fact, there was so much technical stuff in it, I had to put some of it on video. So as you’re reading the book, it refers you to videos that you can watch. And then as the book progresses, it shifts into standards. What are the standards we try to uphold while we are doing all this deeply technical work? And then once we get through the standards, the book shifts again and says, okay, now what are the ethical situations that drive those standards? So the book proceeds from disciplines, deeply technical disciplines, then to the standards that drive those disciplines and then to the ethics that drive those standards. And that was the way I completed that book.

Henry Suryawirawan: So if I may add, there’s actually one book that you missed, which is “Clean Architecture”. So that book is also deeply technical, and it talks about clean architecture, like port adapters and that kind of stuff. So I think that’s also worth a mention.

[00:15:31] Programmer as a Profession

Henry Suryawirawan: So you mentioned about programmer being a technical person. They should have the technical practices. They should have standards and ethics. And if you compare it, other profession like maybe doctor, pilot, lawyer, and all that, programmers seem to not have those kinds of things. Which is why I think in the beginning of the chapters of the book, you wrote about this problem. Developer now is like coming from different backgrounds. They maybe go to the bootcamp. They just learn how to do those technical stuffs, but not necessarily the standards and all these ethics that make them the real profession. So tell us more about these problems that you see, maybe from your consulting point of view, or maybe from recent days that you see the programmers these days. What is the current state of the programmer’s job?

Uncle Bob: Software is a very young discipline. I want to use the word profession, but it’s not a profession. Because there’s nothing that we profess. A profession is the assemblage of standards and disciplines and ethics. The professionals profess those things. We don’t have that. That’s just because we’re a young discipline. We are very young.

The first line of code that executed on an electronic computer is just a little bit older than I am. Alan Turing wrote a little bit of assembly language in a machine in 1946 or 1945. That’s just not that long ago. To complicate that, the need for programmers has accelerated exponentially, as the number of computers has accelerated exponentially, so has the need for programmers. So the number of programmers in the world doubles every five years. It’s pretty stark. The number of programmers in the world doubles every five years or so, which means that half the programmers in the world have less than five years experience. And this will remain true as long as we are doubling every five years. And that leaves our industry in a state of perpetual inexperience. There is no way for us to accumulate the standards and the ethics, because they’re not taught in school and they’re not taught on the job. There is no way to accumulate those things. The people who could accumulate them, the people that have a lot of experience, 20 or 30 years experience in the field, barely exist. As 20 or 30 years ago, there were hardly any programmers.

So it’s a fundamental problem of how do we mature an industry that is dominated by 22-year-olds? We’re going to have to solve that problem because our civilization is now in a state where it depends on us for its existence. If there were no programmers now, our civilization would collapse. So we have to somehow get this idea of standards and ethics, a real profession, into our minds, into our brains. So that was the reason I wrote the book. I wrote the book so that I could start that process. The standards and the ethics that I talk about in that book are just my concepts. They may not be the end result. Other people should take that and massage it and change it. But at least I think it’s a seed. It’s some place to begin.

[00:18:45] Craftsmanship

Henry Suryawirawan: Thanks for taking this precedent. Thanks also for sharing this history. To me, it’s an insight. So I’m still considered young. I mean, my profession. I didn’t know, actually, like 75 years ago when the first program is written, and then up to now, actually the number of developers keeps growing and growing exponentially. Like you said, the numbers of experienced people are not that many. Even if there are, they are just maybe in some parts of the world. Their knowledge is not spread. It’s just like so many people churn out from university, go into the engineering job. And that’s why we are in this state of, like what you said, is perpetual inexperience, where we try to learn from doing, right? Not necessarily from someone who has done it before. Which brings us to the concept of craftsmanship. So your title of the book is Clean Craftsmanship. Maybe in the beginning, if we can clarify, what do you mean by this craftsmanship?

Uncle Bob: The simplest way to describe craftsmanship is pride of workmanship. If you’re a programmer, do you go home at night every day and look in the mirror and say to yourself, “I did a really good job. I’m proud of the work I did today. Not only did I write software that worked, but I wrote it well, and I wrote it in a good way. The process I followed was a good process.” Do you go home and feel good about yourself and good about your job? Or do you have to go home and take a shower? And far too many programmers have to go home and take a shower. Because they’ve gotten caught into this very dominant mindset, that speed overrides everything. You must program fast, and they get caught in this trap of thinking that speed comes from rushing.

Now, the opposite is actually true. If you rush, you will slow down. But you can’t feel that because you feel the rushing. You feel the tension in your body. You feel the tension in your mind. It feels like you’re going fast. You’re not. You’re actually going slow. And the way to go fast is to slow down and take your time, and not make dumb mistakes, and use a nice deliberate process, and keep everything clean. That’s the way you go fast. Very difficult concept for especially young programmers to internalize. Once you’ve done it for 20 years, then you realize, oh yeah, I’m going to spend eight days debugging this mess, and some other guy is going to spend eight days debugging the mess I made if I rushed like a crazy person right now. Maybe I should take my time and do this in a nice orderly way, and that way everybody can continue to go fast. Craftsmanship is that mindset. It is the mindset that you are working on something important and you are going to do it well.

Henry Suryawirawan: So I just want to add on this phrase. Just now you mentioned every programmer went home and then take a shower, right? For those of you who are wondering, why take a shower? Because, in your book, you mentioned that they feel dirty because of the dirty job that they are doing with their code. So just to give a context, why every programmer went home and take a shower is because of that.

The software craftsmanship that you mentioned here is very important, I think. I, myself are guilty of doing so much of this rushing and also bad code, and also trying to meet the deadlines. So you wrote a Software Craftsmanship Manifesto as well. I think this is also very important. For those of you programmers here who listen, maybe you should check it out and try to instill that mindset like Uncle Bob mentioned here and try to do your job well. So that’s the message here.

Uncle Bob: The Software Craftmanship Manifesto, I was there when it was written, but I did not write it. That was other people who collaborated to put that message together. Which, if I remember correctly, there’s a website, softwarecraftsmanship.org or something like that. I can’t remember. I was there at the time and I’m not as sagely as everybody talked, but I didn’t really contribute much.

[00:22:45] Disciplines

Henry Suryawirawan: Thanks for that clarification. So let’s go to the first thing from your Clean Craftsmanship, which is the discipline. So you mentioned these are the technical portion of the things, and I think it’s worth to mention all of the disciplines here. Maybe can you give an overview what are the disciplines that you advocate in the book?

Uncle Bob: The book begins with a very, very deep discussion on test-driven development. I focused heavily on this because, as we have learned over the last 20 years, it is a very rich discipline. There’s a lot in test-driven development. It began with this silly idea that you write unit tests first, and then you make them pass, right? And you get caught into a nice, tight little loop where you write a little test and it fails, and you write a little code and you make it pass, and then you write a little more test and then you write a little bit more code. Over the years, we started to learn how to do this well, and it turned out to be non-trivial. It turned out that there’s a lot of twisty little turns and there’s a lot of complication. Once you internalize all of that, it makes an enormous difference on the way you write code. I mean, it’s a transformative kind of discipline.

So I spend a lot of time on that discipline, especially exploring the advanced concepts. To my knowledge, there are no books out there right now that talk about these advanced ideas in test-driven development. So I think that book is the first one to really attach those ideas, these advanced ideas in test-driven development. I also spend a fair bit of time on the notion of refactoring. The two are brother and sister to each other. You cannot refactor without test-driven development. And the whole reason you’re doing test-driven development is so that you can refactor. And the goal of refactoring is to create a better design, better code, better structured your code, better design code, better architecture. So these two are deeply intertwined. I talk a fair bit about that in the book.

And then I talk about simple design. The basic rules for what design is and what should be motivating design at the very lowest levels. And I draw very much from the work of Kent Beck and Ron Jeffries in that particular discussion. I don’t go into design principles. That’s a higher level topic. This is like what is design at the very lowest level? What are the simplest things that we can say that define the qualities of good design? And then I talk a little bit about collaborative programming, pair programming. Starting to back away from technology so much and starting to get into the interpersonal parts of programming.

One of the things that programmers are very good at is deep focus. Deep focus generally requires that you work alone. Because if you’re working with someone else, it’s very hard to deeply focus cause that person’s always interrupting you. They’re always getting in your way. There is need for deep focus. It’s a good thing to be able to deeply focus. But it’s also a good thing to sit back, and with someone else at your side, walk through the code and coauthor the code and share knowledge and build code. That is a collaborative effort. So I talk a fair bit about that as the last of the disciplines.

If you look carefully at those disciplines, those four that I just mentioned, test-driven development, refactoring, simple design, and collaborative programming. Those are the inner circle of the circle of life diagram that Ron Jeffries put out 20 years ago, describing Agile. So Agile is composed of three circles. And in the book Clean Agile, I talked about the outer two circles, the business facing practices and the team facing practices. In this book, Clean Craftsmanship, I talk about the inner circle of the circle of life. All of the engineering practices, the engineering disciplines.

Henry Suryawirawan: And then one more discipline, which is acceptance tests, right? So, which are the outer part of the inner circle. So maybe if you can give an overview of that as well.

Uncle Bob: The acceptance test discipline is actually part of the middle circle, the team practices, but it is a deeply technical discipline because it involves the writing of tests at a business level. And that oddly makes it technical. But technical in the sense that the business people, the QA people and the business analysts must be able to state the requirements of the system in formal detail. And that’s what an acceptance test is. An acceptance test is the statement of a requirement written formally in enough detail so that there’s nothing left to the imagination of the programmer as far as the behavior of the system is concerned.

You would like the business to specify the behavior of the program. You’d like the programmer to implement the behavior of the program, with a structure that can tolerate change and take it into the future. But you want the business specifying that behavior. And one of the problems we have had in this industry for the last 50 years or more is that the business does not want to dive into enough detail to specify the behavior of the system. So they leave all the really terrible low level detail to the programmers, and that’s where we get into some real problems.

Henry Suryawirawan: Yeah, I think you’ve mentioned this very insightful state of the industry, right? Where it’s always the programmers that wrote all this implementation of the specifications. There’s no business rules that actually the BA or the product manager these days, there’s no BA in some of the startups these days, is the product manager or the QA, they don’t actually write these specifications in the formal details, but actually just give maybe a doc or just verbally mentioned it. So I think this is a very good distinction so that we always have to get the same understanding of the business rules and programmers also understand what is it that they’re trying to implement?

[00:28:49] Discipline: Test-Driven Development

Henry Suryawirawan: If we can go into TDD because most part of the book actually covers about these TDD. And I think this concept, although it has been around for many years since Kent Beck wrote it a long time ago, but still, I think, many people may not be able to practice it fully, including myself, right? It is a hard discipline, like what you mentioned in the beginning. So maybe if you can give us some tips or some guidance or philosophy, how we should do this TDD? Including the laws that you have for TDD.

Uncle Bob: So a test-driven development, I described it using three laws or three rules. The first rule is that you’re not allowed to write any production code until you have first written a test that fails, and it must fail because of the code you have not written yet. You write a test that fails first. And there’s the second law. You are not allowed to write more of a test than is sufficient to fail. As soon as it fails, you have to stop writing the test. And I like to say that when it fails to compile, you have to stop writing the test. So now you’re stuck, right? Because you have to write a test, but you cannot write more than will fail to compile, and it will fail to compile within the first couple of lines. Especially if you’re using a statically typed language like C# or Java or C++ or something like that.

The third law says you are not allowed to write more production code than is sufficient to pass the currently failing test. And this locks you into a cycle that is 30 seconds long. So you write a line of test code. Oh, it doesn’t compile. You write a line of production code. Oh, my God. That made it compile. You go back to the test. You write another line of test code. Oh, it doesn’t compile. You write another line of production code. That makes it compile. You write another line of test that compiles, but it fails. And you write another line of production code that makes it pass. And you’re stuck in this really tight loop. This is the first thing that programmers rebel against. If they’re looking at test-driven development, if they’re evaluating it as a possible discipline, they look at that really tight little loop and they think, well, that’s nuts. That’s stupid. I’d never be able to write an IF statement without interrupting myself. I’d never be able to write a while loop without interrupting myself. I’m not going to do that. So it’s a difficult first step to get across.

I first saw this in year 2000. I had gone to visit Kent Beck. I really enjoyed the eXtreme Programming stuff that he was doing. I went out to visit him and talk to him about it. But I didn’t care for this whole test first thing. I thought that was stupid. And then he and I sat down and we wrote a little Java applet. It took us about two hours. Just a dumb little Java applet that simulated the fairy godmother’s magic wand. Little, little sparkles coming out of it. It was a pair programming exercise. He and I sat together writing this in Java, and he showed me this discipline. And I’ve never seen anything like this. I’ve already been programming for like 30 years. I did not think someone was going to show me something radically different, but here it was right before my eyes. This was different. And it was different in a way that it had a huge effect, because for two hours we wrote that code, we never debugged anything. There was no debugging. We never went into a debugger. We never put print statements in. We never did anything. We just went from tiny little test to tiny little test, to tiny little test until the whole thing worked on the screen.

I walked away from that experience with a very different mindset. I thought, okay, this needs to be looked at. I need to get good at this so that I can properly evaluate it. Well, okay. It took me 20 years to get good at it. But it turns out that it was a lot more complicated than I thought. Now we have enough information and enough knowledge so that other people can get started faster and they don’t have to make the mistakes that I made and that Kent made and that everybody made in the early days. Cause we made a ton of mistakes in the early days.

My advice for people who want to get started with test-driven development is not to do it at work. Don’t do it at work because there’s too much at stake. Do it at home because everybody writes code at home. If you’re a programmer, you’ve got your own little pet projects that you do at home. Everybody does. Do it at home. Do it at a hackathon. Go do a hackathon on a Saturday. Do it there. Do it at lunchtime. Do it in some scenario where there’s nothing at stake or nothing big at stake and get good at it. Getting good at it is going to take you time, months. But once you’re good at it, then you can bring it to work and it will pay off. It is the way I write code nowadays.

Now, do I do test-driven development for every single line of code I write? Nope, I do not. There’s whole bunches of code that simply do not do well with test-driven development. Very specifically, GUI code, code at the graphical user interface. All you can do there is kind of get it on the screen and look at it and get more of it on the screen and look at it and fiddle with it. You’re still in the same loop. It’s still a real fast loop, right? But now you’re not writing tests. Now you’re looking at your eyes. You’re using your eyes to judge it. You work very hard to pull all the intelligence out of the GUI so that you can write the intelligent code with tests. And then the last little bit, all that horrible CSS stuff and all the formatting, you have to do that by eye. That’s the way I approach test-driven development.

Henry Suryawirawan: Wow. Thanks for sharing that insightful story. So I didn’t know that you actually paired with Kent Beck and figured out about this technique TDD, and that’s what we learn from you as well in the Clean Code, in Clean Coders videos. So thanks for sharing that story.

[00:34:31] Discipline: Refactoring

Henry Suryawirawan: So you mentioned about these three laws, which I think people associate a lot with this red, green thing, right? You add the test first, see it fail and you add the production code, make it run. But then there’s this third piece, which is refactor. And you mentioned that TDD always works hand in hand with the refactor. They are like brothers and sisters. They work really well together. Maybe can tell us more about refactoring, why we should do it? What are some of the advice from you as well? How to do refactoring well?

Uncle Bob: So refactoring is the practice of changing the structure of code without changing its behavior. You cannot refactor in a new feature. You cannot refactor out a bun. The behavior of the system remains constant while you are adjusting the structure.

Kent Beck said something a very long time ago. He said, “First make it work, then make it right”. Many, many programmers take the first bit of that advice and ignore the second part of that advice. So they get it to work. The way programmers behave, you know, programmers will work hard. They’ll try to get something to work. They’ll fiddle with it. It’s not working. Try something else. It’s not working. “Oh my God, it works. Oh. Oh, okay. Nobody breathe. Check it in. Check it in.” That’s the wrong approach. What you want to do is, once you’ve gotten something to work, you’ve made a mess in there. Human brains are not that good. We cannot make something work and make it clean simultaneously. Too many factors going on. So we can make it work. But then you have to change. Stop and think, okay, now I need to make it right. And the making of it right is this idea of refactoring. You’re going to keep the behavior while you change the structure.

We talk about this as a cycle. We talk about the name of the cycle is the red, green, refactor cycle, which tries to take refactoring and mix it in with test-driven development. So test-driven development has this very tiny little cycle. Write a test, make it pass. Write a test, make it pass. Write a test, make it pass. And then we try to toss in the refactoring on top of that by saying, okay, write a test, make it pass, clean it up. Write a test, make it pass, clean it up. Good advice, doesn’t always work that way.

What happens to me, anyway, is that I’ll go around the test-driven development cycle, 50, 60, 70 times. Around that cycle, test pass, test, pass, test, pass, test, pass. I will get something relatively significant working. And by that, I mean, 50 lines of code. 50, 60 lines of code, something like that. And that’s when I stop. And I go, okay, this is a mess. And it is. It’s almost always a mess. I’ve done it wrong. I put the wrong names in. I’ve put the code in the wrong place. So I’ve got a set of functions I’ve written, but the functions don’t partition things well. And then I stop and I say, okay, I need to move this over here. I need to move that over there. This name has to change. Oh, my goodness. This function is too big. I need to split it in half. And I spend a relatively significant amount of time restructuring the code while keeping the behavior stable. How do I know that the behavior is kept stable? The tests continue to pass. Without those tests, I would be lost. Because every time I changed the structure, I would be fearful that I had changed the behavior. Because I have the tests, I know the behavior hasn’t changed and I can safely improve the structure.

Henry Suryawirawan: Wow. Thanks for sharing, again, your insights how you normally do this, the TDD cycle plus refactoring. So for people who listen to Uncle Bob, maybe you can also follow his style. One thing that you mentioned about programmers these days, right? They just make it work and they stop after that. So I think there’s one thing that you mentioned in the book, right? So you should not actually ask permission to refactor because most of the times we make it work, and then we stop, and then maybe one week later, or maybe one month later, you tell the business stakeholders, “We need some time to actually refactor the code”. So that is actually a wrong thing to do. And that is probably not part of the craftsmanship that you advocate here.

Uncle Bob: That’s correct. You do not want refactoring to be on the schedule. You don’t want to have a bar on the schedule saying, “This is when we will refactor.” And you never want to go to managers and say, “Is it okay, sir, if we refactor now?” That’s kind of like going to the bathroom and then sticking your head out and asking the manager if it’s okay if you wash your hands. Do I have time to wash my hands or should I just go back and code now?

[00:39:02] Code Coverage

Henry Suryawirawan: So one thing that is always associated with TDD or unit test is about code coverage. So maybe if you can give some advice here, what will be the good code coverage that we should aim for? So that people are not misled.

Uncle Bob: There are a number of very good tools that will measure code coverage. Code coverage is the measurement of the lines of code and the branches of code that are executed in the context of a suite of tests. So you run your suite of tests and the tool will show you every line of code that was executed, and every branch that that code took. And that’s very useful. I mean, if you are writing tests and you’re writing code to go along with it, it is good to know how much of your code is actually being executed by those tests. So that’s what code coverage is. You could break it up into line coverage and decision coverage. There’s another kind of coverage which is path coverage, but that’s when you explode out every possible path and it’s not very practical. So I usually just do the first two. Line coverage and decision coverage. How much of the code should be covered? Is there some number? And most of the tools will give you a number. They will say, “Oh, 92% of your code was executed when you ran the test.” Okay. So what should that number be? And a lot of people will say, “Well, it should be at least 80%”. I reject that. I think, well, no, I mean, the numbers should be a hundred percent or as close to a hundred percent as you can get it. Maybe you can’t get all the way to a hundred percent because there’re some lines of code you can’t cover for some reason. But the numbers should be very high in the high nineties. And you should take every opportunity to push it even higher.

Code coverage is a technical thing. It is not a management metric. It is not something you want to put on the wall to show your customers or your managers, because they don’t understand what it is. Code coverage does not mean that the code works. Code coverage means that the code was executed. That’s all. If you had a bunch of tests and you took all the assertions out of the tests, it would still show you the same code coverage. So one of the problems that we’ve had with code coverage is that managers learn about it. Non-technical managers or managers who used to be programmers, but then became managers and lost all their technical skills. Because that’s instantly what happens as soon as you become a manager. So what will happen is that those managers will say, “Well, we should measure this and we should fail the build if you don’t achieve 80%”. So all of a sudden you’ve got this artificial metric in there. You’ve got to achieve 80% code coverage, otherwise the build fails. Well, you can’t have the build fail for God’s sakes. You can’t ship. You can’t deploy if the build fails. Therefore, the build must pass. And the way you make the build passes, you take all the assertions out of your tests. I’ve been there. I’ve seen that happen. It is a bad idea to make the code coverage number a management metric. It is a very useful tool for programmers, cause programmers can look at it and understand what it means. It’s a very bad idea to export that outside of the programmer community into the management.

Henry Suryawirawan: So for those of you who listen, try to aim as high as possible, a hundred percent. I know it’s really difficult sometimes to achieve a hundred percent, but at least you try your best. Aim at the higher 90. The three other disciplines, I think people should refer to the book.

[00:42:35] Standard: Never Ship S**t

Henry Suryawirawan: So let’s move to the two other things, which is the first one is standards, right? So this is where we go to the non-technical stuff. We will probably cover some of them, which I find interesting. And the first one that stood out, actually, is this phrase called, “We will never ship shit”. Maybe if you can tell us a little bit more about why you have this in the chapter?

Uncle Bob: The idea behind these standards came about because I was looking for a way for managers to encourage programmers to use good disciplines. One of the things you cannot do as a manager. You cannot tell programmers, “You will pair program. You will do test-driven development. You will refactor.” That doesn’t work. You can’t have this stuff being shoved down on you from the top because the programmers are going to rebel. “I don’t have to do test-driven development. Screw you.” Having been there, that’s exactly what’ll happen. Managers need some way to encourage those disciplines.

And what occurred to me one day is that what would the captain of a ship do? Now here you got a guy who the lives of the crew depend on the crew behaving well. But the crew are just a bunch of guys. And if the captain is walking around saying, “You are not swabbing the deck properly, I want you to use the three stroke method for swabbing the deck. Not the two stroke.” That’s not going to work. The captain can’t be at that level of detail. But the captain can say, “I expect the deck to be clean.” He doesn’t have to say how. It’s just, “I expect the deck to be clean.” So I started listing standards that could be expectations that managers communicate to programmers. And the first one is we will not ship shit. The deck will be clean. We will not ship shit.

Now this is something that most managers do not say to the programmers. The message coming from management most often is, “We will go fast and I don’t care if it’s shit.” The implication is that they don’t care if it’s shit. Now, they do care. All managers care. Everybody cares that the software be good. Managers may not understand what good software is, but they still want it to be good. All managers have the expectation that the software will behave properly, and that it can be modified properly, and it can be maintained easily, and it can change its requirements easily. Those are unsaid expectations that need to be said. So that’s the reason I started the standards part of the book with that particular standard. Bad code is below standard. We are not going to tolerate bad code. What a concept!

Henry Suryawirawan: There’s one thing also that the business stakeholders always ask, “When will we be able to release it?” So that goes hand in hand with go fast as well. But they never said, don’t take shortcuts. Don’t do bad job. But they always emphasize when are we going to release it, or do it as soon as possible. So thanks for reminding the standard.

Uncle Bob: There’s something that happens in that communication. Managers have to go fast. There’s got to be speed because it’s money. So the managers are going to focus on speed and that’s what you should expect. All programmers should expect that. What happens then is that there’s a funny communication that goes on. Because then the programmers, they feel like they’ve got to go faster. And so they start asking questions of the manager. “Well, is it okay if I refactor? Because I could probably go faster if I don’t refactor. Is it okay if I don’t write tests? Because we’d probably go faster if we didn’t write tests.” These are not valid questions to ask. This is like the doctor asking the patient, “Should I now cut you? Should I suit you this? Should I now take out this blood clot?” The doctor does not ask the patient in a step-by-step way what to do. Programmers should have in their minds what they are going to do. Yes. Managers are going to say, “We need this by April. We need this by April.” And then a negotiation of what will be delivered by April? Not how it will be delivered by April. “How” is something that’s the programmer’s job, not the manager’s job. “What” can be a negotiation. How many features will be available by April?

Henry Suryawirawan: I wish all the programmers who listened to this, by tomorrow you should not be asking your managers or your stakeholders, “Shall I do refactoring? Shall I write test?” So it should be part of your standard, actually.

Uncle Bob: Yes, absolutely.

[00:47:15] Standard: Always Be Ready

Henry Suryawirawan: The second standard that you mentioned, I think, which is worth to discuss about as well, is this thing called, “we will always be ready”. So maybe you can give some lights on why do you think this is a good standard to have?

Uncle Bob: So the discipline behind this is the Agile discipline. The overall Agile discipline, which says that you’re going to be ready every week or every two weeks, whatever your iteration size is. In most Agile methods nowadays, the iteration size is two weeks. I prefer one week. I think it would be better if we did a one week cycle. But okay, fine. Every two weeks, say, we are ready and what are we ready to do? We are ready to deploy. From a technical point of view, we are ready to deploy. The business may not be ready to deploy. There may not be enough features. Maybe we’ve got logout outworking, but we haven’t got login working. But from the point of view of the programmers, if the business wants to ship it with just logout, we’re perfectly happy to do that. Because we know it works, it’s tested, it’s documented, it’s ready to deploy. Every time around the Agile loop, whatever that loop size is two weeks, one week, whatever it is, every time around that agile loop, we are ready to deploy.

I worked with a group, and this was in the year 2000. These guys created a word processor for the legal community. Lawyers need their own kind of word processor. They can’t use Microsoft Word. They’ve got to have their own kind of word processor. So, this company made the legal word processor, and we taught them, the company I was heading at the time. We went out there and we taught them Agile. We taught them how to do this well. They got to the point where every week, the developers would burn a CD, back in the days when we had CDs, they would burn a CD and they would put that CD on the top of a shelf. And the stack of CDs, every week it just got bigger and bigger. The sales people would go out and do demonstrations for customers. Their policy became they would go to the developer’s room. They would take the top CD off the shelf and they would go out and they would do demos. That was the level of trust that the salespeople and the programmers had developed. The programmers were always ready on a week by week basis.

Henry Suryawirawan: So if people are familiar, these days we also call it Continuous Delivery practice. The Agile, Continuous Delivery, DevOps, all these are interrelated. So I think it’s very good standard to have in that Agile loop cycle. You’re always ready to deploy. Technically ready. But the business maybe able to say, okay, this is not the time to release. From the business point of view, maybe we can take some time before we can turn it on for business users to use it.

[00:50:00] Ethics: Do No Harm

Henry Suryawirawan: So we have one last point to discuss, which is about ethics, right? So we have discussed about disciplines. We have discussed about standards. The last point is about ethics. This is actually very interesting. Why programmers should think about ethics?

Uncle Bob: I modeled this part after the Hippocratic Oath. Long, long, long ago, right? The Greek Hippocrates came up with an oath for doctors, for medical. It’s a long involved oath that Hippocrates wrote. I thought, well, maybe there should be a similar kind of oath for software people, and this gets to the ethics. Ethics drive the standards, but the ethics are the core. You may come up with a different set of standards from the same set of ethics. You may come up with this different set of disciplines from the same set of standards, but the ethics remain. And so I think there’s 9 or 10 points that I put in there. That’s a suggestion to the industry at large. These are the things that I think are ethically important.

The first one, of course, is do no harm. That was Hippocrates’ first statement. Do no harm. The code you write should do no harm. It should do no harm to your customers. It should do no harm to your managers. It should do no harm to your business. It should do no harm to society at large. It should do no harm to your fellow programmers. It should do no harm to future programmers. The code you write should behave properly. It should be well-structured. It should not be harmful. Now, a lot of people will look at that and say, well, that would mean I should never write any code for a weapon system, and I will leave it up to you. Your own particular ethical mindset, whether or not weapons systems are harmful or beneficial to human society. You can make the argument both ways. You might also say that means I should never write software in a gambling application. And then once again, I will leave that up to you as to whether gambling is beneficial or harmful to society. Those are personal decisions. But the fundamental ethical structure below that is where I’m trying to push. Do no harm.

Now consider the programmers at Volkswagen, who wrote code intentionally to cheat the environmental protection agency in California. They literally wrote code that could detect if they were on an environmental test stand, and they would adjust the behavior of the engine to lower the emissions. And then once you were off the test stand, they would adjust the behavior of the engine again to emit more because they could generate more power. That was harmful. That was harmful code. Intentional harm. Some of those programmers are in jail now. Just keep that in mind. Programmers can go to jail if they write harmful code.

Here’s another one. Consider the programmers at Toyota, who wrote a very complex engine management system, which did not properly calculate the size of stacks. And so they made their stacks in an assembly language program. They made their stacks just a little too small. Every once in a very great while, one of those stacks would get blown. It would corrupt the process that was running in the engine management system. And the engine became unresponsive to the accelerator. The engine just started to accelerate out of control, the brakes wouldn’t function, and a number of people lost their lives. That was harmful code. It wasn’t intentionally harmful, but it was careless. The software developers who later on went in to testify in court about that code said things like there were hundreds and hundreds of global variables and there was a massive amount of spaghetti code. I won’t go into the deep details of it, but it’s a very fascinating study of unintentionally, but very harmful code. We will do no harm. The first of the ethics.

[00:53:56] Ethics: Estimate Honestly

Henry Suryawirawan: Which ties to the second point in the oath, which is we always do our best work. So even though the management pushes and all that, we should strive to always do our best work. There’s one point that I also want to ask your opinion, which I think every programmer here should hear, which is one point in the oath you mentioned about “estimate honestly and fairly”. This is always the contention point between programmers, stakeholders, product managers and all that. And I want you to give some advice for us programmers here. How should we do estimation properly?

Uncle Bob: So here’s the scenario. Let’s say that you’ve got some shoes on and maybe they’re tennis shoes that you can tie or untie. How long does it take you to tie your shoes? Probably you can tie your shoes in 10 seconds. Now I want you to estimate how long it will take you to write down the instructions so that a person who has never tied a shoe before can tie a shoe without being demonstrated, just the instructions. How long is it going to take you to write that? Well, that’s the fundamental problem with software. We are communicating with morons. These computers are morons. We have to write down instructions in such detail. Human beings have never had to deal with this kind of detail in the history of humanity before. But we are literally now dealing with details at the one big level.

Human beings, programmers have to estimate that. It’s hard to estimate that. So when a manager comes to you and says, “I need this by Tuesday.” You’re stuck with a real problem because you don’t know if you can get this done by Tuesday. You have no idea. Now, maybe you’ve done things like it. Maybe you got it done in two or three days. Maybe it’s like it, but you still don’t know. So when you are asked to estimate something, you must not give a specific time. Because that’s a lie. You don’t know that you’re going to get it done by a specific time. If you do give a specific time, you damn well better get it done. Because you’re making a promise. So you better get it done by then. There’s no excuse.

What you should do when asked for an estimate, is give a range. And the range should be pretty generous because you don’t know how long it’s going to take. So the responsibility is on you to define for the manager, the shape of your uncertainty. And you do that by maybe giving three estimates. The best case, the nominal case, and the worst case. And the best case should have a 5% chance of success. And the worst case should have a 95% chance of success. And the nominal case should have a 50% chance of success. Hand those three numbers to the manager and say, that’s the best I can do. And manager might say, well, I need a numbering. I can’t give you a number. Can I give you a number? I do not know. Hold to that as much as you can.

And then watch out for the little trick. Here’s the little trick. I need it by Tuesday. Well, I can’t tell you if it’s going to be by Tuesday. It might take me seven days. And then the manager will say, “Well, will you at least try to get it done by Tuesday?” The answer to that is no. Because I’m already trying. I, It’s not like I’m not trying already. And in your brain, little fireworks should be going off saying, how dare you accuse me of not trying. But you probably shouldn’t have those words come out of your mouth. But you should be saying we are already trying. We are already doing our best. I cannot give you a better number. I cannot promise anything, and we are already trying. If you say yes to that little trick. If you say yes, we’ll try. The manager will go away thinking that you just made a commitment.

Henry Suryawirawan: Thanks for sharing this watch out words, “Will you at least try?” So I think people who hear this episode by tomorrow, if their manager asking, try your best not to give a false commitment, even though you think it’s not possible. So that’s always the danger.

[00:57:50] 2 Tech Lead Wisdom

Henry Suryawirawan: So, Uncle Bob, it’s been a pleasant conversation. Thanks again for sharing all these insights. It’s also fun at the same time, right? So I’m really laughing as you mentioned and describe some of these things. Unfortunately, due to the time, we have to end this conversation. But before I let you go, normally I have this one last question that I always ask for all my guests, which is to share your version of three technical leadership wisdom for us to learn from you. What will be your three technical leadership wisdom, Uncle Bob?

Uncle Bob: First one. Programmers are not good at communicating with humans. Generally speaking, we didn’t get into this business because we liked people. So, learn to communicate with people. Learn how to confront managers. Learn how not to back away. Learn how to communicate well. Learn how to write. Learn how to write arguments. Learn how to write articles and documents. Learn how to make your case in a written form. That’s very important. Learn how to speak. Learn how to make your case known verbally. So all of those things are very important. And maybe the most important of all of them. Read like crazy. Read as much as you can. Read old stuff, get old stuff, old software books, read them. Get new software books, read them. Read like crazy. Pour information into your brain and then let the good stuff come back out.

Henry Suryawirawan: Thanks for sharing that. I’m sure all your books actually contain all the historical point of view as well. So sometimes you actually started the chapter by giving us, I don’t know, it’s random sometimes, right? It’s like from physics, from history, from the history of computers and all that. So thanks for sharing that. I think that’s also partly how we read old stuffs as well. So Uncle Bob, for people who would like to reach out for you and maybe learn some of your cool stuffs, where they can find you online?

Uncle Bob: Oh, Heavens. You can find me at the cleancoder.com. That’s my website. All one word, all lowercase cleancoder. My videos are at cleancoders.com, which is the same, except with an s at the end, cleancoders.com. My Twitter handle is UncleBobMartin. And that’s probably enough. You’ll probably see plenty of me that way.

Henry Suryawirawan: Thanks again, Uncle Bob, for your time. So thanks again for sharing all your insights.

Uncle Bob: My pleasure. It’s been a lot of fun.

– End –