Coder rapidement ou écrire du code de qualité ?
Les deux approches reviendraient au même, selon un célèbre développeur dessinateur
Le 2011-01-10 17:27:07, par Idelways, Expert éminent sénior
XKCD est une célèbre bande-dessinée créée et publiée par Randall Munroe, un ancien consultant à la NASA, qui la définit comme un webcomic sarcastique qui parle de romance, de maths et de langage.
Une planche publiée récemment sous forme d'organigramme algorithmique n'a d'autre prétention que celle de résumer, d'une manière extrêmement pessimiste, le métier de développeur.
Les développeurs seraient, selon Munroe, éternellement confronté au dilemme : coder rapidement ou coder correctement.
Ceux qui prennent la décision de "coder correctement" sont selon Munroe toujours dépassés par les événements, et quand leur travail arrive enfin à terme, les spécifications auront déjà changé. Les malheureux doivent donc tout jeter et reprendre depuis le début.
Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de « bidouilles et de code spaghetti ». Résultat, leur code subirait le même triste sort que celui de leurs confrères : être jeté et repris depuis le début.
Bien entendu, cette planche exclut toute possibilité de juste milieu entre ces deux extrêmes.
Il existe bien entendu des développeurs qui arrivent à produire du bon code dans les délais, sinon nous ne serions pas là pour en parler.
Mais d'après vous ?
Source : XKCD.com
Une planche publiée récemment sous forme d'organigramme algorithmique n'a d'autre prétention que celle de résumer, d'une manière extrêmement pessimiste, le métier de développeur.
Les développeurs seraient, selon Munroe, éternellement confronté au dilemme : coder rapidement ou coder correctement.
Ceux qui prennent la décision de "coder correctement" sont selon Munroe toujours dépassés par les événements, et quand leur travail arrive enfin à terme, les spécifications auront déjà changé. Les malheureux doivent donc tout jeter et reprendre depuis le début.
Les autres (ceux qui choisissent de coder vite) finiraient, eux, immanquablement par produire une masse de « bidouilles et de code spaghetti ». Résultat, leur code subirait le même triste sort que celui de leurs confrères : être jeté et repris depuis le début.
Bien entendu, cette planche exclut toute possibilité de juste milieu entre ces deux extrêmes.
Il existe bien entendu des développeurs qui arrivent à produire du bon code dans les délais, sinon nous ne serions pas là pour en parler.
Mais d'après vous ?
Source : XKCD.com
-
jmguicheMembre avertiD'après mon expérience, de presque 30 ans, il y a deux types de "clients".
Ceux qui ont l'esprit clair, rationnel et qui sont capable de stabiliser un besoin et de faire la différence entre l'accessoire et l'indispensable. Avec ceux là, il est possible de travailler bien et souvent vite ! Il est possible de concevoir une solution efficace fonctionnellement et propre techniquement, dans les délais.
Et les autres... Ceux avec qui, quelque soit la méthode de développement, le projet coutera au moins le double de ce qu'il devrait, à force d'incohérences, de voltes faces, d'oublies, d'imprécisions, de y'akafaukon, etc...
Tout cela n'a rien à voir avec la méthode employée. Avec une MOA incapable de stabiliser sa demande, les approche "top down" tombent à coté d'une cible qui bouge tout le temps et les approches itératives (extrem programming et autres) ne convergent pas mais tournent en rond.le 12/01/2011 à 8:47 -
FR119492RédacteurBonjour à tous!
Mon expérience professionnelle est la suivante: dans l'immense majorité des cas, celui (client, supérieur hiérarchique ou autre) qui vous confie une tâche de développement informatique n'a aucune idée de ce qu'il veut, et encore moins de ce qu'il est possible de réaliser. Il convient donc de procéder en deux étapes:
- Commencer par écrire un programme de manière raisonnablement propre, mais sans trop se soucier du cahier des charges, qui, de toute manière, est totalement incohérent.
- Lorsque c'est terminé, faire preuve d'un sens psychologique extrême pour persuader le client que c'est exactement ce qu'il a commandé.
Vous pouvez me croire ou non, mais, dans la plupart des cas, ça marche. On pourrait évidemment envisager un cas critique, à savoir que le client soit compétent, mais c'est plutôt rare; de plus, dans ce cas, il aurait écrit son programme lui-même.
Jean-Marc Blancle 10/01/2011 à 18:57 -
Fifan31Membre avertiIl est aussi facile de coder à partir des spécifications que de marcher sur l'eau
A condition que les 2 soient geléesle 12/01/2011 à 21:56 -
BarsyExpert confirméJe pense que la meilleure méthode reste celle là :
C'est la méthodologie de la RACHE à découvrir ici : http://www.risacher.com/la-rache/ et qui est utilisée dans de très nombreux projets.le 11/01/2011 à 9:36 -
BarsyExpert confirméLe but du commercial reste quand même d'essayer de vendre la baignoire même si le client n'a besoin que d'une douche.
Le but du client par contre est de réussir à acheter la douche au prix du lavabo.
Le défi du développeur sera de réussir à réaliser la "baignoire-douche-lavabo" qui sera un subtil mélange entre les trois solutions et qui au final ne répondra à aucun besoin.le 27/01/2011 à 16:43 -
pseudocodeRédacteur"Make It Work, Make It Right, Make It Fast", Kent Beck.
1. "Make It Work" : Coder quelque chose qui est fonctionnel (implement)
2. "Make It Right" : Reprendre le code pour le rendre clair (refactor)
3. "Make It Fast" : Reprendre le code pour le rendre rapide (optimize)le 10/01/2011 à 17:50 -
zaventemMembre expérimentéTout comme il n'y a rien de choquant que ton plombier t'installe une douche quand tu demandes un baignoire; après tout, c'est lui le pro.
Ce genre de réflexion me fait vraiment peur
Pourrais-je rappeler qu'in fine, l'informatique n'a pour seul utilité que d'être un support au métier. Ni plus, ni moins. Donnez au client toute les cartes pour qu'il puisse décider en connaissance de cause, qu'il soit conscient des contraintes engendrées par son choix, c'est notre boulot; lui dire ce qu'il veut, c'est aberrant.
PS: le jour où un développeur sera un "super utilisateur" (hormis le cas rare de logiciel destiné spécifiquement aux informaticiens), les entrepreneurs de pompes funèbres seront de "super mort"le 27/01/2011 à 11:02 -
BarsyExpert confirméSauf que si le client demande au plombier d'installer une douche en lui disant qu'il veut prendre des bains, je doute que le plombier ne lui fasse pas part de conseils dans ce cas.
Le but n'est pas de développer des fonctionnalités dans le dos du client, mais plutôt d'essayer de comprendre les besoins de celui-ci et proposer la solution que l'on considère la plus adaptée (même si elle peut être discutée ou refusée) plutôt que de se lancer aveuglément dans celle qu'il propose.
C'est un problème récurrent d'ailleurs en informatique, beaucoup de clients demande au développeur de réaliser une solution sans lui faire part des besoins initiaux. Et résultat, ce sont souvent des projets qui se plantent car le client n'a malheureusement pas pensé à tout.
C'est comme si j'allais chez le garagiste pour une panne et, plutôt que de lui expliquer la panne, je lui dis juste quelles pièces il doit changer.le 27/01/2011 à 11:14 -
gangsoleilModérateurMoui. Certaines personnes savent faire de vrais chiffrages, qui sont tres souvent corrects, a quelques pourcents pres bien sur.
Mais ca ne veut pas dire que les commerciaux accorderont ce chiffrage au projet.
Par ailleurs, il faut tenir compte de la loi de Hofstadter :
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.le 28/02/2011 à 11:51 -
NebulixMembre expérimentéPour le point 1, la méthode la plus sûre et la plus rentable n'est-elle pas de reservir ce qui a convenu à un client précédent ?le 12/01/2011 à 9:07