DEV Community: Roiner Camacho Esquivel

Tech debt: What if the problem isn’t the team, but the technical debt?

Roiner Camacho Esquivel — Sat, 22 Mar 2025 10:30:42 +0000

Why does a talented team start to slow down, feel frustrated, or lose confidence in their own code?

More often than not, it’s not the team’s fault. It’s technical debt.

You can’t always see it, but you can feel the tech debt. And if it’s not addressed in time, it slows down the team, dilutes value, and turns every new feature into an uphill battle.

What is technical debt?

Technical debt is the result of making development decisions that prioritize speed over quality. It can show up as duplicated code, incomplete validations, or components that are hard to scale. Just like financial debt, it allows you to move faster in the short term, but at a cost you’ll eventually have to pay.

It’s not always a bad thing

Sometimes, taking on technical debt is a strategic decision. In the early stages of a product, it might make sense to move fast, validate assumptions, and then invest in strengthening the foundation.

The problem isn’t having technical debt — it’s ignoring it. Like any debt, it must be visible, tracked, and paid back on time.

Why is technical debt so easy to ignore?

In a development team’s day-to-day, the pressure to deliver new features usually wins. Deadlines, business demands, and the constant need to move forward lead to technical shortcuts with the promise of “we’ll fix it later.”

The problem is that “later” rarely comes. Technical debt is quiet: it doesn’t break anything immediately, it doesn’t trigger alerts, and at first, it may not even seem like a problem. In fact, it can create the illusion of productivity — the team is shipping fast. But what’s really happening is that they’re building on weak ground that, over time, becomes a serious obstacle to progress.

The silent symptoms of technical debt

Technical debt doesn’t always show up as visible bugs or catastrophic failures. Often, its effects creep in as a gradual slowdown, constant friction, or lack of clarity in the codebase.

Common symptoms include:

Development slows down: Simple tasks take longer because the existing code is hard to understand or change.
Recurring bugs: Fixes in one place reappear elsewhere due to duplicated or poorly abstracted logic.
New developers take longer to onboard: The learning curve is steep due to lack of structure or clear practices.
Small changes require big effort: A single update requires touching multiple files or navigating risky dependencies.
The team loses confidence in the system: Developers avoid certain areas for fear of breaking something.

These symptoms may seem normal in the day-to-day, but when they persist or intensify, they’re a clear sign that technical debt is limiting your team’s ability to move safely and efficiently.

The real cost of not paying down technical debt

Ignoring technical debt doesn’t make it disappear. On the contrary, it makes it grow — and so does its impact on your product, your team, and your business.

As the system becomes more complex and less maintainable, the team loses speed, confidence, and energy. Quality drops, bugs increase, and every new feature becomes more expensive in terms of time, money, and effort. Eventually, progress slows to a crawl — or stops completely.

From a business perspective, this means lost opportunities. A product that can’t adapt quickly to market changes, that takes weeks to ship improvements, or months to scale, is a product losing ground to the competition. On top of that, maintaining systems burdened by technical debt usually requires more resources — both human and financial.

That’s why paying down technical debt isn’t a luxury or a “nice to have.” It’s a necessary investment to protect your product’s future and your team’s long-term sustainability.

How to tackle technical debt without slowing down the business?

Paying off technical debt doesn’t mean halting everything and entering “maintenance mode.” Quite the opposite — it’s about integrating it strategically into the development process so that the team can move faster and with less friction over time.

Here are some effective ways to do that:

Identify, prioritize, and act at the right moment: Not all technical debt is equally critical. Detect, classify (by impact, frequency, or risk), and focus on what directly affects the part of the system that’s about to change. That way, new features are built on cleaner, more sustainable ground.
Plan realistically and technically: Addressing technical debt requires coordination with product team and technical management. Whether by reserving specific sprints or including the technical effort in each story, these tasks should never be treated as “extras”. Refactoring, cleanup, or structural improvements should be estimated and prioritized like any other value delivery.
The key is communication: When the technical team can clearly explain why certain efforts are necessary — and how they affect future speed and quality — it’s much easier to get buy-in and make sustainable decisions.

Final thoughts

Technical debt isn’t the enemy. Ignoring it is. It’s not about eliminating it entirely, but about recognizing it, understanding its impact, and making conscious decisions to manage it.

Paying down technical debt isn’t a waste of time — it’s an investment in your team’s health, your product’s evolution, and your business’s sustainability.

If we want to move fast, we first need to make sure we’re not carrying too much weight on the way.

Maybe the question isn’t if there’s technical debt, but:

What part of your system is asking for help — and are you listening?

Working to be a creative person…

Roiner Camacho Esquivel — Mon, 24 Oct 2022 23:22:58 +0000

I always have been in love about some “special characteristics” from my professional career, maybe my favorite is the possibility to be a creative person

As computers professionals we have an incredible influence in the business scenarios for entire companies, our decisions could have consequences in other departments besides engineering, and even for the financial perspective.

