Change stays cheap, even in year three

The problem

In the first year, new features arrive quickly. By the third year, a feature that sounds just as simple takes three times as long. Estimates start coming with caveats. Then someone suggests the only way forward is to start again from scratch.

It happens gradually. Each shortcut made sense at the time. The system was built for what the business did then, and the business has moved on. Parts that should be separate are tangled together, so touching one means touching five others. And the libraries it's built on are years out of date, so every upgrade is a project in itself.

Rewrites are expensive and risky, and they usually take far longer than anyone expects. Meanwhile the old system still has to be kept running.

What we do

Designed for change

We assume your requirements will change, because they will. So we build the system in parts, each with a clear job and a clear boundary. Changing how invoices are calculated shouldn't mean touching the code that sends emails. When the business changes direction, the parts that need to change can, and the rest stays put.

Some of the systems we look after have been changing for more than ten years without ever needing to start again. TommyTrinder is one of them.

Only the complexity it needs

The opposite mistake is building for a future that never arrives: layers and options added "in case we need them later". Every one of those has to be understood and maintained by everyone, forever.

So we keep things as simple as the problem allows, and add complexity only when it earns its place. It's much easier to add structure to simple code than to take it out of complicated code.

Keeping it current

The frameworks and libraries under your system keep moving. Fall a few versions behind and upgrading becomes a big, risky project that nobody wants to start. So we keep them up to date as part of normal work, a little at a time. It's also most of what keeps the system secure, which is why every system we build comes with support and maintenance.

If you're already several versions behind, it can still be done without a rewrite. We took one application from Laravel 4.2 to Laravel 9.

What it means for you

Change stays affordable. The feature you ask for in year five doesn't cost three times what it would have in year one, and you're not quietly heading for a rewrite. We build for the people who'll be working on your system in three years, as well as the people working on it today.