When coding, my motto is: “Design your code to be easily deleted”.

Virtually every principle, pattern, and practice in clean code, design patterns, and software architecture serves a common goal: drawing a dotted line around our component so future developers can easily cut along it, detach our module, discard it, and replace it with something better suited to the evolving needs of the system.

So, let’s not get too attached to our code. It’s not an asset, it’s a (hopefully temporary) liability. The best code isn’t the code that lasts forever. It’s the code that serves its purpose well and then gracefully makes way for something better.

I understand that the ensemble of practices I call T*D (Trunk-Based Development + Test-Driven Development + and Team-Focused Development), can seem daunting at first.

However, in 2025, any software team that aims to be high-performing should prioritise investing time in understanding and adopting each of these approaches.

When combined, these three practices create a powerful framework that enhances software delivery in several ways. They streamline the development process, improve overall code quality, foster a low-stress work environment, and strengthen communication.

Continuous Delivery is not a starting point in software development. It is where teams naturally end up when they push for high performance.

It is not something you adopt overnight. It emerges as a consequence of constantly refining and optimising how you work.

This is why debates over feature branches versus trunk-based development often miss the point. The delivery model is not a fixed choice. It adapts. As teams strive for higher performance, they gravitate towards what works best.

A long time ago, someone asked me in an interview: “What is the biggest problem in software development?”

It was a broad, open-ended question. I gave an answer at the time, though I honestly cannot remember what it was. What I do know is that I would not give the same answer today, being older, having seen and experienced more.

The biggest problem I can see now is poor end-to-end quality management.

As a software engineer, I don’t want a digested problem presented as “requirements.” I want the raw problem itself.

A common mistake I often observe in software companies is product managers taking on the role of managing teams and dictating requirements.

Software teams don’t need requirements; they need clear problem statements. The role of a product manager is to identify and articulate the right problems to solve.

The team will then collaborate to analyze each problem and design a solution.

There are a few Rustaceans (the silly name that Rust cultists have now given themselves) who keep posting against those “dinosaurs” who still use C or C++ and refuse to bow to the undeniable superiority of Rust and be assimilated.

As usual, a potentially valid message is completely undermined by the messengers.

I do not know Rust, but one of my goals this year is to gain a good understanding of it. The issue is that these zealous and almost fanatical behaviours do not help, especially when coming from people with only two or three years of experience.