Discussion :

[Invité]

...

Ok, on parle pas de la même chose, ce monsieur nous compare à des architectes je pense plus au niveau de la programmation de logiciel et non des couches plus bases, je pensais plus au développement en équipe.

C'est cohérent avec ce que je dis plus haut un expert qui parle de généralité et on part dans tous les sens

Je persiste à dire que citer "les ensembles, les fonctions et la logique" est un contre sens pour la majorité même si vous me trouver des exemples où elles sont le cœur de travaux informatique, pour le quidam cela reste des connaissances générales, et pas les plus pertinentes.

je trouve que l'idée de "ce n'est pas beaucoup utilisé, ne l'utilisons pas" est un bel exemple de frein à l'innovation.

J'ai un ressenti un peu différent le quidam n'est pas ouvert à l’innovation ( sauf si elle est accompagnée de marketing ) et j'ai l'impression que cela vient de l'éducation ( théorie avant la pratique ? ) qui rend les gens apathiques.

[hugobob]

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

[coolspot]

En même temps c'est pas étonnant vu que les SSII ont vampirisé le marché informatique et que leur dogme c'est produire le plus vite possible au plus bas cout possible tout en vendant le plus cher possible pour gratter un maximum de marge.

Ca donne des développeurs payés en cacahuète avec des délais de livraison intenable pour privilégier le cours terme. Et de toute façon si le code doit être revu ca fera l'objet d'une facturation ultérieur au client


Bref comme le dicton dit : When you pay peanuts, you'll get monkey.

[Fanvan]

Foutaises d'abord, parcque des codes ignobles, il y en a toujours eu. "GOTO considered harmful", ça a plus de 40 ans. J'ai refondu du code de 1972 absolument atroce. Et des utilisateurs finaux qui bricolent un code illisible - mais qui les dépanne bien - ça ne date pas d'hier(VBA pour EXCEL, c'est le début des années 1990, par exemple, et il y avait des précurseurs)

C'est sûrement vrai, mais le propos de Lamport n'est pas "c'était mieux avant". La news est construite de façon ambigüe et jette une ombre sur ses intentions, mais si on jette un œil à la source, on on se rend compte qu'il ne s'agit pas de tirer à boulets rouges sur la jeune génération de développeurs qui serait moins exigeante que la sienne.

Son propos est de défendre l'idée que "Writing code without thinking is a recipe for bad code". C'est tout. Hors de toute considération d'époque ou de génération.

Alors bien sûr, il argumente, et le propos est intéressant, mais c'est défoncer des portes ouvertes. Bien sûr qu'il faut réfléchir et planifier.

[fcharton2]

Super ! Alors pourquoi réduire l'amélioration des projets informatiques à de la logique, des ensembles, les fonctions ?

