Bandaid Code Is a Bad Habit

08/28/2024

Lately I have been thinking a lot of game and code infrastructure, and it got me thinking about this. But, Band-aid code is bad habit. And it's nothing new, but it seems to come up quiet often again and again. And recently it just seems to happen more often than it had in the past.

Essentially the problem I've been seeing for projects, is commonly referred to as "Scaling". But it's a little more than just that. I feel calling it a scaling issue might be over simplifying the isssue, Because it's more a lack of planning for a large scale project to succeed, and a failure to adapt. And that's the disturbing trend I'm seeing crop up everywhere in the Software industry. Essentially, it feels like developers aren't properly planning for not only their code, but their content to be scalable and flexible from the beginning. That the project had great ideas, but it feels like they fail to consider industry trends and features that users will want in their product. A part of this could be due to hiring young, fresh developers who have great ideas, but a lack of experience and understanding of things such as applicaton, web and gaming Infrastructure. And another part could be, senior developers who do not know of new trends and have no idea of said new features. A mix of both, with good communication is a must have to succeed and properly plan.

Band-aid code is the product of failing to adapt a project to fit its scale. It happens to all of us and to any project. Something comes along that the original planning for the project didn't account for. But when the project is not refactored to to adapt to the new and needed feature, we then instead, end up with band-aid code.

But the real problematic part is how often these products seem to be failing to adapt to these problems as they arise. Code can be refactored to scale. But that is usually not the case of what ends up happening.

A typical example of this is to meet a deadline, a company will rush the developement of their product. Instead of planning out how to refactor a products code base for a feature, companies will try to implement that feature in an inappropriate environment. Following this, bugs will occur and developers will just fix the bugs as they arise, which leads to sometimes major conflicts. Where the code of feature A will by design not work with the code of Feature B, because the two use features of the code base in two entirely different ways. And this pattern of development will always lead to discovering deep rooted issues of the codebase. Then instead of fixing the deep rooted issue, developers will create work around code, that we developers like to call, "Band-aid" code.

I feel band-aid code has become more common because a lot of Software managers seem to fear doing what's needed to properly fix an issue. It seems they fear fixing the issue will be expensive and time consuming. They may even believe that by fixing the issue it will cause a lot more bugs that will also need to be fixed. Which is true, but, that one is not as duaghting as it should be.

In a lot of cases band-aid code leads to more problems. And because of this, it becomes more expensive for the company producing the product to deal with band-aid code. Almost always, I have discovered, that identifying the root cause of these problems and fixing them, will yes, causes a ton of other bugs! However, it becomes very clear to everyone that by fixing them, leads to other major problems going away. This then avoids wasting developer time spending needless hours on trying to fix these deep rooted problems with band-aid code.

As mentioned this process will cause bugs, but I have also realized that, as you work on the bugs caused by fixing the problem, you'll discover they are mostly simple quick fixes that one developer could probably clean up large amounts of in a small 2 hour task. So it may seem scary, and it may be a lot of work on your project manager to task all of these bugs. But in the end, it actually saves the company time and money.

But it's not easy to find these kinds of deep rooted bugs, and refactor for the fix. This is where someone like me comes in as a Staff/Infrastructural Engineer. As someone who specialize in doing so, I know it takes someone with the right way of thinking who knows what to look for. Someone not afraid to create UML diagrams and trace back an issue through piles and piles of abstraction, to identify the issue. So what I ask of the industry, is to not be afraid of this. If you have that rare person in your staff who's willing to do this, let them, and encourage them to do so. It will seem like a headache to deal with in the short term, but in the long term it will be saving tons of time and money for the company.