Gambiarra: How Quick And Messy Solutions Lead to Technical Debt

Gambiarra: How Quick And Messy Solutions Lead to Technical Debt

By Charles Matte
Gambiarra examples

Have you ever tried using a hairdryer to defrost your freezer? No? Really? How about using duct tape to keep your fridge door closed? If these examples sound familiar, welcome to the world of "Gambiarra." For the uninitiated, gambiarra is a Brazilian term that describes using something in a way it was never meant to be used—a creative, maybe clever workaround, but definitely not a long-term solution.

In the tech world, gambiarras are like adding side-effects to existing code instead of creating proper functions and methods to address those issues. This leads us to what we like to jokingly call "Gambiarra-Oriented Programming" (GOP) as a play on Object-Oriented Programming (OOP). In GOP, you might take a shortcut by forcing a piece of code to solve a problem it wasn’t built for or tweak an existing feature to perform an unintended function. GOP is all about quick messy solutions where functions and methods now start doing different things from what they were originally named for. These makeshift solutions might get the job done in the short term, but they contribute to what we call technical debt.

Now, technical debt isn't like owing money, but instead like that clutter you accumulate in a garage. It starts small—an overlooked bug here, a rushed feature there—but over time, it accumulates, making future development more costly and time-consuming. The “interests” on this debt are compounded, each new feature or addition to the code has to work on top of these kludges and workarounds, slowing down progress and making maintenance more complex. It's the tech world's equivalent of putting off that rickety chair you keep meaning to fix but never do; eventually, it’s going to collapse, probably during Christmas dinner.

So why do we end up with so much technical debt? Sometimes it's due to tight deadlines, where the focus is on delivering quickly rather than correctly. Other times, it’s because the immediate workload leaves no time to revisit those temporary fixes. And often, it's the temptation to implement a quick fix with the mindset of "I'll get back to this later"—though "later" never seems to come.

This accumulation of “debt” not only disrupts development, but also makes it impossible to provide stakeholders with accurate estimates. What seemed like a straightforward feature implementation on the drawing board can now become unexpectedly complex as technical debt surfaces, throwing off delivery schedules in major ways. Over time, the cost of managing this debt can skyrocket, ultimately making it too expensive to build new features. It's a game of whack-a-mole, where a quick fix becomes a permanent feature and starts creating more problems than it solves.

But how do you avoid technical debt in the first place? Two key practices can help: writing clean code and following Test-Driven Development (TDD).

Writing clean code means keeping your codebase simple, readable, and easy to maintain. Each piece of code does only one thing, and does it well. It’s about doing things right the first time, even if it takes a bit longer upfront. Clean code avoids unnecessary complexity, making it easier to build upon and less likely to accumulate technical debt over time. It’s like keeping your workspace tidy—everything is in its place, and you can find what you need without digging through piles of clutter.

On the other hand, TDD is a development process that promotes writing tests before the actual code. By defining the desired outcomes first, you ensure that your code meets the requirements and is easier to refactor without introducing new issues. TDD naturally encourages developers to write clean, modular code since when writing tests upfront, you’re compelled to keep your code simple and focused. Together, TDD and clean code practices form a strong deterrent against technical debt.

But what if you’ve already accumulated technical debt? It’s not enough to acknowledge its existence; you need to prioritise it. This means setting aside time to refactor old code, update dependencies, and revisit those "temporary" solutions. The cost of ignoring technical debt isn't just in the code; it's in the impact on your business and your team's morale. It’s like decluttering that garage: start with the small, manageable stuff, like throwing away old boxes, and gradually work your way up to bigger projects, like rearranging shelves.

So, the next time you're tempted to fix something with a digital equivalent of a coat hanger and duct tape, remember: today's gambiarra is tomorrow's technical debt. Investing the time and resources now into clean code not only prevents future headaches, but can also save you enormous amounts of effort (and money) later. By doing things right from the start, you set the stage for a more sustainable, scalable system. And if you’re feeling overwhelmed by technical debt, our team at Monarq is here to help. We specialise in identifying and addressing these issues, ensuring your systems are robust, efficient, and ready for the future. Let's keep our digital houses in order!
 

Need help identifying and addressing these technical debts?