I am sure every developer had seen the following situation once in his carreer: you have to support an older product which for instance is based on a out-dated technology like the Motif-UI-Framework, a legacy codebase, spagetty-code or whatever. Of course a lot of users are still using this product, it supports a really rich featureset even if the way to use this features seems to be much too complicated. And of course you have to add new features and bugfixes all the day. Unfortunately caused by a really taff project-plan you are only able to add another workaround to bring the new feature up. No time is there to deal with all the legacy code or build some automatic tests or even doing some urgent refactoring tasks. In other words: you have to deal with legacy code.
So how can we deal with stuff like this: let’s rebuild it from scratch for instance? Then you can use some more modern technologies and avoid all the older errors which were made by the old product-team. Sounds good, right …
Nice idea. Other companies tried this as well, Netscape for instance. They tried to rebuild their whole product from scratch and their failed. The old company Netscape is history. But why? Why is a rewrite not the right way to bring a great idea onto a modern foundation. Just keep in mind: the product has users and these users normally have some reasons to use it even if the underlying technology / codebase is legacy. And normally these products a stable in their special way.
Do you know the idea of technical depts? If not take a look into this great article: http://www.infoq.com/articles/managing-technical-debt . You increase your technical dept when you inserting a quick hack to bring up a new feature in time without cleaning up your code base / specification / documentation or tests. Every time when you clean up your code you decrease your technical dept.
The feature-dept coming from the users will be decreased when you have finalize a feature request, even if it done by a hack. Users normally are interested in features even if the underlying code quality is really bad. And this is the one that gives you an income at the end of the day.
So let’s restart your great idea with a new implementation from scratch. You will not have any technical dept at the beginning but a really big feature-dept caused by the old users which core-interest is to solve a specific problem with your tool. They are not interested in your new fancy tech for a really small featureset. And this is the reason that you will have to support the older product as well until the newer one is really “finish”. Of couse the older product still get’s the new requests and bugfixes. And of course the new one has also bugs, needs refactorings. In other words new technical depts will be added as well.
So what has happened: in the beginning you tried to solve the issue with your technical dept by recreating everything from scratch. And now you earned a new feature dept onto the original technical dept plus new technical deps caused by a new fancy tech, repeated errors, …
Of course the sum of all of these is much bigger than the older dept. And when you have finalized the new product? Normally not all users will switch to the new one.
So is this really a win-win situation? From my point of view: no. It makes much more sence to decrease the technical dept of the original product and try to bring it into a state where you are able to deal with the issues. If you want to do so: stop supporting the old product immediately.