How to avoid making a rod for your own back with data

Technical debt is what you accrue when you write bad code or take some expedient shortcut or just think, “Nah, that’ll never be needed.” At some point, you might have to pay that debt off, or, in other words, fix the code. And technical debt accrues interest, as it gets more difficult to fix as time goes by.

In programming, there’s a concept called “technical debt,” and it’s one that has much to offer as a way of thinking about your publishing business.

Technical debt is inescapable, partly because it is accidentally introduced, but also because it is often accrued deliberately. If software were refined to be absolutely future-proof and guaranteed to work a hundred years into the future for every conceivable situation, then nothing would ever get finished.

So you have to accept that you’re going to accrue technical debt, because, in a way, it is part of being efficient; you’re fixing the problem in front of you right here, right now, and there may never be later repercussions.

Publishers accrue their own unique forms of technical debt.

Take, for example, a publisher that uses non-standard, imprecise or time-dependent terminology. They might refer to “Europe” or “the Commonwealth” or “Latin America” in the schedule of territorial rights licensed in their author contracts.

Fast-forward five years to an almighty spat with an author who assumed “Latin America” excluded French Guiana, being a non-Spanish-speaking nation, where she would like to sell the rights herself but where you’ve already licensed an edition.

EU membership changes over time (sob). Does Europe include Russia? Greenland? Does your marketing team have the same understanding of “Europe” as your rights team does? Being aware of the existence of nuances and ambiguity in your data will encourage you to work at a suitable level of specificity. The forms in which debt accrues are practically innumerable.

Having one ISBN for all ebook formats comes back to bite you when your expensive new metadata management system requires ISBNs to be unique, or when your new B2C website platform can’t distinguish between PDFs and EPUBs. It was expedient to keep all your contract data as paper copies (you didn’t even send a photocopied version to offsite storage, you say?), but now that you’ve grown enough to need a royalties and rights system, it’s payback time.

Not recording permissions at the time they’re cleared makes for a giant legal bill when the time comes to sell off an imprint, or at least a penalty for the risk that the buyer is adopting.

Agreeing to an unusual royalties structure is awful at the next royalties run, and continues to be awful until the damned thing finally goes out of print.

Being unable to assign a unique ID to an author is a huge problem when you sign up a second “Joan Smith,” or when an author gets divorced and changes her surname.

That Excel spreadsheet was great for storing sales when only one person had to access it at a time, but now there are four people, and two of them work from home!

Look around you, at the desk and screen where all those important paper notes hold vital information for the next few months. You can’t enter them on your MacBook, because who’s going to back that data up? Nobody—that’s who.

So, as developers, we are alert to and aware of the technical debt we accrue as we code, and we compare the benefit of making our code as bombproof as possible with the additional cost and time that it will take. And as publishers, we are aware of the decisions we’re making that lead to our own form of debt.

And that’s the first step on the path to sanity: awareness and acceptance.

But what are the solutions? They are often obvious, once you’ve realized the problems at hand. Use a free OCR service such as Evernote to scan and store contracts so you can actually search them in the future, wherever you are. Consider migrating your current desktop software to a cloud-based service, such as Google Docs, which allows collaborative editing of a single document (it’s magical when you first try it) and virtually unlimited storage space. If an agent is pressing for an exotic deal, it might be better to offer them preferential contractual terms that at least adhere to your usual, conventional royalty calculation process, than to agree to convoluted terms that will have to be handled manually at royalty time for the next 10 years. Find a non-ambiguous way to express what you mean by “Europe,” and search out solutions, such as ISO standard country, language and script codes, that work internationally so that the foreign publisher or agent with whom you are negotiating can clearly understand you. And so can Margaret in marketing.

The key to identifying and then minimizing technical debt is to ask yourself, “What if?” What if the office burns down? My computer gets stolen? Are we shooting our future selves in the foot if we store data or communicate in this particular way, or agree to that other way of doing things? And we need to be aware of the sorts of processes and data that will need to scale, at some point. Some things don’t need to scale: human interactions, bespoke analyses, careful design. Other things, though, will inevitably have to as the company grows. Being aware of that will go a long way to helping you to future-proof your business.

Are your current systems sabotaging your growth ambitions? Are you hungry to implement new business models, but concerned you lack the strong administrative foundations needed for innovation?

We're always amazed at how resigned publishers have had to become to the low bar in publishing management systems. Demand more.