News for hackers. Stuff that matters.
Re:Lessons Learned from Software Rewrites by hcarvalhoalves on Sunday September 04, 2016 @11:42PM (#12427957)
Sometimes a better approach is to wrap the system you want to deprecate rather than have a parallel implementation. First, because you might not fully comprehend the current implementation to replicate it. Second, because in real life often there's not enough time, budget and coordination between teams to migrate old clients.

Since their main requirement was having a REST API for new clients, and apparently the old implementation worked fine, they could have implemented a EJB -> HTTP layer on top, and have new features talk straight to the DB. Eventually, they replicate all the features talking straight to the DB (w/ the added benefit they can test against the codepath going thru the old system). Finally, death by phagocytosis.

Re:Lessons Learned from Software Rewrites by gpderetta on Monday September 05, 2016 @07:54AM (#12429637)
Unfortunately that doesn't work either. I have seen libraries with 5 (five!!) levels of wrapping because each developer that wrote a wrapping level didn't understand the layer below/thought it could do a better job with the interface/was prematurely generalizing.
Re:Lessons Learned from Software Rewrites by allendoerfer on Monday September 05, 2016 @12:00AM (#12428012)
I think the problem was, that they had to implement new features for the clients only supporting the old version, too. At this point you are left with a HTTP wrapper around your old software, which does not qualify as a rewrite.
Re:Lessons Learned from Software Rewrites by zigzigzag on Monday September 05, 2016 @09:40AM (#12430218)
Well, yeah.

It sounded like an HTTP wrapper is all they actually needed. Or in fact any well specified wire protocol with lots of implementations. It could have been protocol buffers over raw sockets also.