311. XP Values - Simplicity

Extreme programming (XP) continues to gain popularity as more and more teams are using it to enhance their development procedures. In today’s episode of The Rabbit Hole, we explore one of the core values of XP: simplicity. Tuning in, you’ll find out how keeping things as simple as possible can reduce complexity and make the delivery of high-quality software easier, enabling your team to not only deliver a better product faster but stay sane in the process!


Key Points From This Episode:

  • Why simplicity is the key to getting high-quality work out faster.
  • An anecdote from Kent Beck’s book that illustrates how simplicity saves time and effort.
  • Reasons why “simple” doesn’t necessarily mean “easy.”
  • Some of the challenges that may come with prioritizing simplicity.
  • Taking the path of least resistance (without jeopardizing the code).
  • And much more!

Transcript for Episode 311. XP Values - Simplicity

[INTRO]

[00:00:01] MN: Hello and welcome to The Rabbit Hole, the definitive developer's podcast, living large in New York. I’m your host, Michael Nunez. Today, we'll be talking about simplicity because simplicity is key to getting the work out fast.

I mentioned last week that we'll be going over the four values of XP, and I wanted to just have a conversation, I guess, with those who are listening and I myself, to remind myself about these XP values. This one is often the one that I, as a developer, often forget, the idea that simplicity is key. There's that acronym. What is it? I say KISS, but it's the K-I-S-S, which is keep it simple, stupid. Well, I think it's kind of rude to call someone stupid when they're learning how to keep things simple. But the KISS is just to keep it simple and everything that you do and the work that you're putting out.

A lot of the time, we find that developers want to just build the latest and greatest thing or use the latest and greatest technology, which often contradicts the idea of doing something simple. It's just a friendly reminder that if you can get something done much faster, even though it's simple, and it can be extended later, the better it is for your team overall. There's a story in the XP Explained book by Kent Beck. I think it has to do with the product manager wanted a dialog box of some sort. The developer wanted to – had a ton of questions on who else is going to use it, extensibility, and whether other teams can utilize this particular dialog box, if you will.

The original way of building the dialog box, according to the anecdote, takes about like 20 minutes. You have like – I guess, if I had to imagine a title, the message, okay button, this that to the third. But the developer wanted to make it more extensible, which in turn took two days to do this dialog box. By that time, the product manager came with completely different requirements. Unfortunately, that piece of code will no longer be in use at all because this new dialog box is going to have different content or different things in it.

So much so that the person who created this component, if you will, wanted to try and share it to folks, try to find someone who can use this component. Kind of the work that one would do in agile, like a lot of things are going to change. So, it's not always a good idea to start with the most verbose, complicated feature because a couple of days later, your product manager might come down the line and say, “Hey, we might need to change that. We won't even need a dialog box. We'll send them to the next page or whatever.” So, it's always good to ensure that, by putting the simplest code out, it would be best for your team to move forward.

Now, I know that does not mean that it's the easiest. Sometimes, the simplest can be the hardest. You can just make sure you are writing clean code as you're doing the simplest thing, knowing like, hey, if I needed to extend this, I know that we would have to follow this procedure, if you will. But doing that upfront can cost you a lot, especially when the project that you're working on could change midway during the sprint, for example. So always be careful of scratching that itch to want to use the latest tech or a completely different paradigm that doesn't allow you to get the work done as fast as possible.

According to the book, it says the following. “XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it and to do a more complicated thing today that may never be used anyway.” I think that captures the idea of simplicity perfectly, especially with the story that is provided by the book as well. Making those small changes, starting with something simple, if you need to scrap it, it doesn't feel as bad because you only spent 20 minutes on it. If you spend a lot of time and then it gets thrown out, that's a completely separate issue, and people may feel like all that work was done for nothing.

We always make sure that you can do the most simple thing, and that might include – this could also be a catch-22, especially when it comes to pull requests because you may be reviewing someone's pull request and may have an idea on ways to extend it and make it more extensible if you will. But that might conflict with the idea of trying to make it as simple as possible. To have to be able to defend it and mention like, “Hey, no. I'm – this is hardcoded right now because this is all we need right now. We're going to come back into this and change it.”

Definitely, as a PR reviewer, if that's something y'all do, ensure that you are having that lens of like, hey, I imagine this is going to get looked at again, or we're going to extend this bit. So for right now, these features are fine, and we'll figure out how to better fix these other things down the line.

So when you're out there producing some code, take a deep breath in, and ask yourself, what is the simplest thing I can do? We want to get that ticket from the currently in-progress swim lane and over to the done swim lane and figure out how fast we can do that without jeopardizing the quality of the code, of course. Always keep that in mind. But that doesn't always mean to make things complicated. So go out there and keep it simple!


[OUTRO]

[00:06:23] MN: Follow us now on Twitter @radiofreerabbit, 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. Never miss an episode. Subscribe now, however, you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries, 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

Stride Consulting  

Stride Consulting - Contact

The Rabbit Hole on X

The Rabbit Hole