Piano piano si va lontano

There is an Italian proverb that says “piano piano si va lontano” and that translates to something like “slowly you go far.” I heard it years ago, when I was starting to learn Italian, and it has stuck with me ever since.

In a world where we want everything quickly, this phrase sounds contradictory. And in software development, even more so.

#.The fallacy of “going fast”

In my first years developing software, several people recommended that I read some books that marked my career: Clean Code, The Clean Coder, Hackers and Painters, Working Effectively with Legacy Code, among others. Each one arrived at different times and with each reading new ideas, questions and different ways of looking at the software we built appeared.

There is an idea that is repeated in almost all of these books: real speed does not come from going fast, but from going well.

At some point in our careers, we’ve all heard (or said) something like “we need to deliver fast” or “we need to move faster.” And yes, speed matters. But the question that we often don’t ask ourselves is: fast to where?

Going fast without direction, without structure, without the proper foundations, is not speed: it is disorder with haste.

#.“Legacy code is simply code without tests”

I was recently reminded of Working Effectively with Legacy Code by Michael Feathers. In the preface I came across this stark, clear definition about legacy systems:

“Legacy code is simply code without tests.”

Regardless of whether I agree with it at all (I don’t), the interesting thing is what it implies: the tests allow us to change the system with greater confidence. They allow us to mitigate what Feathers calls the “edit and pray” ^fn-1, which is basically making changes and praying that nothing breaks.

This is not a new concept. Kent Beck, creator of Extreme Programming and pioneer of Test-Driven Development, popularized a maxim that he inherited from his father and that summarizes the idea very well: “Make it run, make it right, make it fast” ^fn-2. First it works, then it is well made, and then (if necessary) it is fast. The order matters.

When we reverse the order, when we prioritize the speed of delivery over the quality of what we deliver, we end up with fragile systems that slow everything down in the long run. Ward Cunningham coined the term “Technical Debt” precisely to describe this phenomenon: the shortcuts we take today become the burden we carry tomorrow ^fn-3.## The evidence: quality and speed are not opposites

There is a fairly widespread belief that doing things “right” takes more time and that quality competes with speed. The evidence says otherwise.

In Accelerate: The Science of Lean Software and DevOps ^fn-4, Nicole Forsgren, Jez Humble, and Gene Kim present years of research (backed by data from thousands of teams) showing that high-performing teams deliver faster AND with higher quality. It’s not one or the other: it’s both. These teams deploy code more frequently, with fewer crashes, and recover faster when something goes wrong.

How do they achieve it? With practices such as continuous integration, continuous delivery, test automation, and above all: with a culture that prioritizes quality as part of the process, not as something that is reviewed at the end.

Martin Fowler illustrates this very well with what he calls the Design Stamina Hypothesis

#.Lean knew it before

Long before we talked about Agile or DevOps, Toyota’s production system had already resolved this tension between speed and quality.

One of the core principles of Lean is Jidoka ^fn-6, which translates to “automation with a human touch.” In practice, it means that anyone on the production line can stop the entire process if they detect a defect. Stop to fix. Sounds slow, right? However, it is exactly what allows the system to be fast in the long run, because defects do not accumulate.

Mary and Tom Poppendieck brought these principles to software in Lean Software Development ^fn-7 and one of their most important principles is “Build Integrity In”: build with integrity and quality from the beginning, not inspect at the end. If we have to “check” the quality later, we are already too late.

It’s the same idea that W. Edwards Deming, the father of modern quality management, preached for decades: “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place” ^fn-8. Quality is not inspected, it is built.

#.Speed is not hurry

I want to be clear about something, because I know that all of the above can be read as an argument against speed. It is not. Speed matters. But there’s a huge difference between speed and haste, and confusing the two is one of the costliest mistakes I’ve seen in software teams. The rush is to deliver fast no matter what comes next. Speed—the speed that really serves—is that which comes from eliminating waste, from removing everything that does not add value and does not serve the system. The first principle of Lean Software Development by the Poppendiecks is precisely that: “Eliminate Waste” ^fn-7. Don’t “go faster” or “put more pressure on the team”: eliminate what gets in the way. There is a fundamental difference there.

The problem is that when we are under pressure, it is easy to confuse the two. We started to see tests as waste. Code reviews like waste. The documentation, the pauses, the time to think: everything seems waste when the clock is ticking. But those things are not waste: they are exactly what sustains the rhythm. Removing them is like removing oil from the engine to make it go faster. It works for a while and then everything stops.

The eighth principle of the Agile Manifesto says it in a way that seems difficult to improve: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” ^fn-9 A constant pace, indefinitely. That’s the opposite of haste. And in my experience, a team that maintains that sustainable pace for six months consistently outperforms one that went full throttle for the first two and then stumbled into its own accumulated debt.

#.And then comes the AI

All of this—the speed at which waste is eliminated and the pace at which it is sustained—takes on new urgency at a time when AI tools allow us to generate code ever faster.

If before the challenge was to write fast code, that problem almost no longer exists. AI can generate hundreds of lines in seconds. But generating code is not the same as building software. The generated code needs to be understood, maintained, tested and evolved. If we do not have the structures, practices and discipline to sustain what we generate, the speed of generation becomes the speed of debt accumulation.

It’s not about being averse to change, quite the opposite. It is about creating the conditions to embrace it and make the change safe, understandable and sustainable. A good test suite, a clear architecture, a code review process, shared conventions - these are not things that make you “slower”. They are the things that allow you to remain fast when the system grows, when the team changes, when the requirements change. The ninth principle of the Agile Manifesto says it verbatim: “Continuous attention to technical excellence and good design enhances agility” ^fn-9. Technical excellence is not a luxury or an afterthought: it is what makes agility possible.

#.What really speeds up

After several years working with teams of different sizes and in different contexts, I have come to a simple conclusion: what really accelerates a team is not the pressure to deliver quickly, but the confidence that what they deliver works and can be changed without fear.

A team that has good automated tests can refactor without fear. A team with a clear architecture can add functionality without breaking what exists. A team with shared conventions can incorporate new members without everything stopping.

That security is precisely what allows teams to maintain (or even increase) their pace of development. It is not going slow: it is going with a firm step.

Fred Brooks, in his essay “No Silver Bullet” (1986), already warned us that there are no silver bullets in software engineering ^fn-10. There aren’t any. Neither AI, nor a new framework, nor a magical methodology is going to solve the inherent complexity of building software. What does help is discipline, good practices and commitment to quality.

#.Piano piano

Piano piano if it goes far. Slowly you go far.

It is not an invitation to be slow. It’s a reminder that sustainable speed requires solid foundations. That today’s shortcuts are tomorrow’s problems. That investing in quality, in structure, in good practices is not wasting time: it is gaining it.

And if at the end of the day, after laying the right foundations, you want to use AI to go faster: go ahead. But make sure those foundations exist first.

Because going fast is easy. Going far is what is difficult.