février
2009
Un article de Philippe Vialatte
Cette semaine, loin des techdays, la blogosphère internationale (comprenez, anglaise…) a résonné
des échanges de deux camps de développeurs.
D’un cote, le camp des agilistes et alt.net, de l’autre,
Jeff Atwood et Joël Spolsky (ils ne sont pas tous seuls, mais ce sont eux qui ont tirés les premiers).
Je n’ai normalement pas l’habitude (ceci dit, je blogges depuis peu…) de faire des posts dans le genre,
celui-ci est un peu long, donc, je prierais ceux qui seraient inquiétés par un post un peu long…de ne pas passer
leur chemin, et de lire quand même 
Pour un petit historique des faits:
- Tout commence le 5 Janvier 2009. Bob Martin (http://butunclebob.com/ArticleS.UncleBob),
un des membres signataires su manifeste Agile, donnait un entretien sur le podcast de Scott Hanselman,
sur les principes SOLID
(un excellent podcast a mon avis). - Le 20 Janvier, Joël Spolsky et Jeff Atwood,
dans un podcast
, sont revenus en partie sur le podcast susmentionné, critiquant les principes SOLID,
les qualifiant de ‘bureaucratiques’ (un petit extrait texte ici). - Suite a cela, Bob répliqua avec un
post,
puis une lettre ouverte
a Jeff et Joël le 6 Février (je passe les dizaines de posts de la sphère Alt.Net, tirant a boulet rouge sur le duo) - Le 11 Février, enfin, Jeff posta un post assez long, élaborant sur le fait que suivre des règles de construction ne pouvait mener,
a terme, qu’a des équipes de développement ou l’adhérence aux règles et aux processus est plus importante que le développement de fonctionnalités.
Ce post, en soit, étant déjà assez polémique, étant ensuite appuyé par plus de 150 commentaires dans le genre « oui, les règles, ça sert a rien,
on développe bien sans »… - Finalement toujours le 11 Février, Joël et Jeff ont invité Bob a un
podcast
pour confronter leurs points de vue. Dans cet épisode, après que Joël se soit excuse pour certaines de
ses remarques lors du podcast précédent, Jeff et Joël ont reformule leurs objections contre le TDD et SOLID en argumentant que,
quelle que soit la qualité du code, si les fonctionnalités ne sont pas au rendez-vous, le produit ne réussira pas…et que inversement,
si le produit a les bonnes fonctionnalités, quelle que soit la qualité du code, les clients seront contents.
Au final, on arrive a deux positions opposées.
D’un cote, on a des développeurs dont le premier souci va être de fournir
un logiciel qui fonctionne, quitte a faire l’impasse sur le design, l’évolutivité et la maintenabilité du code source, du moment
que le client a son site/programme/projet a temps, et que les fonctionnalités voulues soient présentes. Pas besoin de s’embarrasser de
designs compliques, il faut livrer le 15. Pour simplifier, appelons-le le groupe A.
De l’autre, le premier souci va être de fournir un logiciel qui, en suivant de plus ou moins prés un ensemble de guidelines,
de patterns et de principes, restera la plus extensible possible, et avec le moins de friction, quitte a renégocier avec
le client un délai supplémentaire pour le rendu. On appellera ce groupe le groupe B (originalité, quand tu nous tiens…).
Je ne dis pas que le groupe A a une vue du développement intrinsèquement mauvaise…seulement que c’est une vision a court terme.
Si on prends un projet lambda, avec une durée de développement de six mois. Dans la majorité des cas, sur ce genre de projet,
des exigences vont évoluer entre la signature du contrat et la livraison finale. Si on prends comme postulat que la qualité du produit
fini est moins importante que la présence des fonctionnalités, pour ne pas avoir un dépassement de date, on va essayer de tordre le design
pour ne pas perdre de temps, ce qui serait vécu comme un échec organisationnel et, une fois le produit fini, en temps et en heure,
certaines parties du code vont ressembler a un plat de spaghetti…charge a l’équipe qui gérera la maintenance du produit de les démêler.
Un autre effet pervers, c’est de dire que, comme la qualité est secondaire, l’apprentissage de patterns, de principes ou de règles
l’est aussi. Après tout, si le but est de livrer le code avec le niveau de qualité minimal acceptable par le client,
il est contre-productif de passer du temps a apprendre comment améliorer la qualité, le seul apprentissage nécessaire
sera de connaitre les frameworks et les langages ‘a la mode’, pas de savoir les utiliser. Les patterns sont vus comme autant de
buzzwords, les principes comme des règles inapplicables, et les tests comme une nuisance.
De tous les posts que j’ai lu et qui ont aborde, de prés ou de loin, ce sujet ces derniers jours, celui qui m’a le plus inspire est
un post de Rob Conery.
Dans ce post, il compare assez
justement les codes de construction et les fondamentaux du développement, en concluant que ce n’est pas forcement une nécessité d’appliquer
les différents principes a la lettre, mais qu’avant de les rejeter, il est nécessaire de les avoir intégrés.
Le développement est une industrie encore assez jeune pour encore avoir ses ‘grands anciens’ (+10 points a celui qui me retrouve
qui a dit que nous sommes de géomètres vivant au temps d’Euclide), alors autant en profiter pour aller leur poser des questions,
lire leur blogs, leurs livres, et décider une fois que l’on a compris ce dont ils parlent de ce que l’on veut appliquer a nos projets,
et comment’
Personnellement, je me sens bien dans le groupe B, venez, il y’a de la place pour tout le monde…
PS: désolé pour le manque d’accents, du au clavier qwerty. Les seuls accents sont ceux de la correction automatique de Live Writer,
j’essayerais de tout corriger plus tard, mais il fallait que ça sorte…
PPS: J’ai écrit trois version de ce post…je ne suis pas sur
d’être cohérent, je suis même a peu prés sur de ne pas être 100% compréhensible, mais si je recommence a relire encore ce post,
je ferais comme avec les deux précédents, direction corbeille, et autant je n’ai pas envie de passer pour un fou, autant si je
ne poste pas ce billet, il va encore me trotter dans la tête toute la nuit…
PPPS: donnez-moi votre avis, s’il vous plait…surtout si vous êtes en désaccord…
6 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
Trois éclairages différents pour faire avancer le débat.
– Certains développeurs ont une vision strictement professionnelle du développement, l’apprentissage des nouvelles technologies est sous la responsabilité de l’employeur ou de l’état. La journée est un moment de productivité, écrire. La soirée est consacrée à la famille et non à l’étude. Point de vue 1.
– L’apprentissage de nombreux concepts avancés exigent un anglais de qualité que certains ne possèdent pas. Microsoft ne traduit que la documentation de base. La blogosphère française est en retard sur la communauté anglo-saxonne. Point de vue 2.
– Mon point de vue : Si on exclut quelques SSII qui n’ont pas renoncé à l’esclavage, la majorité des clients finaux sont pour une part d’investissement personnel dans les nouvelles technologies, si tu as envie de te casser la tête pendant 2 jours pour utiliser un design pattern qui doit rendre le projet plus propre et plus maintenable, tu peux, la raison de l’échec de tant de projets de développement est que le développement reste un projet de création, au meme titre que la création d’entreprise, nombre d’entreprises disparaissent dans les deux ans, comme les projets informatiques…
C’est pour ca que dans tout projet Agile bien conduit dans les groupes de type A, il DOIT y avoir une phase de refactoring pour rendre le code plus souple, plus propre, plus factorisé.
S’il y a un intérêt à utiliser des patterns, cela se fait généralement à ce moment là (à moins que le développeur ait l’expérience nécessaire pour le constater dès le début).
Cette phase de refactoring peut se faire sans risque à partir du moment où les tests ont été écrit et ont été passés.
Mais tu as raison, tous les développeurs ne sont pas capables de le faire. Il faut être sensibilisé à ce genre de pratique et trouver que ca a un intérêt.
Je pense qu’il y a un juste milieu entre les deux points de vue …
D’une part, je ne pense pas que le groupe A soit pour la totale non utilisation de pattern et de méthodologie, d’autre part je ne pense pas plus que le groupe B pousse à l’utilisation des patterns au détriment de la productivité … Et puis j’ose espérer que l’utilisation de pattern est déterminer par l’amélioration de la productivité, de la qualité, évolutivité … Un pattern répond à des problématiques, la finalité n’est pas seulement d’avoir un jolie code, si on prend l’exemple des tests, le but est de limiter les bugs, la régression ect. si la finalité de cela n’est pas d’avoir des fonctionnalité sans bug en moins de temps, alors bon …
Je pense que ces méthodologie et pattern doivent être utiliser dans le sens de la productivité … Mais aussi la qualité et l’évolutivité, je ne pense pas que le client soit insensible à cela ! Vu le nombre de projet informatique qui ont été voué à l’échec …
Malheureusement, de mon expérience, non…
J’ai travaille sur trop de projets ou les développeurs avaient comme vision de leur job que les patterns ne servaient que sur les cvs et pour les entretiens…Et je ne parle pas de jeunes diplômés, mais de développeurs avec 5-6 ans d’expérience, qui servaient même dans certains cas de référents techniques…
Tu connais combien de développeurs qui prennent sur leur temps pour rester « au top » de leur performances ? Autour de moi, si je regarde, pas des masses…Et souvent, l’effort est porté sur les nouveaux frameworks et les nouveaux langages, pas sur les fondamentaux, fondamentaux qui sont d’ailleurs superbement ignorés (et pour de mauvaises raisons) par trop de monde
Dans d’autres industries ou métiers ?
Cite moi une industrie qui fait passer les délais avant la qualité…
Si tu es architecte dans le bâtiment, tu fais des plans pour une maison sans faire une étude des sols et des matériaux ?
Si tu es médecin, tu prescris un traitement qui sera moins long, mais qui ne vas pas guérir le patient ?
Une société de service (groupe B) qui connais bien les méthodes agiles développe un logiciel de qualité, maintenable et évolutif dans les mêmes délais qu’une autre du groupe A car les gains de productivité réalisés dans l’utilisation de frameworks qui mâchent le travail et la réutilisation de codes génériques précédemment développés dans le cadre de projets antérieurs compensent le temps passé à la gestion de projet, l’assurance qualité et la documentation.
Dire que les méthodes agiles et la qualité sont synonymes de temps perdu ou de temps de développement allongé est faux.
Les entreprises (du groupe A) qui sont incapables de faire évoluer leurs produits se font lâcher par leurs clients qui refuse de payer un nouveau produit différent chaque année alors que d’autres sociétés (agiles, groupe B) proposent des produits qui évoluent naturellement avec un coût d’évolution faible et des contraintes de migration limités.
L’avenir est aux méthodes agiles, si tant est que les SS2I savent les appliquer sans perdre de vue la finalité qui est le produit et non pas la méthode.
Ce raisonnement est tiré à l’extrême. Faisons alors de même pour les positions du groupe B :
Comme la date de livraison est secondaire, étant donné que l’on peut toujours la renégocier avec le client, il
faudra prendre le temps qu’il faudra pour fournir un code de très haute qualité. Alors le retard est tel que le
client non seulement annulle le projet mais en plus perd toute confiance à l’endroit de l’équipe de développement!
Je ne suis dans aucun des groupes, mais plutôt dans une approche pragmatique d’optimisation sous contrainte :
Optimiser la qualité du code tout en restant dans les limites tolérables de délais du projet en cours. Pour
certains projets les délais seront flexibles dans quels cas l’on pourrait(!) aboutir à du code de bonne qualité.
Pour d’autres, tout retard de livraison est fatal au projet, et alors il faut livrer à temps.
Cela se produit également dans les autres diciplines, prenons l’exemple du chomage et de l’inflation en économie :
pour faire baisser le taux de chomage les entreprises sont poussées à recruter; Ce qui entraine un surcoût de
production qui sera répercuté sur le prix des biens ainsi produits et donc faire monter le taux d’inflation.
Inversement pour baisser le taux d’inflation, les entreprises sont là poussées à baisser les coûts de production,
et le plus souvent ceci se fait en détruisant des emplois et donc en augmentant le taux de chomage.
Dans un cas comme dans l’autre la modération devrait être de mise.