To recode or not to recode
- 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: .net, asp, date(), decisions, dreamweaver, now(), recoding, scripting, vbscript
