Menu

Technical debt, product debt, and how to prioritize addressing it

Mike Fisher argues that we should rebrand technical debt as “product debt”, and I think it’s a good argument! That said, I’d like to add some considerations to two of his points. First:

We usually think of refactoring as “cleaning up” code, where we change the code to be more easily understood, perform better (faster or more efficiently), or follow current conventions/standards. The goal of refactoring is to change the code without changing its functionality; it should continue to pass all unit and functional tests. 

I take a slightly different approach to refactoring, and how to prioritize the work. I believe it’s important for teams to have a stated and agreed-upon value of “leave the code better than I found it.” This means that refactoring shouldn’t be a separate activity, for its own sake, that needs to be scheduled. It should be a natural part of feature development.

If you’re creating a mechanism for add-ons on the product, spend a few extra days to refactor the billing code you’re already working on. If you are adding metrics to the dashboard in your UI, take the time needed to refactor the front-end code to make it more performant. Whatever code you’re touching while you’re working on a project, leave it better than you found it. It is way more efficient to extend a project by a week to refactor code you’re already working on than it is to create a separate project that needs to be planned, prioritized, and worked into the roadmap.

Second point:

So, how do we ensure we are paying down technical debt when there is so much pressure to ignore it until things really break? I think one part of the answer is to use a different term. Instead of tech debt, which implies it is the responsibility of the tech team, let’s call it product debt.

I think this is a good first step to getting more teams to care about technical debt—but it’s not enough. One of the issues with getting technical/product debt prioritized is that often “the business” doesn’t see the value in statements like “we’re going to clean up the code so that it doesn’t break a few months from now”. Instead, we need to frame the work in terms of the benefits to customers and/or the business.

For instance, we could make the case that refactoring this piece of code would significantly increase our deployment speed, which would mean faster time to market. Or we could argue that fixing our slow staging environments would result in happier, more productive engineering teams.

With technical debt—as with most things in software development—the thing you do is never the main thing. The main thing is what the thing you do enables. What value it brings to customers and the business. That’s the framing we need for working on technical debt.

The Cynical PM Framework, a business-first approach to product

Frank Tisellano in The Cynical PM Framework, a business-first approach to product:

Every product, every feature even, serves a function in your business. It has one of three jobs:

  • Acquire new users or customers
  • Retain those users or customers
  • Expand engagement or revenue per user or customer

Link roundup for February 19, 2023

Underwater Photographer of the Year—2023 Winners. These are so great.

Impostered. Great post from Mandy Brown about the need to reframe how we think about imposter syndrome. “I’ve started to think less about imposter syndrome (a description of a person’s experience with it) and more about being impostered (a framing that draws attention to the systems and structures that lead people to believe they are imposters). While the former framing remains useful in many contexts, the latter creates space to consider not only the symptoms but the root cause of the phenomena.” [everythingchanges.us]

What’s So Funny? Very good essay about the current state of stand-up comedy, and what makes something funny. “The audience whooping and applauding Roseanne’s ‘anti-woke’ comedy is not reacting with laughter at a previously un-acknowledged truth, but instead expressing approval for the point of view that they already knew they agreed with. This is not the same thing as laughter in response to a joke.” [biblioracle.substack.com]

Why Are You Seeing So Many Bad Digital Ads Now? “Social media advertising, once a niche art practiced by specialist agencies, is now easily available to anyone. Many of them are eschewing targeted ads — placements intended to reach specific audiences, usually at a higher cost — in favor of a cheaper spray-and-pray approach online, hoping to catch the attention of gullible or bored shoppers.” [NYT gift link]

Traffic Lights Need a Fourth Color, Study Says: Here’s Why. Yeah what could possibly go wrong. “For the dawning age of the self-driving car, transportation engineers from North Carolina State University are proposing the addition of a fourth ‘white light’ whose function would be to alert humans to simply ‘follow the car in front of them.’” [popularmechanics.com]

The people who live inside airplanes. Ok I kind of like this idea. “By the end, she had a fully functional home, with over 1,500 square feet of living space, three bedrooms, two bathrooms and even a hot tub — where the cockpit used to be. All for less than $30,000, or about $60,000 in today’s money.” [cnn.com]

Move past incident response to reliability

Here’s an interesting article by Will Larson with advice on how to move past incident response to reliability in our products. Among other things it reminded me to watch out for “incident legalism”:

Incident legalism is when an incident response and analysis program—trying to better drive reliability improvements—becomes focused on compliance and loses empathy for the engineers and teams operating within the program’s processes.

He goes on to propose a more holistic, expanded model for reliability to help teams diagnose their systemic problems—and how to solve them:

Finally, you study the mitigated incidents, determining how to prevent them from recurring, and they become remediated incidents.

How to build human connections in an async workplace

This is a great post by Chase Warrington for the Twist Async newsletter on How to build human connections in an async workplace. They make this really important point about what human connection is actually about on a remote team:

I’ve come to realize that team culture and human connection is primarily built by how you work together—not how you socialize together. […]

The work we do is what actually brings us together. That’s ok (and frankly healthy) to admit. One of the biggest benefits of remote work is that it provides you the opportunity to spend more on the people and things you care about outside of work. Let’s not sabotage that with a bunch of forced and awkward social events for teammates to attend on top of their work duties.

I think we forget this too often. Doing a fun online social activity together doesn’t improve team culture if we haven’t also made sure that actually working together is safe, healthy, and enjoyable.

