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.