Yesterday we had an interesting meeting at the Swedish .net user group Swenug in Gothenburg. The them was “The Big Rewrite”. Instead of allowing a speaker to talk about something interesting we chose this time to make it as a discussion meeting. Two groups in two different rooms had an open discussion regarding the big rewrite.
What’s the biggest problem regarding rewrite an application to new technologies? how can we work to prevent major rewrites? What does the business people in the organization act and so on.
Every one agreed that if you need to rewrite something you really need to know what requirements you really need in the new version. To know this you need to measure what features are mostly used today. We need to know if we can change it to better features. We most understand what featured we can delete. We need to understand the ROI of a rewrite.
It’s also important to see a rewrite as a new project not just a rewrite.
Maybe go full agile, use lean startups and so on.
But the most important part is that you can’t just rewrite a product if the whole organization can’t rewrite them self. In other word, it’s not only about write new code you also need the whole organization support to understand what the new rewrite is all about etc… There is no use to take the old backlog and just add new code.