In the embedded video above, I talk about how we can apply the concept of small wins when trying to replace an old, outdated system with a new one using a technique called the Strangler Pattern.
There are many opportunities in software development to make use of small wins. The process of user story mapping and the acceptance test-driven development and walking skeleton concepts that naturally arise from a well-executed story map are just a few examples of small wins in the building of a new system or feature. Small wins don’t just apply to writing new systems though. You can get small wins in making changes to existing systems using techniques like the Mikado method and the Strangler pattern.
In his essay, Things You Should Never Do, Part I, Joel Spolsky told the story of Netscape’s three-year gap between releases when they decided to rewrite the code from scratch. Joel calls this the single worst strategic mistake a software company can make.
I want to address the problem from a different perspective because sometimes the underlying technology changes and you need to transition people to the new technology somehow. There are good techniques for doing this, but let’s look at the problems that occur when you simply decide to build the new system alongside the old and hope to just cutover to the new system when it is ready.
Traditional Cutover To A New System
Picture a team that builds a software product for use within their own company. Their customers within the company have been using the product for years and are used to its flaws and have, over the years, learned to work around them. The team that built the software may not even be aware of all the use cases that have arisen since the product was originally released and people repurposed it for solving new problems.
Technology changes and the team is forced to rewrite the software to keep it running at all. A vendor the software depends on may being going out of business or the version of the vendor’s software is going out of service or becoming too expensive. The team does a great job and builds a much better product in many ways. There’s just a few tiny use cases that the new software doesn’t cover. Now the team needs to get everyone at the company to start using the new software in place of the old.
One possible way this story can go is the customers try the new software, realize it doesn’t cover all the cases they need and this impedes them from making a full cutover to the new software. Since no software is static, new requirements come in over time and these customers apply lots of pressure to get these requirements added to the original software but care little about when such additions make it to the new codebase.
The codebases drift apart and the older codebase picks up bug fixes and features that haven’t made it to the new codebase. Eventually the new codebase falls behind and the company needs to start paying the vendor’s higher fees to keep the old codebase on life support.
The Strangler Alternative
Could this have gone another way? One option is the strangler pattern. In the strangler pattern, you don’t build a second system. You build tiny replacement pieces of the old system that don’t have the dependency on the vendor (or whatever reason you want to get off the old system) and you kill the old piece that you’ve replaced.
Eventually the old system is strangled, replaced piece-by-piece with the new system. You get feedback all along the way if some use case is broken by any one of the changes and there is no big cutover moment.
The aspect of this that relates to small wins is that, with each part successfully replaced, you have created a measurable win in that customers are no longer dependent on that old code. This is far more motivating than the hope that when a second independent system is finally built it will be adopted by all.
I would love to hear what you thought of the video and article, so feel free to comment below, on The K Guy Twitter, or on The K Guy Facebook fan page.