Buying high-quality code means choosing to cry only once
Pay a little more today to save money tomorrow
It’s like any everyday product: buy a €3 T-shirt. After the first wash, it loses its color; after the second, it loses its shape; after the third, you can throw it away. So you buy a second €3 T-shirt, and the same story repeats itself.
Why do we keep buying the same T-shirts that don’t last? Why do we keep building the same apps, which are also practically disposable? “Insanity is doing the same thing over and over again and expecting a different result,” said A. Einstein. Are we crazy?
Not necessarily: buying a T-shirt for €20—or even €50—clearly means spending more money right now. In other words, it’s a cash flow problem. It’s the paradox of poverty: paying less in the short term condemns people to paying more in the long run.
Software is the same: you’ll have no trouble finding people willing to develop the app you have in mind “on the cheap.” However, when you later want to add features, you’ll discover the full extent of the disaster: the code is a tangled mess of unnecessary dependencies, with no apparent architecture, no modularity, and of course, no testing. This phenomenon of technical debt is, unfortunately, all too common.
Whether we’re talking about T-shirts or software, the issue is the same: you have to be willing to pay more upfront, with financing, to benefit in the medium term. And that’s where the problem lies—it’s a matter of education, understanding code, and computer science. Just as when you compare a €3 T-shirt to one that costs €50, the difference in quality is likely to be obvious, code, on the other hand, is invisible.
Making Software Quality Visible
Most of the time, a decision-maker is pressured to pay more based on the claims of a developer who assures them—using language as cryptic as that of Les Inconnus—that:
“Oh yes, but this time we’re doing things right—functional programming, TDD, BDD, DDD, the whole shebang, API tests, end-to-end tests, CI/CD, all in a monorepo, because it’s better, Mr. Gentil. And we do pair programming, and for certain key decisions, we switch to mob programming. Sure, it’s more expensive, but it’s the best way to do it.”
The best, you say? Everyone wants the best, but at what cost? How much better is it? In what ways is it better? To be fair to decision-makers, let’s acknowledge that the choice isn’t obvious under these conditions. Information technology is intangible—not to say invisible—but at any rate abstract, and therefore difficult to grasp.
We have to admit that we, as developers, don’t always make the effort to explain our work or make the issues at stake understandable to people outside the field. That’s what I strive to do every week through this newsletter. My key message is that IT is a business asset, just like other production assets such as machine tools.
Speed vs. Quality: A False Debate
In fact, things are simpler than they seem, because good developers know how to move quickly while laying a sound technical foundation and managing technical debt (when well-managed, debt is a good thing). With experience, programming to these quality standards doesn’t take any longer.
This expertise relies in particular on architectural choices that leave as many options open as possible, without limiting future possibilities. Work organization also plays a key role: building a Walking Skeleton early on the path to the MVP will help guide the work of new, less experienced developers whom you’ll bring on board to support the development effort.
Of course, these skills come at a cost:
“It took me 10 years to be able to do this in 10 minutes. Pay me for the 10 years, not the 10 minutes.”
You know how it goes.
There’s no magic formula: being willing to pay the price means recognizing the value.