You're right Amy, it is very important to plan how to break up the software into pieces. That, for example, was why I was able to fix 1,000 bugs in software more than a decade ago. An example, by the book, of cleaning an entire software without rewriting. And I couldn't agree more with your point that half-cleaned code can be worse —the probable exception is when you're headed in the right direction—, exactly like having to touch 10 copies of the same logic is a mess.

Yet, I am afraid, that most of the right decisions, need skilled developers, and skilled managers. For example, most of the managers that I know do not care about how hard it is for developers to add new features, they only care about their tight schedules and quarterly objectives. And at the same time, most of the developers that I know are not skilled enough to maintain a large, growing codebase by themselves. Just to mention, concepts like dependency inversion completely evade their understanding. And, brace yourself, I've been explained, several times, that TDD is testing the software —manually is ok— after coding. And now, add to the mix that I am talking about very large codebases maintained for more than five years.

For some years, I believed the cause was most frontend developers came without any degree of any kind, but nowadays, I see the same low skills even in people from university. Including the ones from other languages like C# or Java. In fact, just this weekend, I had a conversation with a friend about how low is the level among developers in both organizations.

So, what is the idea behind all this article?

About not rewriting, I believe that good developers often can salvage bad software. There is a lot about that in the DDD methodology, and it is sound. And rewriting has a lot of dangers. In addition to the article in which I explained that, today, I've got news about one rewrite —because change of technology— that missed one use case. It disrupted a critical functionality (something like the shopping cart does not work with some products). That happened because in the rewrite, some specs were lost. Also, there is a big problem, if the team who did the mess in the first place, do the rewrite, the result will be another mess. I saw that too many times. Just to say that I have seen the same software rebuilt three times, just to throw it again. A mess.

And the other point that I try to deal is with learning. I often find that developers love to compromise and rush in deliveries. They do not care about clean code, and when the project becomes a mess, then, or they want to rewrite, or just continue pushing doing nothing.

So, I want to inspire them, to give them the motivation, so they can do better. Because if they stop when they have trouble, or they just continue pushing, they will never try, and they will never learn. What if they make 10 copies of the same? Well, that it is not worse than the already 10 copies that they had. The difference is the mindset, the first 10 copies were just to rush in the delivery, the next 10 copies are trying to make the code better, and thinking about it. What if it is not fully clean? No problem, because they are not qualified to clean everything at once, they need a learning process, so, with the code mixed, they can learn better what works, what not, and why. Yet, if you observe the guide that I give, it is not random, neither frivolous, it has a very clear and direct purpose to attack the problem in the right direction, so it maximizes the success probability. Furthermore, I have seen it success every time. For long lasted projects, five years or more, but it is also working well for shorter ones.

And you are right, the result can be worse, but it also can be better. The objective is not to create good software overnight. Instead, it is to put developers on the right path, and above all, to give them the correct mindset to maximize their chances of success.

So, yes, you are right, but, I guess that not everyone has the luck of working in so a supportive and resourceful environment.

BTW It took me a full day to get a good answer, because, your points, are good and sound.