3 ms·

Technical debt is unavoidable, but letting technical debt grow without managing it is a great way to kill a project. Explaining the benefits of paying down par

by shkkmo 4y ago

Technical debt is unavoidable, but letting technical debt grow without managing it is a great way to kill a project. Explaining the benefits of paying down particlar pieces of technical debt is important, but another important piece of the puzzle is talking in advance with stakeholders about when, where and how much technical debt you want to take on to launch a product. When the existence of technical debt isn't talked about until it needs to be repaid and thus comes as a surprise, the conversation becomes a lot harder. Additionally many of the decisions about how much technical debt to take on to launch something can be improved by bringing stakeholders directly into the conversation, at least on a general level.

hinkley 4y ago
There’s a whiff of victim blaming here that bothers me. When taking on tech debt you often get a lot of pillow talk. We have great reasons to do the wrong thing for the right reasons, but that is all forgotten after the crisis is over. Either immediately for those really bad at it, or when the next crisis hits. I do agree though that when neither transparency nor awareness are good, there will be several crises in the middle that are triggered by the tech debt. I’ve seen that play out a couple of times, typically when I’ve joined a project in progress, and still building trust before I can start pointing out brutal facts. Some developers are blind to different forms of tech debt. And as long as there is dissenting opinion the business will doubt any information that suggests they can’t have their cake and eat it too. I’ve known a handful of jaded engineers at least who, instead of being afraid or awed by titles, end up treating managers like willful children. It… does not yield consistently good results, but then again I don’t know anyone or any process that does. I’ve seen worse, and I’ve seen better.
- shkkmo 4y ago
  > There’s a whiff of victim blaming here that bothers me. Huh, what are you even talking about? What victim am I blaming for what? I am sharing an important part of the technical debt management process that I don't see mentioned as frequently. Planning out where and when your organization should take on technical debt seems as important to me as planning out where and when your organization should pay down that debt. Treating people like children is rarely a good approach and to me indicates someone who is either lazy or unwilling to take the effort to communicate well (edit: including when working with actual children). If an organization can't resolve dissent effectively, that seems like a deeper underlying organizational disfunction that will cause all kinds of problems. The truth is, the line for what is technical debt is kinda fuzzy and a there is a lot of other stuff that isn't really technical debt, but rather process or organizational debt.

by shkkmo 4y ago

hinkley 4y ago

There’s a whiff of victim blaming here that bothers me. When taking on tech debt you often get a lot of pillow talk. We have great reasons to do the wrong thing for the right reasons, but that is all forgotten after the crisis is over. Either immediately for those really bad at it, or when the next crisis hits. I do agree though that when neither transparency nor awareness are good, there will be several crises in the middle that are triggered by the tech debt. I’ve seen that play out a couple of times, typically when I’ve joined a project in progress, and still building trust before I can start pointing out brutal facts. Some developers are blind to different forms of tech debt. And as long as there is dissenting opinion the business will doubt any information that suggests they can’t have their cake and eat it too. I’ve known a handful of jaded engineers at least who, instead of being afraid or awed by titles, end up treating managers like willful children. It… does not yield consistently good results, but then again I don’t know anyone or any process that does. I’ve seen worse, and I’ve seen better.

shkkmo 4y ago
> There’s a whiff of victim blaming here that bothers me. Huh, what are you even talking about? What victim am I blaming for what? I am sharing an important part of the technical debt management process that I don't see mentioned as frequently. Planning out where and when your organization should take on technical debt seems as important to me as planning out where and when your organization should pay down that debt. Treating people like children is rarely a good approach and to me indicates someone who is either lazy or unwilling to take the effort to communicate well (edit: including when working with actual children). If an organization can't resolve dissent effectively, that seems like a deeper underlying organizational disfunction that will cause all kinds of problems. The truth is, the line for what is technical debt is kinda fuzzy and a there is a lot of other stuff that isn't really technical debt, but rather process or organizational debt.