A couple of years ago I understand how from our computer we can impact the life of thousands of people, as software developers, always our main goal is related to improve the user experience, we are constantly asking similar questions: “how can we do this possible?”, “is possible to improve this transaction for users?”, at the end of the day, this is also the idea for web-sites, applications and other software products.

Creative skills

Something that I like to promote are my creative skills, I’m constantly looking for opportunities to create a software solution for some personal requirement, understanding that this is a good way to learn, practice and also, I believe than some day this could be a good solution for thousands of other people.

A couple of weeks ago I was talking with friends about the Soccer World cup, it is coming on November 2022, so we started looking for some app to control and manage data for a common game about predictions, this is very common for some countries in Latín América, this game name is called QUINIELA.

I realized that maybe this could be good opportunity to create my own app for that, so I started thinking about how could be my ideally app, what and how should be the implementation, and then I was motivated to start working on that.

Benefits

Even when I have been working with software for the last 12 years, is very exciting to start doing things that I don’t do frequently, it’s common to aboard projects with technology stacks very defined, and also with guides or a list of defined “how to” do different thing, because of that we don’t need to define a lot of implementations, rules, or new ways to work.

This kind of projects are a great opportunity to working in that implementation that we read and did not have space to do, or maybe to be familiar with some new library, or just get up to date with the new released version of some know library.

This is also a great scenario to discover new things, we can not understand from the beginning the impact about to start doing something by our own, at some point we are going to need something and the only possible way is to investigate, trying to figure it out how to do it, and this is how I discover new possibilities with Vercel, Next.js, Firestore and some other new things, I love this part of the process.

What I did? — My own app

This is how I started creating my own game — its name is QUINIELA-CR

It’s basically a prediction game, as a player, you should introduce a score for each game in the tournament, you are going to get points according to you accuracy, it’s very fun when you play this with friends, because everyone is thinking, and watching the games from a different perspective, “how to win points”.

Technology Stack

The tournament is close to start, so I define to use know technologies like React and Typescript, however, I also used this time to practice with some libraries that I do not use daily, but not everything was old, I discovered some new tools, implementations and ways to work.

Here is a list of technologies and libraries that I used:

React
React hooks
TypeScript
React router
Styled components
Redux
Vercel
Firestore — Real time data
Git
And, other additional libraries and services

How do I started?

My first step was to define the data-base structure, I decide to use Firebase, this is a non-relational data base from Google, this was the first interesting thing that is different according with my daily work as developer.

Something very interesting was to think in order of “how the app is going to display data”, is different than think in object-relational model.

A new challenge was to discover a new way to host, and release my app, I start using Vercel, I have beed reading about it, so it was a good time to test it.

After that, I started working in the project, using React and Typescript to define the project, adding redux to have a state in the project, handling actions and effects, it was a very nice process, I discovered new solutions from my last time working with redux and hooks, always is nice that satisfaction feeling about to learn how something new it’s working.
I was working two weeks on nights, I created my first version, now it was a good moment for QA, obviously I did not have QA resources, so I used my friends as testers, the are my “final client”, so if this version works for them, it will be a success.

This was really useful, they discover some pending things, or even some bugs that I introduced, this is something normal, but even for them it was a really good experience, they been part of some “software definition”, sometimes we can promote something new in people, this is part of create software.

The application

Here are some screens, this is how the application looks like

The login a register screens, as any other app, you are going to have the option to login into the game.

As a player, after login in the app, you will see this screen to introduce your prediction for each game, you can set the amount of goals for both teams, and then you wait until the game finish, according to the result you will get points.

The application also has a screen to see the positions table, at the end of the tournament this table will define the winner.

Besides these screens, in the app we have other sections to players:

Customize the app, defining name, username, password an other values.
Other options for admins, to manage the application, create games, introduce games, maintain players, and many other functionalities.

The application is small, but at the end of the day the most important is all the factors around the app itself.

Always we can add new value, new functionalities, but at the end we should understand that this is a workin in progress, this kind of things happens in software.

Conclusion

My friends and I — Now we are ready, we are waiting for the world cup tournament, this time it will be a different experience for us, because we are expecting for the experience to use the app that we created.

“The results you achieve will be in direct proportion to the effort you apply.” — Denis Waltley

My conclusion is, be creative is something really useful as software professionals, sometimes we don’t know how this could improve our professional career, but been working in this kind of projects like this application, is a great experiment time, is like to create our own playground for coding, we are free to try, to prove, and even to fail.

This kind of process works to discover and understand the capacity of us, is really nice the have this in mind. I’ll continue looking for the new opportunity to came software solution in my real life.

I broke my thumb, and I learned about Adaptability

Roiner Camacho Esquivel — Tue, 13 Sep 2022 06:57:52 +0000

The last week I was reading about: ADAPTABILITY, I was trying to understand the meaning of this word, and the following quote was very interesting for me

“the change is the only constant in our lives.”

I read about the change, it is uncomfortable, it is unfamiliar, and some times it scary us, and this is normal, this is ok.

I was imagine different scenarios about how to incorporate the adaptability in my life, “What if the project assign change?”, “What if some team members change?” but, I did not see what was about to happen.

A change was coming

