Summary
This article started with three conversations. A CTO had rolled out Sonar and GitLab at scale, at real cost, and could show his management neither the usefulness of the work nor its return. A technical director had put pair programming and code reviews in place and hit exactly the same wall. And a CIO did not know the objectives, or the stakes, of his own DevOps programme. I wanted to write about the benefits of good development practices, of technical excellence, in terms that survive that conversation.
The problem is not that the practices are wrong. It is that they are sold with the wrong arguments. Cyclomatic complexity, an algorithm brought from quadratic to linear: to a decision-maker these carry no visible business value. A good practice out of context becomes a bad practice, so before deploying or defending one, ask why, and what problem it solves.
My proposal is to measure on two levels. A tactical level, for the team, with operational indicators; a strategic level, for management, with indicators of performance and value created. And to accept that not every practice fits every context: a maintenance team may not need TDD when well-applied clean code is enough, and when the debt is massive, progressively decommissioning and rebuilding on clean foundations can be the wiser move. Imposing one tool or one method on every project in the name of standardisation is a fatal mistake; a matrix of use cases, by complexity, skill required, learning curve and business criticality, is how I choose.
Craftsmanship is not sold with tools or dogma. Its return is not in TDD, Sonar or GitLab, but in what those practices make possible: software that is more reliable, a team that is more autonomous, a velocity that can be predicted, and in the end a business better served.
Key ideas
- A good practice out of context becomes a bad practice: before deploying or defending one, ask why and which problem it solves.
- Technical arguments do not reach decision-makers; measure on two levels, tactical indicators for the team and value indicators for management.
- Not every practice fits every context: a maintenance team may do without TDD, and massive debt sometimes calls for progressive decommissioning rather than repair.
- Imposing one tool or method on every project in the name of standardisation is a fatal mistake; choose with a matrix of use cases.
- The return is not in TDD, Sonar or GitLab but in what they make possible: reliability, team autonomy, predictable velocity, a business better served.
Why I wrote this
A CTO told me he had rolled out tools such as Sonar and GitLab at scale, at a real cost, and could show his management neither the usefulness of the work nor its return on investment. Another technical director described putting pair programming and code reviews in place and met exactly the same difficulty. I even met a CIO who knew neither the objectives nor the stakes of his DevOps programme. I wanted to focus on the benefits of good development practices, and of technical excellence in particular.