Comments on: When to Throw in the Towel http://thetoolsmiths.org/2009/07/02/when-to-throw-in-the-towel/ Tue, 27 Jul 2010 02:46:52 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Aaron Walker http://thetoolsmiths.org/2009/07/02/when-to-throw-in-the-towel/comment-page-1/#comment-489 Aaron Walker Mon, 06 Jul 2009 14:38:33 +0000 http://toolssig.wordpress.com/?p=257#comment-489 +1 to everything Ted said. +1 to everything Ted said.

]]> By: Ted Howard http://thetoolsmiths.org/2009/07/02/when-to-throw-in-the-towel/comment-page-1/#comment-490 Ted Howard Thu, 02 Jul 2009 15:16:00 +0000 http://toolssig.wordpress.com/?p=257#comment-490 I find a rewrite to be hard to justify unless the code is very immature or incredibly low quality. Mature code includes special cases to fix rare bugs. When rewrites happen, those special cases are usually forgotten, thereby reintroducing the bugs. Also, a rewrite introducing its own new bugs. Rewrites are also a delay for everyone involved. "If ten people waste just ten minutes per day...you’ve lost over 10 weeks worth of work during that project" Well, if the rewrite takes 4 weeks to finish and is only 50% less buggy then you've gained 5 weeks for others but you've lost 4 weeks of dev time. Your gain is only 1 week, not 10. (Unless you can write code that's far superior to what exists already.) I think about 80% of 'rewrite' projects I've seen never got finished. It usually comes down to two truisms. Engineers are too optimistic about their skills. Engineers are too negative about the skills of the engineers who wrote the code they have to maintain. My suggestion: refactor. Treat "bad code" as a bug. Enter it to your bug database, schedule it to be fixed, then fix it not by rewriting but by morphing the code and testing along the way. Often, you can change the architecture of a codebase in-place and fix things without causing a long delay for the rest of the team. Or re-architect to allow you to rewrite a component at a time. Of course, sometimes a rewrite is still the right choice. I find a rewrite to be hard to justify unless the code is very immature or incredibly low quality. Mature code includes special cases to fix rare bugs. When rewrites happen, those special cases are usually forgotten, thereby reintroducing the bugs. Also, a rewrite introducing its own new bugs.
Rewrites are also a delay for everyone involved. “If ten people waste just ten minutes per day…you’ve lost over 10 weeks worth of work during that project” Well, if the rewrite takes 4 weeks to finish and is only 50% less buggy then you’ve gained 5 weeks for others but you’ve lost 4 weeks of dev time. Your gain is only 1 week, not 10. (Unless you can write code that’s far superior to what exists already.)
I think about 80% of ‘rewrite’ projects I’ve seen never got finished. It usually comes down to two truisms. Engineers are too optimistic about their skills. Engineers are too negative about the skills of the engineers who wrote the code they have to maintain.
My suggestion: refactor. Treat “bad code” as a bug. Enter it to your bug database, schedule it to be fixed, then fix it not by rewriting but by morphing the code and testing along the way. Often, you can change the architecture of a codebase in-place and fix things without causing a long delay for the rest of the team. Or re-architect to allow you to rewrite a component at a time.
Of course, sometimes a rewrite is still the right choice.

]]> By: Aaron Walker http://thetoolsmiths.org/2009/07/02/when-to-throw-in-the-towel/comment-page-1/#comment-491 Aaron Walker Thu, 02 Jul 2009 14:35:22 +0000 http://toolssig.wordpress.com/?p=257#comment-491 Another aspect of determining when to rewrite is how long it takes to develop code that extends or interfaces with the existing system. If your code is a central aspect of your pipeline and that pipeline will need a great deal of work for your project, there are other gains that you can use to explain why the rewrite is a sound investment. I could go on and on, this topic reads like my day-to-day experience. Another aspect of determining when to rewrite is how long it takes to develop code that extends or interfaces with the existing system. If your code is a central aspect of your pipeline and that pipeline will need a great deal of work for your project, there are other gains that you can use to explain why the rewrite is a sound investment.

I could go on and on, this topic reads like my day-to-day experience.

]]>