3 ms·

On technical debt

2 points by techterrier 11y ago

brudgers 11y ago
One often overlooked feature shared by technical and real debt is discharge via bankruptcy. One of the impediments to understanding technical debt, I think, is that our primary experience with bankruptcy is with personal bankruptcy and it's potential effects on credit score. When technical debt is discharged via bankruptcy, it is more like commercial bankruptcy...it's an organization or a project that dissolves with the debt and there are no direct personal consequences for an individual's credit score. To put it another way, technical debt doesn't have to be repaid if the product/project/company fails. Even better it doesn't have to be repaid if the company succeeds to a scale where the library/product/project becomes obsolescent and must be replaced for reasons that could not have been reasonably anticipated at the time the first iteration was created.
- techterrier 11y ago
  Absolutely! One of the reasons I wrote this post was experiences gained working in a team that had in effect become insolvent (in the tech debt sense). In the end we went for a combination of large re-writes (which we didn't feel good about, heeding Joel Spolskys advice) and Strangulation Architecture.
  - brudgers 11y ago
    This is all second hand from listening to Spolsky's podcasts. Spolsky's advice regarding rewrites highlights perhaps different kinds of technical debt. The code for Fogbugz was well written VBscript and the motivation for Wasabi was expanding the market for Fogbugz to Linux...I believe this produced an incremental increase of about 10% of sales. Wasabi was a tool that supported the product and where the technical debt accrued. We might call the issue with Fogbugz "platform debt" and at the time Fogbugz was written, few people would have anticipated the growth of Linux...and based on Spolsky's description of sales, focusing on Windows was a sound platform choice -- in 2000 Fogbugz would have been unlikely to have succeeded in its market as a web based product.

2 points by techterrier 11y ago

One often overlooked feature shared by technical and real debt is discharge via bankruptcy. One of the impediments to understanding technical debt, I think, is that our primary experience with bankruptcy is with personal bankruptcy and it's potential effects on credit score. When technical debt is discharged via bankruptcy, it is more like commercial bankruptcy...it's an organization or a project that dissolves with the debt and there are no direct personal consequences for an individual's credit score. To put it another way, technical debt doesn't have to be repaid if the product/project/company fails. Even better it doesn't have to be repaid if the company succeeds to a scale where the library/product/project becomes obsolescent and must be replaced for reasons that could not have been reasonably anticipated at the time the first iteration was created.

techterrier 11y ago
Absolutely! One of the reasons I wrote this post was experiences gained working in a team that had in effect become insolvent (in the tech debt sense). In the end we went for a combination of large re-writes (which we didn't feel good about, heeding Joel Spolskys advice) and Strangulation Architecture.
- brudgers 11y ago
  This is all second hand from listening to Spolsky's podcasts. Spolsky's advice regarding rewrites highlights perhaps different kinds of technical debt. The code for Fogbugz was well written VBscript and the motivation for Wasabi was expanding the market for Fogbugz to Linux...I believe this produced an incremental increase of about 10% of sales. Wasabi was a tool that supported the product and where the technical debt accrued. We might call the issue with Fogbugz "platform debt" and at the time Fogbugz was written, few people would have anticipated the growth of Linux...and based on Spolsky's description of sales, focusing on Windows was a sound platform choice -- in 2000 Fogbugz would have been unlikely to have succeeded in its market as a web based product.