Technical debt isn't technical - Einar Høst - DDD Europe 2019

Domain-Driven Design Europe 2019
dddeurope.com
/ ddd_eu
Organised by Aardling (aardling.eu/)
Technical debt isn't technical (Talk)
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. This means that we cannot hope to address our so-called technical debt by virtuous coding alone. In order to avoid technical bankruptcy, we must step away from the keyboard and start addressing the complex mess of human issues that ultimately affect the software we are making.
Biography
Einar W. Høst is not a software craftsman; he is a genuine, PhD-certified ivory tower zealot. His heretic views include thinking away from the keyboard and making drawings to understand things better. He does domain modelling, API design and computer programming at NRK.

[@jimifriis4507]

Thank you @Einar (+ Alexey, DDD Europe..) - This was a really great talk, one of the best "discussions" I have listened to on a non-technical level; I hope it, with its simplicity and wittiness, reaches many software developers (and if we are lucky also some "business people") - Modelling is complex by nature and so often we do not know enough about what we are modelling (in worst cases the developers are not interested in the why, as long as they can use cool tech and "solve problems" =) BTW.. I would like to have that horse-horse sound like the "birdiest bird" on a live-live broadcast - Can you stream that on NRK? =D

[@DevOpsCraftsman]

I was not expecting something like that from the title, quite a [good] surprise! It was very interesting and insightful about difficulties on modeling data coming from the real world...

[@kokoloism]

I can not find an answer to the question "what can and should be modeled" . This presentation opens a door to new area for me.

[@robertodiana5821]

Good, but some time the spaghetti code happends, because the team ignore the problem, in this case I think that the point break it's unavoiadable ... Good talk

[@ekanshtiwari]

An insightful talk for both developers and businesses.

[@arunlearn]

Thank you for the presentation!

[@orlovskyconsultinggbr2849]

Einar Host didn'T provided any proof of his hypothesis, time wasted... In my opinion legacy code is which hard to maintain , test and extend . On one thing i can agree that any new feature should be validated, before it completely can be added to the running system.