Web Content Debt is the New Technical Debt

We worry a lot about “technical debt” in the IT world. The classic use of this metaphor describes the phenomenon where messy code is written in the interest of quick execution, causing a debt that will need to be repaid (time spent fixing the code later). It can also accumulate interest (additional work on the system will be complicated by the messy code). “Technical debt” is also used more broadly to describe the ongoing maintenance of legacy systems that we spend a great deal of time just keeping alive.

But in addition to technical debt, organizations (like libraries) with large websites have a growing problem with “content debt.” And like with “deferred maintenance” of buildings (the practice of postponing repairs to save costs), allowing too much technical debt and/or content debt will result in costing you much more in the long run. Beyond the costs, the big problem with technical & content debt is that they hold us back from doing new and better things.

Take for example the website I’m working on right now that has over 16,000 pages of content that were created by hundreds of different people over many many years. Redesigning this website isn’t just a matter of developing a new CMS with a more modern design and then hiring a room full of interns to copy and paste from the old CMS to the new CMS. We also need to look closely at all of the existing pages to evaluate what needs to be done differently this time around to ensure a more user-friendly and future-friendly site. It’s no easy task to detangle this mass of pages and the organic processes that generated them.

Some might say that you should just set the old stuff aside and start from scratch but if you don’t take the time to discover what’s causing your problems, you’ve little chance of not replicating them. The wikipedia page for technical debt offers some common causes for technical debt–many of which also fit with my concept of content debt. Here’s my revised version to help illustrate the similarities:

• Business pressures: organization favors speed of releasing code [or content] as more important than a complete and quality release.
• Lack of shared standards/best practices: no shared standards/best practices for developers [or content authors] means inconsistent quality of output.
• Lack of alignment to standards: code [or content] standards/best practices aren’t followed.
• Lack of knowledge: despite trying to follow standards, the developer [or content author] still doesn’t have the skills to do it properly.
• Lack of process or understanding: organization is blind to debt issues and makes code [or content] without understanding long-term implications beyond the immediate need.
• Lack of collaboration: code [or content] activities are done in silos, and new contributors aren’t properly mentored.
• Parallel development: parallel efforts, in isolation, to create similar code [or content] result in debt for time to merge things later (e.g., multiple units creating their own (redundant) pages about how to renew books, where to pay fines, how to use ILL, etc.).
• Delayed refactoring: as a project evolves and issues with code [or content] become unwieldy, the longer remediation is delayed and more code [or content] is added, the debt becomes exponentially larger.
• Lack of a test suite: results in release of messy code [or content] (e.g., I once worked on a large website with no dev environment for testing or training which resulted in a TON of published pages that said things like “looks like I can put some text here”).
• Lack of ownership: outsourced software [or content]efforts result in extra effort to fix and recreate properly (e.g., content work outsourced to interns).
• Lack of leadership: technical [or UX/content strategy] leadership isn’t present or doesn’t train/encourage/enforce adherence to coding [or content] standards/best practices.

To this list, I’d also add one about business values: when the organization values creation of new technology [or content] over maintaining or downsizing existing technology [or content] (e.g., it’s common practice to include webpage creation activities in annual reviews but not so common to brag about the number of pages you retired).

I find this list useful because, when talking about content issues, there’s a risk of seeming judgmental towards the individuals who made said content– but the reality is that there are tons of factors that lead to this “debt” situation. Approaching the problem from all the angles will lead to a more well-rounded solution.