4 ms·

That is how it goes in the end with any estimate. If it is overestimated the product is delivered with high quality. If it is underestimated the product is deli

That is how it goes in the end with any estimate. If it is overestimated the product is delivered with high quality. If it is underestimated the product is delivered with low quality. You can always buy time with technical debt. Our industry always does.

willcipriano 5y ago
I'm in a org that took up a great deal of technical debt, I no longer refer to it as such. It seems to create a false sense of security. Instead I simply call the software what it is, incomplete or unfinished. "We took on some technical debt in Q1." Vs "We didn't finish the project in Q1, but we kinda have something in place that sort of works, as long as you don't look at it funny."
- panta 5y ago
  Calling it incomplete or unfinished may hide the fact that it is broken, maybe beyond repair.
  - willcipriano 5y ago
    Ive had things like that. Previous to me someone put a large amount of relational data in a object store. It's dog slow and stupidly complex. I call that not fit for purpose, and make it clear that it requires a total rewrite.
    - cudgy 5y ago
      It depends on how often this purpose is needed or called by the system. Tackling debt that is rarely executed can cause other debts to mount.
- sirwhinesalot 5y ago
  I like the term debt because it makes it clear it is something that needs to be paid off and is accruing interest. Meaning the longer we don't pay it the more expensive it gets, until almost no development time is going to the "principal". Unfinished does not communicate the same. You can have an extremely clean and polished product that is unfinished. You missed the deadline but you're in a good place to deliver future requests.
  - willcipriano 5y ago
    I have found that the sort of "technical debt" that effects customers has another word for it, a bug. Those issues tend to get prioritized quickly. The other kind of technical debt, that has you working nights and weekends because the system falls over in a light breeze doesn't have a special name. I consider "the system is relatively stable" as a implicit requirement of anything you build, if that requirement isn't hit, it simply isn't done. It probably should go back to the team that failed to finish the work, and the PM involved shouldn't get kudos for it's completion as it isn't completed. I think a lot of the problems with software dev could be resolved by being more honest with ourselves.
    - sirwhinesalot 5y ago
      Understood, but in reality the PM is going to get kudos and your complaints that things that were delivered and paid for are "unfinished" are going to be ignored. Devs are pretty honest, management simply does not listen.
  - ballenf 5y ago
    The one side of technical debt that the term doesn't capture is the quality of life issues involved. It's just misery and pain to work in an org with high levels of debt, even if everyone involved is comfortable with timelines necessary to accommodate it. It's like having a factory with poor lighting or unmaintained equipment that breaks down a lot. There are metaphors that capture that aspect of technical debt better, imo.
    - sirwhinesalot 5y ago
      That's "paying the interest". Lets say you rush a component of your software out. Every time you make a change it causes massive headaches and issues. Lets say this decreases developer productivity by 5%. Then any new feature that touches that component increases this "interest". You're now losing 6%, 7%, etc. Only on interest. The longer this goes on and the more debt you accrue the worse it gets. Getting debt to have something now that you fully intend to pay back is not a problem. Constantly increasing your debt till you go bankrupt (total rewrite) is though. Problem is management is blind to tech debt. It doesn't show up in their calculations, it's just that thing the devs always complain about but somehow the product still gets delivered, just with more "irrelevant" complaints each time until half the team has quit.

willcipriano 5y ago

I'm in a org that took up a great deal of technical debt, I no longer refer to it as such. It seems to create a false sense of security. Instead I simply call the software what it is, incomplete or unfinished. "We took on some technical debt in Q1." Vs "We didn't finish the project in Q1, but we kinda have something in place that sort of works, as long as you don't look at it funny."

panta 5y ago
Calling it incomplete or unfinished may hide the fact that it is broken, maybe beyond repair.
- willcipriano 5y ago
  Ive had things like that. Previous to me someone put a large amount of relational data in a object store. It's dog slow and stupidly complex. I call that not fit for purpose, and make it clear that it requires a total rewrite.
  - cudgy 5y ago
    It depends on how often this purpose is needed or called by the system. Tackling debt that is rarely executed can cause other debts to mount.
sirwhinesalot 5y ago
I like the term debt because it makes it clear it is something that needs to be paid off and is accruing interest. Meaning the longer we don't pay it the more expensive it gets, until almost no development time is going to the "principal". Unfinished does not communicate the same. You can have an extremely clean and polished product that is unfinished. You missed the deadline but you're in a good place to deliver future requests.
- willcipriano 5y ago
  I have found that the sort of "technical debt" that effects customers has another word for it, a bug. Those issues tend to get prioritized quickly. The other kind of technical debt, that has you working nights and weekends because the system falls over in a light breeze doesn't have a special name. I consider "the system is relatively stable" as a implicit requirement of anything you build, if that requirement isn't hit, it simply isn't done. It probably should go back to the team that failed to finish the work, and the PM involved shouldn't get kudos for it's completion as it isn't completed. I think a lot of the problems with software dev could be resolved by being more honest with ourselves.
  - sirwhinesalot 5y ago
    Understood, but in reality the PM is going to get kudos and your complaints that things that were delivered and paid for are "unfinished" are going to be ignored. Devs are pretty honest, management simply does not listen.
- ballenf 5y ago
  The one side of technical debt that the term doesn't capture is the quality of life issues involved. It's just misery and pain to work in an org with high levels of debt, even if everyone involved is comfortable with timelines necessary to accommodate it. It's like having a factory with poor lighting or unmaintained equipment that breaks down a lot. There are metaphors that capture that aspect of technical debt better, imo.
  - sirwhinesalot 5y ago
    That's "paying the interest". Lets say you rush a component of your software out. Every time you make a change it causes massive headaches and issues. Lets say this decreases developer productivity by 5%. Then any new feature that touches that component increases this "interest". You're now losing 6%, 7%, etc. Only on interest. The longer this goes on and the more debt you accrue the worse it gets. Getting debt to have something now that you fully intend to pay back is not a problem. Constantly increasing your debt till you go bankrupt (total rewrite) is though. Problem is management is blind to tech debt. It doesn't show up in their calculations, it's just that thing the devs always complain about but somehow the product still gets delivered, just with more "irrelevant" complaints each time until half the team has quit.