Managing Large Refactorings
It’s very hard to build a large software project without having to undergo major refactorings every so often. Whether it is due to changes in your platform, changes to the market, team growth, regulatory changes, or just dealing with an ever-increasing amount of customers and their data, at some point your current approach will become insufficient. When that happens, you may be tempted to “just rewrite the application”. This is nearly universally a mistake however, pulling off a solid rewrite is almost always several times as difficult as a major refactoring and it always takes longer than you think. And given how awful large refactorings can be, this should generally make you want to avoid a rewrite. That said, a large scale refactoring is still very difficult and very risky endeavour. While your team is busy on refactoring, your competition is not sitting still. You’ll also be navigating political problems – if the people who built the current system are still there, you’ll need to be careful not to alienate them. And there are political problems with the larger business as well. People outside of technology typically have a hard time understanding why software refactorings need to happen – they don’t understand why you couldn’t “get it right the first time”. Most people outside of tech don’t realize how much every decision is really about dealing with tradeoffs in the present, rather than long term best practices (or even how often the latter change). Furthermore, the difficulty of dealing with scaling is almost never linear – having 10X as many records as you did before can often result in the system taking 30X to 100X as long to process a request. However, there is some hope. You can conduct a large scale refactoring of an application over time, without excessive risk and without alienating your team and the rest of the business. Several factors come into play. First, information diffusion throughout the team has to be respected – any change you make is going to take time to be accepted and for everyone to get used to it. This process cannot be rushed. Second, you still have to get “real work” done for you stakeholders – the rest of the world is not sitting still. Third, you have to manage team morale and cohesion carefully – large refactorings are disruptive and require that you change code that other team members have written. Finally, you have to resist the urge to change “everything that’s wrong” about the system – it’s tempting, but it WILL cause you to fail. Large refactorings are risky. Not only is it very easy to make sweeping changes that cause major problems for your application, but large refactorings can also derail your team for weeks or even months, while your competition keeps moving. In addition, if not managed carefully, large refactorings can demoralize your team and create conflict. In addition, large refactorings require that you manage team morale as well as the political situation outside your team. However, if you follow the suggestions we’ve given here, large refactorings will be easier, but not easy. Nothing makes a large refactoring easy, but there is no reason to make it harder than it has to be. Links Join Us On Patreon Level Up Financial Planning