A few years ago, I joined a $30 million digital marketing company to turn around its engineering team. Company leadership had neglected to perform routine upgrades to its money-making products, focusing resources on a new venture that ultimately failed.
When I came on board, the organization was in dire straits. Not only were we playing catch-up with the competition, but we also operated at reduced velocity because of the significant amount of technical debt our failed product had caused. Because fixing technical debt is an investment whose benefits accrue over the long term, the perceived short-term effect of investing in new features routinely won out.
We sold the company two years later. While we managed to add significant new features, we had only eliminated a fraction of the lingering debt. Hindsight is 20/20, but we would have delivered a more robust product and additional features if we had invested our resources into tackling technical debt instead of chasing shiny objects.
When money is tight — whether because of debt or the costs associated with growth — it’s easy to let seemingly inconsequential aspects of your business go unattended. Technical debt is quite similar to financial debt, with penalties that compound over time.
Procrastination is technology's archenemy
In all fairness, technical debt is surprisingly commonplace. CAST Software estimates that the average-sized application has a technical debt of more than $1 million, meaning each line of code averages about $3.61 of debt.
When a growing business has financial issues, engineering teams frequently fall into two major traps.
The first is failing at hygiene — not keeping libraries, frameworks, and tools current with the latest version. Companies that regularly update these items (every quarter, for instance) reduce costs by keeping refactoring and validation efforts in check. When one falls behind, complexity and costs increase in a nonlinear manner as updates accumulate, simultaneously upping the odds that the less appealing upgrade will get ignored for another cycle.
The second trap is being timid about upgrading system architecture. There's a common myth (willful ignorance, perhaps) among business teams that the architecture designed at launch can sustain huge traffic increases. On the contrary, periodic rearchitecture should be a given.
Rearchitecting might be a risky proposition because it touches so many elements of the code. To be blunt, there’s never a particularly good time to do it. That said, there’s definitely a bad time to overhaul your code: when it’s long overdue and your team is stressed out about making short-sighted decisions.
Engineers and business teams alike must have the courage to engage system architecture and data modeling in anticipation of growth rather than to catch up with it. Engineers are often accused of wanting to “play with the newest toys,” but the latest and greatest software tools can open new capabilities while increasing velocity and reliability.
How to stay ahead of the technology curve
For companies to keep their technology stack, products, and tools current during growth phases, here are a few best practices to consider:
Upgrade early and often
A survey by the Software Engineering Institute at Carnegie Mellon University found that a shocking 65% of companies lack defined practices for managing technical debt. Periodic upgrades of libraries, frameworks, tools, and infrastructure will keep your code current with industry trends. Postponing upgrades to save money will cost you a lot more in the long run — getting up to speed after years of falling behind is a massive undertaking.
When I worked for the aforementioned marketing company, a large portion of our code was running on the PHP 5.1 programming language, which was five releases behind the then-current PHP 5.6. Upgrading to 5.6 entailed navigating through five doses of backward compatibility issues, almost guaranteeing major issues with key features. Rather than trying to play a dangerous game of catch-up, we would have been much better off handling incremental upgrades by testing them during the normal release cycle.
Review your architecture at least once a quarter
Quarterly system architecture reviews and data model reviews that are informed by a product roadmap will create visibility and sustain the growth of any company. The best way to ensure system architecture and feature development remain in sync is to develop a technology roadmap.
A technology roadmap stems from the product roadmap, defining the big-ticket technology enhancements required to support the product's major features. It should also address the scalability of the product by defining when major components of the product must be upgraded based on the anticipated traffic volume.
A technology roadmap should lead a product roadmap by about six to 12 months, which is the amount of time an engineering team needs to conduct the research necessary to develop new capabilities. To deploy new business intelligence tools, for example, an engineering team would have to select the proper data store (e.g., Hadoop vs. a traditional data warehouse), data models, etc., before beginning the development of new features.
Find room in the budget for tech upgrades
Financial planning should factor in future technology needs with a minimum horizon of 24 months. This must include major upgrades, as well as rearchitecture projects.
Two years is a lifetime in technology. Any company experiencing moderate success over a two-year span will need to upgrade at least one major component of its product — guaranteed. It would be negligent not to budget for such major efforts during financial planning.
Technology modernization isn't fun, but it's also unavoidable. In some ways, it's similar to a routine trip to the dentist. It might not be fun to have someone poking and prodding around in your mouth, but neglecting those needs can lead to far worse things down the road. Every company must eventually update its frameworks, redesign its architecture, and modernize its tools. The only choice is whether you want to pay now or pay much more later.
Getting ahead of potential problems will ingrain these processes into the DNA of your engineering and business teams. Ultimately, a dedication to deliberate upgrades and updates minimizes the cost of these efforts while accelerating future development velocity. This is the recipe for faster future growth.