Bad software architecture: why are my developers spending more time doing less?

A new software product gets built comparatively quickly. Often there’s commercial pressures: a set of features needed, and a launch date to hit. A great, commercially-aware dev team makes it a reality.

Now let’s revisit that same software project a decade on. It’s become successful, having grown both in features and in scale. More money is available, and the development team, too, has grown quickly.

But despite this, in many cases, the pace of development actually slows.

The bigger development team delivers more or less the same number of features as the smaller one did last year. The output (measured, say, in lines of code) seems to reach an asymptote:

Why is that?

It’s not that the developers are working any less hard. It’s not a communication thing. And it doesn’t take any longer to develop specific features than it did last year (in fact, improved tooling should make it a bit faster).

The problem is:

Architecture.

Because architecture is everything for the long term of tech projects.

The above charts are the hallmarks of bad software architecture. It is a very, very common pattern.

To solve it, we have to understand why it happens:

Why are my developers spending longer on writing less?

Let’s zoom in on a single, long-standing developer from the team and analyse what she spends her time on.

In year one, she had to write some features for the first release. If she tracked her time it would look like this:

That’s all she did - write features. There weren’t any integration pains, because there was nothing to integrate to. Simple.

In year two, she had some more features to write, and had to spend a bit of time integrating them into the existing product.

Something interesting happens by year 5. Now the cost of integrating features has become significant. Bugs are popping up in unexpected places when she merges her code. She has to involve other team members, who have to make changes to their code to accommodate her features.

In all, she spends only about half her time writing features:

By year 10, the cost of integrating features is so high that she spends most of her time debugging problems in totally unrelated parts of the application. And she is constantly being disturbed by other developers, who need her to tweak her past code to accommodate their new features.

This is an example of developers having to fight an architecture. It’s the hallmark of a bad architecture.

So what should it look like?

A good architecture, by contrast, takes a lot of the heavy lifting for developers. It allows them to concentrate on writing features, no matter how big the team or project grows.

The hallmark of a good architecture is that every year, each developers’ time looks like this:

The difference here is enormous. With bad architecture, the project was freewheeling towards a point where adding new features could no longer be commercially viable, because it would cost more to do so than could ever be recouped in sales. And at that point the project - and your whole investment - is dead.

The solution - introducing the Software Architect

The best solution, of course, is to never have let the project get to that point in the first place. For that, you need an experienced software architect.

A software architect is a very senior technical role. It is only available to those who have already had a long experience in software development, particularly in large projects and among large teams, and then further specialised in architecture.

Rather than work on the code itself, an architect works on the structure of the code. They work with senior developers to define how code should be written. That way, an architect barely even needs to know what the features of the software are, or how it gets its inputs, or where it outputs to.

So an architect makes the plug sockets that the features plug into.

An architect is an expensive hire. But the earlier in a project’s life you formalise the architecture, the more it will save you in the long run. The best time to start is right at the beginning.

How do we fix bad architecture?

If you have a project with the hallmarks of bad architecture, to restore productivity your software needs re-architecting. Again, this is something an experienced software architect will be able to work with your developers to do.

But if it’s been left a long time, re-architecting can be an enormous operation. From a financial perspective it can be gigantically expensive. And it can be commercially frustrating, too, since it involves re-assigning developers away from developing new features, maybe for a long period. New features, obviously, are what marketing departments depend upon.

But, as they say, even though the best time to do something is yesterday, the second-best time is right now.

So: if your developers are spending more time releasing less code, this is probably a hallmark of bad architecture. For new projects, make sure that at least one developer is architecture-savvy and ensure code structure is considered before any code is written. For mature projects a full-time software architect is a must.

Getting architecture right saves a project and saves your investment.