Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

17/02/2009

Technical Debt

La notion de dette technique n'est pas nouvelle : à chaque fois que l'entreprise prend une décision de design ou d'implémentation technique sous le coup de facteur externe (temps, coût) au lieu de facteurs internes (qualité, maintenance), l'entreprise contracte en pratique une dette technique.

 

Dans le contexte de la production d'un jeu vidéo, la dette technique recouvre donc tous les détails d'implémentation qui n'ont pas été correctement exécuté. Les hacks, les hiérarchies de classes vite faites, les structures de données mal pensé, les opportunités d'optimisation ratées, mais aussi les lourdeurs dans le pipeline de production, le pis aller dans le choix des outils de productions (CVS au lieu de Perforce par exemple), etc etc….

 

C'est un sujet sensible pour beaucoup de programmeurs, si tant est que nous sommes quotidiennement poussés à aller à l'opposé de notre intuition pour satisfaire les impératifs stratégiques de l'entreprise.

 

Pour autant, il n'y a rien de mal à cumuler la dette technique, du moment qu'elle est proprement géré. Comme toutes dettes, si on ne garde pas l'œil dessus, elle fini par affaiblir le studio en le rendant de moins en moins compétitifs.

 

Il est donc vital de connaître l'ampleur de la dette, afin de ne pas se retrouver dans des situations délicates. Comme toute dette, la dette technique à un cout et des intérêts conséquents.

 

Plus votre base de code est endetté, moins il est facile de la maintenir, et par conséquent il est de plus en plus difficile de démarrer de nouveaux projets. De même, votre process de production est de plus en plus lent, nuisant par conséquence à la productivité de l'équipe et donc à la compétitivité du studio.

 

Pour finir, la dette rend la société fragile à la notion d'information technique informelle. La dette nécessite un effort continu de documentation, qui n'est souvent pas faite correctement. Au fur et à mesure que les techniciens et programmeurs quittent l'entreprises pour de plus verts pâturages (meilleurs payes, moins de nuits blanches pour gérer les problèmes liés à la dette), les éléments mal conçus deviennent de plus en plus obscurs, absconds, et difficile à résoudre.

 

La dette s'élève mécaniquement, relevant de la même logique que le crédit revolving.

 

Il existe des outils pour gérer la dette. L'effort de réécriture (refactoring) est un investissement permettant de réduire la dette. De même, prendre le temps d'évaluer les outils de productions (de perforce au compilateur en passant par les outils de communication interne) permet aussi de réduire la dette.

 

En tant que technicien, Il nous appartient de savoir comment évaluer la dette construite dans une base de code. La dette, c'est du risque, et on nous paye aussi pour réduire les risques.

 

Mais il faut reconnaître aussi que la dette est un outil. Il faut savoir quand et dans quels conditions il est parfaitement légitime de cumuler de la dette. L'impératif premier de toute entreprise, c'est la survie. Et la survie, c'est d'abord faire des ventes.

 

Le seul souci est donc de s'assurer que le coût pernicieux de la dette technique de revienne pas manger vos profits quelques années après avoir commencé…

13:00 Publié dans Business | Lien permanent | Commentaires (0)

Les commentaires sont fermés.