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 goal of software is often to sustain an organization in some
way. It doesn't have to be a private
Enterprise. It might also be a government
organization or an India, or things like that, but the
software rarely exists, just for its own sake.
It always exists to fulfill some other goals that an organization
has, an organization, invests in software in order to achieve the
goal. And hopefully also to sustain
itself in helping achieve that go to software.
Is there to sustain the organization basically.
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, who 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, again, my friends and listeners.
Welcome to the tekhelet journal podcast the show where you can
learn about technical leadership and Excellence from my
conversations, with great thought leaders, and this is
episode number 89. Thank you for tuning in today,
listening to this episode. If this is your first time
listening to tackle, e-journal, subscribe and follow the show on
your podcast app and social media on LinkedIn.
Twitter and Instagram. G, if you enjoy listening to the
podcast and would like to contribute for future episodes
support me and this podcast by subscribing as a patron at
technology. Not Dev slash Patron as a
developer. Many of you would have seen it
in your project or when working with Legacy software a code
base. That is very complex how to
trace an understand and is super difficult to make changes to it.
This kind of code is a code that doesn't fit in our head and it's
one of the main Reasons that software deteriorates and rods
over the time and thus becomes an maintainable.
So how can we avoid this problem in our code base?
My guest for today's episode is mocked, Seaman, Mark isn't a
claim author. International speaker are highly
experienced developer and has published a number of books and
courses. In this episode, Mark shed, some
insights from his latest book. Code that fits in your head on
how we can write sustainable software and man.
Age, software complexity, Mark, first started by sharing the
reasons why he wrote this book and explained why software
development is actually very hard.
He pointed out the difference between software engineering and
other physical engineering, disciplines, especially the
difference on the set of constraints Mark, then explained
the importance of writing sustainable software, and shared
a unique perspective that code is actually a liability instead
of an asset towards the end mark shared.
The rule of seven that he Advocates a lot in the book as a
guideline to manage code complexity and a few other
practices that we can use to build sustainable software such
as using checklists, building vertical slices X driven
development and implementing command query separation
pattern. I really enjoyed my conversation
with Mark learning from him about human brain, shut the
memory and how to write code that could fit in our head
easier. I also love some of the
practices that At Mark shared in this episode which are very
practical and is something that we can start applying straight
away. If you also enjoyed this episode
and find it useful, 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 some comments or feedback about this
episode on social media. It is my ultimate mission to
make this podcast available to more people and I need your help
to support me towards fulfilling my mission.
Before we continue to the conversation, let's hear some
words from our sponsor. 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 the devops our data science is your bus or you're a
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 calm 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 for a new cool
swag? Taglit Journal?
Now offers you some swags that you can purchase online?
These wax are printed on Month 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 swags
available by visiting technology, know that death /
shop and don't forget to break yourself.
Once you receive any of those threats, hello everyone.
Welcome back to another episode of the tech Lejeune our podcast.
Today, I have with me, I guess named Mark semen.
He's based in Denmark Copenhagen.
Mark is actually a well-known author and also Publisher.
A few videos courses on plural side and also clean coders.
He recently published a book with a title coat that fits in
your head. So today, we are going to
discuss a lot about what he means by coat that fits in your
head previously. Mark, also authored a book which
is very popular. It won the jolt award, which is
titled, dependency injection. So mark is really good to meet
you today. Thank you for spending your time
and looking forward to have a chat more about your recent
book. Well, thank you for having me.
So, maybe in the beginning, if you can tell us more about your
background and maybe turning points or highlights in your
career, all right. Okay.
So I was only nineteen seventy and grew up without computers.
I'm not your typical software developer who actually grew up
with early computers. I didn't.
So I actually didn't think that I was going to have anything to
do with computers. I have a degree in economics
from the University of Copenhagen started out actually
in a career in government and then figure out that that was
really not my Property. So I thought that I wanted to do
something else, and I had bought a computer in order to write
some of my master thesis and stuff like that.
I thought that was much more interesting.
So I tried to get a job and I T, and this is back in the
mid-1990s. So, basically, if you could
spell HTML back, then, you could get a job 90 which was what
happened. I actually started out as being
just your normal IT, professional.
And then because I could spell HTML actually written a little
bit of HTML. I actually got the job of being
the company's first wit Master because no one else knew how to
do that. It started out really as a niche
thing. Back then.
And then I discovered, I don't really want to be an IT problem.
I thought it's all quite a bit of a much more interesting.
I had written it a bit of code before that.
So I got myself another job as a software developer.
And then, I basically never looked back since then, thank
you for sharing your story. I think it's kind of like,
interesting, right? You started from the government.
You figure out HTML quite a few of us, probably started as a web
developer, and then moving onto as a software developer in
general. So you recently published a book
titled code that fits in your head, I assume.
That code that we wrote is sometimes too big too complex.
Is that something that you're trying to suggest by writing
this book? Or is there any kind of problem
that you see that you try to tackle by writing this book?
Well, so the book actually started out more as a catalog of
software development software, engineering heuristics, because
I spend a lot of time coaching various different software
development teams over the last decade or more.
I discovered that there were certain explanation and certain
rules of thumb that people kept asking.
Me the same questions basically and I kept giving them the same
answer, so I thought. Well, okay, there's actually a
catalog of things here ideas. Some of them have learned from
other sources and some of them are sort of figure out by
myself. So I thought it's probably
worthwhile to connect all of those things but we also need a
little bit of a backbone, a ceases to put a lot of those
legs together. And particularly with the things
that I've tried to figure out myself.
I've been thinking now for quite a few years, that one of the
things that make software development cult is that one
thing is writing the code, but as Martin Fowler says any fool,
could write code that a computer can understand.
Good progress, write code that people can understand.
That's from his book refactoring.
And that interested me quite a bit because I think what makes
software development hard, it is sometimes writing the code is
difficult, but it's more the fact that you have to go back
and read what was already written, and try to understand
what was the purpose of it, and why was it written in that way
was actually doing and where can I insert some new Behavior into
the existing code? So we spend much more time
Encode. And we actually spent writing
code and I have this thesis that runs through the book bed, one
of the reasons why we are having trouble reading code, is that
the human brain has certain cognitive constraints?
There is just so much working memory that the brain actually
has and it's quite limited. On the other hand, computer has
a completely different way that its memory works.
So if you only take into account, the computer's memory
computer can jog or 10,000 Global variables.
If you wanted to, there's a famous case with Toyota.
If you look up, something called the Unintended acceleration bug.
They figured out that maybe they actually had about 10,000 Global
variables in the code that ran the car.
Well, okay, so I'm just guessing here but basically the computer
can easily juggle ten thousand things at the same time and the
human brain can juggle maybe six or seven things.
So the guiding principle then becomes to see if you can write
code that takes into account, not the memory little bit of the
computer but the memory limit of the reader.
So that's basically the idea and that's why the book is called
coat that fits in your head. I'm sure that almost all the
developers here the listeners me, myself included, we have
seen code that probably cannot fit in our head first.
It's like, it's too big. These either too many lines of
code in one class, for example, one function, or just too many
variables or too many things in one go.
And then also at the same time sometimes you have to jump into
multiple files in order to get the full picture of certain
things. I think we all have been there
and I can see this is a real problem.
And when you mention about human memory limit, I think that
speaks why that sometimes We struggle to read the code.
You mentioned that software development is hard.
Most people predominantly from the business side of the product
side. They will think that writing
software is easy for software Engineers.
Sometimes we think it's not really not that easy.
Why do you think there's this mismatch?
Like when you say software is hard, can you explain a little
bit more? Why is it really difficult?
I think, complexity grows exponentially with software.
So writing something like hello world is not difficult.
You know, most people can do that getting started with things
that are little bit more. Vacated than that is again
something that most people can learn, that's one thing that
might influence, the way that people from the outside.
Look at the industry, they say, well it's easy to get started.
So why is it so hard? And you see this very often in
projects development software? The start from scratch, from
Greenfield, the first couple of months things actually go pretty
well and developers move at a good pace and then as time goes
by things starts to be slower and slower.
One problem with the other stakeholders is that often they
discovered That velocity decreases.
They discover that too late and then they start to complain
about why I say everything going.
So slow with the developers, must be lazy, or something like
that, you often get that sort of response.
So I think there's a problem from the outside is that first
of all, you have this sort of exponential growth of complexity
as time goes by. If you don't do anything to
manage that complexity, that's one thing and I think another
thing is that there is a disconnect between how easy it
is to formulate a problem and then how difficult it actually
is to implement code. So there are things Is that are
difficult right there, still a Frontier where people are trying
to figure out how to redo all sorts of advanced.
Artificial intelligence, whatever people call it these
days, there's still things that are hard to do.
There's this famous XKCD comic where they say something like,
someone comes by and starts giving the software developer a
set of requirements. The person said, that's the
stakeholder, the stakeholder says, we need our application to
be able to identify, if a photo was taken in a national park and
then The developer says, oh, that's easy.
We just look at the coordinates of the metadata on the phone or
the photo and correlate that with the national park, that's
easy. And then tag it.
If the picture contains a bird and then the program I says,
okay, I'm going to need a research Grant and 10 developers
in 10 years because that is as easy to say.
But it's an order of magnitude more difficult to actually
Implement a feature like that. So we have this disconnect as
well where people who don't have the technical insight there
often get completely surprised by how difficult the hard things
are. Even get surprised by that
ourselves. Sometimes we get a requirement
and we say, oh yeah, I could do that.
I could do that in the week and then when you start diving into
it, you figure out. Oh, this is actually really
difficult. I have no idea.
I thought it was going to be easy, I don't know.
It's going to be really hard so that happens a lot in software
development as well. So I'm paraphrasing and I
apologize that I can't remember what the source was.
But someone said something like, you know, software development
copying things is free. We do now.
New things every time because we never do the same thing in
Industry. You may build thousand copies of
the same car because there's actually a cost associated with
creating a copy, but there's no cost associated with creating a
copy and software. So, we never actually spent much
time creating copies, everything we do is always produce a new
things. When we're producing new things,
it also means we do things. We've never done before.
So we are constantly engaged with doing things that we have
never done before. Sometimes it looks like
something we've done before we have some experience.
But we are always doing new things because if we weren't, we
could just have copied what you already have four created
earlier on some development organizations, call the
development part, they called R&D research and development.
And I think that's actually not too far from the truth.
We should probably recognize more than most software
development organizations are actually research departments.
That might actually go a bit of a way towards setting
expectations. A little bit better.
That last part is Thing that just occurred to me right now.
So I haven't really thought that through whether that's a good
idea or not. But you know, that's that's at
least worth thinking about it. I think, in your book, the first
few chapters you are talking about the metaphors of software
engineering forces, the physical, or mechanical
engineering, which has been around for quite some time.
And you mentioned that software engineering, cannot be treated
similar to building a house. Can you explain a little bit?
Why is of engineering is different than the other types
of engineering. Yeah.
Okay so engineering is always about producing.
Outcome decide I'll come within a set of constraints.
I think in the sense that we could talk about software
engineering, that's true as well.
But let's talk about the other things.
First, you asked about the very common metaphor for software
development is like building a house.
That's the metaphor. I don't believe in that metaphor
but it's very common and one of the problems is that the set of
constraints is completely different because when you build
a house you have some constraints that are imposed
upon you basically by the real world you have gravity, you have
strength of materials, you have a A lot of logistics you need to
take care of for example. You can't just start by building
the roof and then later on say, well, yeah, I don't like roof.
Let's try to build another roof and then later on, once you've
done with the roof, you say okay let's now do the foundation's,
that's not kind of work with the building because the set of
constraints is based in the real world where as you also have a
set of constraints in the case of software development, but
constraints are quite different often.
There's no implied or water to things.
So the example that I just gave the way you can't start with the
roof, there is an implied. I'd order to things you have to
sort of start from the bottom and go up if you're building a
house, the constraints implied, or they enforce that order.
On the way you have to do things in a certain order, that's not
so much the case when you do software development because you
can basically start wherever you'd like to start.
If you want to start with the user interface, you can do that
if you want to start with the database, you can do that.
So that's much more flexible but then you have another set of
constraints and people are often not really aware of those.
First constraint is the software needs to actually execute
correctly on the Pewter, that sort of like the bottom line
that's not the end goal. That's sort of like the bare
minimum but then you have all these other problems where you
say well okay? So in order to be able to keep
on developing, on the software developers will have to read the
existing code in order to understand how to move next.
So it's a little bit comparable to Logistics in this sense that
you can't build a house. If you can't get materials on
site and if you excavate the foundation, you need to move all
the dirt away from the building site.
So there's some Logistics in the real world and I think it's a
little bit comparable in The area of software engineering in
the sense that the logistics are more related to know.
How can you enable people to keep on working on adding more
stuff to the software six months from now.
A year from now, or two years from now, and the logistics that
are involved in, that is also the hygiene that is involved
because you have to make sure that the code is understandable
to those people who come after you, or just your future self.
So that's also a set of constraint.
So that's why I think that we can still talk about engineering
but it's just just very different from physical
Structural Engineering. I think it's a good segue as
well because the topic that you just described is actually
sustainability right. In his, I think one of the main
theme of the book you want the code that fits in your head
because you want to aim for sustainable software, you have
this lovely quote, which I will read.
The goal is not to write code fast.
The goal is to sustainable software, so you can you explain
a little bit further. What do you mean by sustainable
software and why we should aim for sustainable software instead
of just rapidly turning out? Coat.
Okay, so a lot of people talk about maintainable software and
I did that for many years as well.
And then I thought, what if I start to call a sustainable
software instead of maintainable?
Because I think we're using the word like maintainable, you're
talking about that characteristic of the software
from the developers perspective. Other developers probably going
to understand what it is that you mean by, but it doesn't
sound sexy. It doesn't sound like something
that other stakeholders would actually be interested in.
So I thought what other words could we look for when I
thought? Well, the goal.
Of software is often to sustain an organization.
In some way, it doesn't have to be a private Enterprise.
It might also be a government organization or an in Geo, or
things like that, but the software rarely exists, just for
its own sake. It always exists to fulfill some
other goals that an organization has, an organization, invests in
software in order to achieve the goal.
And hopefully also to sustain itself in helping achieve that
goal. So software is there to stay in
the organization basically and that's why I chose that word.
Datable code, rather than maintainable code because I
thought the Outlook is a little bit wider.
You can sort of include other stakeholders when you talk about
sustainable software instead of maintainable software.
Yeah, because I'm dense, this can be tricky, right?
So, for something Engineers, sometimes we think writing
software is easy, we just add a few lines of code, doing some
debugging or just compile and build and see the output and
that's it. But actually, if you want to see
sustainable or maintainable software, it's like you have to
look at the bigger picture. Probably, is there a place where
maybe there are duplicates or maybe there are better designs?
And you have to do refactoring and things like that.
And you mentioned in the beginning that code is mostly
red. It's not written mostly.
So there are many Legacy or maybe lines of code that are
already written. That probably you just need to
build and improve from their own optimized for readability is one
thing that you suggest in your book, right?
Because adding more code in your view is not actually an asset.
It's actually a liability. Maybe, you can explain a little
bit more about this aspect of readability and encode as a
liability instead of asset. Okay, so first of all, again,
the observation that Go to the liability.
Not an asset. That's not mine.
I think I have it from Tim ottinger who claims to have it
from someone else, that's how it always goes.
So that's not my idea at all. But basically the idea is that
if we want to talk about assets versus liabilities, the code
itself is really not worth anything.
You can make this thought experiment.
If you imagine that, you've written the perfect software for
the purpose of whatever it is that you're trying to do and by
some magical way, you know that there are no bugs in the
software. Where it does exactly what it's
supposed to do. And there will be no change
requirements. This is a hypothetical thought
experiment. That's never going to happen in
the real world. But, you know, if you imagine
that, you have the perfect software, it's done.
Why would you need to keep the code around?
The code, just created the software the state of exe files
at dlls or whatever it is. You can always just copy them.
You don't need to be able to compile them ever again.
I'm assuming here a compiled language and not an interpreted
one. This make that assumption so I
would argue that the Code is at best worth noting in that
scenario, there's no reason to keep it about.
So the reason why we keep code around this, not because it has
an inherent worth in itself, we keep it around in order to be
able to make changes to the software, because in the thought
experiment, the software was perfect.
But in the real world, it's not, it will have box and even if it
has no box, it will need new features because there will be
change requirements and so on. So we keep the code around in
order to be able to produce the outcome that we we actually
desire. So that's just like any other
liability in the sense that you can keep spare parts around in
your factory. In order to be able to create
new cars, whatever it is that you produce all the parts.
You keep on stock is a liability and the same thing goes with
code, so that's the reason for that.
So that also means that in terms of being productive, you have to
manage the liability, that means minimizing the cost of owning
that liability. So again we come back to this.
Were you know if you make it as readable as possible, the cost
of hooning or having that on stock, the cost goes down.
Thanks for explaining this. Sometimes it's count, eight to
eight different because it is we write the code.
It is an asset. It keeps producing values that
we wanted to do. So thanks for sharing that, that
perspective. It's also something that I
learned you mentioned about optimizing for readability and
also you quoted Martin Fowler in the beginning saying any fool
can write a somewhere that computer understand, but not
everyone can actually write a software that people.
A understand I think again is true.
We all have seen it in our real life and that code that is quite
complex and big and doesn't fit in our head and you have this
rule of thumb or maybe just guidelines for people in your
book over and over again, which is the rule of seven.
Can you explain? What is Rule of seven?
Why is it 7.5? Not then.
Yeah, so this is a little bit of a cheat again in the sense that
it doesn't have to be 7, but the reason why I picked seven,
there's a couple reasons for that but there's a very famous
paper in experimental. Ecology called the magical
number 7 plus minus 2. This was based on some
experiments done by an experimental psychologist called
George Miller and the papers from 1956.
So it's actually quite a robust result.
One of the conclusions of this paper is that we have short term
memory and it can hold about seven things in our short-term
memory plus minus 2. So that means that if we try to
remember random numbers names or colors or variables that were
reading code, we can juggle around.
And things in our short-term memory before we start to
forgetting some of that stuff again.
So I think that's a very interesting Insight in terms of
what it means to read code. Because what we do when we read
code is that we do our best to sort of interpret the code as we
go. So it's almost like we're
running a little interpreter, a little compiler, a little
emulator in our brain, that sort of tries to understand, okay?
So if the input here is that you know it's going to branch and
this one. So we're sort of running an
interpreter in their brain and that means we need to keep track
of State. Because if we encounter and if
statement, for example, We need to be able to say to ourselves,
okay? So if the input was that that if
statements going to be full. So we're going to fall through
into the ill statement. All of these things, we can't
make those interpretations of code, unless we are able to
maintain state in our head. Again, you know, I think we can
keep track of as the paper says maybe seven things, but if they
are small state that we need to keep track of and those seven
things, then the code becomes really much harder to
understand. So I wind a little bit with the
number seven for a couple of No reasons.
First of all, I wanted something simple and easy to remember.
So instead of keep on saying 5 to 9 + - I'm just using this
because it's easy to remember, there's also this thing we're in
lots of cultures 7 is solid like a magical number anyway because
you know from fairytales and so on.
So it's easy to remember. So I never call it the rule of
seven in the book, I don't think I'll be able to do that but you
did that and I've heard other people do that now.
So that's actually quite great that.
It turns out that the ideas catchy enough, that you begin to
put it in your own words. Which means that it's somehow
must be working, which I'm very happy about.
As you can tell, sometimes I'm being a little bit deliberate
with the way that I choose words or the way that I put things, I
don't think that I'm cheating. I think it's very much On Target
in terms of what I've read about, what this human
short-term memory can do. But I also think it's quite
important to present things in a way that their memory rules, and
that's why I'm sometimes picking one number instead of a range.
That's the story. Basically, So to make it more
practical, right? So when we look at code, we
count the number of variables. We count the number of lines to
become the number of what in your book.
You mention about cyclomatic complexity, but what is exactly
seven here refers to. So there could be lots of
different things I like to look at cyclomatic complexity.
So that's one thing where you might say you'd like to have
some sort of threshold in your code.
In the book, I also talked about thresholds because I think it's
very important to have some thresholds.
You can agree on as a team to say And measurement like
cyclomatic complexity should, in general, not exceed a particular
threshold. The threshold might be seven,
might be something else. And the reason why I think we're
so so important is that there's no one looks after the win are
things getting near to, or something that is problematic.
If no one pays attention to that, your code will grow in
complexity in lots of different dimensions and you're not really
going to notice until it actually really hurts.
At that time, it's very late, it's difficult and it's
expensive to fix. He's so it's better to sort of
knit things in the bud, if you will by having some thresholds
where, for example, with cyclomatic complexity you could
say, we should set an aggressive threshold.
I just picked number 7 again, just because I do that all the
way through the book, I've written the code that goes with
the book, that demonstrates that's possible to do.
Most of the code that I write actually doesn't have even
cyclomatic complexity of seven. It's more like three or four
typically, so, that's definitely possible.
So that's just one quantification mechanism.
I'm looking for those Patience various different
quantifications in order to be able to monitor thresholds.
Cyclomatic complexity is one. You also mentioned just counting
objects. Basically accounting variables
is a very unsophisticated way of introducing a metric.
But the thing I want to do with metrics, I don't want the
metrics to be something that only the machine can do for you.
I want metrics to be something where you can just do it.
If you're discussing with the colleague, if you're doing pair
programming, or if you're doing a code review, you should be
able to just do that in your head and say, oh, that's just
too many variables. Here you can just count them so
simple, stuff like that. So those two things like object
activation and cyclomatic complexity, I just picked seven
because I think that's actually quite a reasonable threshold for
those. Anyway, you also mentioned, I
talk about lines of code and also with the number of
characters, you can use on a horizontal line, that's not 7x7.
I'm not suggesting that people should buy curled in the seven
by seven bucks because that's not really going to be useful.
So, I have some other numbers there, it's not seven all the
way but it's 7 in a lot of In lots of places but that's
basically the measurements that I tend to look for.
You know, cyclomatic complexity object activation number
variables lines of code in a method and the width of the
code, that's pretty much what I'm looking for.
So maybe for people who are not familiar yet with the cyclomatic
complexity, if you can take a few minutes to explain, what is
exactly cyclomatic complexity? How do we count it?
Yeah, we should really come up with a better name for it
because the name sounds really scary, but it's a super simple
concept. The idea is basically just to
count the number of Inked pathways through the code.
So, if you imagine, you have a method where there's a single,
if Ranch, either the code can go through the if Branch, if the
Boolean expression turns out to be true or it can fall through
that your files. If the Boolean expression turns
out to be false. So in this very simple example,
you have two distinct pathways through the code.
We count looping as a distinct pathway as well, because in most
cases if you look over the collection and the collection is
empty, all the code that's within the loop is not going to
be executed. So there's a little bit like a
branch instruction. Well, so basically you just stop
by one because there's always going to be one distinct
pathways through the simplest line of code.
Hello world has cyclomatic complexity of one because
there's just one thing you can do to just start by one of these
every time you see a branch instruction or looping
instruction, you just increment, the counter by one.
So it's super simple. And again this is something you
don't need a tool to do that. You can do that your brain while
you're just looking at the code, the name is horrible but it's
just counting distinct pathways through the code and it tells
you a little bit about the load on your A short-term memory as
well because it's almost like those distinct Pathways.
They're sort of like parallel Dimensions or method that can
take three different ways. You're looking at something that
can be healed in one of mutually exclusive ways to sort of like,
you're looking at the things that exist in three dimensions
at once. So again, I think if you're
looking at something with the cyclomatic complexity of 7, for
example, it's sort of like you're looking at a thing that
is one of seven things at the same time.
And that's probably going to tax, your short-term memory as
well. And again, I think the threshold
of seven actually makes a lot of sense to me.
But if you look at the older literature about cyclomatic
complexity, most other sources would say that cyclomatic
complexity of 20 or 30 is actually considered to be quite
acceptable. So if I have anything new to
say, if this book brings anything new to the table is
more, that it really dramatically lowers.
What I think the threshold ought to be thanks for explaining
that. So again for people who may not
be familiar, so you just count by the number of parts that the
code could possibly execute. So if you have, if statements is
probably two Pathways created there.
If you have more and more, if statements, basically you keep
adding the cyclomatic complexity and I think one of the quote in
the book I think is from can back or someone else, the goal
of survey design is to create chunks or slices that fit into a
human mind. So you mention here about the
cognitive load in your brain short-term memories.
So when you reach a certain threshold maybe it's seventh,
maybe something else. Keep spitting maybe the chunks
of code in the smaller compartments, right?
So that you don't have this cognitive load and your software
does become more sustainable which is again the theme of the
book. The code that fits in your Hit.
So thanks for sharing all this. So you mentioned a number of
practices in the book. Maybe, when we have time, we
covered some of them. The first one sounds very simple
but actually it's quite powerful, which is checklist.
I think we sometimes also hear it from medical or maybe we look
at the book as well. The checklist Manifesto, can you
explain to us what is this checklist and how we should use
it in our day-to-day? Yeah, so we can, I actually just
also took a lot of inspiration from the checklist Manifesto.
You just mention that which is written by Atul gawande who's a
surgeon. He has this wonderful phrase
that one of the people who partook.
In this experiment, saved the checklists, increase the
outcome, without any increase in skill.
So you can use the exactly the same skill level as you already
have. But then by using a very simple
Aid to memory, which is a checklist, you can improve the
overall outcome of a process by making sure that we do things in
the right order. And I know that the checklist is
something that to most people sounds little bit oppressive,
or, at least ordering what we need to understand.
First of all, did originals are from military.
Aviation, you can imagine Pilots going through checklist before
they take off and before they go into landing and so on.
So you have to imagine those sorts of situations instead of
imagining filling out boring forms on paper because that's
actually not really what you're supposed to do.
So a checklist is an aid to memory is basically just to make
sure that you always remember to do things in a certain order.
If you are really good at it, you can just run through the
checklist and say okay today remember to do that.
Yeah actually to do remember to do that.
I also actually did remember to that because if you actually do
that as a process you will be surprised.
How many small things you forget this human nature, that we
forget all of those things. And again I think we have this
very limited capacity in our short-term memory, so everything
we can offload and say, well, sometimes, we can remember
things by putting them in long term memory, but if we can
somehow automate things away in various different ways.
By, for example, following A checklist that means we don't
have to spend limited brain power of making sure that we
remember to do all the things correctly, which is the go
through a checklist. So I want to be very explicit
here that a checklist is not a control mechanism.
It's not something that your manager should be able to
leverage in order to keep an eye on you.
Ideally it's just something for example, with the search in some
of the experiments that are to go out the did in the hospital,
he worked on, he put the checklist, you created posters
of the checklist. It was questions.
Like did you remember to wash your Hands before you went into
surgery, are you sure you're operating on the right, patient?
Things like that. You'd actually be surprised.
How often these things go wrong. If you don't explicit the deal
with them. The point is It's a poster on a
wall, so it leaves. No, audit Trace.
There's nothing where some manager can come by afterwards
and try to extract information about how you work or how
efficiently you work or whatever.
It's there to improve the process.
It's not there to keep an eye on you.
And I think that's very important.
I would think twice Ice before I started turning checklist into
something the produced reports you can also make the checklist.
I talked about that in the book as well.
You know, most languages and most development environment
comes with all sorts of extra tools that can make suggestions
about it code. So in some languages, should
call them dentists and in.net. We call them static code
analysis. But the idea is basically the
same, it's sort of like a checklist where it says over you
are using that overload of the method.
But that's not really supposed to do that because it might be
deprecated in the future. You should.
Use that one instead that's sort of like an automated checklist
and I'm all for that but as far as I know also the static code
analysis that comes with that. Net for example, Justin create a
report and I would be very concerned if it started doing
that. So I think it's very important
when we talk about checklist to say it's for your benefit.
It's not for your managers. Benefit is just there to make
sure that you remember to do things in the right order and
while it seems stupid, it's probably a good idea.
So actually, from my personal Checklist is also powerful.
Imagine for example, I've been producing this podcast 80 plus
episodes, so I use checklists as well because it's times, depends
on stress, depends on mood, depending on the complexity of
the episode sometimes you tend to miss certain parts of the
process which even though you assume you know, but you
sometimes miss it and actually you also mention in the book
that sometimes just following a checklist doesn't mean that you
will produce the successful outcome.
But it even increases the chances that you will get
successful outcome. Do keep in mind, maybe in your
your day-to-day process. If there's something that you
want to increase in terms of success rate, maybe you should
use a checklist. So, thanks again for explaining
the second practice that you mentioned is about vertical
slice, so maybe explain a little bit.
Why we should aim for this vertical slice.
Yeah, okay, so again, another idea that's not mine are
basically stolen that from net price and Steve Freeman.
They have this wonderful book called growing object-oriented
software Guided by tests. So that's an entire book about
basically, that idea. But I just thought I Gee
included when I coach teams. I'm trying to teach them to do
some test driven development but then it sort of can't really
figure out where to start. So, I'm not saying we should
always do this vertical slice, but I think it's a very good
idea. If you don't have better ideas,
then do that as a default, if you will.
So that might also be a checklist where to start.
Do you have a good idea for where to start?
If yes, go there. Follow your good idea if no
start with a vertical slice. So basically this idea from
vertical slices to say, try to implement a feature of the
software all The way through as narrowly as possible.
Because I've seen lots of teams that get hung up on all sorts of
side quests, if you will, where they say.
Well, yeah. But before we can Implement that
feature, we need to have the Locking System in place.
That means we need to pick a locking framework.
And then we need to create our own framework on top of the
other logging Frameworks weeks go by and nothing actually gets
produced. And once you actually start
creating features, it turns out that the Locking framework, they
created all the database framework.
They created Doesn't really actually solve the problems,
they need to solve and then they have to go back and retrofit it.
So that's just racist a lot of time.
So instead basically the idea with the vertical slices to same
figure out a simple way to get all the way through.
You don't have to have layered application architecture, but
basically just say well, Implement a feature so that it
actually works. The book has one running example
that goes all the way through which is an online restaurant
reservation system. And the first one I start doing
is to enable you to post reservation.
This is a Stay Pi. So you should be able to post a
reservation little Json document.
The I considered the feature complete when that reservation
is persisted in a dollar store. So that's the first vertical
slice. I start by writing a test an
automated test that posts that Json document to self-hosted
rest API. The first thing is, just to
ensure that the API response with some 200 Response Code.
And that point is not persisting anything, but just to make sure
that the in point is there and then you can sort of Flesh it
out from there, this B takes a lot of time it Almost half the
book just getting to the point where they actually saves into
the database. But then, you know, I introduced
all sorts of different engineering techniques.
Using that idea of the vertical slice, so that's just a very
thin slice through the application, but now you
actually have something that has real Behavior.
So at this point, you could say, we could actually take and
deploy this code to production and conceivably.
Someone could start using it because it actually is useful.
It's not very useful, but it actually does what it's supposed
to do. So the reason why it's called a
Vertical, slice. By the way, is that?
I think it's named like that, in opposition to the traditional
horizontally, layered architecture, where you
typically tried an architecture with the set of layers where the
bottom layer is going to be a Delta X is 3 and then you have
maybe a business logic in the middle and you have UI and the
top and maybe some more layers in between.
So the idea with the vertical slices, just to say, well,
instead of thinking about those horizontal layers, you didn't
create a vertical little section through that layer cake, if you
will. So that's the reason for the
name. I like your metaphor.
Side quests on those. We Engineers when we work on
something, we like to go into a certain different Quest.
We did our rabbit hole and then it goes away.
You mentioned that a newbie come up with vertical slice as narrow
as possible, and then we ship it.
I treated as a value in that, right, when you ship this code
into deduction instead of just building code over time and
actually don't deploy to production.
I think that also doesn't give any value to anyone including
your stakeholders and you mentioned after we come up with
this vertical slice, you've tried to find A certain factor
to keep on improving from there. The next practice that we want
to talk about is about X driven development, mention that to
make a change to the code. You should find a motivation to
do that. These days, we have so many X
driven development like Custer new development, maybe German
driven development or maybe Behavior driven development.
Maybe he can explain a little bit more about this concept X
driven development and I wouldn't Visions to change code.
Yeah, so you already mentioned test-driven development which I
think is probably the most well-known of those extra and
development. Things.
I just noticed that once tester and development gains
popularity, lots of other similar techniques came by where
people started to name things in the same way.
So you have Behavior driven development and property based
testing is also sometimes called property driven development and
then you mentioned domain driven development.
So you have various things like that.
But this idea about using some sort of driver in order to
inform you of what's a good idea.
What should I be doing next? I think that's an important
thing to do because again the human brain is actually not very
good at that. Thinking formally.
So before I talked about the limitations of our short-term
memory, but also if you just look at our ability to do a
formal analysis of things, we're not very good at that actually.
And that's one of the reasons why I've despite our best
intentions, we always create defects in the code because we
write code that we think behaves in one way and then our brains
just weren't really up to the task.
And then we created off by one error and whatever it is that we
do. And that happens all the time.
So I think for that reason it's always a good idea to say, okay
can we Statute some processes. That will help us verify that
what it is that we're doing, is actually appropriate.
So, that's the idea behind tissue development issue, right?
A tests. And the idea of the test is that
it's a stimulus. Our response is to write the
code that can pass the test. We get the verification that
we've done the right thing by first received the test fail.
And then we write a simple implementation and then we see
the test pass. So that's one way where you can
use an external driver in order to make sure that you doing the
appropriate thing. Another just editing code and
thinking it works, you're actually getting some
verification of that. So that's one thing.
Another thing that I talked about is if you working in a
language that is statically compiled and has static typing,
you can use the type system to tell you whether or not you're
done the right thing because if the code doesn't compile, it
certainly doesn't work either and that doesn't mean that if
the code does compile that it works.
But again, you can design things in certain ways, so that if your
code compiles, it's more or less likely to actually compile.
So, I will spend A lot of research time with the
programming language called Haskell which most people
probably have heard about and there's this phrase going around
about Haskell that if it compiles it works, it does often
take your couple of hours actually getting your ass to
code to compile because it's a language where the compiler has
a lot to say, but there's some truth in it.
You can also write books into Haskell code, that's absolutely
possible. It language like Haskell
definitely leans in that direction.
Where if it compiles there's a pretty good chance that it
probably works. But once you understand what it
is, That makes Haskell work like that.
You can actually take some of those ideas and poured back into
languages. Like I work in c-sharp, the book
is written in C sharp. So, if you deliberately started
signing in ways where you emulate, some of the things that
gives Haskell that characteristic, you can also
pull your code in that direction yourself where you can see, I've
designed this API over here. So that it's really difficult to
use wrongly. There's a concept from lean,
manufacturing called Pocoyo key, and I'm probably not pronouncing
it correctly, but it's Japanese and it means something like
mistake proof. But basically the idea is that
you can ride any PI so that if the API called compiles, it
probably also works the way it's intended to work because it's
designed in such a way that you can't really call it in the
wrong way. I have some examples of that in
the book as well, so that's another way where you can sort
of use the static type system as a driver for changes.
I also talked about how to use things, like static code
analysis, or other languages would call that linters and use
that for drivers of changes. So, for example, in my code I
have quite Quite a few places where there's a guard as null
values and all input. There's no junit test.
That provoked me to write that card Clause because there's a
static analysis tool that provokes me to write the
characters. That means if I remove that card
flaws, the code doesn't compile. Because then the analysis true
kicks in and says, well, you haven't checked for now here.
And you should do that. I also turned all warnings into
errors so it's simply not going to compile in that case.
And that means, I don't have to write a test for it because I
have another thing that drives that particular change.
I take whatever I can get from all sorts of different shelves
and combined it into something, where I try very much to always
have some sort of external thing, that pushes me to write
code in a certain way, because then I also have a degree of
confidence that Nick cooked us. What it's supposed to do.
Thanks for sharing this powerful concept.
I think it's really powerful because sometimes we change code
out of our curiosity or maybe certain ways that you mentioned
in the beginning. But I think the lesson here is
that find the appropriate drivers and then use that as the
motivation to change the code. Code instead of just changing
for the sake of changing it and you mentioned about poke, okay?
I don't know how to pronounce it and you compare that with the
Swiss Army, kind of behavior where you have, simply
everything you can do anything. But I think foolproof, maybe
API, design, contract, whatever, that is very simple for people
to understand right. Again, that if it's in your
head, probably rather than having to understand the
context, how to use the thing, there's another powerful
practice that you mentioned for API design, which is this
pattern called command query separation.
I think this is also Worth to explain for people so that they
can improve their API design. Maybe you can explain what is
command query, separation there. So that's an idea from Baskin
Meyer, which goes back to the middle of the 1980s bathroom.
I invented this language called Eiffel and he was a Pioneer in
object-oriented programming. He thought it would be a good
idea to distinguish between two types of operations.
We call one of them commands and he called the other one queries
if I should explain this as succinctly as possible command
is something that changes this. State of basically observable
universe. So that might be something like
if your software sends an email that changes the state of the
universe. If it adds a road to the
database that's also changing the state of the application, at
least, if repaints, the screen change the pixels on your
screen, that also changes the state of things.
So, all of those things we call side effects better.
My, I thought that if you have a side effect, the API and
operational methods, should then be about side effects on the
other hand. If you want to have some data,
then you should have Kind of operation that can go and read
data from somewhere and return data.
It might also just be hard, coded data or calculation like
adding numbers together, but, you know, if you want data,
that's a different operation and he call that queries.
So it doesn't have to be a database query.
It could be any sort of thing that produces data.
That's on my I said it's not a good idea to mix those two
things together, right? If you want to produce that.
So then produce started don't mix them.
So that's command. Curry separation, separate those
two things. You still You thought about them
as belonging to the same class so you can have a class of
objects and then some of the methods would be changing the
state of the object and then other methods would be methods
that produce data and maybe about the contents of the
object. So his idea was, you could
definitely mix them on the same object.
But each method used in isolation, should be doing one
of those things and not both. That's the general idea.
Yeah, I think this pattern really is powerful because I
once worked with a code that has no separation of this, like we
produce side effects, you Something.
And also you read them may be the result of that or maybe some
other extra computation afterwards.
So it makes it slightly more difficult to trace.
And also understand what is actually happening.
I think this pattern is really worth to implement in your code.
Yeah I actually didn't explain why it's beneficial to think,
the reason why this is beneficial is that again,
particularly if you're looking at things that have a static
type system, if you have an operation that is a command
only, you know, it's all about the side effects and it's not
allowed to produce any sort of output.
It's very recognizable because you always tell by the method
signature that it has void, it has no return value.
So that means whenever you encounter something that is void
that has no return value, you know, it's going to be about the
side effect. So this is a big if but then if
you know that a particular code base is designed according to
the command crew separation principle, then you know that
whenever you run into something that does produce an output, it
will have no side effects. Again, this is a big conditional
thing here saying. Well, you have to Be able to
trust that this code follows the principle.
I've worked with code bases, that follow this principle in a
systematically, and it just makes things so much easier
because that means whenever you're looking at an API and
maybe it's not something you're familiar with, oh, you forgot.
Even if you wrote it, you forgotten how you did it.
You don't have to go and read the actual implementation code,
you just look at the API and say, oh, this one has voiced.
Its co-producing. So the side effect.
Oh, this return starter. I know that it's safe to call it
because even if I called it too many times, the only thing
that's going to happen here is that That it might use some
extra CPU Cycles but it's not going to change the state of the
system and being able to just add a glance which of those two
buckets. So particular method Falls that
just saves you so much time because now you don't have to go
and read implementation in order to understand.
She said, one or the other so there's just fewer surprises in
the code base like that when we go back and talk about reading
time, let's just freeze. Our breeding time that cuts down
on the number of different files.
You have to go and visit in order to understand what's going
on. I'm not saying that it
completely eliminates the need to And we do the thing but it
saves you some time there, it definitely will save our brain
cycle, not to be able to read multiple files again following
the principles strictly. I think that's still the
keyword, and also maybe the naming of the API design itself,
the methods or the function name or whatever API.
So that is also must be self-explanatory.
Advising and you will have this cognitive load to guess.
Okay, what is this function about?
So marketing, there are plenty more practices that you have in
the book, right? So I really highly suggest the
listeners here. To read the book because in
preparation of this recording, I actually took a loop.
There are so many tears and insights there.
I think this book is really great.
Thanks for writing this. If you haven't check it out,
please do check. And I'll put it in the show
notes. How you can get the book as
well. Unfortunately, you to time, we
have to end this conversation. So Before I Let You Go,
normally, I have this one last question that I asked to all my
guests, which is what you to share your tree.
Technical leadership is. Mmm.
So think of it like an advisor. You want to give to the
listeners here so that they can follow.
Maybe do your best practice, okay?
So the first one, doesn't sound like a technical advice, but I
think is very useful for technical people.
Take breaks, I regularly take breaks.
I run the Pomodoro Timer. So, I work for 25 minutes and
then, let's take a five-minute break.
So, that's one thing. But I also during the day often
take longer breaks where I go grocery shopping or go and do
the dishes or other things like that.
The reason for that is, again, this has something to do with
how the brain works. I'm not sure I completely
understand what's going on here, but I get old my insights.
When I'm away from the computer, I can sit and look at code or
problem. Definitions for a long time.
And not really go anywhere. And then I go grocery shopping
while I'm in the supermarket. I'll go.
Oh, now I know what I need to do and then they could go back and
actually do something useful. So if at all possible, take
breaks during the day, that's really gonna help your brain to
come up with good ideas. The second tip or advice I would
say is that, if at all possible? See if you can get to continuous
delivery. I'm basing this advice on this
book called accelerate by And he called for screen and Jin Kim.
And just humble, you could discuss whether you want to call
it research. I think research is a fair
enough work to use. So it's based on a lot of
surveys. Just like 50,000 people answered
the survey. It seems like the single most
important thing in order to determine whether or not your
organization Works effectively or not.
Is, can you do continuous delivery because so many other
things will sort of come as a by-product in that Journey
towards continuous delivery and it's a big Journey if you don't
already doing it. But it's really worthwhile to go
in that. That direction that would
definitely be something that I would look into.
The last thing I want to say is, if you're interested in code,
the fish in your head, learn functional programming.
I have an argument to prove, again, that sort of takes this
idea, we talk about democracy operation little bit further and
say, well, if we add another constraint, another idea to this
idea about queries and say, not only must they be side-effect
free. They must also be deterministic,
you have something called a pure function.
There are various reasons why I argue in the book.
Why that actually fits in your brain very well.
So definitely. Leave courage people to learn
some functional programming, the best language to really
understand functional program with this Haskell.
But it's also really difficult to learn.
If you're up to the challenge, if you're curious and I would
recommend that they in my previous episode, I had a chance
to talk to Scott lotion, so he Advocates, F sharp F.
Sharp is a wonderful language as well.
I write quite a bit of a shot as well, for me.
It was a great stepping stone. So I came from C sharp, and then
I'd learned F-sharp. And then from a shop, I learned
high school and that was actually great.
I don't know. If I could have learned Haskell
straight from C sharp that might not actually have been the case.
But spending some years with their shop enabled, me to then
learn Haskell later on. If you ask me, which language
would I pick from all the languages that I know for an
important project I would probably pick up shop because
while I really like Haskell, I'm not so convinced that the
ecosystem is actually something that you would b.
A real Enterprise on, whereas I knew that if Charles is running
on the.net framework and I know that I can trust that pretty
well, he mentioned about this as well.
So, As for this wisdom Mark has been a pleasant to talk to you
and discuss about this idea could that fits in your head.
So for people who want to follow you or find out more from the
book, where can they find it online to find me?
That's probably the existing, I have this blog called block the
plate. The Decay that's the address
from there, you can find links to the book and to my Twitter
profile and anything else, but otherwise you just using your
favorite web search engine and searching for go to fit in your
head. It's probably going to work
pretty well as well. Thanks again for your time today
mark. It's been a pleasant learning
from you. So thanks again.
It was a pleasure, thank you for having me.
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 o.f website, including the full
transcript enter, In quotes and links to the resources
mentioned, from the conversation.
And lastly, make sure to subscribe to the shows mailing
list on package. You know, that deaf to get
notified for any future episodes.
Stay tuned for the next technology, no episode.
And until then goodbye.