I am watching the series "Clean Code". Episode 6 on Test Driven Development describes a nightmare scenario for refactoring that is so close to heart, that I just have to quote it here.
"Have you ever brought up some code on your screen that was ugly? And the first thought through your head was, 'Wow this is ugly, I should clean it'? And the next thought in your head was: '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"
"Sometimes the mess gets so bad, that we contemplate a dedicated effort to clean it... At first our employers might even support this idea. ... But cleaning code is hard and fraught with risk. When we clean a module, we have no way of knowing that that module still works properly. Perhaps we've introduced subtle bugs, or race conditions, or data corruptions. The more we clean, the riskier the situation becomes. The ad-hoc manual tests we've been running to make sure that the system behaves properly, begin to fail for reasons we can't easily explain. We start to debug and the debugging time grows, and as it grows, it eats into the time we thought we'd have for cleaning. After weeks of cleaning and debugging, we finally run out of time, and although we've done a lot less cleaning than we wanted to, and a lot more debugging than we'd hoped, we think the system is at least a little bit cleaner. So we hand the new "cleaned system" to QA... And unfortunately they return with a huge pile of defects. These defects are daunting, they contain inexplicable behaviors, data corruptions, even crashes. The list of new defects is so long and so puzzling, we don't even know how to estimate
how long it would take to repair it. After much wailing and nashing of teeth, we finally conclude that the only sane action is to set the "clean system" aside, and to revert to the pre-cleaned state. "
"And so we're stuck with a mess that we're too afraid to clean. Our estimates grow with every passing year, our productivity continues its asymptotic plunge toward zero, and yet we're helpless to do anything about it, paralyzed by our fear
"Have you ever brought up some code on your screen that was ugly? And the first thought through your head was, 'Wow this is ugly, I should clean it'? And the next thought in your head was: '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"
"Sometimes the mess gets so bad, that we contemplate a dedicated effort to clean it... At first our employers might even support this idea. ... But cleaning code is hard and fraught with risk. When we clean a module, we have no way of knowing that that module still works properly. Perhaps we've introduced subtle bugs, or race conditions, or data corruptions. The more we clean, the riskier the situation becomes. The ad-hoc manual tests we've been running to make sure that the system behaves properly, begin to fail for reasons we can't easily explain. We start to debug and the debugging time grows, and as it grows, it eats into the time we thought we'd have for cleaning. After weeks of cleaning and debugging, we finally run out of time, and although we've done a lot less cleaning than we wanted to, and a lot more debugging than we'd hoped, we think the system is at least a little bit cleaner. So we hand the new "cleaned system" to QA... And unfortunately they return with a huge pile of defects. These defects are daunting, they contain inexplicable behaviors, data corruptions, even crashes. The list of new defects is so long and so puzzling, we don't even know how to estimate
how long it would take to repair it. After much wailing and nashing of teeth, we finally conclude that the only sane action is to set the "clean system" aside, and to revert to the pre-cleaned state. "
"And so we're stuck with a mess that we're too afraid to clean. Our estimates grow with every passing year, our productivity continues its asymptotic plunge toward zero, and yet we're helpless to do anything about it, paralyzed by our fear
