Tuesday, January 22, 2008

To recode or not to recode

When an application is in daily use, especially a web application, for many years (7+), its in all likelihood:
  • Written in a scripting language (ASP, PHP, CF, et al)
  • Been worked on by MANY different developers
  • Has fallen pray of many server and client side "fixes"

The question then eventually becomes when and/or if you should recode the application or parts of it. Some might jump straight to "recode the whole thing in .net/flex/j2ee/ruby" decision, while others might be a little more circumspect, and decide instead to focus on simply recoding with better practices the pages in the language they were written in the first place.

It's a very difficult decision, and I don't know if I have a strong opinion either way, I have a tendency to look at the code base and decide on a case by case basis, especially if the code appears to be stable and operating normally.

The problem is maintainability in the long term, but I don't know if the potential new bugs included in a recode (or worse: a rewrite) make it worthwhile.

It depends on the system. If you have a bad email post form, recode it for sure. If you have a vast client management platform hit by 100 000 users a day... maybe reconsider bringing out your Dreamweaver and going 'bos' on the code base.

Over the coming months I'm going to be doing a partial piece meal code review and instance recode of a large ASP application, so expect some stories of pitfalls around this.

I'll be kicking this off tomorrow by looking at ASP/VBScript's Date() and Now() functions, and why they are ABSOLUTELY not what they seem, and should NEVER be used for anyone expecting any certainty around the date or the time.

Labels: , , , , , , , ,