In this episode of The Rabbit Hole, we're talking about The Rules of Simplicity and why you should be following them when building software. We break down the four Rules of Simplicity first laid out in the book Extreme Programming Explained: Embrace Change by Kent Beck and discuss how they relate to other rules and principles that we’ve discussed on this podcast in the past. For a quick crash course on The Rules of Simplicity, why you should be practicing them, and how to go about applying them today, don’t miss this episode!
Key Points From This Episode:
Transcript for Episode 275. The Rules of Simplicity -- Are you following them when building software?
[INTRODUCTION]
[00:00:00] MN: Hello. Welcome to The Rabbit Hole: The Definitive Developers Podcast. Living large in New York, I'm your host, Michael Nunez. Today, we'll be talking about The Rules of Simplicity. Are you following them when building software? Well, let's find out.
Before we dive into The Rules of Simplicity, let's talk about who created these rules. The rules were created by Kent Beck, when he wrote the book, Extreme Programming Explained: Embrace Change, many, many moons ago. I think this is probably 1999. I actually have the book on my desk, and you probably hear me flipping pages. Yeah. Around 2000/99. I believe this book was released.
A quick TLDR to what is extreme programming. Extreme Programming is pretty much like any other agile methodology that you're familiar with, but it focuses on the technical practices that software development teams should be doing every day. That includes test driven development on all production code. When you're working on that code, you're working with pair programming in mind, so that means two developers to a particular story or task, and that those developers have the autonomy to continuously refactor the code that they're working on.
At Stride, we are XP practitioners, and if that is something that you're interested in your organization, feel free to reach out at stridenyc.com/contact. I'm sure someone will get back to you on how we can help upscale your team, but that's extreme programming, in a sense. And I will go over the rules, and you'll see how extreme programming goes with the rules of simplicity.
I'll read the rules from the agilealliance.org. The Rules of Simplicity are the following. Number one: the code is verified by automated tests and all such tests pass. Number two: the code contains no duplication. Number three: the code expresses separately each distinct idea or responsibility. Number four: the code is composed of the minimum number of components that includes classes, methods, lines, compatible with the first three criteria. Those are the rules, four rules, that's it, close up shop. Thank you for that. No, I'm kidding. I'll dive into each one of these particular rules, one at a time. Let's start with the first one.
The code is verified by automated tests and all such tests pass. This idea is that you ensure that you're test driving your code, writing the tests first, making it pass, and then identifying whether refactoring needs to be done for that particular feature you're working on. I believe that is called the triangulation, the ability to say something's read, make it pass, refactor. I personally call it the TDD waltz, right? Because it's a three step dance that you need to do. I guess that's not really, I just googled it right now. I don't know if someone actually calls it that. I might need to go ahead and copyright that little phrase.
The TDD Waltz is essentially or what I call when you are test driving your code, red, green refactor. That is the dance you will do constantly until you go down the stack if you're working outside in. But the rule of simplicity is simple. In this first line, at least, just ensuring that you're running all the tests and that they're passing. Writing the tests first and then making it pass, ensures that you're delivering exactly what the feature is requesting and the acceptance criteria can be flushed out into tests that you can then validate with your implementation.
The second one is, the code contains no duplication. I think the next couple of rules might actually give us a call back to previous episodes that we've recorded. For most developers out there. I imagine what comes to mind at first is the DRY principle, don't repeat yourself and ensuring that you don't break that rule. Oftentimes, we continue to refactor and ensure that we're not repeating ourselves, but there's definitely arguments that have been done as to when you should start to DRY up your code, and making sure that you have one implementation. Do you start at two iterations of something? Do you start at three iterations of something? What more?
Many, many moons ago, Episode 113, we did record an episode on how the DRY Principle is misunderstood with the Steven Solomon friend of the show. We pretty much talk about like how do people dry their code? How it can disrupt your way of working in one way or another? But always ensure that you are drying up your code so that it makes changing that code better. I think that's the idea of dry.
Often times you can make it too dry, it'll be like a Popeye’s biscuit and you don't have water next to you, which may cause trouble for both you and a Popeye biscuit and how you dry up your code. Just make sure that it does help you in the end when you do remove any duplication.
Number three. The code expresses separately each distinct idea or responsibility. Now this is a call back to me when I read this particular rule of some of the principles we've spoken about in the past that including the solid principle and the one specifically, Episode 162, we talk about the Single Responsibility Principle, that is the first one of the solid. Ensuring that you look at a piece of code and you know exactly what it does and it's responsible for one thing make things easier to debug and to change in the future, because you know that this class is only going to do one thing, or this function is responsible for one thing.
We dive in a little bit deeper on the Single Responsibility Principle and ensure how do you do that in your code, but the idea is making sure that your code makes sense in the naming of that particular class, method, or function. Ensuring that even though you name that correctly, that it's doing the thing that it's saying and that it's one, it's responsible for one thing, when you have that, I imagine, it'll be simple to make changes, to make an update, to extend it if you need to, ensuring that you're following the rest of the solid principles.
Lastly, the code is composed of the minimum number of components, classes, method of lines, compatible with the first three criteria. This is ensuring that you're respecting the first three to the best of your ability with the minimum number of components, right? Just trying to make things as simple as possible. You don't need to create all these different classes of shapes, if you're only dealing with one shape right now. Ensuring that you need to dry up your code, do it in a way that makes sense without creating too much of those confusing components, so that you can continue to extend it down the line.
I think, as I mentioned in the previous rule, this particular but the final rule is like the rest of the “olid” in “solid”, if you will, where you make sure that you have the open close principle, The Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. We definitely have episodes around the 162 episodes. I imagine that there have been remixes in the past for those, but those particular principles will def ensure that you are a respecting that final rule of ensuring that you're building with the lease with the minimum number of components and in doing so respecting the first three bullets.
I think the only one that is a really enforced by the solid principle is the fact that you need to write automated tests, which is something that you should be doing at the moment on your software teams, regardless of whether you're practicing XP or not, because it gives you that confidence that your code is going to work. That you can make changes much more gracefully and when you make changes, it's just a lot more easier.
Shout out to Kent Beck on creating The Rules of Simplicity. That way, we can continue to build the simplest things that we can provide for our users in whatever application that we're building. If your team needs help with building software, feel free to hit us over at stratanyc.com/contact. Hey, you might even get me, who knows, to help you out with your team.
Follow us now on Twitter at Radio Free Rabbit, so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers just like you find their way into the rabbit hole and never miss an episode. Subscribe now wherever you listen to your favorite podcast, on behalf of our producer extraordinaire William Jeffries, and my amazing co-host Dave Anderson, and me your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
Extreme Programming Explained: Embrace Change
113. The DRY Principal is Misunderstood with Steven Solomon
