5 ms·

Just a reminder that the phrase Technical Debt is used a bit broadly here. In general, TD is when the codebase drifts from continuing to align with the developm

Just a reminder that the phrase Technical Debt is used a bit broadly here. In general, TD is when the codebase drifts from continuing to align with the development team's understanding of the problem. So phrases like "design" or "security" don't seem to work. At least to me. FWIW, I wrote a blog article a few days ago on TD, including times when it might be appropriate. http://tiny-giant-books.com/blog/technical-debt-edge-cases/ http://tiny-giant-books.com/blog/technical-debt-edge-cases/

clay_to_n 11y ago
I like that definition - it fits with Martin Fowler's talk about architecture being "the important stuff" among the lead engineer's understanding of the codebase. So architecture is the important stuff when you think about the project, and tech debt are the things that don't fit how you think about the project.
- spinlock 11y ago
  I don't really consider technical debt to be about things that make the code base harder to reason about (unreasonable?). That is an important architectural point but I think of it as orthogonal to technical debt. To me, technical debt is about the trade-off of short term progress for long term flexibility of the code base. Essentially, the need of the business to ship -- side note: I wrote that as shit initially. Freud would be amused. -- the feature immediately outweighs the need of the business to write maintainable code. So, you expend fewer engineering resources than you should now and you spend more than you would have later. Basically, you borrow against the future productivity of your engineering team. So, to me, it's about doing less work now and more work later. That can be a conscious decision or a consequence of ignorance. Things like choosing the wrong abstraction are about being ignorant of the problem space.
pklausler 11y ago
Technical debt is a metaphor, so it can have more than one meaning. My interpretation: TD is making an expedient change with long-term consequences, or mistakenly selecting tactics than undermine strategy.
sampsonetics 11y ago
I also like your wording in terms of the codebase drifting from the team's understanding of the problem, which is a drift that is important to be continually mindful of. However, to the point of your blog post, there have definitely been others talking about when "technical debt" might be okay.[1] A big challenge is not only that people disagree on when debt is present, there really are multiple completely different definitions, and while some look a little like debt many don't behave like debt at all. [1] http://agilefocus.com/2012/07/02/technical-debt-the-good-the-bad-and-the-okay/ http://agilefocus.com/2012/07/02/technical-debt-the-good-the... (I wrote that post, but it also has lots of links to other people talking about different definitions of technical debt.)

clay_to_n 11y ago

I like that definition - it fits with Martin Fowler's talk about architecture being "the important stuff" among the lead engineer's understanding of the codebase. So architecture is the important stuff when you think about the project, and tech debt are the things that don't fit how you think about the project.

spinlock 11y ago
I don't really consider technical debt to be about things that make the code base harder to reason about (unreasonable?). That is an important architectural point but I think of it as orthogonal to technical debt. To me, technical debt is about the trade-off of short term progress for long term flexibility of the code base. Essentially, the need of the business to ship -- side note: I wrote that as shit initially. Freud would be amused. -- the feature immediately outweighs the need of the business to write maintainable code. So, you expend fewer engineering resources than you should now and you spend more than you would have later. Basically, you borrow against the future productivity of your engineering team. So, to me, it's about doing less work now and more work later. That can be a conscious decision or a consequence of ignorance. Things like choosing the wrong abstraction are about being ignorant of the problem space.

pklausler 11y ago

Technical debt is a metaphor, so it can have more than one meaning. My interpretation: TD is making an expedient change with long-term consequences, or mistakenly selecting tactics than undermine strategy.

sampsonetics 11y ago

I also like your wording in terms of the codebase drifting from the team's understanding of the problem, which is a drift that is important to be continually mindful of. However, to the point of your blog post, there have definitely been others talking about when "technical debt" might be okay.[1] A big challenge is not only that people disagree on when debt is present, there really are multiple completely different definitions, and while some look a little like debt many don't behave like debt at all. [1] http://agilefocus.com/2012/07/02/technical-debt-the-good-the-bad-and-the-okay/ http://agilefocus.com/2012/07/02/technical-debt-the-good-the... (I wrote that post, but it also has lots of links to other people talking about different definitions of technical debt.)