PRODUCTHEAD: It’s payback time on technical debt
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
product (mistreated) #
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
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,
what to think about this week #
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]
Why product people should care about technical debt and strategies for addressing it.
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.
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.
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.
recent posts #
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]
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.
[I MANAGE PRODUCTS]
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?
[I MANAGE PRODUCTS]
upcoming talks and events #
5th May 2021, 16:00 GMT
Online product management round table discussion (topic TBC)
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from unenticing food from the 1980s.