Refactoring vs. Feature Work

Track the balance between maintenance and features

Refactoring vs. Feature Work

In one of my projects, we introduced Maintenance Fridays. A fancy name for dedicated time each Friday when we were addressing technical debt. At the beginning, participation was voluntary, and not everyone joined. Over time, however, the impact became clear: the overall health of the codebase noticeably improved.

Before this change, the team was heavily focused on shipping features. While delivery speed looked good on paper and dopamine levels were high, the cost was accumulating technical debt. Maintenance Fridays provided us a safe space to spend some time on bike-shedding and refactoring.

Why it matters

As a tech lead, balancing feature pressure with long-term technical health is a constant challenge. Practicing Maintenance Fridays made that balance easier because the Product Owner was aware that part of our capacity would be invested in cleanup and refactoring.

Cosmic Analogy

Imagine your codebase as Earth's orbit. Launching satellites (features) adds capability, but without clearing debris (refactoring), the orbit gets cluttered with technical debt, making every new launch more dangerous and expensive.

Track your "launch vs. cleanup" ratio using conventional commits, and schedule regular cleanup windows (like Maintenance Fridays). So stakeholders expect and support refactoring time.

Cosmic analogy

Refactoring vs Feature Visualization

How to Fix

Planning & Goals

Set explicit team goals for refactoring time. You can aim for 10-20% of commits dedicated to technical health.
Schedule dedicated refactoring sprints or allocate time in each sprint for technical debt reduction.
Create a technical debt backlog and regularly review it to address the highest-impact items.

Tracking & Visibility

Use conventional commit messages (feat, fix, refactor, test) to track work types.
Make refactoring visible to stakeholders by tracking metrics and showing impact on velocity over time.
Monitor the bug fix ratio. If it's climbing, pause features to address underlying quality issues.

Prioritization & Balance

Prioritize refactoring in hotspot areas where technical debt actively slows down feature development.
Balance feature pressure by demonstrating how unchecked debt leads to slower delivery and more bugs.

Culture & Habits

Apply the Boy Scout Rule: leave code cleaner than you found it with small refactors in every feature commit.
Celebrate refactoring wins and test coverage improvements to build a culture that values maintenance work.

Does this actually work?

I've been running this analysis against real repositories in Code Evolution, a personal side project, to see whether the idea actually makes sense in practice. It's still rough and unfinished, and for now it only uses a demo repository, but you can already check it out. I'm planning to open-source it soon.

See this one running