Package 3

Refactoring and technical debt

We do not rewrite the system from scratch. We put it in order in stages.

Each stage has its own price and a measurable target written into the contract. After every stage the system runs, and you can stop — with no abandoned project and no half-finished rebuild.

Outline your case
Symptoms

How to tell that the time has come

Technical debt rarely announces itself. It usually makes itself known through deadlines.

A small change takes a week

An hour’s fix requires half the system to be tested, because the dependencies are not known.

Nobody wants to touch one module

There is an area the team enters only as a last resort. Usually the same one that fails most often.

A library update blocks the release

The dependencies are old enough that raising one version pulls a dozen others with it.

AI-written code that nobody has read

It works, but no one can say why it works or what happens with different input.

Process

Measure, change, measure

Every stage closes with an acceptance of its own. The measurement at the start and at the end is taken with the same tool, in your environment.

1Baseline measurementthe state before the work 2Stage 1work and acceptance 3Stage 2work and acceptance 4Stage 3work and acceptance 5Final measurementthe same metrics The number of stages depends on the scope. After each of them the system runs and the engagement can end.
Scope

What the stages consist of

Baseline measurementThe current state is measured before the first change: technical debt and complexity in SonarQube, test coverage, response times, vulnerabilities in the dependencies. Without it, an improvement cannot be demonstrated.
Safety netTests around the area to be changed. Refactoring without tests is rewriting blind — which is how failed rebuilds usually end.
Putting the code in orderSeparating responsibilities, removing duplication, simplifying the points of highest complexity. Changes in small steps, each one reversible on its own.
Dependencies and vulnerabilitiesLibraries and frameworks updated, known vulnerabilities removed, open source licences put in order.
PerformanceWhere the measurement showed a real problem: database queries, memory use, response times.
Final measurementThe same metrics as at the start, taken with the same tool. The difference is what the acceptance is based on.
Contract

Measurable targets instead of declarations

For each stage, specific values are written into the contract. Acceptance consists of checking whether they have been reached — not of judging whether the code looks better.

SonarQube rating — the technical debt and complexity indicators for the designated area: the baseline value and the target value.
Test coverage — the coverage percentage for the module in scope, measured with the same tool before and after.
Response time — for the operations you identify as significant, measured in your environment.
Vulnerabilities in dependencies — the number of known vulnerabilities in the scope covered, before and after the update.

What we do not promiseNo percentage figures are given before the baseline measurement. The numerical targets are set after the first stage, once the starting state is known — and only then do they go into the contract.

Questions

Frequently asked questions

Do we have to suspend work on new features?

No. The stages are designed so that they can be fitted between releases. That is why we work area by area rather than on the whole system at once.

What if we decide after the first stage that it is enough?

Then it ends there. Each stage is a self-contained whole with its own acceptance and carries no commitment to the next one.

Would it not be cheaper to rewrite everything?

Almost never. A rewrite means reconstructing every business rule that has accumulated in the old code over the years, most of which is written down nowhere. Putting the system in order in stages takes longer, but the system runs throughout.

Do you start with an audit?

With the baseline measurement, which covers a narrower scope than a full audit. Where it is not yet clear where the problem lies, it makes more sense to start with the code audit.

Do you work on our infrastructure?

Yes. The repository, the environments and the data stay with you. We work with the access you grant us and return it once the work is finished.

How do you use AI tools?

Under supervision: every fragment goes through a second engineer’s review before it moves on. Your data does not go into prompts. The rules are set out in the document “Data, GDPR and AI tools”, provided before the work begins.

The module nobody wants to touch

Tell us where the difficulty is greatest. The initial assessment of the starting point is free of charge.

Outline your case