Brian Marick includes it in his recent blog discussion about the different approaches to dealing with legacy code.
I have been thinking about this a lot lately. I have been working with a client where a strangler application would have been a good solution. It was an almost repeat scenario from when we first applied the Strangler Application approach to a legacy financial trading system.
One of the key aspects of the original project is that we left the legacy application alone. The legacy application was still maintained by the original team. A new team completed the replacement strangler application. The rationale behind this was that the original team had repeatedly failed to address the legacy problems and was holding back the business. A key problem was the team itself. The team appeared incapable of coming up with an alternative solution, but management did not want to change the team as they were the only people who knew how the legacy application worked.
The new client rejected the approach
We can’t do that! There is no way we can get the budget for two teams
Asking for more money in this way highlights the problems of the original team and the fact that the project management do not know how to fix the original team (and have not addressed it before).
I now realise a critical success factor of the original project was the way the Project Manager hid the cost of the strangler application by associating it against a different project that had spare cash available.
This is a real barrier to applying these ideas in this situation. I wish I knew an alternative way to make this happen (any thoughts on this would be welcome!).