Technical debt is “the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time,” Wikipedia, “Technical debt.”. Like financial debt, technical debt isn’t always a bad thing. You can use a loan to buy a house right away (at least in the U.S.) and then pay off the debt over time while living in the house. Technical debt allows you to create something quickly instead of doing it exactly right and taking much longer.

Too much technical debt, though, will hamstring your work. The trick is to find the Goldilocks solution.

For content, we have several categories of technical debt. Here are a few:

• Lack of investment
• Scalability
• Strategy

Technical debt due to lack of investmentLack of investment usually looks like an outdated tech stack that is actively blocking efficiency. For example, a workflow based on InDesign or Word can produce highly formatted print/PDF output, but there’s no path to HTML for the website.

The PDF deliverable is appropriate and necessary, and once upon a time the print-only workflow made sense, but now it’s an obstacle to creating a modern website. The organization needs to invest in a new tool stack to meet new requirements.

Technical debt in scalabilityWe strongly encourage prototyping and proof of concept (POC) work to reduce risk and validate assumptions before committing to a Big Build. But with that said, POCs introduce a huge risk—they are nearly immortal. You can cut corners in a POC—that’s one of their great benefits. But when you go to production, you need to remember which features were omitted and either put them in or start over with a more careful design.

A common example of this is in formatting automation. Let’s say you’re testing out a DITA-based workflow and you build a couple of publishing pipelines in the DITA Open Toolkit to show output to HTML and PDF. For the POC, you just build for a single language and don’t worry about localization. Later, you’ll need to backtrack and fix the places where you embedded single-language processing so that you can support the dozens of languages that your output actually requires. Or, worse, because the person doing the POC is new to the Open Toolkit, they just hack together a bunch of customizations instead of using DITA’s plugin architecture to separate out customizations from the core code. Unwinding those hacks is painful.

It’s surprisingly difficult to balance “go fast for the prototype” against “don’t incur crushing technical debt in the future.”

Technical debt in strategyYou can guarantee significant technical debt by failing to plan for the right things in your content ops. For example:

• Scalability. If you fail to account for scalability, you’ll find yourself in a system that works for up to 10 authors, but then you merge with another company, you suddenly have 20 authors, and your system just lies down and dies. I was told by an installer that our Internet router can handle up to 30 devices and I thought, “oh that’s plenty.” But then I started counting Internet-connected devices—laptops, phones, tablets, watches, e-readers, gaming systems, TV boxes—and got up to 23 without really trying. 30 devices sounds like a big number, but maybe it isn’t. Be sure that your system can handle planned—and unplanned—increases in authors, publishing pipelines, connectors, and more.
• Localization. Localization is a special case of scalability. We’ll simplify and focus on translation for the moment. When you translate content, you’ll need to increase your storage capacity for each language. If English is your starting point and it takes up 100MB, figure that each additional language will add another 100MB. You need to think about publishing pipelines and ensuring that they are configured to publish your supported languages. You’ll need a translation management system to keep track of the translated assets, and you may need a content authoring environment that supports multiple languages. If you’re delivering on-device help, you need to decide how many languages to deliver on the device, which increases storage needs, and how to allow people to choose the language that they want.
• Business changes. Your content ops approach has to align with the business needs. A business that sells just two or three product variants has different requirements than a business that sells a product with hundreds or possible configurations. You can set up an efficient operation for either scenario, but making a transition from “a few variants” to “effectively unlimited variants” is challenging. You didn’t have technical debt until the day that the CEO said, “hey, let’s componentize our product and let customers choose what they want.”

Each of these scenarios presents unique challenges. Failure to plan ahead results in trouble, but overplanning is expensive. Your goal is to manage your technical debt to stay ahead of the curve and avoid technical bankruptcy.

Need help managing technical debt? Let’s talk! "*" indicates required fields

Your name (required)Your email (required)Your companySubject (required)Consulting requestSchedule a meetingTrainingOtherYour messageData collection (required)*I consent to my submitted data being collected and stored.NameThis field is for validation purposes and should be left unchanged. 3560 The post Technical debt in content operations appeared first on Scriptorium.