Lessons Learned from Software Rewrites

Re:Lessons Learned from Software Rewrites by faragon on Monday September 05, 2016 @09:31AM (#12430159)

In my opinion, asking for "removing unused features" is one of the consequences of full rewrites. Also, a reason for having to maintain "dual systems" for years. It is not infrequent having "dual systems" and having to deprecate the "new", just because after e.g. 10 years you can not get rid of the old, or even worse: the "new" performing worse than the old (e.g. old simple centralized system working much faster on new hardware vs "new" pseudo decentralized mess that can not scale as good because inter-node communication overhead).

BTW, every time I read Martin Fowler quoted in a post as full rewrite justification for the "faith jump", I get scared.

I don't know why the poster didn't implemented the new API, using it for the new features, and eventually, rewrite old API commands (one by one, not all at once) calling the new API, so in the end, new API would remain, and old API would be just some wrapped calls to the new API.

[ Parent | on HN ]

Re:Lessons Learned from Software Rewrites by amartinsn on Tuesday September 06, 2016 @02:12PM (#12438004)

That was exactly our approach, for the old HTTP API, we kept the same contracts (URIs, response body, etc.) For the EJB one, as only one remaining client was using it, we deprioritized that, but we were going to pick the features they were using, and make the Java client point to the new API implementation, also keeping the same contract.

[ Parent | on HN ]