Strangler Fig for Service Migrations

When you need to replace a legacy service entirely, the strangler fig pattern (named by Martin Fowler) is the safest path. Stand up the new service alongside the old. Route a percentage of traffic — start at 1%, ramp slowly, watch the metrics. Migrate functionality incrementally.

Months later, the old service handles zero traffic and can be deleted. No big-bang cutover, no rollback nightmares. The Martin Fowler StranglerFigApplication essay remains the canonical reference.

Expand and Contract for Schema Changes

Renaming a database column in a production system without downtime requires three deploys: add the new column, write to both columns, deprecate the old. Skipping any step risks breaking either the old code (still reading the old column) or the new code (depending on the new column).

The same pattern applies to API field renames, configuration migrations, and message queue contract changes. It is more work upfront and dramatically less risky. The discipline pays off the first time you avoid a 3am rollback.

Feature Flags Decouple Deploy From Release

Feature flags let you ship code to production that is not yet active. You can refactor large code paths behind a flag, test in production with your own account, gradually roll out to users, and roll back instantly if something breaks.

LaunchDarkly, Unleash, Statsig, and ConfigCat are the major hosted options. Open-source flagd from CNCF is a solid self-hosted choice. See our code review practices for how flags interact with PR review (flagged-off features can ship faster).

Boy Scout Rule, Bounded

“Leave the code better than you found it” works as a mindset but breaks as a literal rule. PRs grow uncontrollably as engineers refactor adjacent code that “just needs cleanup.” Reviewers cannot review a 2000-line PR that mixes a bug fix with a refactor.

The bounded version: small, mechanical improvements (rename a variable, extract a constant, add a missing test) are welcome inline. Anything bigger goes in a separate PR. The bug fix and the refactor get reviewed independently.

Document Decisions With ADRs

Architecture Decision Records (ADRs) capture why decisions were made, not just what was decided. When future engineers wonder “why did we choose Kafka over RabbitMQ?” the ADR has the answer with its tradeoffs and rejected alternatives.

ADRs prevent the team from re-litigating settled decisions every six months and provide context for newcomers. The format is simple — title, status, context, decision, consequences. The ADR community resources have templates and tooling. Combine with microservices vs monolith thinking to document architecture choices clearly.

Wrap Up

Technical debt strategies that work are continuous, not episodic. Strangler fig for service replacement, expand-and-contract for schema changes, feature flags for safe refactoring, bounded boy scout rule for incremental improvement, and ADRs for documented decisions. Most “we need a refactor sprint” requests would be unnecessary if these practices were already in place. Build them into your engineering culture and tech debt becomes a known cost rather than a crisis.

Frequently Asked Questions

How much time should we spend on tech debt?

15-25% sustained, not 0% for months and 50% for a sprint. The latter pattern usually fails — refactor sprints scope-creep and ship late. Continuous improvement is more effective.

When should we rewrite vs refactor?

Refactor unless the existing code is fundamentally wrong (wrong language, wrong runtime, wrong architecture). Rewrites famously fail to ship. Strangler fig is almost always better than full rewrite.

How do I justify tech debt work to product?

Frame in business terms: velocity, incident frequency, security risk, hiring (engineers leave codebases full of debt). Specific metrics (“we deploy 3x/week now, was 1x/month”) are most persuasive.

Are feature flags themselves a source of debt?

Yes if not cleaned up. Set a deletion deadline when you create a flag. Flagged-on-everywhere flags should be removed; flagged-off forever flags signal abandoned features.

What about tests as debt?

Tests that don’t catch real bugs and slow CI are debt. Tests that document behavior and catch regressions are assets. Audit your test suite periodically and delete tests that aren’t earning their keep.

The post 7 Critical Technical Debt Strategies That Actually Work appeared first on GTWebs.