A while ago, I had to explain, not for the first time in my career, why using interfaces, having loosely-coupled code, and writing tests (first) is a good idea.

Time and again, I find developers, teams and companies resisting certain ideas that have been around for years or even decades. One of the reasons often stated, is novelty. An idea, principle or technology is refused because it is new and who knows what the next thing will be. Better to stay with what we have.

Of course, a company should not be as cutting edge as an individual developer would/could want to be. A developer can play around in his/her free time with pre-alpha frameworks. But a company works within the constraints of budgets and time, so using a framework that might still change a lot, might have bugs, might never really go anywhere, etc. is a risk. A risk a company should not take.

However, playing it safe doesn’t mean we should be writing software like we did 20+ years ago. Our industry is a fast-rolling train and no-one really knows where it’s going. But certain things have been tried and tested thoroughly, even if some people haven’t really heard about it. Ask yourself where you want to be on this train.

As a company, you don’t want to be in the locomotive, where you get all the smoke, flies, and the occasional cow in your face.

But neither do you want to be at the back, in third class, where people have to sit on hard, wooden benches. They’ll get off the train and take a bus. Ok, my metaphor is falling apart, but you get the picture.

Principles like unit-testing, loosely-coupled design, composition over inheritance, dependency injection, etc. are no longer a novelty. You should be using them right now. And if you have a legacy codebase, then you should start introducing them. Evidence and experience show that you will benefit.

But will your code not become a mix of styles and techniques? Yes. And that is a justified concern. But it is entirely possible to avoid it.

Will it be a lot of work? Most likely. But start with small changes, the low-hanging fruit. In time, your code will improve, your test coverage will improve, and your ability to change will improve.

The project will benefit in that there will be less bugs, devs will enjoy their work more, will become better devs, and in time, changes should become easier and faster to apply.

Any codebase can be improved. But it takes an open mind to new techniques and stopping the old way of doing things. This isn’t a matter of being radically new, as these principles have been around for quite some time now.