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.

I wrote this article about technical debt for DBW in February 2015.

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 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.

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. 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.

Archives

    Most popular

  1. Ruby code and why you should care
  2. A quick look at data visualisation and analysis
  3. Learning how to code, the long way around
  4. A manifesto for skills
  5. It's us in the industry who need to be able to code
  6. Menial publishing jobs are destroying our future
  7. Company news

  8. New website
  9. 2018 Customer survey report
  10. 2017 in review
  11. And now we are five
  12. Prizes galore
  13. Sara O'Connor to join the team!
  14. Product news

  15. 'Continuing to solve real problems': Futurebook 40, London Book Fair 2018 and the Works page
  16. How many authors is too many?
  17. Better ONIX fragments
  18. Advanced advance information!
  19. Schedules page
  20. Publishers hack their own bibliographic data
  21. Case studies

  22. Burleigh Dodds Science Publishing
  23. Zed Books
  24. IOP Publishing
  25. Code

  26. What publishers need to know about Ruby on Rails
  27. How APIs can make publishing more efficient
  28. A day in the life of a programmer
  29. A publisher’s guide to APIs
  30. eCommerce

  31. Don’t outsource your publishing business away
  32. Inbound marketing
  33. Who has the balance of power over data?
  34. To go direct, publishers must mean business
  35. Why publishers must use direct sales
  36. The business case for going direct
  37. ONIX

  38. A hidden benefit
  39. Thema Subject Codes Update November 2017
  40. ONIX. Not very standard
  41. BIC, Thema and artificial intelligence...
  42. Three ways to do more with ONIX
  43. How to create a catalogue automatically using ONIX and InDesign
  44. A non-technical, beginners’ guide to ONIX for Books
  45. ONIX Changes
  46. Skills

  47. A taste of code
  48. Mechanical sympathy
  49. Publishers can learn a few things from programmers
  50. Embrace the code
  51. Strategy

  52. A company of one's own.
  53. Responsibility, Authority, Capability
  54. Five things I've learned since moving into enterprise product management
  55. The search for publishing's holy grails
  56. Sometimes, size matters
  57. Managing expectations
  58. Rejuvenation
  59. Decisions, decisions
  60. The real price of a strategy shift
  61. Why ‘easy’ publishing solutions hardly ever are
  62. Technical debt
  63. Start with Why – How to refine your publishing mission
  64. The right tool for the job
  65. No computer system can fix a broken publisher
  66. Creative industries and the division of labour