Bigcommerce Engineering — Why the way we look at technical debt is wrong

Dans cet article l'auteur explique que la dette technique n'a pas le même poids en fonction de l'endroit du code qui est codé salement. C'est presque pas gênant si c'est du code qui ne sera jamais touché, alors que c'est très coûteux si ça concerne une partie du code qui est amenée à évoluer souvent.
Sachant celà, il faut passer son temps à bien s'occuper de l'architecture des parties essentielles du code, quitte à aller vite sur les parties annexes.

Je suis globalement assez d'accord avec son propos, par contre je trouve la conclusion de son article vraiment très étrange : «Technical debt is ok, and often a solid product strategy. The importance is getting to market.»

Wtf ?! Non ! Au secours ne faites pas ça ! Oubliez cette phrase par pitié ! Ne perdez pas trop de temps sur des détails, certes, mais surtout ne vous dites pas que la dette technique c'est un levier ! La dette technique (la vraie, celle sur les parties essentielles du code qui bougent beaucoup) a un prix incommensurable ! Et contrairement à ce qu'on pense parfois, vous ne la payerez pas au bout de quelques années, vous la payerez dès lors que le premier employé (ou stagiaire) travaillera avec vous sur le code ! Qui dit code mal pensé, dit code difficile à prendre en main, et propice aux erreurs ! Si vous commencez à avoir du code tordu dans le cœur de votre application vous êtes partis pour des mois voir des années de galère, avec des bugs inexplicables qui apparaissent parce que quelqu'un a touché un bout de code dont il ne maîtrisait pas chaque ligne sur le bout des doigts.

Parier sur la dette technique comme levier de croissance c'est investir dans le druidisme comme système de gestion de la connaissance dans l'entreprise : transmission des secrets par voix orale du maître à l’apprenti … Inutile de préciser que ça ne passe pas très bien à l'échelle …

La discussion sur cette article ici est intéressante : https://news.ycombinator.com/item?id=9541134