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.