Hey, a quick message. For those of you who are listening to this episode on Spotify. I have a small favor to ask Spotify. Now allows mobile users to rate podcasts. I would really appreciate it. If you can take a quick, pause to go to the technique Journal podcast page, and leave your favorite show. Your best rating on Spotify. It will help me a lot to get this podcast to reach more people on the platform. Thanks a lot. The simplest way to describe craftsmanship is pride of
workmanship. If Or 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 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 if you have to go home and take a shower and Are 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. Hey everyone. My name is Henry Surya with Robin.
And you're listening to the technology, you know, podcast the show where I'll be bringing you the greatest technical leaders practitioners and thought leaders in the industry to discuss about their Journey ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our Journal. Hello, to all of you, my friends and listen. - welcome to the technology.
Now, 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 hundredth 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 Our 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 technology, you know, 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 technology not deaf / Patron. Today, I am really, really excited to share my conversation with one of the great thought leaders in the surf industry. When I started my professional career. I used to read and watch a lot of his great work, such as clean coat, clean coder, and he's
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. Be sewed. 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 more widely known as Uncle, Bob he is the co-founder of clean code, s.com. And acclaim 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. Osman ship Uncle Bob then touch 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 shit. 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 tree is and Do 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, would continue to mature towards a better future, especially in the current ERA of software, eating the world. If you enjoyed 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 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 the conversation. Let's hear some words from our sponsor. Today's episode is proudly sponsored by skills matter. The global community and events platform. With more than 100,000 software professionals here members. Can organize their learning experiences around the technology topics.
They care about most you get on-demand access to their latest. Content thought leadership insights, as well as the exciting schedule of tech events running across all time zones. So whether devops our data science is your bus or you are fan of functional programming or all things Cloud. You can make real connections with people who share your interests head on over to skills method or Cam to become part of the tech community that matters
most to you. It's free to join and you will find it easy to keep up with the latest tech. Trends are you looking New cool swag pacolet Journal. Now offers you some swags that you can purchase online. These wax are printed on demand based on your preference and will be delivered safely to you all over the world. We're shipping is available. Check out all the cool swag is available by visiting technology. Know that death / shop and don't forget to break yourself.
Once you receive any of those tracks. Hello everyone, welcome back to another new episode of the package, you know, podcast today. I 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 blocks. And even your clean coders series, the videos. I watch her 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. 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, 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, little plastic computer and it's got a little readout with ones and zeros on it. There's three. B in here and they can go back and forth to 1 and 0. It looks pristine. 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 countdown or add to b, or subtract to B solve a number of logic puzzles. I was very fascinated by this machine at the age of 12. So I taught myself how to program which required that I learned Boolean, algebra and learn about State machines, learn about logic and that set me on the path to becoming a
program. So I started very early the year was 1964, could long time ago, my father noticed my interest and he somehow managed to get me books on Fortran and COBOL and pl1, the suite of languages that was popular at the time and I just Devoured those books. I've read them. And tried to understand that I wrote lots and lots of software that I could not execute, because they didn't have a machine, but I still wrote it in pencil on paper.
You know how when you're at a preteen or a teen Ager, you can really focus on something. 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-8, sand pdp-10 s just sitting there on the floor and 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 8 and make it executes. And we learned how to edit programs on paper tape. Using a teletype. There's an awful lot of that stuff that I was doing. I got my first job as a programmer probably at age 16. I mean that was a temporary summer job Road, 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
variance 620 gas. So you don't need to know all that, but gives you a background of where I came from very early on with very low level machines. Thanks for sharing your And actually, the toy that got you into all this. It's really fascinating. And you still have that toy, right? So 50 million years ago. So that is really a Monumental toy. I believe, I always like devouring your content into your
books or maybe your videos. You actually gave some history on 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. Sure. So, Uncle Bob, do you have written a number of books? But today we go. Gonna 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 other reasons that now, actually, you wrote this book 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, all together in a nice neat little bow. And then I started writing books, like clean code. And that was a difficult look for me to decide to write because who am I to tell anybody what clean code is? I'm just a 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 Of topics. I wanted to talk about once I published clean code. I wrote the clean color. It just kind of Spilled Out, right? All this stuff that was stuck in my brain. Just kind of Spilled Out that the clean coders all the none 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, your 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 Stimate, 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 a giant. 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 corrected 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 Edge. I'll Book as a way to just reset and describe what agile was of how we got there and why we got there. And where would you 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 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, ever 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, It 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 of end of the ethics to drive those standards. And that was the way I completed that book. So if I may add, that's actually one book that you miss, which is clean architecture. Oh, yeah, I forgot. Yes, so that book is also deeply Technical and it talks about clean architecture. Like ports adapters and that kind of stuff. So I think that's also what dimension.
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 with other profession, like maybe dr. Pilot lawyer and all that programmers seem do not have those kind 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 boot camp.
They just learn how to do those technical staffs, but not Necessarily the standards and all these ethics that make them the real profession. So tell us more about these problem 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 programmers job software? Use 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 professed. Those things we don't have that but it's just because we're a young discipline. We are very the first line of code that are 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. Let's just let that long ago to complicate that the need for programmers has accelerated. Did 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 F 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 in 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 with a lot of experience 20 or 30 years experience in the field. Barely exist as 20 or 30 years ago, door, hardly any programmers. So it's a fundamental problem of how do we mature an industry? That is 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 not 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 with the ethics that I talk about in the 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. Thanks for taking this President.
Thanks also for sharing this history to me. It's an Insight. So, I'm still consider young. I mean, my profession. I didn't know. I actually like 75 years ago when the first program. Is written and then up to now actually the number of developers keep 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. They are knowledge is not
spread. It's just like so many people turned out from University going to the engineering job. And that's why we are in this state of like what you say is Perpetual in experience where we try to learn from doing, right? Not necessarily from someone who has done it before, which brings us to the concept of crust. Worship. So, your title of the book is clean, craftsmanship, maybe in the beginning if we can clarify. What do you mean by this
craftsmanship? 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 not only did I write software that worked, but I wrote it well. And I wrote In a good way, the process I've followed was a good process.
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 mud. It feels like you're going fast. You're not 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 rush like a crazy person right now and 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, it is the mindset that you are working on something important and you are going to do it. Well, so I just want to add this phrase.
Just now you mentioned every programmers, when 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. So 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. The software craftsmanship, Manifesto. I was there when it was written.
In but I did not write it. It was other people who collaborated to put that message together, which I remember correctly. There's a website. So a preference if that order something like that. I can't remember. I was there at the time and I nodded sagely as everybody talk, but I didn't really contribute much. 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 that I think it's worth to mention all of the disciplines here. Baby, can you give an overview? What are the disciplines that you advocate in the book? 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 fast, right? And you get caught into a nice tight little Loop for you, right? A little test and it fails and you write a little code and you make it past and then you're a little more tests.
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 but 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 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 and test-driven development. So, I think that book is the first one to really attach those ideas. These Advanced ideas and 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 with that test-driven development and all The 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 talked 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 level and I draw very much from the work of Ken. Back and run 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 talked 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 because that person is always interrupting. You 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 co-author the code and Share knowledge and build code.
That is a collaborative effort. So I've talked a fair bit about that as the last of the disciplines. If you look carefully at those disciplines those for 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 a giant. 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, and then one more disciplined with his acceptance test, right?
So, which are the outer part of the Inner Circle, so maybe if you can give an overview of that as well, the acceptance test, this one 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 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 for Emily 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 in terrible, low level detail to the programmers and that's where we get into some real problems. Yeah. I think you've been said this very insightful state of the industry. Right? Where is always the programmers that wrote all this implementation of the specifications, There's No Business rules that actually the VA or the product. Are these days? There's no be a when some of the startups, this day is a product
manager or the Q&A. They don't actually write this specifications in the formal details, but actually just give maybe a dog of just firmly mention 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 if we can go into TD because most part of the book actually covers about these TD. And I think this concept although it has been And for many years, since can back 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 DVD including the laws that you have 40 d? So a test driven development. I describe 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 this 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 with it. 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 then we'll fail to compile, and they will fail the compiled within the Couple of lines, especially if you're using a statically typed language, like C, sharp or Java, or C++, or something like that. The third law says, you are not allowed to write more production, code than is sufficient that pass the currently failing test. And this locks you into a cycle.
That is 30 seconds long. So you write a line of pesto. No, it doesn't while you write a line in production code. Oh my God, that made, well, you go back test, your write another line of Tesco doesn't compile it. Write another line of production code that makes a compile your into the light of test, it compiles, but it fails and you write another line of production code that makes it past and you're stuck in this really tight Loop.
This is the first thing that programmers rebel against if they are 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 ever be able to write a while loop without interrupting myself. I'm not going to do that. That it's a difficult first step to get across.
I first saw this in the 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 old test first thing. I thought that was stupid. And then he and I sat down and we wrote a little Java applet. Took us about two hours, just a dumb little Java applet that simulated the fairy. Mother's magic one with little sparkles coming off. 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'd 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 That coat we never debugged anything. There was no debugging, we never
went into a debugger. You never put print statements in, we never did anything. We just went from tiny little test to tiny little test. The tiny little dust 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. Well, okay, it took me 20 years to get good at but turns out to put 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 can't made and that everybody made in the early days. 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 coded home of your
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. Don't know. A hackathon on a Saturday. Do it there. Do it at lunchtime. Do it in some scenario where there's nothing at stake. Your nothing big at stake and get good at it. Getting good at it is going to take you. I'm months, but once you're good at it, then you can bring it to work and it will pay on it is
the way I write code nowadays. Now, do I do customer development for every The 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, gooey 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 fiddled with it. You're still in the same loop. It's still a real fast loop,
right? But now you're not writing test. Now, you're looking at your eyes using your eyes to judge it. You worked very hard to pull all the Agents out of the gooey so that you can write the intelligent code with tests. And then the last little bit all that horrible CSS stuff from all the formatting and go. You have to do that by. That's the way I approach test-driven development. Wow. Thanks for sharing that
insightful story. So I didn't know that you actually paired with Ken back and figure out about this technique tdd. And that's what we learn from you as well in the clean code in CODIS videos. So thanks for sharing that story. So you mentioned about these three laws, which I think People associate a lot with this red green thing, right? You add the test per seat fail and you add the production code
make it run. But then there's this third piece, which is refactor and you ensure that tdd always work hand-in-hand with your Factor. They're like brothers and sisters, their work really well together. Maybe he 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, so refactoring is the practice of changing the structure of code without changing its Behavior. You cannot refactor in a new feature.
You cannot we factor out a bug, the behavior of the system remains constant. While you are adjusting the structure Kickback, 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. Fiddle with it's not working. Try something else.
It's like working for. Oh my god, it worked. Oh, okay. Nobody breathe, kept 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, oh, Okay. Now I need to make it right and
the making of it right? Is this idea of refactoring 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 psycho. Write a test. Make it pass, write a test. Make it fast, right? It says they could pass and then we try.
Tossing the refactoring on top of that by saying, okay, write a test, make it past, clean it up. Write a test, make it as 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, test, test, test test test as best. I will get something relatively significant working. And by that, I mean 50 lines of got 50, 60 lines of code,
something like that. And that's That's what I stopped. 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. 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 and move that over there. This name has to change. Oh my goodness, this functions,
too big. I need to split it in half and I spend a relatively significant amount of time. Structuring 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 change 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.
Wow. Thanks for sharing again, your insides, how you normally do this that he D PSI. 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 a 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 stopped 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. But us. Correct. You do not want refactoring to be on the schedule.
You don't want to have a bar on the schedule seeing 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 of it's okay. If you wash your hands, don't have time to watch my hands, or should I just go back and cook them? 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. 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. And if you are writing tests and you're writing code to go along with 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 Be practical. So I usually just do the first two wind coverage and decision.
How much of the code should be covered. Is there some number? And most of the tools will give you a number, they will 0 92 percent of your coming 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 percent and reject that I think will know. I mean, the number should be 100%, or is close to 100% as you can get it. Maybe you can't get all the way to 100% because there's some
lines of code. You can't cover for some reason but the number should be very high in the high 90s 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 you are 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 non technical managers for 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 Manager, so when happen is that those managers will say, well, we should measure this and we should fail the bill 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 covers. Otherwise the build fails. Well, you can't have them. Build fail for god sakes. You can't ship, you can't deploy of the build fails. Therefore the build must pass and the way you make the bill passes. You take all the assertions out of your tests. Yeah. 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 program.
It's programmers, can look at it and understand what it means. Very bad idea to export that outside of the programmer Community into the management. So for those of you who listen, try to aim as high as possible, 100%, I know it's really difficult sometimes to achieve 100% But at least you try your best. Aim at the higher 90, the three other disciplines, I think people should refer to the book. 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 staff. 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, 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 parent program, you will do. Test-driven development. You will RE Factor 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 Castro development. Screw. You having been there? That's exactly. What'll happen managers need some way to encourage those discipline. And what occurred to me one day. Is that what would the captain
of a ship? Now here you got a guy who the wives of the croup 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 Muppet to swim. That's not going to work. Captain can't be at that level of detail, but the captain can say I expect the deck to doesn't it. Say how you say?
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 lock 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 We'll 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 would manage. MERS 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 Diesel and it can change its requirements. Kiesel those Unscented expectations that need to be set. 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, couple what a concept that'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 realize it or do it as soon as possible? So thanks for reminding the
standard. There's something that happens in that communication managers have to go fast. There's got to be speed because it's month. 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. There's in 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 with probably go faster, if we didn't write test. These are not valid questions to ask. This is like the doctor asking. The patient. Should I now cut, you should I shoot 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 programmers job, not the manager's job. What can be a negotiation? How many features will be available by a? I wish all the programmers who Into this by tomorrow, you should not be asking your managers or your stakeholders. Shall I do refactoring or shall
I write tests? So it should be part of your standard actually. Yes. Absolutely. 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 can give some lights on. Why do you think this is a good standard to have?
So the discipline behind this is the agile discipline, the overall edge of discipline, which says that, You're going to be ready every week, or every two weeks, whatever your iteration size, it the in most agile, methods, nowadays. The iteration size is 26. I prefer one week. I think it would be better if we did it 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. Or maybe we've got log out working, but we haven't got login one. But from the point of view of the programmers, if the business wants to ship it with just log out, 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 Your 2000 these guys, created a word processor for the legal Community, lawyers need their own kind of weird process. 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 a stack of CDs every week. Just that bigger and bigger. The sales people would go out and do demonstrations for customers. Their policy became, they would
go to the developers room. They would take the top CD off the shelf and they would go out and they would give demos that was the level of trust that the salespeople and the programmers had developed. The programmers were always ready on a week. Weak bases. So if people are familiar with these days, we also call it continuous delivery, practice The age-old Continuous delivery, devops. All, these are interrelated. So I think it's very good standard to have in that Asia
Loop cycle. You always ready to deploy technically ready, but the business may be 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. So, we have one last point to discuss, which is about ethics, right? So, we have discussed about the Disciplines, we have discussed about standards. The last point is about ethics. This is actually very
interesting. Why programmers should think about ethics remodeled this part after the Hippocratic Oath long, long, long ago, right? The Greek Epocrates came up with an oath for doctors from medical. It's a long involved though. That Hippocrates wrote, I thought. Well, maybe there should be a similar kind of of for software people and this gets to the ethics. Sex 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 a different set of disciplines from the same set of Standards, but the ethics remain and so I think there's nine or ten 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 Epocrates. First statement Do no harm The code. You write should do know her. You 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 weapon systems are harmful or beneficial to Human Society. You can make the argument both ways. You might also say, 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 intentional, you cheat. The Environmental Protection, Agency in California. They literally wrote code that could detect if they were running environmental tests and, and they would adjust the behavior of the engine to lower
the emissions. And then once you are off the test, and they would have just the behavior of the ends again, to emit more because they could generate more power. That was harmful. That was harmful coat intentional art. Some of those programmers are in jail. Now, just keep that in mind. Programmers can go to jail. If they pry Farmville 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 A very great while one of those Stacks will get blown. It would corrupt a 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 coat. 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, Almost like their work, hundreds and hundreds of global variables. And there was a massive amount of spaghetti code.
I won't go into the details of it, but it's a very fascinating study of unintentionally, but very harmful code. We will do know her. The first of the ethics, 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 As do our best work, that's one point that I also want to ask your opinion, which I think every programmers here should here, which is one
point in the oath. You mentioned about estimate honestly and fairly. This is always the contention point between programmers. They call this product managers and all that, and I want you to give some advice for us programmers here. How should we do a summation properly? So, here's the scenario. Let's say that you've got some shoes on and maybe their 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 died of shoe before can tie your shoes without being demonstrated, just the instructions. It's going to take you to write that. Well, that's the fundamental problem with software. We are communicating with more on these computers are morons. We have to write down the instructions inside.
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 at the 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.
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. Do you better get it done by then? There's no excuse what you should do. When asked for an estimate.
It's 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 uncertain. And you do that by maybe giving three estimates the best case, the nominal cased in the worst case and the best case should have a 5% chance of success. And the worst case you 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 number. I can't give you cannot 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 a little trick. I need it by Tuesday. I can't tell you if it's going to be by Tuesday, might take me seven binney's 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, 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. Thanks for sharing this watch out words. Will you at least try? So I think people will hear this episode by tomorrow. If their manager asking, try your best not to, you know, give a false commitment even though you think it's not possible. So that's always the danger. So Uncle, Bob is 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 Normally, I have this one last question that I always ask for all my guests, which is to share your vision of three technical leadership wisdom for us to learn from you.
What will be your three technical leadership, wisdom and Kebab. First one programmers are not good at communicating with humans. Generally speaking. We didn't get into this business because we like people so learning 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't read old stuff, get old stuff, old software books, read them get new software books. Read them read like crazy, poor information into your brain and then let the good stuff. Come back out. Thanks for sharing that.
I'm sure all your books actually contains all the historical point of view as well. So sometimes you actually started a chapter by giving us. I don't know, it's random. Sometimes writes like room 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 all stops 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.
Oh heavens. You can find me at the clean coder.com. That's my website. All one word. All lowercase clean coder. My videos are at clean coders.com, which is the same except for the Tessa p.m. Think ogres.com. My Twitter handle is Uncle Bob Martin, and that's probably enough. You'll probably see plenty of me that way. Thanks again, Uncle Bob for your time. So, thanks again for sharing all your insights. My pleasure.
It's been a lot of fun. Thank you for listening to this episode and for staying, right until the end if you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode. And if you are new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to
grow this podcast better. You can also find the full show notes of this conversation on the episode page, at Tech, Legion of death website, including the full transcript interesting. Quartz and links to the resources mention from the conversation. And lastly, make sure to subscribe to the shows mailing list on pack leader. No dot f to get notified for any future episodes. Stay tuned for the next technology. No episode. And until then. Goodbye.