I understand the reasoning behind Joel Spolsky's article Things You Should Never Do, Part I, but I always see it referenced in regards in situations where the end goal is the production of software. What if I'm a developer who maintains an ecommerce site? My job isn't writing a retail platform, but instead putting it to use. In fact, this wouldn't even be a re-write, as such, but a big database and web design transition.The software our site is based on is written in classic ASP, and is fundamentally missing many features that customers expect from a current shopping site. Rather than continue to add these features in piecemeal, my gut feeling is that I should start to transition to a more modern platform. We would lose the customizations that we've made over the years, but frankly, many of this features already exist (and have have almost certainly been implemented better!) in the package that I'd like to switch to.Am I falling victim to the spirit of Netscape, or am I right in thinking my time is better spent in places besides making our tools do what we need?To clarify, this is the equivalent of switching blogging platforms for us. Any development that I do is essentially rewriting the front end of our website, while the back end is out of my control. Suppose WordPress development had stopped years ago, and was missing modern features like commenting, static pages, clean permalinks, etc. Sure, I could write a plug-in to add those things, but after a while, wouldn't it be better to switch platforms to something that had all those (needed) features built in from the beginning?
We're not a software company. Is a complete re-write still a bad idea?
design;refactoring;rewrite
Before You Upgrade...It could be a good idea if, and only if:it adds features that your customers requested,it don't lose any existing features over the current solution,(some users will ask form them, and if you're a small company, leaving customers are very costly - and might start a wave)it doesn't add invisible/hidden requirements and side-effects,it doesn't come with environmental constraints (or consider them in calculations),your new target middleware is actively developed and supported, and will be so for a (long) while,you carefully consider the costs (and see a relatively short-term benefit afterwards) of:development,deployment,training,maintenance & support,maintenance & support,maintenance & support.Make sure that it won't be harder to maintain than it is now.Plus, you do mention your current technology, but what you'd want to move to. It's even more dangerous if you shift technologies.If You Decide to Upgrade...Be sure to:backup your data,rehearse a business recovery plan...:to revert to your current working status as quickly as possible if things go awry,to communicate with customers about the (failed) transition and issues, and the status of their data.If you upgrade (and if possible) do it iteratively!Update your database or create a new one,copy over your data,update your backups regularly to work on recent copies,and backup the old copies as well (safely encrypted, etc...)Develop on a separate environment,test internally a lot,test with a focus group of some trusted customers.If a complete switch of middleware is necessary, then see if there are any success stories of migrations between these 2 software solutions, and read carefully what other people have done and what pitfalls and roadbumps they encountered.Refactor and Monitor QualityIf it's only (or almost entirely) about messy code, don't do it. Instead:Read my answer on how to organize uncommented, dirty code (it applies to specific code snippets, but also to larger codebases, and the recommened material could help!)Just refactor over time,Use continuous integration and continuous inspection systems to monitor quality and the impacts of the refactoring,And try to reach out to customers to clearly ask what features they are missing and build a very sound business case around each of them to know if they're worth it for small improvement projects.Development is costly, maintenance even more, and building stuff for no particular reason might be nice to please users but remember that you will need to maintain and support it.Also, if you're not a software company, do you have enough trained staff to support this task during development and after deployment? What if some of your staff leaves in the middle of the task?