05 / 06
Discipline
Quality Engineering
Two kinds of work that belong together. Making software provably correct, with tests that check what the code does and tests that check the architecture has not rotted underneath it. And taking on software somebody else wrote, that nobody currently understands, and making it safe to change again.
The second one is where most of our enquiries start.
Approach
Positions we hold
How we approach it.
A rewrite is usually the wrong answer
The system you inherited is years of accumulated business rules, most of them undocumented, many added in response to a real problem nobody wrote down. A rewrite discards all of it and asks you to rediscover it under deadline.
That is why rewrites overrun. The estimate covers the features somebody listed, and the overrun comes from the ones nobody knew about until a customer complained.
And we will say so, against our own interest
A rewrite is the larger invoice. When one genuinely is right we will say which part, in what order, and what it costs to run both systems during the transition, because that overlap cost is what rewrite proposals leave out.
Characterisation tests before changes
When nobody knows what a system is supposed to do, tests asserting what it currently does are worth more than tests asserting what it should. Pin the existing behaviour, including the behaviour that looks wrong, then change deliberately.
Changing code whose correct output nobody can define is not engineering.
Coverage in the right order
Inheriting a system with no tests is common and is not an emergency. It is also not fixed by a coverage target, because a number does not tell you whether the tested part is the part that would cost you money.
We start where failure hurts: the paths that touch money, the paths that touch compliance, and the paths that run overnight with nobody watching. A system at thirty percent coverage concentrated there is in better shape than one at eighty percent exercising getters.
Architecture tests
Dependency rules that live in a diagram get violated. Dependency rules that live in a test suite fail the build. On our own platform, architecture rules run as one of three suites and a violation breaks the build.
It costs about a day to set up and prevents the specific decay that turns a five-year-old system into a rewrite candidate.
Technical debt with a number and a date
Saying there is a lot of technical debt is not information. A register with what it is, what it costs now, what it will cost if left, and a remediation window lets you make a commercial decision rather than a mood-based one.
Some debt should be paid immediately, some when you next touch that area, and some documented and deliberately kept. All three are legitimate positions.
Where we stop
We will not promise you defect-free software. We will tell you where the risk sits, what we have tested, what we have not, and what we would do next given another week.
Stack
What actually runs in production.
Unit tests
Integration tests
Architecture tests
Jest
Characterisation tests
Pull request review record
Jira
Regression runs
UAT scripts
Written sign-off
Engagements
Typical shapes this takes.
Inheriting a system
Documenting what it does, how to run it, how to deploy it, and where it is fragile, then making one small change end to end to prove the documentation is real.
Stabilisation
Characterisation tests, a pipeline, and the removal of whatever makes releases frightening. Weeks rather than months.
A debt assessment
What is wrong, what it costs, and in what order to fix it. Fixed fee, delivered through the engineering assessment.
Deliverables
What you get.
A codebase inheritance document
Proven by having someone follow it end to end.
A test suite that starts where it matters
Money, compliance, and the jobs that run unattended.
Architecture rules in the build
Where the system warrants them.
A technical debt register
Impact, priority and a remediation window per item.
A defect process where severity means something
And fixes verified against the original report.
Ownership
Tests and documentation are yours, the same as the code.
Reading
Related reading.
The strongest seams here are the argument against rewrites, characterisation testing on inherited code, and architecture tests at build time. Those pieces will be linked here as they are published.
Claer & Volker
453 Winifred Yell St, Garsfontein
Pretoria, South Africa
info@claervolker.com
© 2026 Claer & Volker
·
·