Discussion :

[ustensile]

Une fois, j'ai eu l'occasion de bosser avec IT manager, un "vieux de la vieille" de l'informatique mélangé avec maître Yoda, il avait un poster dans son bureau qui listait les principes à toujours garder à l'esprit pour mener à bien un projet. Avec le temps, je me suis rendu compte qu'il avait toujours raison. Voici ces principes:

1-Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le vôtre soit le premier.
-Les bénéfices seront inférieurs aux estimations, si on a pensé à faire des estimations.
-Le système finalement mis en place le sera avec du retard, et ne fera pas ce qu'il est censé faire.
-Il coûtera plus cher mais ce sera une réussite technique.

2-L'un des avantages à fixer des objectifs vagues, c'est que vous n'aurez pas de difficultés à estimer les dépenses correspondantes.

3-L'effort nécessaire pour redresser le cap croit géométriquement avec le temps
-Plus vous attendez pour définir les objectifs, plus c'est difficile
-Après l'installation, c'est trop tard.
-Faites le maintenant

4-Les buts, tels que les entend celui qui en décide, seront compris différemment par chacun des autres.
-Si vous vous exprimez avec une clarté telle qu'il soit impossible que qui que ce soit ait mal compris, ce sera quand même le cas de quelqu'un.
-Si vous faites quelque chose qui, vous en êtes sur, recevra l'approbation de tous, quelqu'un n'aimera pas ça.

5-Seuls les bénéfices mesurables sont réels. Or, les bénéfices immatériels ne sont pas mesurables. Donc les bénéfices immatériels ne sont pas réels.

6-Toute personne qui peut travailler à temps partiel pour un projet n'a surement pas assez de travail en ce moment.
-Si son patron ne lui donne pas un travail à temps complet, vous ne devez pas le faire non plus.
-S'il y a un problème de répartition d'horaires, le travail de son patron n'en souffrira pas.

7-Plus grande est la complexité technique du projet, moins vous avez besoin d'un technicien pour le diriger.
-Trouvez le meilleur manager possible, il trouvera le technicien.
-Le contraire n'est presque jamais vrai

8-Un projet mal planifié prendra 3 fois plus de temps à réaliser que prévu.Un projet bien planifié prendra seulement 2 fois plus de temps.

9-S'il y a un risque que quelque chose marche mal, ça marchera mal. S'il est impossible que quelque chose marche mal, ça marchera mal quand même

10-Quand les choses vont bien, quelque chose ira mal
-Quand les choses ne peuvent réellement pas devenir pire, elles le deviendront
-Quand les choses semblent aller mieux, c'est que vous avez oublié quelque chose

11-Les équipes de projet détestent les compte-rendus hebdomadaires d'avancement des travaux parce que ceux-ci mettent trop vivement en lumière l'absence de leur progrès

12-Les projets progressent rapidement jusqu'à 90% de leur achèvement, puis ils restent achevés à 90% pour toujours

13-Si on laisse le contenu d'un projet changer librement, le taux de changement dépassera le taux d'avancement.

Je pense qu'il n'y a pas grand'chose à ajouter

[Invité]

Je partage ce qui vient d'être dit.
Depuis plusieurs années, mon expérience de chef de projet montre que les raisons principales pour lesquelles on arrive pas à tenir nos échéances sont :
- une analyse fonctionnelle trop succincte --> certains choix fonctionnels faits en cours de dev nécessitent beaucoup de refacto de code
- une analyse technique trop succincte --> si on s'aperçoit au milieu du dev que telle ou telle contrainte (ex : volume de données, performance...) n'a pas été prise en compte au départ, ça peut remettre en cause une partie du code déjà écrit.
- ajouter des choses sur du code ancien mal architecturé et incompréhensible

Sur des applis complexes, la phase d'architecture technique est absolument indispensable et je pense que c'est le sens principal des propos de Leslie Lamport.
Plus on anticipe les choses, plus on est en mesure de faire du code propre, maintenable et évolutif. Ensuite, bien entendu le développeur doit avoir à coeur de faire du travail de qualité...

[Uranne-jimmy]

