La Dette Technique chez un éditeur logiciel

La Dette Technique est un concept qui a pour but de sensibiliser à la perte d’argent engendrée par le fait qu’un code logiciel soit mal écrit. Cela est particulièrement vrai pour un éditeur logiciel qui vend ses produits plusieurs années en les faisant évoluer, en appliquant de la maintenance…

images

En réalité, tout code « mal écrit » sera plus coûteux en terme de maintenance. Mais le coût sera aussi plus élevé lorsqu’une évolution, se basant sur ce code, sera demandée par le client.

En fait, il est souvent plus judicieux de choisir de perdre du temps à l’écriture du code pour gagner ce temps sur la future maintenance ou les futures évolutions.

Cependant, le contexte professionnel, fait qu‘il est rare de pouvoir choisir la solution optimale pour la qualité du code, l’architecture… et de ce fait, la dette technique se crée, augmente…

Est-ce un réel problème? non en théorie. On peut toujours y revenir après. Et ça n’a d’ailleurs rien de choquant avec les principes itératifs du TDD par exemple.

Mais! (parce qu’il y a un mais) le problème est qu’on planifiera rarement un refactoring du code concerné par la création de dette. Et ce, toujours à cause du contexte professionnel. On préférera ajouter des évolutions pour gagner des clients supplémentaires plutôt que de revenir sur l’existant…

Bon, une fois qu’on a décidé de ne pas se voiler la face et qu’on prend conscience de ces points, il faut trouver son propre compromis de qualité/dette technique et évolutions.

Ne pas prendre en compte la dette technique conduit à un crash quasiment certain du produit à terme. Alors qu’une trop grande importance accordée à la qualité parfaite conduit à un dépôt de bilan avant même d’avoir pu trouver deux clients (ok c’est schématisé à mort).

En effet, il est parfois nécessaire de choisir délibérément de créer de la Dette Technique, et cela peut même être plus rentable, en prenant en compte la vente du produit, que d’avoir tout de suite pris le temps de coder la fonctionnalité sans engendrer de dette technique. Cela arrive quand le Time to Market est décisif. Il est alors intelligent de choisir de créer une dette pour répondre au marché dans le temps imparti, et revenir dessus par la suite, que de la coder parfaitement immédiatement, et de rater ses clients.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s