Reinvent the Wheel Anti-Pattern

Welcome to Building Better Developers, the Developer Nord podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We're continuing our season where we are talking about architecture, software architecture, patterns and anti-patterns. This episode, we're going to look at and walk through the Reinvent the Wheel anti-pattern. This is a pattern where we almost seem to feel like we're going to get bonus points for doing more work than we need to do. And that is an anti-pattern. That is the problem with it. We don't get bonus points. We don't get credit for working extra hard, particularly when we don't need to. And that's the key. We want an architecture. We want a solution where we are doing the right amount of work to solve the problem. And that's it. We've looked at other anti-patterns where we end up doing more than we're supposed to. We add bells and whistles or we creep the scope in a direction that is not useful. Or we don't rein in the scope when people start talking about requirements and options and enhancements and growth and things like that. The problem with Reinvent the Wheel is not that a problem is getting solved. It's that we're solving a problem that's already been solved. Now this can be because we just want to do it. We want to put the extra effort in. We don't want to go use somebody else's solution. It's just for whatever reason not appropriate. We don't judge it worthy. Or sometimes we think we can do better. Now in some reasons, in some situations, that's perfectly valid. If your special sauce, if your value add to the solution is redoing a solution that's already been done, then that's not reinventing the wheel. That's improving on the wheel. That's saying, okay, these other people made a solution that was feasible, but we're going to do it better. Or our solution needs a better solution than these things provide. Sometimes there are things like scalability, maintainability, performance, where the available solution is not good enough. It's not going to cover your specific needs. And that's okay. That's not reinventing the wheel. Reinventing the wheel is when in particular you're putting this effort in to solve a problem that really is ancillary, is some non direct piece of your solution. For example, because I use this all the time, it may have a log in to your application. There's no value for 99.999% of the applications out there and building their own login. If you have a solution that's essentially off the shelf, off the internet that you can incorporate in so you don't have to worry about it, go for it. There could be security concerns or whatever, but generally speaking, you're going to have components. You're going to have pieces of your application that are solutions of some sort. And there's no value in you redoing that, reinventing the wheel. Instead just go with it and spend the effort, the time, the resources on the things that are your true value add. And in a lot of cases, it's also focused on your true problem. There's no sense in building a big framework of an application or an architecture that is, I'm trying to think of the best way, but like administrative type tasks, things like user management and general data management like CRUD, stuff like that. It create, remove, update, delete, or actually it's create, retrieve, update, delete types of actions on your data. The things that these are problems that get solved in every application. And so why spend the extra time solving it yourself for your application? Why spend the time trying to re solve a problem that where the solution is readily available? Now this is not say that there are not situations and arguments for doing it yourself. And there's all kinds of different reasons. Like I said, it may be performance, maybe maintenance, it could be cost, maybe something where, yeah, you would love to be able to use that solution, whatever it is, but it's just too dang expensive or the licensing doesn't work for your model. You're going to end up not being able to make it work. That's okay. Not reinventing the wheel. Obviously though, it's not so much, it's not as obvious. A lot of times we end up reinventing the wheel because we start into our problem and maybe we assume that it is more unique than it is, that people haven't seen it. And we solve pieces of it only to find out later that, oh, this has already been done. Maybe even in some cases, this is already part of the core language. We just didn't realize that that was something in the latest release or we're a version behind if we had upgraded to the current version, then maybe we would have that feature. That would be a solved problem for us. And this does occur quite a bit when you deal with very active languages. Java, for example. And actually Java and C Sharp are great examples because what you have is a vibrant developer community and actually you think of like Perl, React, these things are out there too, where there are a lot of people working in this. They are working on similar problems and so they end up building similar solutions. And somewhere along the way, somebody says, hey, I'm going to turn this into a third party library or component or framework or the standards body or whoever it is that is growing the language sees that this thing is being done a lot. This problem is being solved a lot by the developers using their tools. And so they create craft or create an easier way to deal with that in a new version. Particularly, I know Java has done this and it seems like C Sharp has done a lot of this too where with one version, you'll see some things sort of go in a certain direction and developers can sometimes see that their challenges in earlier versions are now being taken care of as new versions come out. So it's easier to do common things. And again, it often comes back to patterns and anti-patterns. If there are a lot of patterns that we adopt on a regular basis, then we will find those components existing in the language. So we will find things like, if you go back to the Gang of Four patterns, you will find things like iterators as part of languages and factories and singletons and it's like all kinds of different things in there that you'll see that that pattern has basically already been somewhat provided for you. So in those cases, why figure it out yourself when you can use what the language already gives you or what the framework already gives you? And in some cases, this is in an architecture sense even worse because you're spending a lot of time defining and then implementing that solution because you're having to make that part of the architecture. You're making that, you're pulling that piece in and you're starting from scratch when you don't need to. Another issue with this is that you're doing this, it seems dismissive to say you're doing this for the first time, but you're doing it from scratch. Even if you have done that before for other customers and other solutions, if you start from scratch, then you may make mistakes that anything else you would have grabbed would have already caught those because they've been, maybe because they have been used multiple times. I think most of us have seen that when you use software, the first time it's going to be buggy. You reuse it and use it a second time and it's going to be much higher quality. By the time you get to the third or the fourth time, you've had enough different types of users and numbers of users that you've probably got a pretty solid piece of software, a pretty solid component. So when you reinvent the wheel, you lose all of that. You go back to square one as far as quality is concerned and that can cause you problems. That can mean you end up doing a whole bunch of testing when you don't need to. And while that may seem like something that's, yeah, that's good to know, but it's not that big a deal. It really is. When you think of quality and you think of the time and the planning that goes into testing, when we have known quantities, we have known components and pieces of work where we can make some assumptions about them and not have to test from scratch, that can be huge. In architecture, we can spend a lot of time building out these tests, especially if we create it, start from scratch. But if we don't, then we have all of those tests and all of that time that we don't have to worry about. Those things are already in place, particularly even better if what we're using has its own test suite as part of it. Then we get all of it in one shot and don't have to think about it. Somebody else has, somebody else has put the time in, they've proven it to some extent. And so that just like skyrockets us, jumpstarts us quite a bit on the actual solution that we want to build, not all of the surrounding things that we need to build to get to our solution. And when you think about the progression of software solutions and you look at how many things are out there today that are configurable or low code or no code types of solutions, when you get down to the brass tacks, this is the opposite of reinventing the wheel. These are solutions where enough real examples were put together so that we now have a way to very quickly get to focusing on our solution as opposed to all of the other things that are just a part of a solution. That can be a huge time saver and also give us a great foundation to sit on for when we're working with our solution. We don't have to go worry about all of these other things because they're there, they're in place, they have been tested, they are integrated, all of the important things that we want. And that leaves us free to focus solely on our solution. That is how we get things done faster and better and how we build our solutions on the shoulders and backs of those that went before us. This also applies to what we've done. If you are in, particularly in an organization where you've been there for a while and you've been through multiple projects, don't be afraid to look at prior projects, prior solutions, particularly if it's the same organization, same lines of business, because you're probably going to see over and over a lot of the same types of problems to be solved. So if you already solved that in a prior project, there's no reason to do it again unless your prior solution was trash, in which case you didn't really solve it. But if you got something that worked, even if you're looking to improve upon it, it may be that you start from that working solution and tweak it as opposed to starting from scratch. So hopefully there have been enough reasons behind this discussion that you can understand that reinventing the wheel does not get you brownie points. It is not a good approach to take. It really is being busy versus being productive. And we know that you're not going to be a better developer just by being busy. You become a better developer by being more productive, producing more solutions, better solutions, faster solutions, higher quality solutions, all of our favorite buzzwords and ways to measure success of a solution. So don't be afraid to utilize others. You do it all the time anyways. If you jump on Google and you Google a solution, boom, you are trying to avoid reinventing the wheel. And while he had that, you know, there's always some concerns about that. You want to make sure that what you grab makes sense, that you understand it. But it can be very helpful in getting you to get to the solution you need faster, sooner rather than later. That being said, I'm going to let you get back to work sooner rather than later. So go out there and have yourself a great day, a great week. And we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. There are two things I want to mention to help you get a little further along in your embracing of the content of Develop-a-Nor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Develop-a-Nor site. You can also find it on Amazon, search for Rob Rodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week. And this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at Develop-a-Nor dot com if you would like more information. Now go out there and have yourself a great one.