The thing is, I like to play soccer, the past week I was playing with friends, well, the ball hit my fist, breaking a thumb on my left wrist, I could not believe it, I’m a software engineer, and I can not use my computer for a while!

The following day I knew that I require surgery, and it means some rest after that.

I was with something really different and new, something perfect to try to adopt this new word: ADAPTABILITY

What I learned from this accident?

1. You can not control everything, and this is ok

Sometimes we think that we are irreplaceable, and we force us to do things because “who else is going to do this?”, but if something like this happens, we understand that at the end of the day someone else can replace what you do, sorry but this is true

Always I’m going to do my best, but understanding that I need to be fine to work, I need to take care of myself to add all the possible value to my company

2. We work with people, we are not machines

I work in a company with amazing people, when I talked with my boss, her firsts questions were “how do you feel? are you ok?”, in a business with a high rush and filled of higher priorities to complete, feels very good to be involved with people that makes me feel good, people that take cares of me as a person, more than an engineer.

Also, this makes me understand that this kind of accidents occurs, and we should understand and support people when this happens.

3.Positivity

I read from a book the following text:

You can hear from many different channels that you should see things as a Challenge and not as a Problem

When I was in front of this scenario, I was trying to identify what can I get from this as a Challenge, and the result was clear for me, I’ll use this time to study some pending things and see a couple of courses that I did have time before.

I mean, probably this is not a “big Challenge”, but In my scenario I only have two options, try to fix this and work with that I had, or just sit to re think “why did that happen to me?”.

Today I’m recovering from the surgery, taking some time for me. I’m reading, learning, watching some courses, and also, using this time to think about how lucky we are every day

It's maybe a different perspective about design patterns

Roiner Camacho Esquivel — Tue, 06 Sep 2022 23:19:01 +0000

Have you ever been on a team where you don’t have like a clear idea about how to do an implementation of some feature? This is a common case as developer, also so many times we are working on similar features, always working with “objects” definitions, a new screen to handle a form, or doing a new request to get a list of data from the data base, all these cases are an example of where a design pattern is useful.

What is a design pattern?

I understand a design pattern like:

A defined approach to work when I’m working in some common functionality

I like this definition from sourcemaking.com

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

As engineers we like to know how to do the things, we need to understand what is the expected result from our work, there is where a design pattern helps us. We can imagine that we are working with so many incredible senior developers, and using their expertise, they propose a way to do our job, that is a design pattern, for us it is a define and optimized way to do our work.

Types of design patterns

Exists a lot of design patterns, these can be classified in 3 types:

Creational: Patterns designed for class or object instantiation
Structural: Patterns about the structure and composition
Behavioral: Patterns designed about how one class communicates with others

Let’s talk about patterns in React.Js

React as UI library is a common way to compose a user-interface (UI) using JavaScript, when we work with React, we are going to create a whole UI by separating it into small reusable components, this is *componentization*.

I’m going to introduce a couple of design patterns that I common use with React.

Singleton Pattern

Singletons are classes that can be instantiated once, and can be accessed globally, this instance can be shared throughout our application.

If you are a React developer, probably you see some familiar behavior with global state managers, for example Redux, EasyPeasy, MobX, all of them are different ways to have a global state in our apps, its basically the singleton pattern, we are going to have a only instance for our state, and the state is shared across the entire app.

did you see? the state management was a common problem in our applications, some developers understand that and fixed it using this design pattern

Provider Pattern

In some cases, we want to make data available in some specific components, but maybe we don’t have a state manager library implemented, or we need to use a different approach.

In React we can pass props far down the components tree, but exist a limitation if you required to pass props up in the components tree, its name is prop drilling.

In react you can create a new context provider, its an object to manage the context throughout the applications, to manipulate the context you can use a hook (useContext) to implement this provider pattern

Container/Presentation Pattern

This is a way to enforce separations of concerns, the principle idea is to have separate the view from the application logic.

We can define presentational components, these are the components that take care about how to show data to the user, and also define container components, these are component that take care about what data is shown to the user.

If you think in a list of images, we can define a container component with all the logic to fetch data using an api service, and also define a presentational component with all the jsx code to displaying data.

Hooks Pattern

This is my favorite! 😁

React 16.8 introduced a new feature called Hooks.

This pattern is derivation of Container/Presentation pattern, because is the same idea but implemented with hooks, so we are going to create a component with all the implementation about how to display the data, and then define a hook with all the logic related to the presentational component.

In this hook we can control everything related to logic, for example: interactions with services, user events in the UI, or form validations.

Other common design patterns

HOC Pattern (higher order component), this pattern is a common way to reuse the same logic in multiple components, is used to add functionality or logic to components

Proxy Pattern, with this pattern we can define with more control the interactions in our objects. We can define functions over the object definition.

Conclusion

At the end, Design Patterns is not something difficult to understand, they exists because when we are coding we are constantly resolving the same scenarios, and they give us a define and confirmed way to implement a solution.

Sources

Patterns: Stay up to date on the latest design and performance patterns. - patterns.dev

Source Making: I'm SourceMaking. I will tell you a lot of stories about good software… - sourcemaking.com