Ever heard the IT team talk about “technical debt”?
Sounds complicated, right?
But if we ignore it, this one “debt” can silently eat away at the health of our applications and even our business.
Here’s an easy way to think about it. Imagine we want to build a commercial building quickly so we can rent it out right away. To meet the deadline, we use subpar materials and don’t properly check the foundation.
The building gets finished fast, and the rental income starts flowing in. But a year later, the walls start to crack, and the roof leaks everywhere. In the end, the repair costs are far more expensive than if we had built it correctly from the start.
Well, that’s technical debt. The “shortcuts” the development team takes today will become expensive “repair costs” in the future.
What Is Technical Debt?
Technical debt is the ‘debt’ that arises when a developer prioritizes the release of a project (that is mostly functional) over perfecting its coding process.
Our Game Plan: How the Team Manages Technical Debt
This isn’t about blaming anyone. Technical debt is sometimes unavoidable. The important thing is how we manage it consciously as a team.
From now on, this is the approach the Logique team will take:
1. Identify and Label It Clearly
Whenever you find or are (forced to) create technical debt, mark it.
- In the Code: Leave a comment like
// TODO: Refactor [reason] #tech-debt. This will help us track it. - In a Ticket/Task: If a task results in debt, write it in the description or comments. If you find debt while working on another task, create a new ticket in the backlog with the
tech-debtlabel.
2. Communicate Trade-offs, Don’t Just Complain
When a Product Manager (PM) asks for a feature to be rushed, don’t just say “it can’t be done” or “it’s too hard.” Present clear options.
- Use this sentence: “Okay, we can get this request done in 3 days by taking shortcut A, but the consequence is that process X will become slower in the future. The proper way takes 1 week, but it will make the system healthier. Which is our priority right now?”
- This changes our position from being a “blocker” to a “strategic partner” who helps the PM make better decisions.
3. Apply The Boy Scout Rule
If you’re not familiar with this, feel free to Google “the boy scout rule in software development,” but the principle is simple: “Always leave the campground a little cleaner than you found it.” If you’re working on a file and see a weird variable name, or a function that could be simplified, fix it while you’re there! No need for a major refactoring. Small, consistent improvements have a huge impact.
4. Leverage Code Review (CR) Sessions
A code review isn’t just for finding bugs. It is our main line of defense against new technical debt. During a CR, ask questions like: “Will this code be harder to understand 6 months from now?”, “Are there any test cases missing?”, “Can this be made simpler?”.
5. Allocate Planned Time
We will routinely allocate about 10-20% of each sprint’s capacity to work on tickets labeled tech-debt. This isn’t “bonus” time; it’s a core part of our work, just as important as building new features.
Our Shared Responsibility
Managing technical debt is a collective responsibility. It’s about building a work environment where we can all be proud of our work, sleep soundly at night, and focus on more interesting challenges.
Let’s build great software, the right way, together.
