Continuing in the series of XP explained, today we discuss false feature rich, the idea that software has many potentially interesting features that are fun to program but don't provide much value to the customer. We talk about simplicity as a key feature of XP and why only the highest-priority tasks should be addressed. To learn more about the ThoughtWorks tech radar and other helpful tips to avoid the pitfalls of false feature rich software, tune in today!
Key Points From This Episode:
[INTRO]
[00:00:01] MN: Hello and 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, “False feature rich may make you poor”, or stop over-engineering things.
Still going off the series of XP explained, I'm trying to go over the basic problem. I think last time, we spoke about the schedule slips, and that could be something that's more product manager-related. But this one resonates with me, the idea of building software and building the best thing possible, using the latest and greatest tools. For me, it can cause a problem in your delivery of your software.
Reading through the bullet of False Feature Rich says the following. “False feature rich: the software has a host of potentially interesting features. All of which were fun to program, but none of which makes the customer much money. You can have all sorts of cool ways to display something on a screen. One of the things of XP, the value, one of the values of XP is simplicity, the idea that you are creating the simplest thing for a given problem. I understand sometimes simple does not equal easy. But I know on teams that I've worked on and myself included, I can kind of try to use pieces of technology that makes my resume look better or my current client to use like the cutting-edge piece of software. But sometimes, you just got to make a RESTful API, and you may not need something super fancy or something that probably requires a high load when you can do something very, very, very simple.
The way XP addresses false feature rich was that XP insists that only the highest priority tasks are addressed. So you are tasked to do the highest priority thing. But also keep in mind that you are to solve that as simply as possible. You may not want to build something that no one's going to use, right? I'm trying to think, for example, if you just really wanted the application to have to do with calculating your expenses, for example. You may want to just be able to have an input of how much money is coming in and different ways to get money to come out, right? Because bills got to get paid.
The idea of catching yourself over-engineering something so that it works for some future that no one asked for is a trap that I will say that I've done before. I hope this is a safe space because we're all still working through this. I've done it in the past, like trying to use the coolest thing possible.
I do want to give one more shout-out, a way and a tool for me to identify whether a piece of software should be considered. I use the ThoughtWorks tech radar. If you are not aware of the ThoughtWorks Tech Radar, I think every quarter— So ThoughtWorks is a consulting company that is worldwide that has a ton of clients. I've had the opportunity to work alongside a lot of ThoughtWorkers, and they're awesome. There's no denying that.
I think one of the benefits of being able to have all these clients worldwide is that you will run into a slew of technologies. Using the tech radar, they updated, I believe, every quarter or every six months. I tend to forget. The idea is to let you know whether a piece of software has been adopted. It's something that's safe to use because people will expand using this particular tool or framework.
ThoughtWorks has like four separate circles. If you imagine a large circle and the outermost layer of the circle is hold, which tells you, “Hey, you may not want to consider using this thing at the moment. We're still assessing whether it'll be, people are picking up and using this particular piece of software.” Assess is when you are currently assessing a new piece of software, and it will kind of move from assessed to whether up or down. The idea being that you want to make sure that it is a specific application for you and your use case and that kind of stuff.
Trial is like, hey, it passes the use case. It may have like the right community for you to work with. You should definitely give this a more considered consideration if you're interested in using this particular framework and adopt this something that like the community and the clients that ThoughtWorks worked with has adopted this particular technique or tool or framework or platform.
But, again, try to do the simplest thing in the highest priority order. That way, you are delivering value to your customers. I get it. You may want to work on some cutting-edge stuff. Using an API endpoint to get ChatGPT to respond and do all sorts of stuff. But if it's just a simple response or you need to make a simple text box modal, what have you, no need to reinvent the wheel. It’s probably a package that exists, and you can use that in the meantime as you assess any other particular framework that can help your business move forward. So go and deliver the thing. Do it as fast as possible and as simple as possible.
[OUTRO]
[00:06:07] 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, 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
