Technical Debt: Slowing Down in Order to Speed Up

Accruing technical debt is a natural part of life at a software company. Technical debt as described by Martin Fowler, is a useful metaphor for describing the end result of quick-and-dirty decisions, which generate a debt in the form of ongoing maintenance or development cost that must be paid back at some point in time. Like a loan, you can continue to pay only the interest, or start paying down the principal through refactoring and redesign.

On the surface, technical debt sounds like something to be avoided at all costs. However, there are several valid reasons why the managed accumulation of technical debt may make sense. You might need to prove the market for a product or feature exists before investing in the optimal design or most scalable solution. It may also make sense to prioritize delivering a particular feature by a particular date even if it necessitates the creation of new technical debt. Finally, certain types of technical debt may never need to be paid off. If a feature is in need of redesign, but is seldom used or valued by your customers it would be smarter to remove the feature altogether.

Technical debt is manageable if the debt is visible, willfully taken, and paid down consistently and gradually. Visibility means writing it down. Technical debt can and should be tracked either formally or informally. We’ve used a wiki for this purpose in the past, and are using a Trello board for this purpose now. Taking on debt willfully means that careful consideration is given before taking a shortcut or choosing a suboptimal design, knowing that this will incur a cost in the future. Paying back debt consistently and gradually can be accomplished by allocating a certain percentage of your development budget to addressing technical debt issues.

Over the last few weeks, the Optify product development team has been heads-down working to pay off some technical debt. Our hope is that this investment will provide us with the tools and processes to deliver new features faster.

So what have we been working on?

1. Streamlining build and deploy
A reliable and repeatable build and deploy process is crucial to allow quick delivery of new features to production. Failed builds, unreliable unit tests, and manual deployment processes result in developer overhead that takes away from product features. We’ve made great strides in removing this overhead via automation and are excited to put these changes to work. For the geeks out there, I plan to blog about some of these changes in detail in a future post!

2. Improving scalability
We have also been investing to ensure that certain services like site crawls are able to scale simultaneously with our customer’s needs and the size of our overall customer base.

3. Improving user experience
Last but certainly not least, we’ve been standardizing our user interface and interaction design practices in order to continue to deliver easy-to-use and polished features. We’ve also been re-imagining the design and workflow behind several key components of Optify’s Inbound Marketing Suite. Our developers and product designers are laser-focused on making Optify simple, insightful and actionable.

We’re confident that this investment has been worthwhile and are excited to put these new processes and tools to work building compelling new features for our customers!

Over the last 18 months, we’ve shipped new Optify features every three weeks. These process improvements allow us to cut overhead enabling the team to deploying compelling new features for our customers even more frequently!