4 ms·

Good technical debt... well, what's the expected lifetime of a piece of software? How long do you think it'll be maintained and growing, before it is either no

by beat 7y ago

Good technical debt... well, what's the expected lifetime of a piece of software? How long do you think it'll be maintained and growing, before it is either no longer relevant/needed, or replaced by a new product? Over the right time scale, technical debt can be a huge win. That's "good debt". Consider the race against time - either time to market (get a product out the door asap, for valid business reasons), or because it's currently in proof of concept stage and will either be replaced or fixed later, once it becomes a real project destined for production. In either case, technical debt is a good deal. Even if it costs you more in the long run, the time saved in the short run can be the difference between success and failure.

WrtCdEvrydy 7y ago
> currently in proof of concept stage > replaced or fixed later > becomes a real project destined for production These are the justifications that lead to Technical Debt. Unless you write a self destruct system that prevents the software from starting after a certain date... there is no such thing as 'good debt'. Projects come from POCs, they get moved into Production and are never replaced, just patched.
- bluGill 7y ago
  Technical debt it the intentional decisions you make to go faster. You can pay it off or not if you want to. Unfortunately every project I have been on has very little of this. The real problem I see are not intentional decisions, but "If only I had known". The team that choose a framework and 3/4ths the way though the framework company dropped the product (I know a product shipping on WinCE 6 - MS dropped support for that on them 1 week before code freeze). The team that started on some new fad that seemed good only to be the first to find the issues when used in their situation (the fad is overall good, but the limits are not understood).
- beat 7y ago
  I've come to the sad conclusion that excessive code quality is a smell. And most attempts to head off technical debt are really just premature optimization, which is its own sort of evil. Don't burn the village in order to save it.

by beat 7y ago

WrtCdEvrydy 7y ago

> currently in proof of concept stage > replaced or fixed later > becomes a real project destined for production These are the justifications that lead to Technical Debt. Unless you write a self destruct system that prevents the software from starting after a certain date... there is no such thing as 'good debt'. Projects come from POCs, they get moved into Production and are never replaced, just patched.

bluGill 7y ago
Technical debt it the intentional decisions you make to go faster. You can pay it off or not if you want to. Unfortunately every project I have been on has very little of this. The real problem I see are not intentional decisions, but "If only I had known". The team that choose a framework and 3/4ths the way though the framework company dropped the product (I know a product shipping on WinCE 6 - MS dropped support for that on them 1 week before code freeze). The team that started on some new fad that seemed good only to be the first to find the issues when used in their situation (the fad is overall good, but the limits are not understood).
beat 7y ago
I've come to the sad conclusion that excessive code quality is a smell. And most attempts to head off technical debt are really just premature optimization, which is its own sort of evil. Don't burn the village in order to save it.