I have heard countless teams complain that “requirements change all the time!”

Many developers crave stability. Constantly shifting priorities can feel like an endless source of frustration. Many blame stakeholders, product owners, business analysts, believing they should spend more time figuring out what they really want before disrupting the team’s flow.

But requirements change for a reason and teams must understand that. Sometimes it happens because the original objectives were unclear. Other times, it is because new opportunities emerge, and adapting to them creates a competitive advantage.

Are we trying to get things more right or less wrong?

I believe there is a fundamental mindset shift between these two approaches: a) We’re doing X well today. We think we have an idea of how to improve X tomorrow. b) We know we’re doing X somehow wrong today. We can’t wait to discover the data that will help us do X less wrong tomorrow.

The first approach is built on pride. It assumes we are mostly right and only need refinement. It consolidates bias.

“My team is great, they haven’t produced a defect in a long time!”

I’ve heard managers say this with pride, but the truth is that “defects per unit of time” is a terrible metric for evaluating a team’s success.

A team that never produces defects isn’t necessarily high-performing. They might just be playing it safe, forced to slow down because the environment around them wants to see heads roll when they make mistakes.

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.