Comme partout, être autodidacte a plusieurs signification. En programmation, deux choses sont importantes à apprendre : la grammaire, et la méthode. Aussi bien la grammaire, la partie construction, donc, est facile à apprendre, elle nécessite d'intégrer des principes, de connaitre les règles. Aussi bien la méthode est généralement plus difficile à obtenir, sur internet on trouve beaucoup moins de source.
J'ai été autodidacte par simple envie pendant quelques années, avant de spécialiser mes études en ajoutant la compétence programmation, et malgré la pauvreté de l'enseignement (la licence pro bioinfo carcassonne, n'y allez pas), avoir un prof qui nous apprends plus que le code la manière, ça a booster mes capacités. Et à plus grande ampleur, developpez.net m'a apporté beaucoup dans la méthode.

Je résume mes propos médulleux (^^') : ce n'est pas qu'on oublie une étape, c'est qu'on apprend pas a réfléchir.

Mais comme disent beaucoup ici, il n'y a pas proportionnellement plus de mauvais qu'avant, bien que je pense que ce soit lié à la souplesse grandissante des langages.

[TiranusKBX]

Evidemment que le code est de moins en moins bon avec ces de deadlines trop courtes et sans marges de manœuvres
du coup pour tenir les délais on écris à l’arrache et ça donne du code pourris

[hugobob]

La multitude de langage pourrait aussi bien être la cause.

[Johnny P.]

L'éternel débat sur la qualité du code il n'y a pas de recette miracle qualité du code + temps respecté + les imprévus + complexité c'est un peu le monde du magicien qui essaie de trouver que quelque chose ne va jamais , on veut toujours faire mieux en programmation hélas c'est un monde où il n'y aura jamais de certitude comment peut-on être sûre , on essaie de trouver des règles dans un domaine avec trop de paramètres.

[Jitou]

La qualité de code n'a pas disparue car elle n'a jamais été à mon sens ... par contre la qualité se dégrade même si elle n'était déjà pas géniale il y a 20 ans. Pour moi il y a une raison essentielle de cette dégradation, les prestataires SSII qui produisent l'immense majorité du code que l'on trouve dans les système d'information des entreprises, recrutent à bas prix des jeunes étudiants qui n'ont que faire du métier de développeur et qui se servent donc de se passage obligatoire pour évoluer vers d’autres postes. Donc inutile de dire qu'avec des équipes composées de débutants qui ne sont même pas intéressés par l'apprentissage du génie logiciel, de l'architecture des bonnes pratiques etc ... on ne peut vraiment pas en attendre de la qualité. Tous les jours je tombe sur du code écrit à l'arrache, sabotant une architecture bien pensée et verrouillant des pans de code entier. Pour les entreprises clientes se sont des milliers de jours homme chèrement payées qui partent dans de la maintenance inutile, du retro-engineering sans fin, de la recherche de bug dans du code spaghetti etc ... Heureusement pour nous que les clients croient encore que l'informatique est nécessairement quelque chose de compliqué ce qui nous permet de justifier ces prestations gargantuesques qu'on leur vend

[guizmaii]

Je ne suis pas non plus d'accord avec cet article et ce que ce monsieur, que je respecte profondément, dit là. Cependant, cet article au titre provocateur a le mérite d'avoir des commentaires de la part de la communauté d'excellentes qualités !

Les commentaires sont bien plus intéressants que l'article ! Donc merci aux gens (el_slapper, par exemple) qui ont répondu à cet article de façon magnifique.

[landry161]

Y a une chose qu'il faut pas oublier quand même ,c est que quand on fait une application pour son entreprise ou une tiers personne ,c est plus le délai qui est pris en compte.Comment vous faites l'application ça on ils s en moque éperdument.Le plus important pour eux il faut que l application fasse ce que le client demande .Même si cela est fait dans un cafouillage total.
Je me souviens du tout premier projet sur lequel j'ai bossé, à chaque fois que disais à mon boss avoir tel problème ou qu'il me fallait utiliser telle technique ou procédé bah le mec il s 'en foutait complètement ,seulement lui c’était son argent qui l intéressait.
Pour ce qui est de la beauté du code je crois qu'il faut faire preuve de professionnalisme, quand on est encore en année de BTS, c est normal parce qu on est plus motivé de d abord voir que "ça marche " et le reste nous importe peu.Mais quand on veut jouer dans la cour des grands faut coder comme un pro.Personnellement, je pense qu il faut écrire du code tout en ayant à l esprit qu 'il peut être utilisé par quel qu un d autre(avec des commentaires ,indentations) mais aussi pour une maintenance plus facile .

[Bousk]

C'est "marrant" de voir ce type de sujet apparaître quand la mode actuelle est à l'expansion des SSII, outsourcing, délocalisation, ...
Sans compter les formations : y'en a plein, trop, et leur qualité est tellement disparate.. mais qui fournissent toutes un "même niveau" (sur le sacré papier qu'est le diplome), et on retrouve tous ces gens sur le marché du travail (et en premier lieu, vous l'aurez deviné, en SSII qui auront vite fait de les placer et boycotter un peu plus un projet au passage)
coïncidence ?

[GPPro]

C'est "marrant" de voir ce type de sujet apparaître quand la mode actuelle est à l'expansion des SSII, outsourcing, délocalisation, ...
Sans compter les formations : y'en a plein, trop, et leur qualité est tellement disparate.. mais qui fournissent toutes un "même niveau" (sur le sacré papier qu'est le diplome), et on retrouve tous ces gens sur le marché du travail (et en premier lieu, vous l'aurez deviné, en SSII qui auront vite fait de les placer et boycotter un peu plus un projet au passage)
coïncidence ?

Le blog initial est de début 2013, donc pour une news sur les tendances du moment... No comment.

[Luckyluke34]

Je suis assez d'accord pour dire que les développeurs succombent trop souvent à la tentation de coder tout de suite, au lieu de prendre de le temps de se poser deux minutes en traçant à grands traits sur un tableau ou un bout de papier un schéma d'ensemble de ce qu'il vont faire.

Maintenant, il serait une erreur de considérer que ces blueprints sont gravés dans le marbre et qu'ils vont rester valables pendant toute la durée de vie du logiciel. Il y a toutes les chances pour que les plans tracés au début s'avèrent de mauvaises idées et soient remaniés au fur et à mesure du développement. Se pose alors l'éternelle question de la synchronisation des specs et du code, et force est de constater que plus les specs sont précises, plus il y a de risque qu'elles soient fausses. Il faut donc créer juste ce qu'il faut de documentation, et c'est cet équilibre qui est difficile à trouver.

A cet égard, j'ai l'impression que l'auteur de l'article verse un peu trop dans le "faisons comme on l'a toujours fait avant" et qu'il pousse loin l'analogie avec les métiers du bâtiment, sans tenir compte des singularités de cette discipline qu'est la programmation. Par exemple, j'ai rarement vu un ouvrier seul péter des murs porteurs pour transformer une grosse partie d'un bâtiment en une heure sans avertir personne, alors qu'en développement l'équivalent est beaucoup plus vite arrivé.

D'autres arguments sont simplement complètement faux ou irréalistes, ce qui me rend un peu perplexe au vu du pedigree du bonhomme.

One thing to avoid is using code. Code is a bad medium for helping to understand code. Architects don’t make their blueprints out of bricks.

Ah bon ? Et les tests automatisés ? N'est-ce pas une bonne façon de comprendre le code ? Ne parle-t-on pas de "spécifications exécutables" ?

Et la programmation par contrat ? Les pré et post-conditions aposéees sur des méthodes ne constituent pas une bonne documentation/spécification de celles-ci ?

Sometimes figuring out exactly what a method should do requires thought, and its spec may be a paragraph or even a couple of pages. I use a simple rule: The spec should say everything one needs to know in order to use the method. After the code has been written and debugged, no one should ever have to read it.

J'ai l'impression d'avoir affaire à des règles d'un autre âge. Un référentiel de documentation aussi énorme est un boulet qu'on va se trainer à chaque fois qu'on veut en savoir plus sur une méthode et qui va générer du context switching à foison. Pourquoi s'interdire de regarder le code pour le comprendre alors que les IDE modernes fourmillent de moyens de naviguer très rapidement dans une base de code et que, des tests au nommage en passant par les commentaires et les annotations, tout est là pour documenter au maximum dans le code ?

[e-ric]

Je ne conteste pas le point de vue de Leslie Lamport, qui au vu de ses travaux, a certainement des arguments fondés.

Mais de mon point de vue, le métier de développeur n'est pas strictement identique à celui d'architecte (la paie non plus d'ailleurs).

- le métier d'architecte est un métier ancien, qui je pense est largement codifié, notamment les documents (plans...) alors qu'en informatique, aucune méthode de spécification n'a vraiment conquis la communauté du développement. Ca change sans arrêt.

- l'ambiance de travail n'est certainement pas la même non plus, les architectes sont en général des professions libérales soumises à des contraintes professionnelles différentes de celles des développeurs que l'on sollicite assez fortement avec des spécifications mal ficelées (quand il y en a), facile de dire après qu'il a rien compris. Le tout en prenant les développeurs pour de vraies billes.

- un programme informatique reste un produit immatériel alors qu'un bâtiment finit par être construit et on voit bien s'il manque un mur, avec un programme c'est pas toujours facile même si le mur est gros.

D'une façon générale, dans ces discussions, le développeur est toujours le mauvais type : asocial, incapable de s'exprimer correctement ou pire dans un jargon incompréhensible, il ne sait pas tenir les délais et j'en passe ... Dans les autres professions, il est vrai, on a jamais ces problèmes (sic).

Mais c'est souvent lui qui s'arrange pour que le projet ne soit pas en totale déshérence.

Pour revenir à la qualité du code, il suffit de lire des programmes Cobol (pas toujours très vieux) pour se rendre compte qu'elle n'a pas baissé mais qu'elle est restée assez médiocre. C'est une question de personnalité avant tout, un développeur dispose de la configuration mentale pour faire du code ou pas.

[TiranusKBX]

en parlant de spec c'est moi qui finit par les faire et de mande au client de valider car le cahier des charges n'est jamais fait par lui
du coup avec cette méthode je réduit vachement les allez-retours inutiles et chronophage
et je peut me poser des jours de congé

[bmayesky]

L'expert à raison quand à ce qu'il faut pour écrire du bon code. Il passe simplement à coté d'une vérité: personne n'a besoin de bon code.

Sans développer, les effets du "lean management" font que personne dans le cycle de vie du projet ne va faire quoi que ce soit d'autre que produire le minimum d'effort pour remplir la fonction attendue du logiciel ("les ressources sont concentrées sur le seul objectif du projet" pour la version politiquement correcte).
Et la qualité, l'efficience du code ne fait pas partie des caractéristiques attendues du projet "lean" (sauf si c'est un impératif industriel auquel cas le coût s'envole comme de normal).

[e-ric]

Il passe simplement à coté d'une vérité: personne n'a besoin de bon code.

Encore une prodigieuse connerie issue des écoles de management. J'espère que les logiciels embarqués (avion, matériel médical..) ne suivent pas cette orientation.
A quoi bon emmerder les gens avec des études supérieures ?

Effectivement, on le constate souvent dans les projets informatiques,et on se retrouve avec des bouses qui plantent tout le temps. mais bon c'est pas grave, les développeurs sont là pour corriger. Pour résumer, les cadres se disent "Après moi, le déluge" et on leur donne des promotions pour ça...

Concernant les dérapages, il serait bon de se demander comment sont évalués les charges ? Mais souvent la vérité sur les charges fait peur et on arrange sur les données pour que le projet soit lancé ou alors on impose le délai sans prendre connaissance du problème, encore mieux...

Il n'y a qu'en informatique où on peut trouver des cadres qui ne connaissent rien au métier dans lequel ils sont censés exercés. Misère!!

[Paul TOTH]

Encore une prodigieuse connerie issue des écoles de management. J'espère que les logiciels embarqués (avion, matériel médical..) ne suivent pas cette orientation.
A quoi bon emmerder les gens avec des études supérieures ?

Effectivement, on le constate souvent dans les projets informatiques,et on se retrouve avec des bouses qui plantent tout le temps. mais bon c'est pas grave, les développeurs sont là pour corriger. Pour résumer, les cadres se disent "Après moi, le déluge" et on leur donne des promotions pour ça...

Concernant les dérapages, il serait bon de se demander comment sont évalués les charges ? Mais souvent la vérité sur les charges fait peur et on arrange sur les données pour que le projet soit lancé ou alors on impose le délai sans prendre connaissance du problème, encore mieux...

Il n'y a qu'en informatique où on peut trouver des cadres qui ne connaissent rien au métier dans lequel ils sont censés exercés. Misère!!

alors moi j'ai donné +1 à son message, car dès fois on se demande tout de même si le bon code est recherché. C'est en tout cas l'impression que j'ai quand on me refuse un devis considéré comme trop cher et qu'on me demande si je ne connais pas un jeune qui débute qui voudrais se faire les dents sur le projet.

dans un autre registre, les tarifs de formation sont rarement négociés, alors que dès que tu proposes une prestation de développement le client cherche à tirer les tarifs vers le bas. Il est du coup plus facile de vendre 5 jours de formation à un tarif donné que de faire passer 5 jours de développement sur ce même tarif; le client va systématiquement remettre en cause soit la durée, soit le tarif.

[e-ric]

car dès fois on se demande tout de même si le bon code est recherché. C'est en tout cas l'impression que j'ai quand on me refuse un devis considéré comme trop cher et qu'on me demande si je ne connais pas un jeune qui débute qui voudrais se faire les dents sur le projet.

Et quand le projet va vraiment mal ou qu'il faut le maintenir ou encore parce qu'on se rend compte qu'un programme qui marche ça sert bien aussi, on appelle le pompier de service i.e. un bon développeur qui ramasse toutes les bouses de ses prédécesseurs. Il règne dans le monde de l'informatique, en particulier de gestion, une philosophie selon laquelle la programmation est en quelque sorte du boulot de saisie, sans grande qualification, et que seule la conception prime d'où l'importance accrue des CDP et de la MOA au détriment des développeurs. Ces derniers sont généralement considérés comme des petites mains.

Le problème est que l'un ne va pas sans l'autre une super conception sans une bonne réalisation ne vaut pas plus qu'une réalisation qui tente de compenser une conception ratée. Une absence de conception est parfois préférable car il laisse le champ libre pour un développeur qui connaît son boulot.

la complexification croissante des EDI qui en apportant du confort à des développeurs confirmés ne sont plus à la portée du premier venu. Il n y a qu'à comparer les EDI actuels et celui de TurboPascal 4.0.

Pour rigoler, chez un client, les développeurs micro étaient classés bureauticiens, tout un symbole.

[atha2]

Il règne dans le monde de l'informatique, en particulier de gestion, une philosophie selon laquelle la programmation est en quelque sorte du boulot de saisie, sans grande qualification, et que seule la conception prime d'où l'importance accrue des CDP et de la MOA au détriment des développeurs. Ces derniers sont généralement considérés comme des petites mains.
Le problème est que l'un ne va pas sans l'autre une super conception sans une bonne réalisation ne vaut pas plus qu'une réalisation qui tente de compenser une conception ratée. Une absence de conception est parfois préférable car il laisse le champ libre pour un développeur qui connaît son boulot.

Le mot Conception peut signifier tout et n'importe quoi (souvent n'importe quoi d'ailleurs ), je vais donc préciser comment je l'utilise ici : analyse du projet qui se déroule avant l'écriture de la moindre ligne de code (à part pour tester une API ou la faisabilité d'un point nécessaire au projet) qui comprend la définition :

• des besoins fonctionnels
• du modèle de donnée (via un MCD(Merise) ou un diagramme de classes (UML))
• des différents traitements à effectuer (régulièrement ou à la demande)
• de l'architecture globale de l'application (diagramme de classes et/ou de package (UML))
• des entrées et sorties de l'application et de leurs formats
• si présente, de l'interface graphique (SNI, Wireframe)

Avec une conception, telle que je la décris, faite correctement, il parait difficile de faire foirer un projet si le développeur suit à la lettre la conception. Le seul problème est que pour que ces étapes soient faites correctement, la personne (CDP, MOA) qui conçois doit avoir une bonne connaissance et maitrise de différents outils (UML, Merise, POO, Forme Normale, XML, SNI...), ce qui à mon avis sont (pas forcément devrait) plus des compétences que possède un développeur.

En soit un conception est nécessaire et si on ne fourni pas une conception correcte au développeur, c'est malheureux à dire mais c'est à lui de la faire/corriger avec le peu d'information qu'il possède. Et après classiquement, si le projet foire, ça retombe sur lui parce qu'il n'a pas assez posé de question ou n'a pas remonter le problème

[Marco46]

Êtes-vous d'accord avec l'expert ?

Un développeur professionnel travaille au sein d'une équipe et doit rendre compte à une hiérarchie qui doit elle-même rendre compte à ses clients.

Dans ce contexte, lire de sa part que le développeur a tord de ne pas planifier c'est oublier que non seulement il ne peut pas forcément, mais qu'il n'en a pas forcément non plus le droit.
Attention je ne dis pas qu'il a tord de dire qu'il faut planifier pour coder propre, je dis que le développeur a très rarement ce pouvoir !

Bref, ce monsieur est à l'ouest.

Et puis quid des tests unitaires et de l'intégration continue qui se mettent en place depuis quelques années ? Ces pratiques pénètrent de plus en plus les entreprises. Aujourd'hui les dernières techno web sont capables de faire de même ( AngularJS ). C'est pas une progression dans la qualité ça ?

Grand respect pour ses créations mais on dirait plus un savant fou dans une tour d'ivoire qui juge la populace sans ne l'avoir jamais rencontrée.