How the fediverse can help us collaborate better at work

Mehul Kar says he’s not super excited about the “fediverse” in the context of social media. However, he sees a huge need for The Fediverse At Work. The issue? The lack of integration across all the tools we use at work has become incredibly tedious and hard to keep track of:

Sometimes there are Figma design specs, with their own set of comments. And Loom walkthroughs, also with comments and likes. And any number of other things over time. The combinatorial complexity of these tools across these platforms (not to mention emails) can be quite messy to track. It’s really hard to remember where a conversation took place. Coworkers often repeat the same text in multiple places, prefixing with phrases like “Shared this in Notion comment also, but…” or “Just left a review, but high level: …”.

He believes that a decentralized platform for all these tools to effectively talk to each other would be hugely beneficial:

Maybe the protocols that make up the Fediverse can help. What if, instead of sharing a Github Pull Request URL in Slack, your Slack team channel could instead be subscribed to the Github repository. Maybe new Pull Requests are broadcasted to followers, and replies from Slack users to those posts are sent as comments to the Pull Request in addition to being threaded in Slack. Maybe the Notion document is treated the same way. Maybe the Loom walk through is a reply to a Slack thread, and comments on the video appear in Slack. Maybe the Slack thread is a series of comments displayed on a Figma design.

There are more examples in his post. I really hope we can get to this type of philosophy for our work tools. It does sound a little bit like the problem that Luro is trying to solve.

Link roundup for February 15, 2023

AMEN by Jessica Hilltout. “The aim of AMEN was to shine the light on all those in the shadow of the World Cup, far from the big stadiums and the corporate carnival-nature of the event. To embrace Africa and everything that makes it unique. To speak of the authenticity and sheer ingenuousness of a continent that manages to do so much with so little. To capture people with simple needs and huge hearts. To express football in its purest form.” [jessicahilltout.com]

God Did the World a Favor by Destroying Twitter. I love Paul Ford. “Our smarter, richer betters often preach the idea of a town square, a marketplace of ideas, a centralized hub of discourse and entertainment—and we listen. But when I go back and read Genesis, I hear God saying: ‘My children, I designed your brains to scale to 150 stable relationships. Anything beyond that is overclocking. You should all try Mastodon.’” [wired.com]

SolidGoldMagikarp (plus, prompt generation). This is all super weird and shows that we really have no idea what’s going on with these LLMs. Are we really ready for this stuff to become the backbone of internet search? “We’ll demonstrate a previously undocumented failure mode for GPT-2 and GPT-3 language models, which results in bizarre completions (in some cases explicitly contrary to the purpose of the model), and present the results of our investigation into this phenomenon.” [lesswrong.com]

Hey, Ease Up; A Load-Bearing If-Statement. What happens if, for health reasons, you need to use a fitness tracker to move less? “But if you’re trying to conserve energy, you don’t want to reach that goal. You want to stay under it. Sure, you want to maybe get up and about, I guess? Take a very slow short walk outside? But you are supposed to be resting.” [newsletter.danhon.com]

Scientists Develop Compound That Kills So Efficiently They Named It After Keanu Reeves. “The molecules ‘kill so efficiently that we named them after Keanu Reeves,’ German researcher Sebastian Götze said in a press release, ‘because he, too, is extremely deadly in his roles.’” [futurism.com]

Buy Nothing groups and the culture of free stuff. This deep-dive into the things people post in Buy Nothinggroups (and that actually get picked up!) is quite something. “There is something about free stuff that makes us abandon all rational thought.” [washingtonpost.com, soft paywall]

The mystery of the disappearing vacation day. Why have we stopped taking regular vacations? “Many were on a paid-time-off (PTO) plan that lumps sick days, personal days and vacation days in a single bucket. While workers often appreciate the flexibility of PTO and employers find it easier to administer, such plans can deter taking long vacations by making us feel as if we’re cutting into the PTO we might need in case of sudden illness or tragedy.” [washingtonpost.com, gift article link]

Nope, coffee won’t give you extra energy. It’ll just borrow a bit that you’ll pay for later. Ok listen, don’t come at me with your “facts”, please. “While it feels energizing, this little caffeine intervention is more a loan of the awake feeling, rather than a creation of any new energy.” [theconversation.com]

Principles for building software for developers

Kathy Korevec started a series about her principles for building software/tools for developers. Since I work on Postmark—one such tool—I read the intro post with great interest. The second installment is on the principle she calls You are a chef cooking for chefs:

Developers are masters of building applications, so when you’re building tools and experiences for them, you’re cooking in their kitchen. You can marvel at the delight you bring to the experience because no one can appreciate your hard work more than another developer. Developers can spot inconsistencies, antipatterns, and hurdles a mile away, so you must pay close attention to these details. At the same time, they know the challenges, understand the concerns, appreciate the details, and can provide crucial feedback to make your product even better.

This is one of the main reasons why I love working on developer tools. It’s an audience that can be brutal critics. But for the most part they do that because they care and want to see the product succeed—not because they want to fight just for the sake of it. And because they care, feedback generally have a degree of specificity that is invaluable for troubleshooting, use case discovery, and improving the product.

Anyway, this looks like a fantastic series and I can’t wait to read the rest. You can sign up for Kathy’s newsletter here.

More

  1. 1
  2. ...
  3. 27
  4. 28
  5. 29
  6. 30
  7. 31
  8. ...
  9. 201