Parce que ce sont les briques de bases, en gros l'algèbre et l'analyse, et qu'on les retrouve un peu partout en informatique. Tu citais Knuth, je suppose que tu es familier de l'Art of Computer Programming: c'est juste des maths, essentiellement du dénombrement (aka des ensembles) et de l'analyse (aka des fonctions). C'est pareil pour le calcul des performances d'un algorithme, du dénombrement et des séries formelles, éventuellement un peu de probas (toujours de l'analyse, quoi).

Mais plus généralement, ce qu'il veut dire, je crois, c'est qu'en informatique, on utilise (ou on peut utiliser) beaucoup de maths, et qu'on a intérêt à le faire, parce que les maths sont un langage précis: exactement ce qu'on veut quand on spécifie. Et comme dans beaucoup d'autres domaines, en maths, on a généralement intérêt à rester près des notions de base, la logique, les ensembles, les fonctions...

Si le sujet t'intéresse, il faut absolument lire A Programming Language, d'Iverson (et plus généralement, tout ce qu'Iverson a écrit), c'est ancien mais extrêmement bien fait (et ça date d'avant les maths modernes...)

Francois

[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

[CodeurPlusPlus]

Il oublie fortement de parler des deadlines qui sont de plus en plus courte et qui ne permettent pas de faire un code propre

On n'a jamais d'excuse pour faire de la merde.

[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.

[pvincent]

Je suis d'accord avec fcharton2.

Tout d'abord Leslie Lamport n'est pas n'importe qui
http://en.wikipedia.org/wiki/Leslie_Lamport
et je n'aurai pas l'outrecuidance de croire que mon avis est meilleur que celui de l'auteur de LaTeX.

Il y a cependant un biais dans cet avis: c'est celui d'un expert et d'un mathématicien très doué, dont l'expérience permet de cerner les problèmes avant d'y avoir été confronté. Pour le vulgum programerus, il n'en est pas de même et il n'en a jamais été de même.

Quand à la qualité des codes d'antan, il néglige sans doute tous les bricolages de scientifiques programmeurs autodidactes qui développaient comme ils pouvaient leurs programmes de modélisation (je songe à mon cas personnel).

Mais certains commentaires me semblent à courte vue et incapable d'imaginer ce qu'un gars vraiment doué est capable de faire rien qu'avec des concepts.

[Invité]

Parce que ce sont les briques de bases, en gros l'algèbre et l'analyse, et qu'on les retrouve un peu partout en informatique. Tu citais Knuth, je suppose que tu es familier de l'Art of Computer Programming: c'est juste des maths, essentiellement du dénombrement (aka des ensembles) et de l'analyse (aka des fonctions). C'est pareil pour le calcul des performances d'un algorithme, du dénombrement et des séries formelles, éventuellement un peu de probas (toujours de l'analyse, quoi).

Je n'ai pas cité ce livre qui comme le numerical recipies sont marqués par l'âge...
D'innombrable livres plus accessible sont parus depuis.

Mais plus généralement, ce qu'il veut dire, je crois, c'est qu'en informatique, on utilise (ou on peut utiliser) beaucoup de maths, et qu'on a intérêt à le faire, parce que les maths sont un langage précis: exactement ce qu'on veut quand on spécifie.

Bof, j'en ai pas eu l'impression quand j'ai vu des statisticiens et le data mining...
Une lecture des programmes de l’agrégation et du premier cycle universitaire me fait penser le contraire : les bases de grobner sont généralement absentes, les combinatoires datent d'avant ma naissance et n'ont pas profité des développements récents, au niveau supérieur la théorie de Galois est absente...

Et comme dans beaucoup d'autres domaines, en maths, on a généralement intérêt à rester près des notions de base, la logique, les ensembles, les fonctions...

L'exemple récent d'OpenSSL qui réclame des connaissances non trivial en mathématiques prouve le contraire... pour la majorité des utilisateurs.

Si le sujet t'intéresse, il faut absolument lire A Programming Language, d'Iverson (et plus généralement, tout ce qu'Iverson a écrit), c'est ancien mais extrêmement bien fait (et ça date d'avant les maths modernes...)

Je jetterais un œil à l'occasion.

et je n'aurai pas l'outrecuidance de croire que mon avis est meilleur que celui de l'auteur de LaTeX.

Dois-je en déduire que seul les plus grands créateurs ont le droit de s'exprimer?
Et doit-on se prosterner? Et combien de fois?

Je remercierais ce monsieur pour Latex mais pas pour ses remarques d'améliorations.

celui d'un expert et d'un mathématicien très doué, dont l'expérience permet de cerner les problèmes avant d'y avoir été confronté. Pour le vulgum programerus, il n'en est pas de même et il n'en a jamais été de même.

J'ai fais des études ( que je regrettes ), et y ai croisé des monstres du même niveau, un exemple : un grand expert (*) de la géométrie-algébrique réelle qui arrivait sans préparer ses cours et qui le jours de l’examen final constatait benoitement que presque personne n'avait compris le trimestre de cours : 6 sur un amphi ont eu la moyenne.
Et à la fin des trois heures il nous demandait "mais pourquoi vous n'y arrivez pas?".

Comme quoi on peut être brillant et ne pas comprendre le monde dans lequel on vit...

(* normalien et prof à paris 6 et X.)

Mais certains commentaires me semblent à courte vue et incapable d'imaginer ce qu'un gars vraiment doué est capable de faire rien qu'avec des concepts.

Comme cette personne ne sera pas ( JAMAIS ) mon collègue imaginer cela reste un rêve.