PRODUCTHEAD: It’s payback time on technical debt

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 Busuttil

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.

Avoid creating more of a mess

[ALLIE DYER BLUEMEL / CLUBHOUSE]

Technical debt and product success

Why product people should care about technical debt and strategies for addressing it.

Give your team time to learn

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

Don’t despise legacy code

[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?

Read on for my answer

[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!

Product People Limited logo

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.

Jock is a freelance head of product, author and conference speaker. He has spent nearly two decades working with technology companies to improve their product management practices, from startups to multinationals. His clients include the BBC, University of Cambridge, and the UK's Ministry of Justice and Government Digital Service (GDS). In 2012 Jock founded Product People Limited, a product management consultancy and training company. He is also the author of the popular book The Practitioner's Guide to Product Management and the blog I Manage Products.

Agree? Disagree? Share your views: