When code rots, it becomes rigid, fragile, and immobile.
When you make a change, you need to make it in many places. And each time you touch the code, you risk breaking it in still more places!
Fear dominates.
You need to clean that code, but you don't. Why? Because you are afraid! You look at ugly code and you think: "Wow, this is ugly. I should clean it.". And the next thought in your head is: "I'm not touching it!". Because you know - if you touch it, you'll break it. And if you break it, it will become yours.
So you leave the code in the system to gradually rot into chaos.
That rot slows us down, slows everything down. Changes that take days take weeks instead. As the uncertainty in the code grows, so do our estimates - and yet we still miss them. The whole project slows down to the point of stillness.
Let me clean this up
You decide to propose a dedicated effort to clean the code. The management agrees. After all, you forecast that with cleaner code your estimates will shrink and the project will be able to progress at a faster pace.
You begin cleaning by changing a small portion of the code and conduct simple manual tests that you have put in place to verify the software still works as it should.
At some point you notice a bug. You fix it and notice that another bug appeared. You fix that too. With each bug that appears you spend more and more time debugging, and less and less time actually cleaning the code.
After a few weeks you decide to hand the "cleaned up" code to QA. They run their manual tests and return to you with a long list of weird behaviors, malfunctions, and even crashes - things so delicate that your manual tests had no chance of revealing them!
With regret you finally make the decision to throw out the "cleaned" version of the code, and return to its original version.
Cleaning your code
Uncle Bob shows an example of code cleaning done in a function with 100% code coverage. That is a fearless example of code cleaning. As he concludes:
Tests let you clean your code.
No time for TDD
You may hypothesize TDD is too expensive for real-world projects - that a good test suite is much too time-consuming to create.
Here is Uncle Bob's experience:
These tests [we have in FitNesse] save us a massive amount of time - and they have from day 1. From the very first line of code until now, FitNesse has been a test-driven project. And we can develop it faster and safer than any previous project I've been involved with. There are fewer defects, we debug less, we code faster, we code better. In short, we can dance rings around projects that don't have tests.
He concludes that his project crew needs that suite of tests, as "it mitigates defects, it shrinks debug time, it speeds development, and it eliminates the fear of cleaning the code".