We have all understood Tech Debt wrong!

“Shipping first-time coat it’s like going into debt. A little debt speech development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code count as interest on the debt. Entire engineering organisations can be brought to a standstill under the adept load of N and consolidated implementation.” — Ward Cunningham

1. Manny assumes tech debts are a result of “ugly codes”
2. though refactoring could solve some of the issues, no refactoring without remodelling!
3. A rewrite will end up with the same problems as the original unless you close the understanding gap
4. solving tech debt using tech solution is way more manageable and measurable, also rarely end up in conflicts

There are 2 main problems with tech debts:

1. The stuff being modelled. The reality has no interests in being modelled, it is messy and organic, slips away and evolve. We are trying to impose structure on something unstructured
2. Those doing the modelling. If you remake awful software from scratch without changing the culture that created it you will remake awful software. Corollary to Conway’s law: if you design a system, but you didn’t design the organisation structure, you are not the system’s designer

Key takeaway

1. clean codes will not and cannot save a rotten model, clean codes will not and cannot save a rotten model
2. we are trying to impose structure on something unstructured
3. there are no technical solutions to technical debt (in the speaker’s opinion)