In the early stages of any application, there's a tremendous emphasis on speed and new features. This blog will talk about how to prevent falling into this trap and how to navigate past it if you do.
Click here to see part one of this series, World class SaaS-Building a durable competitive asset.
If you've been around technology long enough, the following is probably a familiar pattern:
In the early stages of any application, there's a tremendous emphasis on speed and new features. "We need this feature! If we don't get it in two months, we lose the market." Sound familiar?
This pattern lives at the expense of technology health with teams taking shortcuts to solve for speed. If it continues, it can create major problems and you wind up with convoluted, hard to navigate code. Adding new capabilities becomes very complex and only a few of the veterans know how to navigate the codebase.
Every mature software company I know has hit this wall. Some of them are able to navigate past it, some aren't. Another pattern you're probably familiar with: the re-architecture project that takes years and never finishes. This blog will talk about how to prevent falling into these traps and how to navigate past them if you do.
Preventing technical debt
As a technology leader, you need to know the right time to break the initial cycle of "feature craziness." This is extremely difficult — like kicking an organizational drug addiction. You can't do this too early (before product has gotten traction) or too late (development has slowed to a crawl, or defects and outages are impacting you severely) in the product evolution and requires judgment.
This step requires an explicit discussion with the entire team, including product owners. The team needs to agree that the current path is not sustainable and commit to operating differently with a sustainable process and an adherence to design and architecture.
Teams should factor in time to do things "right" as part of their estimates. They should do this as opposed to taking shortcuts. When exceptions have to be made, it should be an explicit discussion with a plan to address it later in the form of a backlog item.Allocate about 20% of your team's bandwidth on an ongoing basis to refactor code, upgrade to newer technologies, and ensure that you're not building up technical debt. This also requires commitment of the entire organization starting with the engineering and product leadership. Your car and house require ongoing care and maintenance to ensure that they last a long time and operate efficiently; this is not that different.
Paying off technical debt
If you're at a stage where the technology debt has already ballooned and requires a reset, then start looking for a new job! (Just kidding.) This is an interesting challenge and is actually a great experience to go through.
The following is a path I've taken in my own past-and failed miserably. You attempt to re-architect the entire product/platform from ground up. This project is set up with a separate group of enthusiastic engineers while others continue to toil on the old code base, which comes with its own set of organizational challenges.
Ultimately the projects end up taking too much time without sufficient pay-off in the interim; the business ends up losing interest and the project is abandoned. Projects that are completed end up becoming disappointments since the expectations are sky high after taking so long. This story has played out over and over again at many companies.
Now let's talk about the characteristics of the re-architecture projects I was involved in that did work.
- It was a joint partnership between product and engineering and not just an engineering project.
- The approach was to do it gradually where parts of the e2e functionality were re-imagined and rewritten in the new technology stack.
- The re-imagining ensured there was end user/business value provided by every release rather than just a technical project where the exact same functionality is provided using newer technology.
- Both the product and engineering team were very thoughtful about where to start and the roadmap of e2e flows that were to be delivered.
- The user experience was thought through carefully during this transition phase and some necessary concessions were made.
This path might feel like it'll take longer than a total re-architecture from the ground up, but it gives you a much better chance of navigating a tricky situation and coming out successfully. Don't forget that prevention is the best medicine and make sure you're investing in your technology health in the first place to avoid needing a re-architecture project.
As SVP of Engineering and Operations, Sunil Rajasekar oversees core development and delivery of Lithium's enterprise social customer platform.