Every small change to your application takes three weeks? Here is why, and what to do about it

You need just one new field on a form. Or one more column in a report. The team says: three weeks. You ask why, and you get an explanation you don’t understand, but it sounds serious.

And you remember it used to be different. In the first year, new things arrived in a few days. The team didn’t get worse. The system they work in did.

Why this happens: technical debt

Picture a house that has been extended for ten years without a plan. Every time, someone ran a cable through a wall in a hurry, because that was the quickest way. Today, to move one socket, you have to break through three walls and hope you didn’t cut something in the next room.

In software this is called technical debt, and it behaves exactly like debt: every time something is done in a hurry, you take out a loan. The interest is paid on every change that follows. After a few years the interest is bigger than the principal, and all development goes into repayments.

In an application, it looks like this:

• Everything is connected to everything. A change in one place breaks something in another, so every change has to be checked by hand everywhere.
• There are no automated tests. Every change means testing the whole application by hand, and the fear of breaking something slows everything down.
• The same logic is copied in ten places. A change has to be made ten times, and one place is always forgotten.
• Releasing is manual and risky. So releases are rare, come in big batches, and everybody keeps their fingers crossed.
• Only one person knows part of the system. Everything that touches that part waits for them.
• The technology is outdated. An old version of .NET and libraries that can’t be upgraded without everything else falling apart.

How to tell it’s your problem too

You don’t have to read code. It’s enough to watch for this:

• estimates for similar tasks keep growing
• the team says “we don’t touch that” about some parts of the application
• something breaks after every new version
• new developers take months to work on their own
• the answer to “why does it take so long” is always “it’s complicated”

If you recognise three or more, the problem isn’t the people, it’s the system.

What doesn’t help

Hiring more people. More people in a tangled system means more people breaking each other’s work. Fred Brooks wrote it down back in 1975: adding manpower to a late software project makes it later. And finding a good senior developer takes months anyway.

Putting pressure on the team. A team under pressure takes even more shortcuts, and every shortcut is a new loan. The debt grows faster.

Rewriting everything from scratch. It sounds like a solution, but it means a year or two without new features, and throwing away everything the old system does well. It is rarely the right first decision, as we wrote here too.

What helps

Debt isn’t paid off at once, but in a smart order:

1. SnapshotWhere the time goes
2. BottlenecksWhat changes most often
3. Safety netTests and automated releases
4. As you goEvery change leaves the code better

1. Snapshot. An independent look at the code and at how a change travels from request to production. Where exactly does the time go: writing code, testing, waiting, or fixing what broke along the way?
2. Bottlenecks. Not everything needs fixing. Parts nobody touches can stay ugly. What changes most often gets sorted first, because that’s where the interest is paid every week.
3. Safety net. Automated tests around the most important parts, and releases with one click. When the team isn’t afraid of change, changes get faster on their own.
4. As you go. Every new feature leaves the code it touches a little better than it found it. Development doesn’t stop, and the debt is paid off in instalments.

The first improvements usually show within a few weeks, not years, and without stopping development. The best measure is simple: how long a typical change takes, from request to production, before and after.

How we work

ProCoding is a .NET studio from Split, Croatia, and sorting out systems that have become slow to develop over the years is one of the things we do most often.

We start with a review of the code and the process, and you get a list of bottlenecks ranked by how much they cost you. Then we sort them out together with your team or instead of it, whichever suits you better. The first step is a free 30-minute call in which we go through what one typical change looks like for you.