Prioritizing and decision-making when you need to refactor your SaaS product
Building software is not like building a house. It's like building a spacesuit while flying through space.
The software systems we build are in a constantly changing environment. The materials we use to build them are shifting and the people who use the tools are changing. When talking about "building software," we are likely referring to adding features and enhancements. Sometimes we refer to performance and security, which are less visible qualities. We almost never talk about the most important, but completely intangible ideals of simplicity and technical excellence.
When companies focus on building features and ignore ongoing technical crafting and general maintenance, this introduces something referred to as technical debt. The reason business leaders should care about this technical debt is simple: adding new features to a labyrinthine software platform is expensive and the outcomes are unpredictable. The system becomes exponentially more costly to change, bug-prone, and overcomplicated.
It's inevitable that teams will reach a breaking point where the cost of building new features outweighs the possible benefit (and profitability) of those features.
Deciding to refactor or rewrite
At some point business and technical teams will be sitting around a table asking themselves what to do, when to do it, and how much it will cost. Your options might include:
- Increase developers working at the new features and maintenance.
- Refactor what you have.
- Use the current system while rebuilding a new platform.
- Ignore the problem.
- Rebuild the platform completely.
The timing and prioritization of your product refactoring will have an enormous impact on the cost and effort that your team will need to consider. Many of the Agile/LEAN principles can be helpful during this process to avoid costly missteps. It can be a messy process and sticking to a consistent agile process while refactoring can contribute to a smoother process.
A few key insights to SaaS refactoring:
If you're still deciding on the best time to start refactoring, it's right now. Waiting too long to put resources behind the effort can result in a tipping point where even maintaining the current platform requires far more effort than the benefits/profitability of keeping the project alive. Refactor or die—that might be a reality for teams that don't strategically plan to attack the problem. Floundering or delaying the process can often be the worse option, causing compounding interest to accrue on your technical debt making it harder and harder to improve the product.
Pace small refactorings
Build into your sprint and resource planning the process of identifying incremental refactoring activities whenever possible. By creating repetitive refactoring practices you will create some "overhead" that could dramatically reduce the technical debt as you pace the refactoring out over time. This is best for teams that don't have much flexibility in resource planning, and reinforces best practices as team members learn from, and adjust based on what they discover.
Partial refactor for larger projects
Not all refactoring work can be done in small increments. There will undoubtedly be large batches of code that require more attention, like a full module or 3rd party component that your system has many dependencies on. Look for opportunities to run both the old and the new versions of the component simultaneously. By partially refactoring you can break a large refactoring into many smaller pieces. This may also force your team to refactor the system to be more modular in its dependencies. Looking for creative technical solutions is crucial.
Building Business / Technical Team Trust
A combative relationship between business/non-technical folks and their technical counterparts can often delay progress and cause unnecessary financial and technical costs. Creating a shared language that clarifies needs and requirements can help bridge the understanding gap.
It's the business leaders' responsibility to better understand the implications of refactoring a platform and trust their technical lead. Allowing developers the freedom to refactor even if it may impact deadlines for feature releases or visible improvements can reinforce strong relationships and create a more cohesive team.
Technical leaders would also benefit from a crash course in how business needs and strategies are prioritized. By delivering requests and recommendations in non-tech language that ties to business objectives, you can easily move your agenda forward. Software teams need to be clear about the costs to minimize the costs and gives stakeholders important information to make decisions. In the end, both teams benefit from a stronger platform.
Tech Team Solidarity
In refactoring work, Agile teams require high levels of communication and collaboration. With a cohesive understanding of why and how the refactoring process is being done, a team will be able to work faster and more effectively. According to the Agile Manifesto "The best architectures, requirements and designs emerge from self-organizing teams." The practice of pair programming is often used to create deep levels of shared understanding among team members. Shared ownership of code supports developers making independent decisions with confidence. Accountability and a culture of experimentation allows for teams to try alternatives quickly and with team support.
Big Room Studios supports development teams as they refactor and grow their platform. We consult on best practices and work alongside your developers to speed up the refactoring process for legacy code bases. If you're interested in understanding more about our Team Augmentation services, get in touch!