You might be wondering: Just what is technical debt?
Well, ever hear of a “bush fix” or “jury rig”? These are makeshift repairs or temporary procedures made with materials on hand. Think of using duct tape as a quick fix until you can get a more permanent solution. When applied to web or software development, this dynamic is referred to as “technical debt” and can lead to major problems if not handled properly.
Technical debt is a metaphor Ward Cunningham coined to help understand the consequences of a quick and dirty fix versus doing it the “right” way. The basic idea is that doing things with short-term compromises creates technical debt, which is similar to financial debt. And like financial debt, it will eventually need to be paid down before more debt can be accrued.
Marketing is getting increasingly technical. Marketers today rely on marketing automation, CRM integrations, APIs, websites, and mobile apps. While mostly associated with a website or other business software, technical debt can, in fact, be accrued with any of the technical systems used in marketing.
Good Vs. Bad Technical Debt
As with financial debt, not all technical debt is bad. Taking on debt to buy a house can be considered a good investment. Assuming a mortgage is “good” debt because there is a plan to pay down the debt that is arranged up front.
The same concept can apply to technical debt. A little technical debt can speed development and aid creativity in the beginning, but when there is no plan to pay it back by implementing proper solutions, it can become a danger and make future development work difficult and sometimes impossible.
Startups often incur a little technical debt to prove a market concept and then pay down their debt if and when the concept proves viable. In a startup environment, every dollar counts. Startups often have to delay expenses for a while and then plan to pay for them later when more funds are available, rather than using precious seed money.
In general, technical debt that has been incurred unintentionally due to low-quality work, hasty decisions, or lack of understanding is considered bad debt. Technical debt incurred for tactical or strategic reasons (e.g., to prove a market concept, preserve project capital, etc.) is considered good. The main difference between these two is one comes with a plan to pay it down and the other does not.
Some Examples of Technical Debt in Marketing
Let’s examine some high-level examples to demonstrate how technical debt can have a negative impact on marketing activities.
No Planning for Mobile
It’s all about mobile now. Imagine a site that was built only for desktop computers, but that now needs to support a growing mobile user base.
If the site was not built with a mobile experience in mind, this will be problematic. A desktop-only site build will need to be considerably refactored for mobile. Creating CSS for a responsive design, re-structuring HTML markup to support responsive CSS, resizing images to be mobile friendly, deciding which site features should be present for mobile, and more will need to be considered.
Unfortunately, the code and assets of the initial desktop build would not have been constructed in a way that is compatible with what will need to be done to support mobile. It would be highly likely that the cost to shoehorn in mobile support would be close to just starting over from scratch.
In this instance, technical debt was taken on when the site was initially built by deciding not to include mobile support.
Rushing to Market
When building a new website, getting the site live fast is sometimes a high priority. And almost always, the need to get a project up and running quickly can lead to technical debt.
For instance, one way to speed up website development is to use a pre built “theme” to jumpstart the design/build process. A pre-built theme is selected and then modified to fit the needs for the project.
Usually, this is done without investing the time to understand the nuances of the theme or become completely familiar with its functionality, thus inheriting technical debt from the original theme developer and adding more by choosing to implement the theme without thorough understanding.
Operating in this way could have a negative impact if future features are planned that aren’t compatible with the inner workings of the theme. You would end up “fighting” the theme to do what needs doing.
Waiting to Document
Marketing automation workflows can quickly become complicated. As with anything complicated, documentation is extremely helpful.
However, documentation is an easy thing to put off and ultimately forget about. When it comes time to change a complex marketing automation nurturing campaign, you’ll need to understand how the various pieces work together or risk breaking things. If you don’t have any documentation, you’ll have to spend extra time examining all aspects of the workflow and taking your own notes to understand how it works.
In this case, deciding not to produce documentation up front would be considered technical debt.
Consequences of Technical Debt
From longer development times, to annoying bugs, to crippled projects, the effects of technical debt can manifest in a variety of ways. Here are some common consequences as technical debt builds over time:
- It becomes more and more difficult to change things.
- The project loses the ability to respond to the needs of stakeholders.
- Estimating the effort or cost for change becomes increasingly harder, eventually impossible.
The impact of technical debt can be a sneaky, slow-growing problem. Numerous tiny compromises add up over time to contribute to a larger problem.
While most people chose not to deal with technical debt head on because it can be expensive to fix, it often becomes more expensive to ignore. This graph from Jim Highsmith does a nice job illustrating the relationship between technical debt and the cost of change.
So how do you avoid technical debt? The answer is simple: You don’t. It is impossible to avoid technical debt. The need to upgrade systems, add new features, and try new techniques will always create technical debt. Instead of trying to avoid it, you should plan for it, handle it when it is accumulated, and be prudent with technical decisions.