{"id":224,"date":"2012-10-02T11:12:38","date_gmt":"2012-10-02T10:12:38","guid":{"rendered":"http:\/\/dev.qualilogy.com\/fr\/?p=224"},"modified":"2013-01-05T11:13:36","modified_gmt":"2013-01-05T10:13:36","slug":"la-dette-technique-et-les-consultants-qualite","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/fr\/la-dette-technique-et-les-consultants-qualite\/","title":{"rendered":"La dette technique et les consultants Qualit\u00e9"},"content":{"rendered":"<p title=\"Technical Debt\"><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2357\" title=\"TechDebtConsult\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/10\/TechDebtConsult.jpg\" alt=\"\" width=\"313\" height=\"210\" \/><\/a>Vous savez quelle est ma blague pr\u00e9f\u00e9r\u00e9e sur les consultants ?<\/p>\n<p title=\"Technical Debt\">Un homme entre dans un magasin d\u2019animaux et voit un singe dans une cage avec un \u00e9criteau \u2018Singe C &#8211; $2 000\u2019. Le propri\u00e9taire du magasin s\u2019approche et le client lui dit : \u00ab Il est cher votre singe. Qu\u2019est-ce qu\u2019il a de sp\u00e9cial ? \u00bb. Et le propri\u00e9taire lui explique \u00ab C\u2019est un singe qui programme en C. Tr\u00e8s bon programmeur, il est rapide, il produit un code de qualit\u00e9 et sans bugs. A ce prix-l\u00e0, c\u2019est une affaire \u00bb.<\/p>\n<p title=\"Technical Debt\">Le client regarde la cage \u00e0 c\u00f4t\u00e9 avec un panneau \u2018Singe C++ &#8211; $3 000\u2019. \u00ab Dites-donc, celui-ci est encore plus cher. Qu\u2019est ce qu\u2019il sait faire ? \u00bb. \u00ab M\u00eame chose que le pr\u00e9c\u00e9dent, mais en C++, un langage orient\u00e9 objet, plus complexe, mais qu\u2019il ma\u00eetrise tr\u00e8s bien \u00e9galement, tr\u00e8s bon programmeur. Et il conna\u00eet un peu de Java aussi \u00bb.<\/p>\n<p title=\"Technical Debt\">Le client voit alors une troisi\u00e8me cage et un panneau \u2018Singe \u2013 $5 000\u2019. \u00ab Ah, celui-ci est aussi cher que les deux autres r\u00e9unis. Il doit vraiment \u00eatre tr\u00e8s bon. Qu\u2019est-ce qu\u2019il sait faire ? \u00bb.<\/p>\n<p title=\"Technical Debt\">\u00ab Et bien, je ne sais pas vraiment \u00bb r\u00e9pond le propri\u00e9taire. \u00ab Mais il dit qu\u2019il est consultant \u00bb. <em>(1)<\/em><\/p>\n<p title=\"Technical Debt\"><!--more--><\/p>\n<p>Pourquoi est-ce que je vous raconte cette blague ? Parce que je vois de plus en plus de consultants s\u2019emparer du concept de dette technique avec le souhait, certes louable, de l\u2019actualiser, de le compl\u00e9ter ou de l\u2019am\u00e9liorer mais aboutissent finalement \u00e0 le transformer en une th\u00e9orie g\u00e9n\u00e9rale, peu concr\u00e8te et d\u2019application incertaine pour ne pas dire impossible.<\/p>\n<p>J\u2019avais d\u00e9j\u00e0 \u00e9crit il y a quelques mois un post \u2018<a title=\"Technical debt versus marketing guys\" href=\"http:\/\/qualilogy.com\/fr\/dette-technique-developpeurs-vs-marketeux\" target=\"_blank\">Tecnical debt vs. Marketing guys<\/a>\u2019  dans lequel je d\u00e9non\u00e7ais les \u2018marketeux\u2019 qui, avec beaucoup d\u2019inventivit\u00e9, \u00e9tendaient la notion de dette technique \u00e0 toutes sortes de variantes financi\u00e8res plus effrayantes les unes que les autres. Comme par exemple, le parall\u00e8le avec les actifs financiers toxiques : certaines applications seraient toxiques et n\u2019attendraient que le pire moment pour exploser toutes seules avec l\u2019intention de causer le plus de d\u00e9g\u00e2ts possibles.<\/p>\n<p>Et je vois de plus en plus de consultants Qualit\u00e9 faire de m\u00eame, comme dans cette vid\u00e9o &lsquo;<a href=\"https:\/\/www.youtube.com\/watch?v=SDlaMgs-oi0&amp;feature=plcp\" target=\"_blank\">Technical Debt A Finer Edge<\/a>&lsquo; dont je vous r\u00e9sume les principaux points :<\/p>\n<ul>\n<li>La d\u00e9finition de la dette technique introduite par Ward Cunningham en 1992 est archa\u00efque car trop centr\u00e9e sur le code et les programmeurs.<\/li>\n<li>Elle doit \u00eatre actualis\u00e9e afin de prendre en compte tous les d\u00e9fauts, manques, erreurs, n\u00e9gligences, malpractices survenant dans le processus de production logicielle et le cycle de vie de projet, lors de toutes ses phases (conception, tests, etc.).<\/li>\n<li>Elle doit prendre en compte \u00e9galement les erreurs de management et les processus incorrects ou insuffisants : estimation des charges, du planning, gestion du risque, etc.).<\/li>\n<\/ul>\n<p>Cette vid\u00e9o reprend un article de Capers Jones \u2018<a title=\"Technical Debt\" href=\"http:\/\/www.ontechnicaldebt.com\/blog\/the-errors-and-hazards-of-technical-debt\/\" target=\"_blank\">The Errors and Hazards of Technical Debt<\/a>\u2019  dans lequel il d\u00e9finit la dette technique comme les co\u00fbts de correction des erreurs commises durant le d\u00e9veloppement d\u2019une application.<\/p>\n<p>\u00ab The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify. \u00bb<\/p>\n<p>Les inconv\u00e9nients r\u00e9sident dans l\u2019absence de prise en compte des d\u00e9fauts de qualit\u00e9 dans la d\u00e9finition de la dette technique : \u00ab In order to evolve from a novelty into an effective metric, technical debt needs to encompass all quality costs and not just post-release code changes \u00bb.<\/p>\n<p>L\u2019article conclut que la dette technique est seulement une partie des co\u00fbts de qualit\u00e9 et que cette derni\u00e8re mesure (Cost Of Quality ou COQ) est plus appropri\u00e9e lorsque l\u2019on veut \u00e9tudier la dimension \u00e9conomique de la qualit\u00e9.<\/p>\n<h3><strong>Dette intentionnelle et dette involontaire<\/strong><\/h3>\n<p>Je suis bien d\u2019accord avec Capers pour dire que la dette technique n\u2019est qu\u2019un \u00e9l\u00e9ment des co\u00fbts de non-qualit\u00e9 mais je ne suis pas d\u2019accord pour qu\u2019on \u00e9tende la notion de dette technique de mani\u00e8re \u00e0 inclure tous ces co\u00fbts, comme souhait\u00e9 dans la vid\u00e9o pr\u00e9c\u00e9dente.<\/p>\n<p>La notion de dette technique est comprise et interpr\u00e9t\u00e9e de mani\u00e8re tr\u00e8s diff\u00e9rente et Ward lui-m\u00eame s\u2019est expliqu\u00e9 dans cet article \u2018<a title=\"Dette technique Ward Cunningham\" href=\"http:\/\/c2.com\/cgi\/wiki?WardExplainsDebtMetaphor\" target=\"_blank\">Ward Explains Debt Metaphor<\/a>\u2019  qui vise \u00e0 \u00e9claircir la confusion habituelle selon laquelle celle-ci est caus\u00e9e par du code de mauvaise qualit\u00e9.<\/p>\n<p>L\u2019analogie utilis\u00e9e par Ward est qu\u2019en empruntant, vous pouvez r\u00e9aliser votre projet plus rapidement, mais qu\u2019\u00e0 un moment donn\u00e9, il vous faudra rembourser votre dette. R\u00e9aliser une premi\u00e8re version prototype est l\u2019\u00e9quivalent d\u2019un investissement qui permet de livrer quelque chose rapidement aux utilisateurs et donc d\u2019aller plus vite que si vous attendez d\u2019avoir des sp\u00e9cifications fonctionnelles compl\u00e8tes et la phase de d\u00e9veloppement termin\u00e9e.<\/p>\n<p>Mais un refactoring sera n\u00e9cessaire afin de passer du prototype \u00e0 une version finalis\u00e9e, et donc ainsi rembourser votre investissement.<\/p>\n<p>Le concept d\u2019origine vise \u00e0 promouvoir une m\u00e9thodologie de d\u00e9veloppement \u2018Extreme programming\u2019 bas\u00e9e sur des cycles it\u00e9ratifs, afin de compl\u00e9ter notre connaissance des sp\u00e9cifications fonctionnelles, adapter le design de l\u2019application et engranger de l\u2019exp\u00e9rience (l\u2019\u00e9quipe de Ward avait d\u00e9cid\u00e9 de programmer en Smalltalk, un langage objet nouveau pour eux).<\/p>\n<p>Comme l\u2019explique cet article sur le blog de Uncle Bob, \u2018<a title=\"Technical debt mess\" href=\"http:\/\/blog.objectmentor.com\/articles\/2009\/09\/22\/a-mess-is-not-a-technical-debt\" target=\"_blank\">A mess is not a technical debt<\/a>\u2019, la dette technique est un compromis volontaire \u2013 livrer rapidement une version 1.0 incompl\u00e8te \u2013 afin de faire face \u00e0 des contraintes de projet. Un code de mauvaise qualit\u00e9 n\u2019est pas une d\u00e9cision rationnelle, et donc ne rel\u00e8ve pas de la dette technique, mais plut\u00f4t d\u2019une perte nette.<\/p>\n<p>Mais dans tous les cas, il s\u2019agit bien de refactoring effectu\u00e9 par les d\u00e9veloppeurs. Et donc comment identifier les modifications r\u00e9alis\u00e9es pour am\u00e9liorer l\u2019architecture du code de celles visant \u00e0 corriger un d\u00e9faut ? Un programmeur d\u00e9cide de scinder une classe en deux parce que des fonctionnalit\u00e9s compl\u00e9mentaires n\u00e9cessitent de sp\u00e9cialiser celles-ci ou tout simplement pour en diminuer la complexit\u00e9 et am\u00e9liorer la lisibilit\u00e9 du code. Dette technique ou pas ?<\/p>\n<p>Martin Fowler explique dans cet article &lsquo;<a title=\"Technical Debt Quadrant\" href=\"http:\/\/martinfowler.com\/bliki\/TechnicalDebtQuadrant.html\" target=\"_blank\">TechnicalDebtQuadrant<\/a>&lsquo; que la question importe peu. L\u2019int\u00e9r\u00eat r\u00e9side dans le fait que la m\u00e9taphore est un outil de communication puissant qui permet de justifier aupr\u00e8s des stakeholders et du management un refactoring du code, quelque soit la nature de cette dette technique, d\u00e9lib\u00e9r\u00e9e ou involontaire. Un bon d\u00e9veloppeur conna\u00eet les bonnes pratiques de programmation mais peut en omettre certaines, soit volontairement dans l\u2019attente d\u2019une prochaine version, soit par manque d\u2019attention. La perfection n\u2019est pas de ce monde.<\/p>\n<h3><strong>Diff\u00e9rentes natures de dette<\/strong><\/h3>\n<p>Mais dans tous les cas, quelque soit la nature ou l\u2019origine de la dette technique, ce sont les programmeurs qui g\u00e8rent celle-ci. Et c\u2019est bien la raison pour laquelle je consid\u00e8re que cette notion ne doit pas s\u2019\u00e9tendre \u00e0 d\u2019autres co\u00fbts de non-qualit\u00e9.<\/p>\n<p>Une erreur ou un oubli dans les sp\u00e9cifications fonctionnelles ou dans la phase de conception vont certes n\u00e9cessiter de modifier le code, mais l\u2019origine de cette modification ne se trouve pas dans la programmation et les choix ou les manquements aux bonnes pratiques des d\u00e9veloppeurs.<\/p>\n<p>Un plan de test incomplet ou insuffisant peut r\u00e9sulter d\u2019une volont\u00e9 du management de livrer le plus rapidement possible un prototype qui permette aux utilisateurs de pr\u00e9ciser leurs besoins sans se soucier des bugs, ou au contraire d\u2019un manque de temps, de connaissance ou d\u2019exp\u00e9rience de l\u2019\u00e9quipe de QA, ou encore d\u2019une documentation incorrecte ou d\u2019un outillage inad\u00e9quat.<\/p>\n<p>La m\u00e9taphore de la dette peut s\u2019appliquer \u00e0 ces diff\u00e9rents exemples, mais dans ce cas, parlons de dette fonctionnelle ou de dette QA, plut\u00f4t que de vouloir int\u00e9grer \u00e0 la dette technique tous les co\u00fbts de non-qualit\u00e9.<\/p>\n<p>Autre raison pour laquelle je pense que la dette technique doit s\u2019appliquer au code et aux programmeurs :<\/p>\n<ul>\n<li>Les bugs qui trouvent leur origine dans le code sont les plus nombreux : environ un sur trois.<\/li>\n<li>Les d\u00e9fauts de code sont les plus faciles \u00e0 d\u00e9celer et \u00e0 corriger : environ 85% et ce chiffre peut monter jusqu\u2019\u00e0 95% en utilisant un outil d\u2019analyse de code.<\/li>\n<\/ul>\n<p>Les bugs issus de d\u00e9fauts de sp\u00e9cification et de design sont moins nombreux mais plus difficiles \u00e0 identifier et \u00e0 supprimer.<\/p>\n<p>La non-qualit\u00e9 des applications trouve son origine dans des d\u00e9fauts de nature tr\u00e8s diff\u00e9rente pour des risques et des impacts tr\u00e8s diff\u00e9rents. Les regrouper tous dans le m\u00eame panier de la dette technique cr\u00e9e de la confusion et rend cette notion impraticable.<\/p>\n<h3><strong>Dette technique et programmeurs<\/strong><\/h3>\n<p>Derni\u00e8re raison enfin : les d\u00e9fauts de code sont les seuls que l\u2019on peut identifier de mani\u00e8re automatisable, \u00e0 l\u2019aide d\u2019un outil d\u2019analyse de code. Vous ne pourrez jamais automatiser la d\u00e9tection d\u2019une sp\u00e9cification absente, d\u2019une conception erron\u00e9e ou d\u2019un manque de tests. Ce sont forc\u00e9ment des t\u00e2ches manuelles.<\/p>\n<p>Par contre, vous pouvez analyser 5 000 classes Java et 100 000 lignes de code en quelques minutes et identifier rapidement et facilement toutes les violations aux bonnes pratiques. Vous pouvez m\u00eame construire automatiquement des plans de rem\u00e9diation que le d\u00e9veloppeur d\u00e9couvrira dans la liste de ses t\u00e2ches.<\/p>\n<p>Si l\u2019on veut int\u00e9grer les autres d\u00e9fauts dans la dette technique, alors il faudra effectuer une estimation manuelle du risque fonctionnel ou de test pour chacune de ces 5 000 classes. Impossible.<\/p>\n<p>Les programmeurs l\u2019ont d\u2019ailleurs bien compris qui utilisent la notion de dette technique sur un plan op\u00e9rationnel, comme le montre cet article \u2018<a title=\"Effective code review with Sonar\" href=\"http:\/\/www.sonarsource.org\/effective-code-review-with-sonar\/\" target=\"_blank\">Effective Code Review with Sonar<\/a>\u2019  sur le blog de Sonar. Un processus de Continuous Inspection permet de mesurer le niveau de dette technique et de veiller \u00e0 ce que celle-ci ne s\u2019accroisse pas.<\/p>\n<p>Je suis donc d\u2019accord avec Capers pour dire que la dette technique ne doit pas \u00eatre confondue avec les co\u00fbts de non-qualit\u00e9 (COQ) sinon le concept devient impraticable.<\/p>\n<p>Et pendant que nous autres consultants discutons de la d\u00e9finition exacte du concept, les d\u00e9veloppeurs utilisent la dette technique quotidiennement comme une m\u00e9trique op\u00e9rationnelle qui permet de surveiller le niveau de non-qualit\u00e9 dans le code, sans se soucier d\u2019une d\u00e9finition exacte.<\/p>\n<p>Vouloir actualiser ou \u00e9tendre le concept de dette technique peut \u00eatre intellectuellement int\u00e9ressant mais s\u2019av\u00e8re inutile sans application concr\u00e8te et op\u00e9rationnelle, ou sinon, comme dans la blague sur les consultants, on ne sait pas trop \u00e0 quoi cela sert ou ce qu\u2019on peut en faire.<\/p>\n<p>&nbsp;<\/p>\n<p><em>(1) <\/em>Variante : \u00ab Et bien, je ne sais pas vraiment \u00bb r\u00e9pond le propri\u00e9taire. \u00ab Mais les deux autres l&rsquo;appellent &lsquo;Boss &lsquo;\u00bb. Eviter cette variante avec votre chef ou il va croire que vous insinuez qu&rsquo;on ne sait pas ce qu&rsquo;il fait.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Vous savez quelle est ma blague pr\u00e9f\u00e9r\u00e9e sur les consultants ? Un homme entre dans un magasin d\u2019animaux et voit un singe dans une cage avec un \u00e9criteau \u2018Singe C &#8211; $2 000\u2019. Le propri\u00e9taire du magasin s\u2019approche et le client lui dit : \u00ab Il est cher votre singe. Qu\u2019est-ce qu\u2019il a de sp\u00e9cial [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-224","post","type-post","status-publish","format-standard","hentry","category-qualite-des-applications"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/224"}],"collection":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/comments?post=224"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/224\/revisions"}],"predecessor-version":[{"id":225,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/posts\/224\/revisions\/225"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/media?parent=224"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/categories?post=224"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/fr\/wp-json\/wp\/v2\/tags?post=224"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}