PRODUCTHEAD: It’s payback time on technical debt
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
product (mistreated)
tl;dr
Don’t ignore technical debt
Devote time for removing some debt in every sprint
Debt can be a prudent choice in some situations
It’s harder to read code than write it — so resist the temptation to start the code base again from scratch
hello
Back in the mists of time (1992), co-author of the Agile Manifesto Ward Cunningham described a metaphor he’d come up with for the debt an organisation incurs when shipping rough code in a product:
“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
This concept of debt neatly describe how deferring even a small fix will mean your team has to expend increasing amounts of time and effort working around it, over and above fixing the original problem.
In just the same way, even a small financial loan will accrue increasing amounts of interest to be repaid over and above the original sum loaned, the longer it goes unpaid. If you’ve ever let your credit card repayments slip, you’ll know what a kick in the wallet that can be.
I like Martin Fowler’s refinement of this concept into a quadrant of reckless / prudent and deliberate / inadvertent debt. Of the four combinations, the realisation that comes with greater experience and hindsight that you could have built something better (prudent-inadvertent) is inevitable as long as you’re still learning. It’s also probably the most excusable, though it doesn’t absolve your team from paying that debt back once you’re aware of it.
There’s a saying that all code becomes legacy once shipped. In other words, as soon as you ship something, it becomes a candidate for later improvement or replacement. While that’s true to a certain extent, this is no excuse for ignoring technical debt until such a point that the only option is to nuke the code base from orbit and start afresh. Joel Spolsky points out the many reasons why the ‘clean slate’ approach isn’t a great idea either.
Have a think about your housekeeping. Are you devoting an appropriate proportion of your team’s ongoing effort to paying back technical debt? Do you schedule in a ‘firebreak’ every now and again to free up the team to tackle the bigger refactoring jobs?
As a product manager, one of your many tasks is to make sure that senior management’s relentless drive to ship more headline-grabbing features is tempered by the essential work that goes on behind the scenes to avoid technical debt spiralling out of control. You may not be thanked for it, but it will save your team a great deal of pain later on.
So this week I’ve pulled together a few good reads for you about technical debt and how to deal with it.
Speak to you soon,
Jock
what to think about this week
Project managing your way through technical debt
The worst thing you can do with technical debt is ignore it. That just makes it harder to deal with later. So here’s what it is, why you should approach it strategically, and how you can manage projects within an Agile framework.
[ALLIE DYER BLUEMEL / CLUBHOUSE]
Technical debt and product success
Why product people should care about technical debt and strategies for addressing it.
[ROMAN PICHLER]
Product Management Coaching
Whether you’re new to product management or have been a product manager for years, a coaching session can help you to step up your career.
We’ve coached people wanting to get into product management, product people with nobody in their organisation to manage them, and experienced product managers preparing to apply for a promotion.
A proportion of the fees from every coaching session is donated to charity. Just reply to this email if you’re interested in finding out more.
TechnicalDebtQuadrant
The question of whether a design flaw is or isn’t debt is the wrong question. The debt metaphor reminds us about the choices we can make with design flaws. The prudent debt to reach a release may not be worth paying down if the interest payments are sufficiently small – such as if it were in a rarely touched part of the code-base.
Deliberate or inadvertent debt?
[MARTIN FOWLER]
Things You Should Never Do, Part I
It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they? Well, yes. They did.
They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
[JOEL SPOLSKY]
recent posts
What technical skills do I need to be a product manager?
I am searching for a career change and Product Management/ Project Management are my areas of interest. I was looking to understand, based on your experience, if in such roles technical skills are required?
[I MANAGE PRODUCTS]
How to start a new product manager job
Starting a new product manager job can be daunting, particularly if you don’t change jobs very often. I work freelance, so I find myself in a new organisation roughly every 3-6 months. Let me share with you my tips for your first few months in a new role.
What to do in the first 30-90 days
[I MANAGE PRODUCTS]
Should a product manager have responsibility for profitability?
Should the product manager have some level or perhaps a great deal of responsibility for the profitability of the product? Should they understand things like the unit economics, that sort of thing?
Have a sense of your financials
[I MANAGE PRODUCTS]
upcoming talks and events
5th May 2021, 16:00 GMT
Threads
Online product management round table discussion (topic TBC)
Tickets
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from unenticing food from the 1980s.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”
— Lyndsay Denton
Jock Busuttil is a freelance head of product, product management coach and author. He has spent over two decades working with technology companies to improve their product management practices, from startups to multinationals. In 2012 Jock founded Product People Limited, which provides product management consultancy, coaching and training. Its clients include BBC, University of Cambridge, Ometria, Prolific and the UK’s Ministry of Justice and Government Digital Service (GDS). Jock holds a master’s degree in Classics from the University of Cambridge. He is the author of the popular book The Practitioner’s Guide To Product Management, which was published in January 2015 by Grand Central Publishing in the US and Piatkus in the UK. He writes the blog I Manage Products and weekly product management newsletter PRODUCTHEAD. You can find him on Mastodon, Twitter and LinkedIn.
Leave a Reply