Every rewrite project has opportunities in it. Opportunities to improve your development process, your build and deployment strategies, your third party tools and libraries, even our choice of language can come under scrutiny (except for when you have to move because of the language you were using!)
There are also opportunities within a rewrite that can help the rewrite project itself and make your life easier supporting that rewrite after it has successfully completed, because the decisions you make during the rewrite will go on to bite you for a long time afterwards if you make them without exploring all the possible outcomes.
One way to make sure you cover as many possibilities as you can is to prototype. By this I don’t mean do a quick rewrite on a small part of your project and see if it works, because doing this will only give you a false dawn and make you think you’ve started your rewrite before you’ve even considered where to begin.
What we have done, and what I suggest everyone does prior to rewriting a single line of code, is to take all the third party libraries you intend to use in your rewrite, the version of the .net framework you will stick to, the IDE you will use, the database tools and providers you need, the development style and driven-development method you intend to use, and add in the process of how our rewrite will run.
Obviously it’s difficult to see into the future and yes, you can’t plan for every eventuality, but you can get damn close and realistically you should have a good idea of how you intend to put everything together before you start.
Now, with all that knowledge and information, find a problem within your own company that can be solved with an eventual product that is on the same delivery platform as the product you intend to create at the end of the rewrite – ie; don’t write a web-app when you need to rewrite a desktop application! Then, go ahead and write it using all of the areas we discussed above – use a database if your eventual rewritten app needs a database, use a third party WinForms library if you’re writing a WinForms app and intend to do so. Remember to think about all the little extra things you might plug into your rewritten product. Will you use bug reporting software? If so, include it in your prototype app.
But here’s the most important requirement of all for your prototype – make sure it is something that people will use because the knowledge you will gain from this prototype is invaluable and if no-one is using your prototype you will not get that knowledge.
If you can, do more than one. Or better still if you are asked by a client to write an application then use your rewrite methods and all of the above to develop their app (just remember to tell them it might take a little longer and knock the price down a little) – as I say, the information you will gain from the prototype stage is absolutely invaluable – you will learn so much about how your processes and tools do or do not stick together.
For example, we did three prototypes and from the first one we realised that our chosen UI tool was not going to cut the mustard. On the face of it, sure no problem, it looked good, it did all we wanted to and the support seemed great. We took a trial, even bought a license but as soon as we got deeper into what we were prototyping we realised that there were certain elements that we were going to have to tinker with. Had we started the rewrite and bought licenses for the entire team we’d have had no choice. We’d still be tinkering and possibly working around bigger problems as a result of that tinkering. It might have taken us a year to find the problems in the rewrite because the plan wouldn’t have got us to a specific stage quick enough to realise the inherent difficulties in this ‘chosen’ UI library. So we had to look around at other vendors.
Thankfully we found DevExpress and I’m so glad we did as they have been second-to-none with their customer support. The power of the libraries are immense and the tools they provide, not only in the product but also in the after-sales; things such as the webinars, the training videos, the reams and reams of documentation and the people, not to mention the excellent CodeRush. There is a very big reason why DevExpress were awarded the Best Software Development Tool Award at TechEd.
Had we not done the prototypes we would have stuck with the cheaper UI tools and we’d still be working around the problems today.
I’d like to point out that I’m not employed by or paid-in-kind by DevExpress. I have no ties to them apart from being a loyal customer.