Modification during conversion

Changing it while we convert it

Most old software goes unchanged not because nobody wants it different, but because nobody can be sure what a change would disturb. A conversion is the one moment when that stops being true.

Why the change belongs here

When software has run for decades, the people who knew why it does what it does have usually moved on. What is left is a system everyone depends on and nobody wants to touch. Requests for changes get refused, or they get made carefully and slowly, and each one carries a risk nobody can quantify.

A conversion changes that position, because it is the point at which the behaviour of the existing system has to be established anyway. Once we hold an account of how the software behaves, and can show that the new version matches it, a deliberate difference is no longer a leap in the dark. It is one of the few places where a change can be made and its effect demonstrated rather than hoped for.

Doing it at that moment also costs less than doing it afterwards. Afterwards, the change is a second piece of work against a system that has just settled. During, it is part of the work already under way.

How it goes

  1. You tell us what you have, and what you would like different

    A repository link or a plain description is enough to begin. The change can be specific, such as a rule that should now behave differently, or it can be a problem you have lived with and would like solved. If you are not sure whether it is possible, say so and ask.

  2. We establish what the software actually does today

    Not what it was meant to do, and not what the documentation says it does, but what it does. A long-lived system almost always contains behaviour nobody remembers deciding on, and that behaviour is part of what the software does.

  3. We tell you what your change actually touches

    Before anything is written, you get a plain answer about the scope of what you asked for, including the places it reaches that you did not expect. Sometimes a change that sounded small turns out not to be, and it is better to know that here than later.

  4. The conversion is carried out with the change in it

    The new version is produced with your difference included from the start, rather than converted first and amended afterwards. There is no interim version carrying a change that has to be unpicked.

  5. You get evidence, separately, for both halves

    For everything you did not ask to change, the evidence shows the new version behaves as the original did. For the part you did ask to change, it shows the new behaviour is the one you asked for. The two are reported separately and on purpose, so a difference can never be quietly counted as a match.

If we cannot show it, you get your money back

We do not turn a change down for being hard. If you ask for it, we attempt it. What we will not do is hand you a modification we cannot produce evidence for and let it sit alongside the ones we can, where you would have no way of telling the two apart.

So the risk is ours rather than yours. If we attempt your change and cannot show that it does what you asked, we tell you plainly and you get your money back. That is a better arrangement for both of us than a quote that hedges, and it is the only version where the evidence keeps meaning the same thing every time you are handed some.

What you end up with

Working software in a language that can be run and hired for, behaving as the original did except where you asked it not to, with the evidence for both and documentation of what was found along the way. The parts of the old system nobody remembered are written down as a by-product.

If you already know what you want changed, say so when you first get in touch. It is cheaper as part of the work than after it, and asking costs nothing.

Talk to us about a conversion →
A worked example of a conversion, done in the open and free, is the ACAS accounting system — fifty years old, still running, now with a machine-checked twin beside it.