Software engineering: how you know delivery is going well before it is too late

A company receives its ordering system on the agreed date. It works, the supplier invoices and the project is closed with a signed acceptance. Four months later the business needs a small change: adding a type of discount. The quote arrives with six weeks of work and a warning that it may affect invoicing. For the first time, the company understands that it bought something that works and cannot be changed.

Nobody lied. What the contract said was delivered, on the date the contract said. What the contract did not say anything about was the most important property of a system that will live for five years: how much the next change will cost. That property is not visible on delivery day, and so it is not negotiated.

Five indicators that do not require reading code

Asking whether the project is on time is the worst question available, because it can be met by delivering something that later cannot be changed. The DORA research programme has measured software delivery performance for more than a decade, and publishes five indicators any team can provide from data it already generates (DORA):

• How often something new reaches production.
• How long it takes from a change being ready to it being in production.
• What share of deliveries require immediate intervention.
• How long it takes to recover when a delivery fails.
• What share of deliveries were unplanned and went out because of an incident.

The useful idea is that speed and stability are not traded against each other: teams that deliver often tend to fail less, because each delivery is smaller and easier to roll back. And measuring it does not require buying a tool. It is enough to note down each delivery, whether intervention was needed and how long it took.

The acceptance criteria are written by whoever will use the system

A specification can be complete and still leave the business problem unsolved, because it describes the system and not the outcome. What closes that gap is acceptance criteria written by the department that will use it, odd cases included: the partial return, the customer with two tax IDs, the order invoiced to another company. And acceptance is not done by demo. It is done with the people from that department, with real data, and with nobody from the team that built it touching the keyboard.

The technical debt you accept, and the debt you do not

Technical debt is what teams call the shortcuts that will have to be paid for later. Martin Fowler proposed the distinction that makes the metaphor useful: what matters is not whether there is debt, but whether it is prudent or reckless, and whether it was taken on deliberately (Martin Fowler, Technical Debt Quadrant). Shipping earlier with provisionally organised code is a defensible business decision. What makes it reckless is not writing down when it gets paid.

Asking for no debt sounds demanding and backfires, because it forces the team to hide it. What you require is a visible list with three columns: what was done, why, and which condition would trigger paying it off.

Artificial intelligence amplifies; it does not fix

DORA’s 2025 report says it plainly: artificial intelligence does not fix a team, it amplifies what is already there. In the same report, 90% of respondents say they use it at work (DORA, 2025 report). A team with automated tests and a clear path to production delivers more. One without them produces more code with no filter, and the problem shows up later, in testing, security and delivery.

Before buying artificial intelligence tools for the team, it pays to know which of the five indicators are measured today. If none are, there will be no way to tell afterwards whether the tool improved delivery or only produced more code.

Six things to require at signing

• Ownership of the code and access to the repository from day one.
• Automated tests for the business’s critical paths, not a coverage percentage.
• A written, tested procedure to set the project up from scratch.
• The list of third-party components, and who updates them.
• Deliberate debt, declared and dated.
• What the company receives, and in what format, the day the relationship ends.

All six cost little at signing and are expensive or impossible later. The most useful signal of the whole selection process is how the supplier reacts when reading them.