Technical debt isn't technical - Einar W. Høst

Technical debt is not primarily caused by incompetent developers, architecture astronauts, unrealistic UX people or even stupid project managers. What causes it then? It is a symptom of weak abstractions, which stems from insufficient understanding and modelling of the problem domain.
These inadequacies are compounded by organizational inertia and communication problems. What does this mean? It means that we cannot hope to address our so-called technical debt by virtuous programming alone. In order to avoid technical bankruptcy, we must instead improve the way we collaborate and build our understanding of the problem we are trying to solve.

NDC Conferences

[RubertoPaulo]

I must have watched this video now 10 times. It is very very good, thank you Einar.
Over the last 9 years I have been asking myself the same questions but sorta just said in my mind that it's not a perfect metaphor, I have yet to have met someone with the same opinion till this video. The references that are shared here are very good, Virus of the Mind gave me many things to think about.

[Huffman_Tree]

It's unfortunate that the video cuts off when the questions started in the end. It sounded like there was an interesting discussion eminating

[pufferfish]

"I will, in fact, claim that the difference between a bad programmer
and a good one is whether he considers his code or his data structures
more important. Bad programmers worry about the code. Good programmers
worry about data structures and their relationships." Linus Torvalds

[allmhuran]

Fantastic talk, and I love understated Scandinavian humour.

[JaihindhReddy]

The first ten minutes of this talk perfectly sums up what I've been thinking about technical debt. Conway was right. Nice talk!

[bocckoka]

use functional programming. better domain modelling, better abstractions. really, the problems he mentions are problems of OO.