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
I'll see your Uncle Bob and raise you one Joel Spolsky.
ReplyDeletehttp://www.joelonsoftware.com/articles/fog0000000069.html
"There's a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong."
There's a lot of valid points here. Funny there's good cases both for and against starting from scratch. Rewriting G2 as a whole? Years of unnecessary delays, and repeating many of the old mistakes. Rewriting the sound system? Massive savings in productivity for the content creators, and a bunch of other benefits.
ReplyDeleteThe point Joel makes about code not rusting, sounds good in theory, but I don't agree. No, bits don't deteriorate and code you don't touch doesn't all of the sudden start doing something different. But unless you're living in a vacuum, code always grows, new features are always added, patches are applied, and the code that used to work stops working. This happens all the time. And it's more likely to happen in code that takes too long to read thru, because nobody can understand the full consequences.
And yes, the old system has been tested. Unfortunately, unless the tests are automated, their validity evaporates over time. Sue's feature has been tested, Bob's feature has been tested, and then John comes in with his Sue-Bob-code interaction extravaganza, and everyone forgot what they were supposed to be testing for.