New and Improved

I always wondered about that phrase- "New and Improved". Either it's 'new', which means it never existed before, or it's 'improved' which means that it's better than the previous version(s) and, therefore, existed before. Finally I can stop wondering because I think I've come up with a situation where it can actually be logically applied.

Now that the first version of TFS (Team Foundation Server) is out in the wild doing its wild thing and we're well on the way in our hunt for version 2 we have a new issue to contend with. This issue is something that never came up in the last product cycle- Legacy Code. I'm talking about both product code and automated test code (of which we have a great deal).

The issue of course is that as we work, we learn. We come up with smarter, better, faster, stronger ways of doing whatever needs to be done. The old way still works, certainly, it's just not correct according to new preferred practices. In an ideal world, we'd like to refactor all of the code any time a new method comes into the shuffle. However, we only have so many hands and would like to release the next version some time this decade.

Given that, you have to make some tradeoffs and costing decisions. How bad does old code have to be before you update it? Certainly you'll update anything that gets broken, but do you apply all new practices, or just the critical ones? If it's bad enough, do you scrap it and start again?

In this sense, our automated test code is both new and improved. Some portions of it never existed before since the features tested didn't exist previously. Some portions of it have been upgraded to the new standards. And the third, unspoken, category is all that testcode from V1 that still does something useful, whether or not it's written the way we'd do it today.

I'd like to finish by posing a question to all you code writers out there- When what made your code tick just doesn't click, do you give it a kick, or just let it stick?