SOFTWARE DELIVERY
When to rewrite, and when not to
Rewrites are chosen for how the code feels to work in, and justified afterwards with business reasons.
SERVICE 03
Building the thing that does not exist yet.
Product engineering, web and mobile builds, and modernisation of systems that still work but have become expensive to change. Delivered with your engineers, and handed over properly.
THE PROBLEM
The build is not the hard part; the scope is
Most software projects that go badly were not badly built. They were scoped to a wish list, estimated against a best case, and specified far enough in advance that half the assumptions had expired by the time anyone wrote code.
The counter is unglamorous: ship something narrow and real early, find out what was wrong about the plan while it is still cheap, and keep the architecture simple enough to change when you do.
WHO IT IS FOR
Who custom software is designed for
Teams with no spare capacity
The roadmap is agreed and there is nobody free to build it.
Teams without the skill in-house
Mobile, real-time, or a domain nobody on the team has shipped before.
Teams with ageing software
It works, and every change takes three times longer than it should.
Founders validating something
You need a real version in front of real users, not a prototype that cannot survive them.
WHAT IT INCLUDES
What this work may cover
Not every engagement covers all of it. The shape depends on what you are deciding.
Scoping
Cutting the wish list to a first version that is worth shipping on its own.
Architecture
Decisions sized for your team, written down with the trade-offs that drove them.
Delivery
Increments you can use, in your repo, reviewed by your engineers.
Modernisation
Strangling the parts that hurt rather than rewriting the parts that do not.
Handover
Tests, documentation and pairing, so your team owns it before we leave.
THE FRAMEWORK
How the work is sequenced
- 01
Understand the job
What the software is for, judged by what changes for the user when it works.
- 02
Cut the scope
The smallest version that is genuinely useful. Everything else is version two.
- 03
Decide the shape
Architecture chosen for the team that will maintain it, not the one that built it.
- 04
Ship increments
Something real every couple of weeks, used by someone outside the project.
- 05
Hand over
Documentation, tests and a team that can take the next change alone.
ILLUSTRATIVE EXAMPLE
A fifteen-year-old internal system that nobody will touch
A constructed example to show the shape of the work, not a client case study.
- 1
Find out which parts actually change often. Usually it is a small fraction of the code.
- 2
Put a seam around one of those parts and move it out, leaving the rest alone.
- 3
Run old and new side by side until the new one is boring.
- 4
Repeat for the next painful area, stopping when changes stop hurting.
- 5
Leave the remaining legacy in place. Rewriting working code that nobody edits is spending for its own sake.
RELATED READING
Worth reading alongside this
CLOUD AND INFRASTRUCTURE
The cheapest fix is usually configuration
Before the architecture conversation, check the settings. A surprising share of production pain is a default nobody changed.
WORKING TOGETHER
How to brief a consultancy
The brief determines the outcome more than the firm does. Bring the problem, not the solution.
QUESTIONS
Common questions about this work
Should we rewrite or refactor?
Refactor far more often than instinct suggests. Rewrites throw away years of accumulated edge-case handling that nobody documented, and they tend to take two to three times the original estimate. Incremental replacement is slower in theory and faster in practice.
Can you give a fixed price?
For a well-scoped phase, usually yes. For a project defined as a long feature list, a fixed price would be a guess with a confident number on it, which helps nobody. We would rather scope a first phase properly and price that.
Who owns the code?
You do, from the first commit, in your repository. There is no arrangement here where the code lives somewhere you cannot reach it.
Scope a first phase
A narrow version that ships beats a complete one that is still being specified.