4 ms·

> I don't think tech debt should be communicated to the business people. This is wrong. Technical debt is almost always incurred because of the business requir

> I don't think tech debt should be communicated to the business people. This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP. Example: a startup is asked by an investor for a particular feature to be implemented for a trade show a week from now. That feature - if done properly - would require a database schema change otherwise the queries will be abysmally slow. Luckily, for the trade show the amount of data being queried is small enough that it won't matter. But as soon as it starts getting used, whoa boy. Management needs to be made aware that there is technical debt being incurred here. Yes, the deadline will be met and the show will go well. But there better be time on the schedule to do it right afterwards.

defined 7y ago
And somehow other priorities preempt “doing it right” and the debt stays unpaid for much longer than is healthy...
BurningFrog 7y ago
Thanks for a concrete example to discuss. In this case I'd tell the business that we can absolutely write a hacky version for the trade show, but if they want a fully performant version later, that's a separate story, and much of the work going in to the first story will have been wasted. Maybe we don't even disagree on much there. The scenario I had in mind was when you decide to rework/refactor some existing code because it's badly designed because of incompetent original design, changing requirements or whatever else. To me that's just an ordinary Tuesday, all part of the work we do all the time, and nothing I need to communicate, any more than I need for when we take a lunch break. Maybe this is the difference between thinking of the business as my "customer" rather than my "boss".
pytester 7y ago
>This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP. I absolutely loathe doing this - the costs of technical debt are too specific (e.g. 2 hours a week) while the benefits are too diffuse and too hard to measure. If you have a conversation with business people about it it feels like you're having to make a business case for buying pencils.
- WrtCdEvrydy 7y ago
  "We can't afford it do right the first time, but we can sure afford to do it twice when it fails" - Me, a week ago.
- Thorrez 7y ago
  > benefits are too diffuse and too hard to measure. Wouldn't "the feature gets done in 1 day instead of 2 weeks" be a very specific benefit?
  - pytester 7y ago
    It would be, but the most realistic, specifc claim you could typically make is that some hypothetical feature that probably hasn't even been dreamed up yet would get done in less time than it normally would. It's a hard sell, and that's precisely why it doesn't get done.
    - Thorrez 7y ago
      Maybe I'm misunderstanding. I think "the benefits [of technical debt]" are the reasons for taking on technical debt. When you take on technical debt it's for a specific feature that's needed, not for something that hasn't been dreamed up yet.
tonyedgecombe 7y ago
I'm not sure about that, most deadlines are arbitrary. There are exceptions but I wouldn't class a trade show as that. It doesn't come from business requirements, it comes from poor management.

defined 7y ago

And somehow other priorities preempt “doing it right” and the debt stays unpaid for much longer than is healthy...

BurningFrog 7y ago

Thanks for a concrete example to discuss. In this case I'd tell the business that we can absolutely write a hacky version for the trade show, but if they want a fully performant version later, that's a separate story, and much of the work going in to the first story will have been wasted. Maybe we don't even disagree on much there. The scenario I had in mind was when you decide to rework/refactor some existing code because it's badly designed because of incompetent original design, changing requirements or whatever else. To me that's just an ordinary Tuesday, all part of the work we do all the time, and nothing I need to communicate, any more than I need for when we take a lunch break. Maybe this is the difference between thinking of the business as my "customer" rather than my "boss".

pytester 7y ago

>This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP. I absolutely loathe doing this - the costs of technical debt are too specific (e.g. 2 hours a week) while the benefits are too diffuse and too hard to measure. If you have a conversation with business people about it it feels like you're having to make a business case for buying pencils.

WrtCdEvrydy 7y ago
"We can't afford it do right the first time, but we can sure afford to do it twice when it fails" - Me, a week ago.
Thorrez 7y ago
> benefits are too diffuse and too hard to measure. Wouldn't "the feature gets done in 1 day instead of 2 weeks" be a very specific benefit?
- pytester 7y ago
  It would be, but the most realistic, specifc claim you could typically make is that some hypothetical feature that probably hasn't even been dreamed up yet would get done in less time than it normally would. It's a hard sell, and that's precisely why it doesn't get done.
  - Thorrez 7y ago
    Maybe I'm misunderstanding. I think "the benefits [of technical debt]" are the reasons for taking on technical debt. When you take on technical debt it's for a specific feature that's needed, not for something that hasn't been dreamed up yet.

tonyedgecombe 7y ago

I'm not sure about that, most deadlines are arbitrary. There are exceptions but I wouldn't class a trade show as that. It doesn't come from business requirements, it comes from poor management.