“Never Rewrite, Never Surrender”
Presenting the developer’s emotional guide to conquer technical debt without sacrificing your sanity or shipping schedule.
It’s a bold claim. And it’s not just about technical debt. It’s not even about how tangled the dependencies are. It’s about the emotional stress that weighs on the developer every time they need to make a change.
And yet, in our industry, we continue to talk about technical solutions while ignoring the emotional cost that developers suffer. We discuss patterns, best practices, and methodologies, but rarely address the fear, anxiety, and frustration that comes from maintaining unsustainable code.
“When code gets complex, it’s not just about technique, but also mental preparation.”
And this is how this book was born. Precisely from this struggle, from this need to find a path that acknowledges both the technical and emotional burden. What started as an article became longer than expected. And soon after, I had to complement it with others. And shortly after, it has become this book, a collection accompanied by new content that connects and guides to help at every step. All to regain control and agility without falling into the rewrite trap. Because there is a better way, and it starts with a simple but challenging, powerful golden rule:
“Never rewrite. Never stop delivery.”
The book begins with a basic question, “What is technical debt?” It seems like a well-trodden topic, very well-known, and yet, practically, everyone is unaware of its true impact.
“Usually, when we talk about technical debt, people think of borrowed time. It seems that we can borrow some time to deliver earlier, in exchange for returning that time later. But it is not that simple. […] the technical debt was not the time saved to deliver sooner, but the cost overrun for each next feature.”
And this leads us to think about how technical debt originates. It’s easy to say it’s the pressure to deliver quickly, but it goes beyond that. Because even though the developer is under pressure, there’s a whole series of incentives pushing them in the wrong direction.
“Both global warming and dirty code are propelled by the same human behaviors: a short-term reward for moving in the wrong direction and a consequence of collective behavior.”
But there is a better way. A path that begins with five simple but powerful rules. Five rules that, though old, were the key to this book. These rules teach how to recognize and tackle technical debt in early stages. And they set the cornerstone of the book. Because stopping delivery isn’t the solution, it’s part of the problem:
“Rule 4: No great refactors; do not stop delivering.”
We must accept our humanity. After all, we are human. And we are fallible. And as much as it pains us, code isn’t perfect. But we don’t want to acknowledge it. We want each piece of code to be definitive. But that never happens, evolving it is inevitable. And in a conversation with a former student, this very grief that needs to be addressed came up:
“He told me that he feels uncomfortable working on software that will change. That, although it meets current requirements, later ones could require a major overhaul.”
And this is where TDD comes in, not as a testing tool, but as a transformation tool. It’s not about writing tests before the fact — it’s about using tests to guide the transformation of legacy code into maintainable, reliable paths. Each new feature becomes an opportunity to clean and strengthen the infrastructure. And like a map, it guides us step by step, helps us step firmly on ground.
“The TDD not only improves the code of the destination, but the code of all the journey.”
But to get here, first we must learn to make small changes. Because it’s one thing to say that we shouldn’t rewrite from scratch, and another to not evolve the code. And to do this, the smaller the changes, the easier it will be for us. And using the Bowling Game Kata as a foundation, we’ll learn how to make changes so small that may seem insignificant, but when added together, make the difference.
“a whole series of techniques to gradually manipulate the code, transforming it into useful and fertile code […] a basic skill that all developers should cultivate to create agile code that always maintains delivery speed.”
And we’ll keep doing small steps. And we’ll keep going. And we’ll learn techniques that allow us to change giant codebases, but in small steps, and always releasable. Eliminating the anxiety and nerves of accumulating many changes without holding back deliveries and commitments.
“There is a mantra behind each step: ‘and the code works again’. […] Instead, of breaking a big chunk of code for days, weeks, or even months, we can deliver small bits every change. […] The team can work as a team again. 100% running of the time means that we can still be shipping new code while refactoring the old one.”
And here we reach the end. Where everything adds up and culminates in addressing fears and anxieties. Where it shows how the fear of breaking everything can paralyze, and how to help the developer overcome it. How the developer can feel they’re wasting time on solutions with no future, and how to orient their efforts to achieve maximum return with minimum effort. Where it moves forward to the vision of software that might look like Frankenstein, but understanding that any other way is a waste of time and money. And that we must rethink even the most basic principles, because even Don’t Repeat Yourself (DRY), when misapplied, can lead to disaster.
“We need to understand that, at this point, the code is already a mess, and any change could potentially break anything. […] You’ll go slower. But… how much? […] If the code has improved, won’t we be faster? Won’t there be a lesser chance of breaking something? […] The two alternatives are: either you rewrite all the old code every time you improve, or you stick with the old patterns and give up on improvement. Neither sounds good, right? […] And I see myself burning at the stake for recommending just the opposite, but it’s what needs to be done. There’s no other way. More than that, it’s good to do it!”
Step by step, we build a path. A path that begins by recognizing the developer’s emotional burden, and ends by giving them the tools to overcome it. Because in the end, it’s not just about technical debt or tangled code. It’s about developers. About people. And about giving them the confidence and tools to be able to say:
“resist, because there’s always a way.”
And now the developer is no longer alone. They no longer have a sea of emotions overwhelming them. Now they can feel like a superhero, ready to win the most epic battle: rescuing software that everyone had already given up for lost.
You’ve read about the journey. Now hold it in your hands.
I’ve seen it happen repeatedly — developers reach out weeks after implementing these techniques, sharing how they’ve improved not just their code, but their entire approach to development. Some even point out (with a hint of irony) how I sometimes need to follow my own book’s advice. Because yes, these struggles are real for all of us, myself included.
And now, you have the opportunity to hold this guide in your hands. A real book, printed on cream-colored paper, waiting on your desk when you need that moment of clarity during a challenging refactor. Highlight the techniques that resonate with you, scribble your thoughts in the margins, and build your own path to better code. No subscriptions, no fees, just reliable guidance when you need it most. In your library, ready for use.
Get your copy on Amazon.com because, sometimes, the most powerful tool in fighting technical debt isn’t another IDE plugin or framework — it’s having a clear path forward that you can literally hold in your hands.
Thanks for the read. If you find the book helpful, please consider leaving an Amazon review — your experience might help other developers find their way through legacy code challenges. And for anything else, from new ideas to different approaches, I’m always open to learn new things.
