This video explores the concept of "clean code," discussing its origins and what it truly means. The speakers delve into different interpretations, from Robert C. Martin's book to Kent Beck's "tidy first" and Richard Gabriel's "habitability," which focuses on the developer's experience with the codebase. They argue that clean code isn't a fixed set of rules but rather a relational concept that depends on context and aims to make code comfortable and confident to change, ultimately leading to joyful and efficient software development.
Key Takeaways
1
The term "clean code" has several origins, including Robert C. Martin's 2008 book, Kent Beck's "tidy first" series, and Richard Gabriel's earlier concept of "habitability."
2
Habitable code is characterized by being comfortable to navigate and confident to change, focusing on the developer's experience rather than just static code properties.
3
There's a distinction between "Clean Code" (the specific, sometimes dogmatic practices associated with Robert C. Martin's book) and "clean code" as a general, suggestive description of good code hygiene.
4
The metaphor of hygiene, like in a professional kitchen, suggests that clean code involves many small, continuous habits to keep the codebase maintainable and safe.
5
Some advice from early "clean code" discussions, like having good names and boundaries, remains relevant, while other advice, such as excessive code fragmentation, has become less applicable due to changes in development practices (e.g., full-stack developers).
6
The effectiveness of code organization, like breaking code into smaller pieces, should be judged by how much mental effort it requires to understand and change, rather than arbitrary line counts.
7
Fragmentation of code can be as problematic as overly large, monolithic functions, as both extremes hinder comprehensibility and mental model construction.
8
A concept called "locality of behavior" (LoB) suggests grouping all related elements for a single goal, such as a report field, instead of separating them by technical layers.
9
Inspired by the Theory of Constraints, the cleanliness of code should be a function of what you're trying to achieve with it; over-cleaning can be an opportunity cost, while insufficient cleanliness can be a bottleneck.
10
Ultimately, "cleanliness" in code is not a fixed myth but a relational and contextual concept, judged by whether it facilitates efficient, joyful, and sustainable software development.
No matching segments found
0:00
Welcome to the modern software
0:02
engineering channel and to one big
0:04
question. If you like this, give us a
0:06
like and if you want more of stuff like
0:08
this, um, be sure to subscribe to the
0:10
channel. My name is Kevin Henny and I'm
0:12
here with Daniel Turos North and we are
0:14
going to answer one big question. And
0:15
the one big question we're going to
0:17
explore today. And by the way, let's be
0:19
clear, we're not going to give you a
0:20
simple answer. We're going to explore
0:22
the question. The question here is, is
0:24
clean code a myth that we tell
0:26
ourselves? Daniel, where do we start on
0:29
this one? Where do we start? Well,
0:31
always with terms. Um, so clean code
0:33
itself, I'm going to start by by being
0:35
you or at least by channeling you. You
0:37
wrote no, you wrote a delightful post
0:39
recently exploring the origins of uh the
0:42
term clean code. And I need to say for
0:45
folks that don't know Kevin, he does
0:47
this really well um in his talks, in his
0:49
writing, is I some people call him the
0:51
history guy. I describe him as the
0:52
context guy that when when something is
0:55
happening in in the software world, in
0:57
the technical world, there's an awful
0:59
lot of standing on the shoulders of
1:00
giants. I think a lot of that goes
1:02
unagnowledged, sometimes deliberately,
1:04
but mostly accidentally. And one of the
1:06
things that Kevin does really well is
1:08
surfaces, well, well, hang on, that's a
1:10
reference to this 1973 paper that that
1:12
three people have ever read, and I'm the
1:14
fourth one. So for me there's I I I have
1:17
kind of three three uh vectors if you
1:20
like three sources for clean code.
1:22
There's probably the one most people
1:23
will be familiar with is Robert C.
1:26
Martin's book clean code from the I
1:28
think early 2000s thereabouts 20
1:30
something years
1:31
>> 2008
1:32
>> 2008
1:32
>> 2008 wow later than I thought. Okay so
1:34
from the late NS then much more recently
1:38
Kent Beck has been writing uh a
1:40
wonderful series that he's calling tidy
1:42
tidy first. Um, part of that I suspect
1:46
is is to differentiate from from clean
1:48
as a term uh and not to muddy the waters
1:51
any further. But then for me, and again
1:53
this is so a lot of my I'm not going to
1:56
lie, a lot of my software thinking has
1:57
been informed by Kevin over over decades
1:59
is uh Richard Gabriel, Dick Gabriel, who
2:02
wrote a series of articles he published
2:05
as a book um that that that Kevin got me
2:08
on to. And Dick Gabriel des uses this
2:11
term habitability and he talks about
2:13
habitable code and habitable code has
2:16
two characteristics. Uh one is
2:19
comfortable. So you are comfortable
2:21
moving around in it. So as opposed to
2:23
uncomfortable, scared, nervous,
2:25
whatever. And the other characteristic
2:27
is confident. You're confident to make a
2:29
change. And if you're comfortable
2:31
navigating code and confident to make a
2:33
change in code, I'm like that's that's a
2:34
good place to be. And in fact that that
2:36
was my launching point for Cupid which
2:38
was my my attempt at joyful code a few
2:41
years back was was okay so Martin Fowler
2:43
talks about people should be able to
2:45
people should write code that that
2:46
humans can understand. I'm like
2:48
understandable is good habitable is
2:49
better. Can we get to joyful? So I I
2:51
have these sort of three axes of clean.
2:53
There's there's the the Bob Martin's uh
2:56
patterns and book. There's Kent's kind
2:59
of more recent riff of tidy. And then
3:02
predating all of those by some time is
3:04
Dick Gabriel talking about habitability.
3:06
>> Yeah, that's in fact I think the really
3:08
interesting thing there's a number of
3:09
things you teased apart there. Um uh one
3:11
of which is Thank you. Uh the other of
3:13
which is I didn't have the Dick Gabriel
3:14
book to hand and I've just retidied my
3:17
office so I have no idea where that book
3:19
is at this point. I can't reach it
3:21
easily. But that book is is interesting
3:23
and I think the idea with habitability
3:25
that I uh like so much is that it
3:28
describes an experience. It's actually
3:30
more to do with the relationship between
3:32
the developer uh and the codebase and
3:34
the ecosystem than it is necessarily of
3:37
the distinct practices within the code.
3:39
That's not to say they're not important,
3:40
but it it sort of tells you where you
3:42
want to evaluate it. And it's not
3:44
necessarily in the code. It's within and
3:46
around the relationships to the code.
3:48
And habitability I love as a metaphor
3:50
because it it invites you to think of
3:52
architecture as a place where you know
3:54
people live, which funny enough is
3:55
actually the original point of
3:57
architecture. uh what is the experience
3:59
of being here and I think we forget that
4:01
as well. But I think also the idea of
4:04
moving from just static properties of
4:06
the code to the experience and exactly
4:07
as you say cupid joyfulness I think is a
4:10
really interesting way of of exploring
4:12
that and it goes clearly beyond um an
4:15
idea of cleanliness and it kind of
4:16
almost invites this kind of idea of the
4:18
metaphor. um when we're talking about
4:20
these things that are abstract, we're
4:22
always looking for something that gives
4:23
us a new insight or the vocabulary to
4:25
talk about things because code is remark
4:27
well code and software is remarkably
4:29
non-physical. And I think there's
4:31
another distinction that you brought up
4:33
that I thought was really good when we
4:34
were talking about clean code before in
4:36
a chat was there is a kind of a
4:38
difference between clean code capital C
4:41
capital C TM um which we might associate
4:45
um with uh Robert Martin and some of the
4:47
the practices that associated with that
4:50
kind of view um of Kodi and sometimes
4:52
people feel and have reacted to I've
4:54
noticed in the public space that there's
4:56
a little there's a little bit dogmatic
4:57
perhaps and that that's a lot of people
5:00
reacting against that, which is
5:01
understandable. They're not necessarily
5:02
reacting directly to the guidelines or
5:05
perhaps the intentions that other people
5:07
have, but very much the the apparent
5:09
dogma, which nobody likes that. Um, and
5:12
then clean code just as a general
5:13
description. And this was um an
5:15
interesting thing going going through
5:16
the the history of this and a recent
5:18
discussion triggered this and caused me
5:20
to go back and say, well, where where
5:23
has this term come from? because uh
5:25
there was this impression for a number
5:27
of people and number of trend they they
5:30
have this kind of point of origin. Oh
5:31
yeah, Clinko it was invented by Robert
5:33
Martin and often there is a sense that
5:35
it was further back than it was which by
5:37
the way for anybody watching is the
5:39
opposite of what happens with music.
5:41
Whenever anybody says can you remember
5:42
this track you always get it wrong by
5:44
thinking it's more recent. It turns out
5:45
for some of these things we get them
5:47
wrong the other way. And I and I one of
5:49
the things that I found is that I was
5:51
pointing out no no this term was already
5:52
in the air before it got it were
5:54
[clears throat] captured and nailed
5:56
down. It was already it wasn't it was
5:58
suggestive. It was just it wasn't a when
6:00
I say clean code I mean all of these
6:02
practices. It was just a it was slightly
6:04
better. It was trying to um associate uh
6:08
for example with the idea that
6:09
refactoring is a form of hygiene. And
6:11
that's a refactoring. The hygiene
6:13
metaphor that um Martin Fowler often
6:15
uses that idea of um it's the idea of
6:19
you you brush your teeth and you shower
6:21
on a regular basis. You don't save it up
6:23
for once a year, you know, um and then
6:25
go and see your friends um because you
6:27
won't have any friends by then.
6:29
>> This is this is a kind of like a daily
6:31
and continuous practice. It's not a
6:33
>> I've got to say this is an uncomfortable
6:34
way to learn this about myself, but
6:36
there we go. [laughter]
6:38
>> Like we said, one big question, lots of
6:39
knowledge. Um, so this is the
6:42
interesting thing is I I found that with
6:43
with my training in TDD, I I quote, so
6:46
let's go back to Kent and I quote the
6:48
beginning of this book from Kent,
6:49
test-driven development by example and
6:52
um and this book was published in 2003.
6:54
So that is um that is a generation ago.
6:57
But the interesting thing is right there
6:58
in the beginning, the opening um
7:00
sentence is in fact the opening words
7:02
clean code. Clean code that works in Ron
7:04
Jeffy's pathy phrase is the goal of
7:06
test-driven development. And then he
7:08
describes why it's a worthwhile go and
7:10
worthwhile goal and enumerates the
7:12
qualities and the again funny enough the
7:14
experience but he also clarifies he got
7:17
the he talks about it from Ron Jeffy's
7:18
point of view and he also clarifies
7:21
something that often people sort of say
7:22
yeah your code's clean but it doesn't
7:23
work he said well the phrasing is clean
7:25
code that works you know that so he is
7:28
talking about it from an experiential
7:30
but also a much more complete
7:32
perspective I then found that given I
7:34
mentioned Martin the original version of
7:36
refractory Martin uses the terminology
7:38
clean code extens ensively. So I think
7:41
what okay this takes us back to the
7:43
1990s you know it's just like this is
7:45
we're in the 1990s and I started
7:46
thinking again Kent's work a lot of his
7:49
work was about was about this kind
7:52
vocabulary has changed at various times
7:53
but I thought you know I think it was in
7:55
the air before that so I did a bit of
7:56
digging around and here is my copy of
7:59
the elements of programming style um
8:01
this published in the 1970s um okay so
8:04
this is I actually learned from this
8:06
this is a second edition late '7s uh
8:08
kerning and plan
8:08
>> that's a cardboard mockup isn't That's
8:10
not a real book.
8:11
>> Damn. [clears throat] Rumbled. Um uh
8:13
people, this just as a point, this book
8:15
is really slim because people did not
8:17
get into the slightly cynical game back
8:19
then of publishing books with thick
8:21
paper so that they took up more um space
8:23
in the bookshelf and there there are
8:25
publishers that really specialize in
8:26
this. So this is um it's 130 odd pages.
8:30
Yeah, it's about 130 or so pages. And I
8:32
learned an immense amount from this
8:34
book. It was written in the late '7s.
8:35
The original and this is the thing. I
8:37
found the first edition 1974 clean code
8:40
and they use the phrasing clean code.
8:42
They use clean as a verb. They also use
8:45
they use clean code as a noun phrase and
8:48
it's there and again they're not saying
8:49
this is clean code and here enumerating
8:51
a set of practices. They're just using
8:53
as a suggested metaphor rather than just
8:55
something bland like good or also moral
8:58
in that sense. And I think that's really
9:00
important because I think that a lot of
9:01
people have come to think of clinko.
9:03
They either gravitate towards the phrase
9:06
um and therefore the branding or they
9:08
are repelled by it. Exactly. They are
9:09
they are either drawn to it or repelled
9:11
by it or
9:11
>> they have an opinion. Yeah.
9:12
>> Yeah. They have an opinion. And the
9:14
problem is I I don't think we really
9:15
want to that's really not the original
9:17
goal. I mean I can you know you read
9:18
these things and they kind Yeah. I'm
9:19
with you. I'm with you all all the way.
9:21
And so that kind of gets us to this
9:23
interesting question that perhaps we
9:24
need to distinguish when we're talking
9:25
about clean code. Are we talking about a
9:28
particular set of practices and opinions
9:30
or is it suggestive and connects to
9:32
something bigger? as you say things like
9:34
habitability or that question that very
9:36
simple question um we are ultimately
9:38
human does this bring me joy you know
9:39
when I work in this code base um when I
9:42
work with these people when I work in
9:44
this arc is that bringing me joy um or
9:46
am I constantly frustrated um and so
9:48
therefore it's a very human thing rather
9:50
than merely something co it's like clean
9:52
code is the start of the conversation
9:54
but not the end
9:55
>> well and this this is what I want to
9:56
pick up on because you know you don't
9:58
have clean code for the sake of you have
10:00
clean code in order to and So I I see
10:03
this very much as relational. It's
10:04
relationship between the programmer and
10:06
the code. And I I I've heard the the
10:09
term hygiene a lot. I think of hygiene
10:12
when folks like Martin use the word
10:14
hygiene. I think of it less in the sense
10:16
of personal hygiene and more in the
10:18
sense of hygiene of a kitchen. So
10:20
hygiene of a place in which you want to
10:23
do something where cleanliness is an
10:26
important part of doing the thing. So a
10:29
uh surgical an operating theater or a
10:31
kitchen or something. And when you look
10:34
at the way a high performing kitchen
10:36
works like a professional kitchen,
10:38
restaurant kitchen, then what you see is
10:41
many many many small habits repeated
10:43
again and again and drilled into people,
10:46
right? You wash up as you go. You put
10:48
things away as you go. You don't put the
10:50
cooked meat next to the raw meat. They
10:52
they live in different in different
10:53
fridges, different containers. And so
10:55
there are certain rules that have grown
10:57
up around this not because we like rules
10:59
but because they keep us safe. And if I
11:01
think of code hygiene is not and this is
11:04
where you get into the why I tend to
11:06
push back on the the more dogmatic kind
11:08
of you have to have this many lines in a
11:10
function or you know the the the the
11:12
separation of concerns that everyone
11:13
gets wrong. I'll come back to that. I've
11:15
got a good rant about that.
11:16
>> Oh yeah, I'm with you on that one. I
11:18
will co-rant.
11:18
>> Right. Right. But the the uh the idea
11:21
that we want clean in order to hygienic
11:23
in order to and it's a relationship
11:24
between people and code. Um and that
11:26
brings me to a lot of the specific
11:30
advice in the clean code book. You know,
11:33
we talk about things aging like milk or
11:35
aging like fine wine, right? And a lot
11:38
of the advice that interestingly because
11:40
I I read I read clean code. I had never
11:43
read it. Dave Farley has a has has
11:45
something I think it's just come out on
11:46
the on the modern software engineering
11:47
channel where he's comparing uh Bob
11:50
Martin's take on clean code with his
11:52
take on modern software engineering and
11:53
how they they compare and contrast and I
11:55
think he's done a very evenhanded job I
11:58
must say I think he's been um very very
12:00
fair and what I find in in so I I one of
12:04
the things he says is it's never really
12:05
impacted him one way or the other. He's
12:06
he's he's kind of lived his he's lived
12:08
professional life independent of this
12:09
book but he decided to go and look at it
12:11
and I did the same a few years ago. I I
12:13
took it on holiday and I read it and I'd
12:14
never read it and oh my word my Kindle
12:17
has many many notes from reading this
12:20
book and most of them are what or no or
12:24
things like that and some of them so I'm
12:27
going to name names there's so it's an
12:30
anthology book so a lot of the chapters
12:31
he wrote himself a number of the
12:33
chapters are invited uh James Greing uh
12:35
c embedded systems guy uh wrote a
12:38
chapter on boundaries and my Kindle
12:40
notes say an oasis of clar clarity in a
12:43
sea of I won't say what the rest of the
12:45
sentence is but basically it's a
12:47
beautifully written little paper about
12:51
identifying boundaries I mean you could
12:53
derive the whole of domain driven design
12:55
from first principles from this chapter
12:57
it's gorgeous Tim Oinger again
12:59
contributed a chapter on naming and
13:01
naming things is hard one of the three
13:03
great problems and again it's
13:04
beautifully written very actionable
13:07
really good advice and so in this book
13:09
is some really good stuff some stuff
13:11
that stood the test of time in it. Also
13:13
is some shocking advice. And my kind of
13:16
analytical brain kind of started chewing
13:18
on this like why why would this be? And
13:20
there's uh I'm I'm I'm a Christian. I
13:22
spent a lot of time uh poking around in
13:24
the Bible. And there's a there's a way
13:26
of studying uh ancient texts uh called
13:29
hermeneutics. And there's another word
13:32
as well. I'll just escape in a minute.
13:34
But um hermeneutics is where you say,
13:36
okay, what was true at the time that
13:40
this thing was written? what was the
13:41
context of this thing at the time and
13:43
exugesus that's the other part and then
13:45
if I were then to extrapolate that to
13:47
now what would it be so Jesus tells
13:49
loads of parables about fishing right
13:51
he's a big he's got a lot of stories
13:52
about fishing yeah uh why because that
13:55
was one of the main industries most of
13:56
the people he was talking to either were
13:58
fishermen knew fishermen had fishermen
14:00
in the family it was fishing was a big
14:02
deal they were on the Sea of Galilee and
14:03
okay what might you compare if he was
14:06
telling those stories now what might
14:07
they be they could be I don't know
14:09
office type work or whatever would be
14:11
reasonable. And so I'm looking at this
14:13
um I'm looking at clean code. I'm
14:15
thinking, okay, so what is true? So what
14:17
would need to be true? Such the advice
14:19
that you take this code and break it
14:21
into lots of small pieces. Break it and
14:23
it's it's not it's it's it's more it
14:25
feels to me more extreme than coupling
14:27
and cohesion and separation and all
14:29
that. It feels more more militant than
14:31
that. And if you if you play back to
14:34
like the late '9s, early 2000s when all
14:36
of this stuff was happening, you would
14:38
have requirements coming into a team and
14:40
the requirement might be okay, we need
14:42
to um put put some new content on this
14:45
report. So Kevlin, you're doing the uh
14:48
health reporting subsystem and we need
14:51
to put a new piece of information in
14:52
this report. We need to add some more
14:54
details about the doctor and we go,
14:55
okay, right, what work needs to happen?
14:57
Well, there's some UI work. We need to
14:59
add some fields in the user interface.
15:01
We need to make some database changes.
15:02
We probably need to populate that
15:03
database with some default values. We
15:05
need to uh make some uh change to some
15:08
of the service stuff. The rendering
15:10
logic needs. So I ended up with this big
15:11
pile of work. Right? Now in the '90s
15:14
that work would have been farmed out to
15:16
different teams, right? And they might
15:18
not even have been in the same building.
15:20
So so a requirement would not have been
15:22
add this field to this report. It would
15:23
have been make this database change,
15:25
make this service change, make this UI
15:27
change, make this uh rendering change.
15:30
And what you don't want is the people
15:31
who are doing that ideally fairly close
15:33
to each other in time trumping all over
15:35
each other's code changes. And so but
15:37
the way you do that is admin, right? You
15:39
you move the code into different places
15:41
so they're less likely to crash into
15:42
each other. Now you play that forward 5
15:44
10 25 years. And you now have Kevlin.
15:49
Kevlin is Mr. Full Stack, right? And
15:52
Kevin gets the requirement to change the
15:55
to add the field to the form and he goes
15:57
in and changes the UI, changes the
15:59
database, changes the schema, writes an
16:01
automated um SK database migration to to
16:04
move that forward, writes the test, does
16:06
so so now the one person or the one team
16:10
is going to do all of that work. It
16:11
doesn't get split out anymore, right? It
16:13
doesn't get split out and and farmed out
16:14
anymore. So, so what do we have now with
16:17
all that code all scattered around the
16:18
place? What we have now is a is an
16:20
administrative problem, right? Is I've
16:22
made it more work, right? If all of that
16:25
stuff if all of the stuff about the
16:27
reporting form fields was in the same
16:30
bunch of code in the same bunch of
16:32
areas, then I I can navigate that really
16:35
easily and really quickly. Again, making
16:37
it so technical, making it about humans
16:39
and code. What how should we structure
16:41
the code that makes it easiest to make
16:43
sense of, to navigate, to change
16:46
comfortably and confidently? How do we
16:48
make the code habitable?
16:49
>> And it turns out breaking it into 30
16:51
different places is not is no longer the
16:54
answer. But if we project that forward,
16:57
having good names is still the answer.
17:00
Having good boundaries is still the
17:01
answer. So some parts of that have aged
17:04
like wine. Some parts of it have aged in
17:07
the same way that they're relevant in a
17:09
different era.
17:10
>> Yeah. I I pick I I'm going to pick up on
17:12
on a couple of points you mentioned that
17:13
the point about James Granning. He has a
17:15
he wrote lovely book on uh test-driven
17:18
development um for embedded C. Um and
17:21
there's a couple of things I really like
17:22
about that book. One is
17:23
>> which is a brave thing to try let alone
17:26
write a book about.
17:27
>> Exactly. First of all that's sometimes
17:29
when I'm talking about TDD for people
17:31
mad props to the man. People say oh we
17:33
can't do this in
17:34
>> and he's a lovely human being as well. I
17:36
mean he's genuinely lovely human being
17:38
>> and but he also but there's a point in
17:40
that book I sometimes there's a couple
17:41
of paragraphs I quote that capture the
17:44
flow and he also talks about a
17:45
joyfulness uh as well there's a there's
17:48
a paragraph where I think he calls it
17:49
the physics of DDD and there's a there's
17:51
a kind of a simple paragraph where in
17:53
that paragraph you have everything you
17:54
ever wanted to know about what you want
17:56
from a workflow but it starts with fun
17:59
and then then we go into the technical
18:00
aspects and we talk and he manages to
18:03
it's a really nice so very quotable and
18:05
I use it But so I use that but I also
18:07
the book as an existence proof. If
18:08
somebody says oh we can't do this in our
18:10
environment I say is your environment
18:12
more or less extreme than embedded sea
18:14
because if it's less then I think you
18:15
probably can cuz here's a whole book on
18:17
how to do it in this hard hard
18:19
environment. So there's that but that
18:21
point very much about finding boundaries
18:24
for and you hit on something I think
18:25
that's really important that it's often
18:27
about boundaries and there's also
18:29
acknowledgement. You talked about the
18:30
standing on shoulders. Um the I
18:32
mentioned you mentioned the tidy first
18:33
book. Kent in the intro to tidy first
18:36
talks about kind of the story about how
18:38
he got here and he refers to guess what
18:40
I've also got this book cuz just just
18:43
for folks I was not developing software
18:44
in the 1970s. I just like old books.
18:46
Okay. I just dig around. So this one
18:49
structured design from Yordan and
18:50
Constantine and Kent refers to this and
18:53
he talks about it and the the the
18:55
origins and how it made him think and
18:57
how he responds. And again these books
18:59
and I do quote from this in a couple of
19:01
other books where they are talking very
19:03
much uh they don't use the term
19:04
habitability but they are very much
19:06
talking about modularity as a kind of
19:08
human experience about understanding and
19:11
readability they they're relating it to
19:13
us and that's a really important idea.
19:15
So our boundaries and going back to
19:17
naming boundaries are important in
19:18
naming so that we can it helps us group
19:21
these ideas. In other words, these are
19:22
there to facilitate your thinking and
19:25
how you construct a mental model. When
19:26
you are reading the code, code is one of
19:29
the weirdest things we have as humans
19:30
do. We're literally trying to take an
19:32
idea from one head and transplant it in
19:34
another. And it's not just it's not just
19:36
suggestive. It's got to be precise as
19:38
well. So, we're trying to pursue these
19:41
many almost contradictory um goals. But
19:44
the thing I like about that point of
19:46
view is that we we do have the I you
19:48
sort of described it from a point of
19:49
view of the time, but I'm going to
19:51
remember back to the 90s and 2000s and
19:53
go, "Yeah, people weren't even doing
19:54
that." Or was that even the right
19:56
response then? And so the the problem
19:59
that we are we recognize and we
20:00
recognize now is like, "Yeah, legacy
20:02
code, one of the characteristics is big,
20:04
long messy methods and and all the rest
20:07
of it." And that's a bit like saying,
20:08
"Oh, this is really big. The problem is
20:10
the bigness." Yes, we solve it by
20:12
breaking everything into small pieces.
20:14
Not necessarily. What you want to do is
20:17
do something that causes small pieces
20:19
rather than aim for small pieces. If
20:21
that makes sense.
20:22
>> Yes. Yes. Yes.
20:22
>> In other words, the Yeah.
20:24
[clears throat] And it's actually
20:24
something I said to somebody a few years
20:26
ago.
20:26
>> Sorry. Can I just sort of jump in there?
20:28
It's really important is small is about
20:31
how much thinking you have to do, not
20:34
about how much code there is.
20:36
>> Yes. So small is about now there's a
20:39
term that has become massively overused.
20:42
Let's talk about Pearl. Oh no, let's not
20:44
talk about Pearl.
20:45
>> I I've I've written production systems
20:46
in Pearl 5. Let's there's a term that's
20:49
become massively overused. I get a lot
20:50
of semantic diffusion which is cognitive
20:52
load. And I'm not going to get into into
20:55
why I think it's been misused now or the
20:57
context in which it's being misused, but
20:58
effectively as a as a heruristic how
21:02
[sighs] how much mental effort how much
21:05
mental juggling I have to wrap my head
21:07
around something and the kind of the
21:10
contra of that which is how easy it is
21:12
for me to accidentally mess something up
21:14
in in that thing. Yeah. Right. That that
21:16
that is the biggest thing. Now, it might
21:19
be, and I've seen this, I've worked with
21:20
code bases where you were looking at a
21:23
lot of code at one time and it all made
21:26
perfect sense and it was completely easy
21:28
to make to navigate. It was that comfort
21:30
thing again, Dick Gabriel's comfort
21:32
thing.
21:32
>> Yeah.
21:33
>> I've also looked at small bits of code
21:35
and not necessarily because it's a high
21:37
a high density language like Haskell or
21:39
APL or something, just code that was
21:42
really bonkers written. So where in
21:45
within a few lines of code there's so
21:47
many different things trying to happen
21:48
as scream and fail and stuff.
21:51
>> Yeah.
21:51
>> That that you need to unpack it into
21:53
something that Yeah. You want to make it
21:54
bigger so that it will fit in your head.
21:56
Yeah. Make it more verbose. Yeah. So
21:58
there's an interesting thing here. So
22:00
the it's one of the things that a few
22:01
years ago I wrote up and I gave
22:03
workshops at a particular environment. I
22:04
did I came up with this idea in the
22:06
early 2000s based on a particular
22:08
consultancy visit with a client. But
22:09
it's a programmers dozen. I had 13
22:11
pieces of advice and somebody
22:12
>> I remember your programmer's dozens.
22:14
There were I I recall there were several
22:15
programmers dozens that it evolved.
22:17
>> Oh no no no it was it was it was
22:19
actually pretty much it stayed very very
22:21
stable and it would but what was
22:24
interesting is one of the comments I
22:26
have from somebody said oh you never
22:28
recommend that our you know our
22:30
functions should be small and I said no
22:31
you get by doing this you get small
22:34
functions the go you know is the idea
22:36
>> do not have the tail wag the dog. Yes.
22:38
>> Exactly. And that I think is is part of
22:40
the issue. You talk about the
22:41
information density which I think is
22:42
really important. And you also talk
22:44
about the idea that something could be
22:45
all in one place and that's and and it's
22:48
all makes sense. And that led me to a
22:50
kind of a a realization a few years ago
22:52
when when talking to somebody and they
22:54
were talking about breaking stuff up and
22:55
stuff. And I said, "Well, the thing is
22:57
here you you're treating it as like a a
22:59
linear relationship. More is bad, less
23:01
is good." And I said, "Actually, it's a
23:02
bit more Goldilocks. It's there's a kind
23:04
of a one of the problems we have if I um
23:08
so you know some some code I saw the
23:10
other week there was a um a function
23:12
that was uh over a thousand lines long
23:14
and I can't remember the levels of
23:16
indentation but I'm not going to put a
23:18
magic number to it but let's just say
23:19
I'm going to say that's too big. Okay,
23:22
this poor brain can't handle everything
23:24
all in one place.
23:25
>> Does it hurt to read the function? If it
23:27
hurts to read the function, it's
23:28
probably too big.
23:29
>> Am I waiting too late? you know, do I
23:31
genuinely have to keep my finger down to
23:33
get to the end? You know, sitting there.
23:34
Yeah. Are we there? No, we're not there.
23:36
>> Am I seeing the left margin do this?
23:38
>> I once actually once it was a 1500
23:40
liner. I once had the experience of
23:43
going down uh going down a function and
23:45
then I got a blank screen because the
23:46
indentation took it outside my window.
23:49
>> Wow. Yeah, I know everybody. Yeah, I
23:51
love that story cuz that's the story
23:52
that started me down zooming things to
23:55
the smallest point size to just look at
23:56
the landscape and the shape of the code.
23:58
But the thing there is that one of the
24:00
issues that we have and this is a this
24:01
is this is kind of a problem of like I
24:03
have so many things in one place
24:05
mentally I have to tease them apart in
24:08
order to understand it. I am mentally
24:10
decomposing and deconstructing all of
24:11
this. But we also have the potentially
24:14
the opposite problem as we start to
24:16
actually realize that rather than just
24:17
do it in our head do it in the code. If
24:19
we keep on pulling everything apart we
24:21
end up with the opposite problem
24:22
fragmentation. All the pieces are all
24:24
over and in order to understand it I
24:26
have to put them back together again. So
24:27
I'm now doing the opposite. So that
24:29
somewhere in the middle and it's not a
24:31
point, it's going to be a zone and it's
24:32
going to be different for different
24:33
people at different times. But there is
24:35
this idea of am I looking at the code
24:37
and I'm mentally h there's so much going
24:39
on I'm trying to pull apart what I'm
24:41
seeing and then at the other end of the
24:43
scale are there so many pieces lying on
24:45
the floor. I'm mentally having to try
24:47
and put them recompose in my head rather
24:50
than having it present it. So for me
24:52
exactly that that that the fitting in
24:54
the brain that comprehensibility you can
24:56
have something that rather than
24:58
mandating a magic number for the number
24:59
of lines is what's going on here you
25:03
know what is the am I having to pull
25:05
stuff apart or recompose am I constantly
25:08
hunting around my code for fragmented
25:10
methods and that bookkeeping yeah that I
25:12
think is an issue that clean code a lot
25:14
of the guidelines in clean code lead to
25:16
frag arbitrarily they put limits and
25:18
they lead to fragmentation and I don't
25:20
want fragmented thinking But I also
25:22
don't want to have the problem of
25:23
overwhelm. So you you you end up with
25:26
that you're looking for that balance and
25:27
therefore is that Goldilock zone. And
25:29
that for me is a much again it goes back
25:32
to that point you made about the
25:33
experience. It's a relational thing. And
25:35
and that's what we're after. That's the
25:37
habitability. That's where I find the
25:39
comfort. My h Yeah. My house has rooms.
25:41
It does not have small boxes that I've
25:43
broken everything into. Um it has roots.
25:46
But if I put all of the junk into one
25:48
big room, that's too much. But if I
25:49
break everything into tiny tiny rooms
25:51
that I can barely get into, maybe that's
25:53
a little bit too small. That there is a
25:55
kind of a hierarchy and a balance of
25:57
understanding. And I think that's kind
25:58
of an important one. Now, can I offer
26:00
you a lovely phrase I came across uh a
26:02
little while ago? There's a a very an
26:04
ultralight web framework called HTMX.
26:07
And HTMX is trying to be effectively the
26:10
antidote to your Reacts and your
26:11
Angularas. Um, I'm not going to mention
26:13
many technologies, but it's [laughter]
26:16
if if as if our viewers haven't seen it,
26:18
go and check it out. Not least because
26:21
uh the main author has a very very good
26:24
meme game on on uh on social media, but
26:27
also there's some really great essays in
26:29
there and case studies. But what what he
26:31
talks about is his kind of counter to
26:33
separation of concerns where you get all
26:34
these little react bits or rails bits or
26:36
whatever all scattered all over the
26:38
place. He calls it locality of behavior,
26:40
lob. And I hadn't heard this phrase and
26:42
I really like it. Locality of behavior
26:44
is bringing back bringing together all
26:45
the things that are your that field on
26:48
your report. You know, there's no you
26:49
don't keep the database stuff with the
26:50
database stuff. You keep the the the the
26:52
the field of the of the report stuff
26:55
together. And and for me this is kind of
26:58
an inversion of separate the um single
27:01
responsibility in the um in the solid
27:04
sense in the in the Bob Martin sense is
27:07
you know breaking out layers or breaking
27:09
out different things. So the database
27:10
stuff goes over here and the service
27:11
stuff goes over here and the UI stuff
27:12
goes over there and you end up with the
27:14
you know the Rails type the the top
27:17
level is telling you your your your
27:19
framework architecture rather than your
27:21
product architecture is rather than
27:24
thinking of single responsibility think
27:25
about single goal. So if I think about
27:27
the single goal principle which I just
27:29
coined I think I just invented it. You
27:32
okay folks you heard it here first.
27:33
>> Heard it here first. Exclusive Mon
27:35
software engineering channel. Uh the
27:36
single goal principle is assuming I want
27:39
to achieve a goal are all of the pieces
27:41
that I need to achieve that to that goal
27:44
close to hand because if they are it's
27:46
going to make it easy for me and then we
27:47
can get on to and I we're probably over
27:49
time at this point but
27:50
>> we are but no worries. I I wanted to
27:52
mention I wanted to tie in because I
27:54
think it's really important theory of
27:56
constraints. So it since we're doing old
27:58
old stuff 1984 book uh by Elahu Goldrat
28:03
the the goal which a few years ago came
28:05
out as a graphic novel which I'm very
28:07
excited about.
28:08
>> Oh do you know I didn't know that bit.
28:09
>> Yeah. No it's amazing. They they did it
28:11
properly. They got I think it's like one
28:12
of the Marvel um illustrators to to do
28:15
the like the artwork. So it's a proper
28:17
it's a proper graphic novel. It's done
28:20
so well. And what they've done um I know
28:22
you know the book is essentially the
28:24
book the book operates in two levels.
28:26
It's it's Yeah, of course you have. It's
28:28
a
28:29
>> Yeah, I knew I knew it was near me. I
28:31
can remember that one.
28:32
>> In fact, I I was talking to someone
28:34
about this recently, so I happen to have
28:35
it on my desk. There we go. The graphic
28:37
novel. Um so so it's a story of a chap
28:40
called Alex who runs a factory and he's
28:42
given 30 days to turn the factory
28:43
around, otherwise they're going to shut
28:44
it down and fire everybody and his
28:46
marriage is on the rocks and the dog's
28:48
dying and it's all going wrong for Alex,
28:49
right? And the story is about how Alex
28:53
uh bumps into an old school teacher and
28:55
they have this kind of Socratic
28:56
questioning type relationship and he he
28:58
he guides Alex through you know learning
29:01
about what turns out to be theory of
29:02
constraints and flow and he saves the
29:05
day spoiler the dog doesn't die but the
29:08
the the brilliant thing is so you've got
29:09
the the the story the actual plot of
29:12
quite a quite a fun story as well as
29:14
some quite deep principles about
29:17
management theory and what the graphic
29:19
novel does brilliantly is that all of
29:21
the story happens in the pictures and
29:23
all of the theory happens in the
29:24
dialogue. So it's it's so well done.
29:27
They really did think it through.
29:28
Anyway, um the point about theory
29:30
constraints is this is in any system and
29:33
he has a factory system but it applies
29:35
to product development system. It
29:37
applies to any system of work. If you
29:38
look at how value is created, there is
29:41
one thing right now that is the pinch
29:43
point. There is one thing right now that
29:46
is c that is limiting the flow of value.
29:49
And from that he makes two observations.
29:51
He says if you optimize anything
29:53
downstream of that constraint then it
29:55
makes no difference
29:58
because nothing's coming through the
29:59
pipe. If you optimize anything upstream
30:01
of the constraint you just make it worse
30:04
right because they are creating more of
30:05
a backlog at the constraint. So the only
30:07
place to work is the back is the
30:08
constraint. And so the whole theory of
30:10
constraints model is identify the
30:13
constraint which is often harder than
30:14
you think because where you're seeing
30:16
the problem might be presenting
30:17
symptoms. It might not be the
30:18
constraint. You know, we have a
30:20
bottleneck at testing, right? Does that
30:22
mean you need more testers or does that
30:23
mean you need to write code that needs
30:24
less testing? Yeah, you have an upstream
30:28
quality problem, not a downstream test
30:29
number of testers problem. So, identify
30:31
the constraint. Then he says elevate the
30:33
constraint. Sorry, exploit the
30:34
constraint. So, exploit the constraint
30:35
is okay, we know that's our limit. Is it
30:37
running at capacity? Because if it
30:38
isn't, we've got spare capacity. Now, we
30:40
elevate the constraint, make it the most
30:42
important thing, right? And now we
30:44
alleviate it. So, now we stop it being a
30:46
constraint. And what that means is it's
30:47
like whack-a-ole. The next constraint
30:49
will appear somewhere else. So for me,
30:51
when we talk about like bringing this
30:52
right back to the big question, is clean
30:54
code a myth? We don't. And this goes
30:56
right back to your 1970s references.
30:58
Clean code cleanliness, code hygiene,
31:01
kitchen hygiene in and of itself isn't a
31:03
thing. Hygiene in a kitchen is there in
31:07
order to serve food sustainably,
31:10
quickly, effectively. Right? We want to
31:13
be able to deliver software sustainably,
31:15
quickly, effectively. And most of that
31:18
for most of the time is changing
31:19
existing software rather than writing
31:20
new software. So that means you want
31:22
existing software to be able to be
31:24
change it quickly, effectively,
31:25
sustainably. And so the cleanliness of
31:29
code should be and this is I make a
31:32
reference to something else I've been
31:33
talking about recently which I call a
31:34
best simple system for now. Uh the
31:36
cleanliness of code should be entirely a
31:38
function of what it is we're trying to
31:40
do with the code. If it's more clean
31:42
than that, if you like, then we've
31:43
overengineered and that's opportunity
31:46
cost. We could have been doing something
31:47
somewhere else. But if the clarity of
31:49
that code, the cleanliness of that code,
31:51
the navigability of that code is what's
31:53
slowing us down right now, we absolutely
31:56
need to elevate that constraint. And I
31:58
think let's let's um pick that one up in
32:00
terms of the idea of context. In other
32:02
words, the cleanliness. So in I guess to
32:04
answer the one big question is that
32:06
cleanliness is not so much a myth, but
32:08
it is not a fixed point. it is a
32:10
relational thing. In other words, it is
32:12
the idea of exactly as you described it.
32:14
If um if we want to make it that it's
32:17
not a set of uh a set of specific code
32:20
practices, although those can
32:21
contribute, that's your toolkit. Um what
32:24
you actually your judgment of your code
32:26
um is going to be something to do with
32:28
the context. Is it is this slowing us
32:30
down? Is this making us miserable? Is
32:32
this and if the answer is yes, then let
32:34
us change our balance of tools. Look at
32:37
it differently. take a step back and
32:38
rearrange things. Um, that that of
32:40
course presupposes that we don't like
32:42
being slow and miserable. Oh, of course.
32:44
Yeah, there you're right. There's a big
32:45
that's probably the subject of a number
32:47
a number of other videos. But I also
32:49
like the way that you brought out
32:50
principle of locality in terms of
32:51
behavior. Principle of locality is what
32:52
drives my Goldilocks model. I often use
32:55
that. I say, "Oh, you might have heard
32:56
of principle of locality to do with
32:57
caching and stuff like that." I said,
32:58
"Actually, it's to do with us, but
33:00
specifically behavior." I think that's a
33:01
lovely way of looking at it. And I think
33:03
there's a lot of stuff we want to talk
33:04
about in future in terms of um things
33:07
like solid cupid and stuff like that.
33:09
But folks, that is a different video and
33:12
is we're going to Yeah, time has caught
33:15
us. Um we're going to land this plane
33:16
right here. Um hopefully we've explored
33:19
that question either to your
33:21
satisfaction or to your frustration. Let
33:23
us know. Throw something into the
33:24
comments. Um give us a like if it
33:26
provokes some thinking or some thoughts.
33:28
And uh don't forget to follow the
33:30
channel. And for the moment in that case
33:32
um wherever wherever you are and
33:34
whenever you are um have a good rest of
33:36
day and thank you very much Daniel.
33:38
>> Thank you Kevin. What I would add as
33:40
well I mean please please put your
33:41
thoughts in the comments. One of the
33:43
things that we do as a team um and as
33:45
individuals we look at these comments
33:47
and they often inspire future one big
33:50
questions future sessions on the
33:51
channel. So we absolutely love your
33:53
feedback.
Start a conversation
Ask anything about Clean Code: Timeless Truth or Myth?
100/100 free messages remaining
AI responses may be inaccurate. Verify important information.
Clean Code: Timeless Truth or Myth?
Continuous Delivery