Discussion :

[souviron34]

Et ne va pas dans le domaine de la finance, on y trouve encore très facilement des logiciels qui ont plus de 30 ans, en cobol notamment.

Ni dans celui des sciences, des maths, de l'aéronautique, du calcul numérique... En C ou Fortran...

Bref, ça limite

Aff oui si tu fais un site Web

[sevyc64]

Aff oui si tu fais un site Web

Même pas Il faudra tenir compte de IE6 très populaire encore et qui a plus de 10 ans

[Mr_Exal]

Je vais même plus loin en disant que la vie d'un logiciel ne doit pas dépasser 5 ans.

LA phrase à retenir pour le développement : "Tant que ça fonctionne, on n'y touche pas."

A quoi bon vouloir refaire un programme avec une technologie x ou y tant qu'il tourne comme il faut (donc dépenser inutilement de l'argent et des ressources humaines) et qu'il n'a presque pas (parce qu'aucun est impossible) de bug(s) ?

[souviron34]

Vu ce qu'il dit, il est vraisemblablement le pur produit de ce dont le thread parle

[deuz59]

Cet article reprend clairement ma conclusion suite à la lecture de l'excellent ouvrage "coder proprement" de Robert C. Martin

==> nous voulons tous faire de la qualité mais nous ne sommes pas conscients du principal critère de qualité, en partie à cause de notre formatage lors de nos études, à savoir qu'un code propre est avant tout un code lisible et maintenable

Faites l'expérience, demandez à n'importe quel développeur, surtout débutant, qu'est ce qu'un code maintenable, 9 fois sur 10 il répondra "un code commenté"...et voilà à quoi se réduit le travail de maintenabilité, forcément tout le reste en pâti.
Sûr qu'aux début de l'informatique, les commentaires à profusion étaient indispensable à la maintenabilité du code...mais avec des langages/outils modernes, y'a bcp plus efficace

Nos études devraient avant tout nous montrer que l'informatique est un moyen et nous expliquer comment l'utiliser à bon escient selon les objectifs professionnels...la frontière avec le débat sur l'étanchéité apprentissage/emploi n'est pas loin.....

[deuz59]

LA phrase à retenir pour le développement : "Tant que ça fonctionne, on n'y touche pas."

A quoi bon vouloir refaire un programme avec une technologie x ou y tant qu'il tourne comme il faut (donc dépenser inutilement de l'argent et des ressources humaines) et qu'il n'a presque pas (parce qu'aucun est impossible) de bug(s) ?

Je reste partagé sur la question :
- OUI le fait de retoucher qqchose qui fonctionne, aussi limité soit-il, induit un vrai risque d'impact sur le bon fonctionnement....trop souvent on peut regretter d'avoir fait du zèle et d'en payer les conséquences
- NON, on ne peut décemment pas, sous prétexte qu'on apporte un risque sur la production, fermer les yeux et laisser le logiciel se dégrader...plus on attend plus le jour où on devra mettre le nez dedans on se cassera les dents.Je ne parle pas forcément de migrer totalement un logiciel d'une techno à une autre, juste de penser à améliorer en même temps qu'on corrige ou qu'on fait évoluer ("laisser la place plus propre qu'on l'a trouvée').

==> Je pense que la solution reste effectivement de "retoucher" le code quand l'occasion se présente mais d'être conscient des risques et de s'en prémunir. Avoir une panoplie suffisante de tests unitaires pour valider la non régression sera ainsi un moyen de limiter les risques du refactoring plutôt que de l'éviter.

[sevyc64]

- NON, on ne peut décemment pas, sous prétexte qu'on apporte un risque sur la production, fermer les yeux et laisser le logiciel se dégrader...plus on attend plus le jour où on devra mettre le nez dedans on se cassera les dents.Je ne parle pas forcément de migrer totalement un logiciel d'une techno à une autre, juste de penser à améliorer en même temps qu'on corrige ou qu'on fait évoluer ("laisser la place plus propre qu'on l'a trouvée').

==> Je pense que la solution reste effectivement de "retoucher" le code quand l'occasion se présente mais d'être conscient des risques et de s'en prémunir. Avoir une panoplie suffisante de tests unitaires pour valider la non régression sera ainsi un moyen de limiter les risques du refactoring plutôt que de l'éviter.

Je comprend ta position de développeur consciencieux,et je la partage ... dans un monde idéal.

Malheureusement la réalité est tout autre, et cette position n'est pas compatible, ni avec le client à qui il faudra expliquer pourquoi, tout d'un coup, un bug apparait sur une fonctionnalité que l'on était pas censé touché, ni avec le service commercial, à qui il faudra expliquer pourquoi, gratuitement (puisque non prévu donc non vendable au client) on se permet de modifier, corriger, améliorer le logiciel, tuant dans l'oeuf, de fait, une possible future prestation.

Sauf à être ton propre éditeur et ton propre patron, il faut aussi savoir se refréner à ne pas aller modifier plus que ce qui est demandé. Quoiqu'il arrive, tu n'en récupèrera jamais les bénéfices sur le long terme, par contre tu peux être certains que les emmerdes occasionnées seront à ton crédit.

[deuz59]

La maintenabilité est purement subjective dans beaucoup cas car elle dépend avant tout du niveau moyen des intervenants présents et futurs.

Si nous résumons la maintenabilité à ceci:

1) "Facile" à faire évoluer
2) "Facile" à modifier
3) "Facile" à corriger

Et que l'on essaye de les appliquer sur un projet de grande taille (minimum 500k de lignes de code). Il est impossible d'appliquer les meilleures techniques pour avoir 1, 2, 3 si le niveau moyen est bas. La facilité est subjective. Dans la bouche de beaucoup de "managers", maintenable signifie surtout "peut être compris par n'importe qui".

Je résumerais la maintenabilité par "coder ce qu'on fait avant de coder comment on le fait"

Le code est ainsi lisible, pas besoin de comprendre tout le fonctionnel pour cibler la seule partie qui nous intéresse ==> le premier niveau de lecture (d'abstraction) du code doit clairement retranscrire ce qui est fait, on devrait avoir l'impression de lire les specs directement via le code et non passer notre temps à déduire ce que l'auteur à voulu faire selon comment il l'a fait, avec qui plus est tous les risques d'erreurs d'interprétation que cela comporte.
Les fonctionnalités des différents langages, méthodes de programmation, frameworks, etc.. ne doivent servir que de moyens pour parvenir à cette fin.

La cerise sur le gâteau avec une telle clarté, c'est d'inverser la tendance où les specs montrent une non conformité dans le code....la programmation étant logique, si le code est structuré d'abord selon les specs métiers, il révèlera très rapidement les "spécifications bancales" et les concepts/notions métiers à revoir où à créer pour avoir une vraie cohérence fonctionnelle

[deuz59]

Je comprend ta position de développeur consciencieux,et je la partage ... dans un monde idéal.

Malheureusement la réalité est tout autre, et cette position n'est pas compatible, ni avec le client à qui il faudra expliquer pourquoi, tout d'un coup, un bug apparait sur une fonctionnalité que l'on était pas censé touché, ni avec le service commercial, à qui il faudra expliquer pourquoi, gratuitement (puisque non prévu donc non vendable au client) on se permet de modifier, corriger, améliorer le logiciel, tuant dans l'oeuf, de fait, une possible future prestation.

Sauf à être ton propre éditeur et ton propre patron, il faut aussi savoir se refréner à ne pas aller modifier plus que ce qui est demandé. Quoiqu'il arrive, tu n'en récupèrera jamais les bénéfices sur le long terme, par contre tu peux être certains que les emmerdes occasionnées seront à ton crédit.

On est bien d'accord, il y a la réalité "business".
Grande frustration que de te dire qu'y aura toujours un concurrent qui n'hésitera pas à faire plus crade pour être moins cher et donc capter ton client qui n'est souvent d'abord que dans une logique financière.

Ceci dit la maintenance a un coût, il est possible d'y sensibiliser son client et celui-ci peut très bien comprendre son intérêt à ce que tu fasses en sorte d'améliorer constamment son code.
Un code maintenable et propre facilitera/réduira les correctifs : recentrage sur la valeur ajoutée
Un code maintenable facilitera les évolution : maîtrise des budgets d'évolution (si t'achètes une voiture pas cher mais qu'ensuite tu dois faire souvent des révisions qui sont de plus en plus chères, pas sûr que tu reprennes la même marque en changeant de voiture, même si tu dois mettre un peu plus cher à la base)

Il ne faut juste pas tomber dans l'extrêmisme inverse... d'où la nécessité des tests unitaires, de la non régression etc...et tu améliores au fil de l'eau le code que tu es déjà amené à toucher un minimum pour les évolutions/maintenances donc tu dois déjà assurer une NON REG dessus.

[Invité]

En lisant le lien joint au premier post, j'y ai trouvé ces statistiques. Eh ben ! En 2020 on aura 67% des développements qui porteront sur de la maintenance.

En lisant le présent thread, je vois que certains sous-entendent à peu près que toute maintenance sur une application signifie qu'il faut tout refaire. Ce n'est pas le cas. je le redis il faut savoir qu'il y a une maintenance dite évolutive (ajout d'une nouvelle fonctionnalité mais que cela peut être difficile à mettre en place du fait certaines applications ont une architecture qui n'est conforme à aucune norme, aucun standard etc)

Ce qu'il faut savoir : Tout choix sur la technologique ou sur la technique ou sur la manière de coder effectué la veille peut être renier demain. Donc le fait de dire qu'on doit tout changer et tout refaire parce qu'aujourd'hui nous avons des technos qui nous permettent de le faire facilement, rapidement et avec un gain de performance c'est ne pas penser que demain que le choix technique fait aujourd'hui deviendrait un jour caduque voilà. Prendre du recul n'a jamais fait du mal Les applications legacy étaient à leur apogée au moment de leur conception et votre application sera à moyen ou long terme dans cette catégorie

[souviron34]

Ce qu'il faut savoir : Tout choix sur la technologique ou sur la technique ou sur la manière de coder effectué la veille peut être renier demain. Donc le fait de dire qu'on doit tout changer et tout refaire parce qu'aujourd'hui nous avons des technos qui nous permettent de le faire facilement, rapidement et avec un gain de performance c'est ne pas penser que demain que le choix technique fait aujourd'hui deviendrait un jour caduque voilà. Prendre du recul n'a jamais fait du mal Les applications legacy étaient à leur apogée au moment de leur conception et votre application sera à moyen ou long terme dans cette catégorie

Très bon paragraphe


Note: c'est un peu ce que voulais dire mon post page précédente : l'idée (reçue et fortement répandue depuis une 10aine d'années) que les technos/langages/méthodos d'aujourd'hui relègiuent aux oubliettes ce qui s'est fait avant est d'une telle absurdité (et présomption quant à la pérennité des choix d'aujourd'hui), qu'un peu d'humilité serait bonne à enseigner...

[Mr_Exal]

Je reste partagé sur la question :
- OUI le fait de retoucher qqchose qui fonctionne, aussi limité soit-il, induit un vrai risque d'impact sur le bon fonctionnement....trop souvent on peut regretter d'avoir fait du zèle et d'en payer les conséquences
- NON, on ne peut décemment pas, sous prétexte qu'on apporte un risque sur la production, fermer les yeux et laisser le logiciel se dégrader...plus on attend plus le jour où on devra mettre le nez dedans on se cassera les dents.Je ne parle pas forcément de migrer totalement un logiciel d'une techno à une autre, juste de penser à améliorer en même temps qu'on corrige ou qu'on fait évoluer ("laisser la place plus propre qu'on l'a trouvée').

==> Je pense que la solution reste effectivement de "retoucher" le code quand l'occasion se présente mais d'être conscient des risques et de s'en prémunir. Avoir une panoplie suffisante de tests unitaires pour valider la non régression sera ainsi un moyen de limiter les risques du refactoring plutôt que de l'éviter.

Bien entendu qu'il faut retoucher le code de temps en temps afin d'apporter des améliorations, mais pas de là à migrer de technologie, comme tu le dis.

Le fait de se prémunir des erreurs pouvant arriver fait aussi partie du métier.

[arkhamon]

Je cite :

"LA phrase à retenir pour le développement : "Tant que ça fonctionne, on n'y touche pas.".

J'ai mieux : LA phrase de l'informatique ! (a part sur le MAC où il faut faire toutes les mises à jour... ).
De façon plus générale, certaines applis tournent depuis 30 ans, elle tournent bien et font parfaitement ce pour quoi elles ont été faites. Pourquoi les changer ? Pour la sacro-sainte avancée technologique ?

Dans le fond maintenant. Il existe deux types de maintenances : la préventive et la curative.
La première est normalement prévue dans le dossier de l'application : ca concerne principalement des études de volumes, de performances... bref tout ce qui est nécessaire pour que les performances de l'application ne se dégradent pas de façon incontrôlée. C'est ce qu'on fait quand on apporte sa voiture chez le garagiste poru la visite d'entretien. Il n'est pas question de remplacer une pièce parce que ça tourne mal, il est question de faire la vidange, et peut être de changer la courroie PARCE QUE la notice dit qu'il faut la changer tous les 100 000 KM...
Donc ici, point n'est besoin de descendre dans le code : on ne démonte pas le moteur, on remplace juste le joint de carter et on change l'huile...

La seconde (curative) concerne la correction des bugs, et la réparation des pannes. Je rappelle la définition d'une panne : le passage d'un état opérationnel à un état non-opérationnel. Je rappelle la définition d'un "état opérationnel" : c'est le fait pour un dispositif de fournir un service dans les limites de ce qui a été défini comme acceptable par le client".
Donc une appli qui plante tous les jours pendant 1 heure, mais qui a été conçu avec un engagement de service de 80% est parfaitement opérationnelle... Fallait juste faire attention avant de signer le contrat.

Donc je reprends. Maintenance curative : régler les pannes (dysfonctionnement d'un système) et corriger les bugs. Notez bien cette petite mais intéressante distinction que je fais entre "panne" et "bug" : une panne est par définition accidentelle. Le bug lui relève d'une erreur de conception (quelle que soit son étape dans le processus de création) et n'est donc pas une panne : c'est une réaction PARFAITEMENT PROGRAMMEE et donc PARFAITEMENT PREVISIBLE ! Même si le programmene semble pas si parfait que ça...
Donc pour régler une panne, point n'est besoin de descendre dans le code et de débugger, puisque par définition le problème ne se situe pas là...
Et pour les bugs, je vais être un peu méchant, mais quand un code est conçu dans les règles de l'art (encapsulation, séparation des codes, unicité de fonction, visibilité des infos...), ben normalement il ne devrait plus rester que les erreurs de conception. Et si les phases de tests sont conduites avec diligence, sincérité et professionnalisme, ben devrait plus y avoir de bugs du tout.
Je vous rassure, je suis un programmeur, et mes applis ont des bugs. Mais je sais presque toujours d'pù ils viennent : le non-respect des règles d'or, la légèreté des tests, et le "bon toutes façon c'est pas bien grave, ca arrive presque jamais...".

Et il est vrai aussi que ce que je dis, c'est un peu le monde merveilleux de Mickey... Ou des bisounours. Je ne prends pas en compte les pultiples paramètres que sont le budget, le calendrier, les bulk-code, les managers incompétents, les directions autistes, les "afficionados" de l'informatique, les "amateurs éclairés" et j'en passe et des meilleurs qui ne semblent avoir été inventés que pour pourrir la vie des vrais informaticiens...

Mais ceci est un autre débat...

[Abdellah2010]

Personnellement je cherche pas à maintenir les applications des autres, j'ai ma propre méthode de la conception jusqu'à le déploiement.

[deuz59]

Je cite :

"LA phrase à retenir pour le développement : "Tant que ça fonctionne, on n'y touche pas.".

J'ai mieux : LA phrase de l'informatique ! (a part sur le MAC où il faut faire toutes les mises à jour... ).
De façon plus générale, certaines applis tournent depuis 30 ans, elle tournent bien et font parfaitement ce pour quoi elles ont été faites. Pourquoi les changer ? Pour la sacro-sainte avancée technologique ?

Dans le fond maintenant. Il existe deux types de maintenances : la préventive et la curative.
La première est normalement prévue dans le dossier de l'application : ca concerne principalement des études de volumes, de performances... bref tout ce qui est nécessaire pour que les performances de l'application ne se dégradent pas de façon incontrôlée. C'est ce qu'on fait quand on apporte sa voiture chez le garagiste poru la visite d'entretien. Il n'est pas question de remplacer une pièce parce que ça tourne mal, il est question de faire la vidange, et peut être de changer la courroie PARCE QUE la notice dit qu'il faut la changer tous les 100 000 KM...
Donc ici, point n'est besoin de descendre dans le code : on ne démonte pas le moteur, on remplace juste le joint de carter et on change l'huile...

La seconde (curative) concerne la correction des bugs, et la réparation des pannes. Je rappelle la définition d'une panne : le passage d'un état opérationnel à un état non-opérationnel. Je rappelle la définition d'un "état opérationnel" : c'est le fait pour un dispositif de fournir un service dans les limites de ce qui a été défini comme acceptable par le client".
Donc une appli qui plante tous les jours pendant 1 heure, mais qui a été conçu avec un engagement de service de 80% est parfaitement opérationnelle... Fallait juste faire attention avant de signer le contrat.

Donc je reprends. Maintenance curative : régler les pannes (dysfonctionnement d'un système) et corriger les bugs. Notez bien cette petite mais intéressante distinction que je fais entre "panne" et "bug" : une panne est par définition accidentelle. Le bug lui relève d'une erreur de conception (quelle que soit son étape dans le processus de création) et n'est donc pas une panne : c'est une réaction PARFAITEMENT PROGRAMMEE et donc PARFAITEMENT PREVISIBLE ! Même si le programmene semble pas si parfait que ça...
Donc pour régler une panne, point n'est besoin de descendre dans le code et de débugger, puisque par définition le problème ne se situe pas là...
Et pour les bugs, je vais être un peu méchant, mais quand un code est conçu dans les règles de l'art (encapsulation, séparation des codes, unicité de fonction, visibilité des infos...), ben normalement il ne devrait plus rester que les erreurs de conception. Et si les phases de tests sont conduites avec diligence, sincérité et professionnalisme, ben devrait plus y avoir de bugs du tout.
Je vous rassure, je suis un programmeur, et mes applis ont des bugs. Mais je sais presque toujours d'pù ils viennent : le non-respect des règles d'or, la légèreté des tests, et le "bon toutes façon c'est pas bien grave, ca arrive presque jamais...".

Et il est vrai aussi que ce que je dis, c'est un peu le monde merveilleux de Mickey... Ou des bisounours. Je ne prends pas en compte les pultiples paramètres que sont le budget, le calendrier, les bulk-code, les managers incompétents, les directions autistes, les "afficionados" de l'informatique, les "amateurs éclairés" et j'en passe et des meilleurs qui ne semblent avoir été inventés que pour pourrir la vie des vrais informaticiens...

Mais ceci est un autre débat...

En fait on parle pas tjrs de la meme chose
- OK que c'est ridicule de changer de refondre une appli uniquement pour utiliser la dernière techno alors qu'elle est opérationnelle en l'état
- Juste sur la partie maintenabilité de code : dans ce cas oui, on se doit de toujours chercher à améliorer le code sur lequel on intervient et non juste poser son correctif ou son évolution

[mattj]

Tout d'abord je précise que j'appelle dans ce message "maintenance" le fait de modifier le code d'une application après release, afin de corriger des bugs et de modifier ou ajouter des fonctionnalités.

Et pour les bugs, je vais être un peu méchant, mais quand un code est conçu dans les règles de l'art (encapsulation, séparation des codes, unicité de fonction, visibilité des infos...), ben normalement il ne devrait plus rester que les erreurs de conception. Et si les phases de tests sont conduites avec diligence, sincérité et professionnalisme, ben devrait plus y avoir de bugs du tout.

C'est justement l'enjeu de cette discussion! En fait pour moi il y a deux aspects dans ce que j'appellerais 'l'enseignement de la maintenabilité":

• maintenir du code existant
  J'aime en particulier l'idée de h2s84 :
  

  Dans ce cas, je préfère plutôt que le projet parte d'une application sans architecture codée par le professeur lui-même en y insérant tous les anti-patterns connus. Après dire aux étudiants de les détecter et de les corriger. Voilà c'est ça la réalité sur le terrain. La plupart des applications mal faites sont sûrement codées par des débutants. Connaitre les bonnes pratiques en partant d'une application pourrie est une bonne idée

• créer du code maintenable
  L'aspect principal à mon avis : dès qu'un projet est mis en production il passe par définition dans la catégorie des projets en maintenance (vlegaci.com, cité plus haut, semble du même avis). La plupart des projets "réussis" passent donc plus de temps en maintenance qu'en développement. C'est pourtant la phase de développement qui conditionne la complexité de la phase de maintenance, et donc le coût final.
  Dans une assez célèbre interview de David Parnas, celui-ci déclare:
  

  Q What is the most often-overlooked risk in software engineering?
  R Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

  Je pense que cela s'applique parfaitement à notre discussion, même si mon propos n'est pas de chercher à identifier les bons programmeurs (légèrement arrogant quand même), mais plutôt de mettre en évidence des lacunes dans les formations, en particulier sur le plan de la maintenabilité du code. Je ne sais pas si un mauvais développeur peut vraiment créer deux emplois, mais il peut coûter extrêmement cher en temps et en argent. En fait je ne pense pas qu'il faille parler de mauvais développeur mais plutôt de mauvaises pratiques. Un bon développeur, à la réflexion et l'analyse aiguisés, capable de se former rapidement à n'importe quelle technologie, ayant le souci du détail, etc., mais appliquant de mauvaises méthodes produira un code difficile à maintenir comme tout le monde...d'où le problème.

Il y a déjà eu quelques éléments de réponse, mais pensez-vous que le problème soit franco-français?

[deuz59]

Un bon développeur, à la réflexion et l'analyse aiguisés, capable de se former rapidement à n'importe quelle technologie, ayant le souci du détail, etc., mais appliquant de mauvaises méthodes produira un code difficile à maintenir comme tout le monde...d'où le problème.[/LIST]

Du coup c'est pas un bon développeur...le pb c'est justement la définition d'un bon développeur.
Dans un domaine aussi vaste et changeant que l'informatique, difficile de déterminer les bons critères...et combien même on fini par s'en faire une bonne idée, qu'ils sont obsolètes !!!
Si on en revient à la formation, les profs d'aujourd'hui sont des geeks d'hier où l'informatique n'était pas la même, ils apportent donc de bonnes réponses mais aux mauvaises questions....ajouté à cela la méconnaissance des terrains (certaines formations généralistes peuvent aboutir à des emplois bien différents, informatique industrielle, de service...), je me demande si ce n'est pas un espoir bien trop utopique que d'avoir des débutants suffisamment sensibilisés à la maintenance.....

Il y a déjà eu quelques éléments de réponse, mais pensez-vous que le problème soit franco-français?

A priori non au regard de la citation de David Parnas que tu soulignes

[souviron34]

Je pense que cela s'applique parfaitement à notre discussion, même si mon propos n'est pas de chercher à identifier les bons programmeurs (légèrement arrogant quand même)
...
En fait je ne pense pas qu'il faille parler de mauvais développeur mais plutôt de mauvaises pratiques.

En un sens, si...

Bien entendu, les mauvaises pratiques (et les "bonnes" appliquées sans savoir le pourquoi du comment, simplement parce qu'il "faut" le faire)sont un élément...

Bien entendu également la plupart des profs ne sont jamais passs dans la réalité d'un gros dev d'un gros projet au sein d'une grosse équipe, et n'ont le plus souvent que des connaissance théoriques..

Mais aussi, le phénomène est non-négligeable, que ce soit l'engouement (personnel, via jeux et "passion" de jeune, ou de la société en général pour le domaine), que ce soit l'incompétence des recruteurs (qui ne savent la plupart du temps du temps de quoi ils parlent et se font avoir par les derniers buzz-words marketing), que ce soit le règne de l'enfant-roi qui fait dre aux parents "mon gosse est un petit génie", que ce soit enfin les formations qui prônent que l'informatique est un domaine d'avenir, sans préciser que c'est un domaine de création et intellectuel, tout cela crée des "mauvais" programmeurs, dans le sens où ils savent coder en utilisant ce qu'on a leur donné, mais ce ne sont pas des "intellectuels" et des "créateurs"... On les forme pour être des "ouvriers à la chaîne", avec l'illusion qu'ils sont des bons, et des créatifs...

Or le métier est basé là-dessus...

La formation et le développement "de masse" du métier fait que forcément la proportion de "mauvais" dans ce sens-là, c'est à dire simplement de personnes qui n'ont pas forcément les outils/bagages pour effectuer un travail de création intelligemment, augmente..

Et, comme je disais, cette illusion est propagée par la formation et l'enseignement... (ne serait-ce que les formations pour avoir un diplôme de CP )

L'illusion rousseauiste que "l'homme est bon" s'est propagée depuis le milieu des années 80 comme étant "tout le monde peut être intellectuel et créatif"...

Ce qui est bien évidemment faux..

Il y a donc effectivement des "bons" et des "mauvais", comme partout.. L'informatique n'est pas un domaine à part... où il n'y aurait que des "bons".. dont certains ne seraient pas découverts...

[deuz59]

Je partage cette excellente analyse.

Bien que la formation ait une responsabilité prépondérante pour rendre opérationnel les futurs informaticiens, chacun a ses propres limites et on ne peut espérer de tous les débutants qu'ils soient aussi bon qu'on le souhaiterait.

Juste que les bons devraient se révéler plus vite et ne pas (trop) découvrir quelles sont les bonnes questions à se poser pour produire de la qualité. C'est un des rôles mal incarné des formations que d'anticiper les "erreurs pédagogiques" qui se retrouvent finalement faites en entreprise avec les coûts que cela implique mais pour toutes les raisons évoquées précédemment, elles n'y parviennent malheureusement que très rarement.

Cela m'amène une réflexion sur les grilles de salaires à l'embauche.
Plutôt que de fixer arbitrairement les salaires selon la réputation de tel ou tel établissement, il serait plus pertinent de mettre en place des indicateurs (baser sur la revue par les pairs par exemple, ne s'agissant pas d'évaluer la maîtrise des langages/outils mais davantage la démarche, les 'bons réflexes') permettant de déterminer quel établissement prépare le mieux à la réalité des métiers du développement logiciel et de réajuster les salaires en fonction (il est normal qu'un ingénieur qui coûtera moins à l'entreprise pour "finir de se former" soit payer davantage à l'embauche....)

[arkhamon]

Je suis un peu plus modéré que deuz59.
Le recrutement est une chose très complexe et très risquée, qu'il faut faire soit à l'impro, soit avec une batterie de tests de la mort qui tue...
Je ne suis pas sur qu'on puisse repérer un "bon" informaticien avec un ou plusieurs entretiens. Un mauvais programme ne se révèle parfois que plusieurs mois ou années après la mise en prod. C'est en général pile poile après que le "fameux" consultant ait quitté la boite pour une autre mission.

Embaucher, c'est investir. Pourquoi alors vouloir immédiatement une rentabilité ? L'entreprise ne devrait-elle pas plutôt passer un moment à intégrer l'informaticien dans son schéma global plutôt que de lui demander d'être totalement opérationnel immédiatement ? Ne pourrait-elle consacrer un peu de temps à le former opur qu'il fournisse exactement ce qu'on attend de lui ? Ne pourrait-elle le laisser travailler correctement et lui faire confiance au lieu de lui imposer des délais impossibles ? Car de cette manie moderne de "faire vite" avec moins on arrive à des situations catastrophiques.
Je reprends l'esprit d'un post que j'ai fait il y a quelques semaines : est-il raisonnable pour un non-informticien de critiquer voire imposer des choix à un informaticien ?
Mais il est vrai que tellement de personnes s'auto-proclament que je comprends que certains managers ne leurs fassent plus confiance. Et cela nuit aux bon informateux (car il y en a et beaucoup) et ça finit par ruiner le métier...

Du coup je me pose la question suivante :

Programmer c'est quoi ?

• C'est connaître un langage suffisament pour développer, pas nécessairement pour écrire une thèse dessus. Je m'explique : si pour développer des classes de composants pour DElphi, il est préférable de bien maitriser les concepts pointus de POO. Par contre poru uen simple application de gestion est-ce nécessaire ?
• c'est savoir conceptualiser une fonctionnalité afin de la retranscrire en algorithme

Ce sont à mon avis les deux choses qu'on devrait attendre d'un analyste-programmeur.

Et ma question : de quoi a-t-on besoin pour programmer ? est-il raisonnable de d'attendre d'un programmeur qu'il connaisse 5 langages différents, avec pour chacun des diversités importantes ? N'est-ce pas générateur de risques pour l'entreprise ?

D'où ma conclusion (oui je sais je me disperse souvent...) : un bon programmeur, c'est avant tout une personne qui a eu une bonne formation.
S'il était possible en début de siècle d'être raisonnablement un "bon polytechnicien", cela n'est plus vrai maintenant. Le polytechnicien d'avant était capable de concevoir un avion qui vole en entier, car il avait les connaissances dans tous les domaines.
Maintenant, aucune personne n'est "bonne" dans autant de domaines, c'est trop complexe. Pareil pour l'informatique : il y a tant de domaines qu'il est totallement illusoire de se prétendre bon dans plus de quelques domaines. Et la programmation (un domaine par langage) n'est pas différente : je pense qu'on peut maîtriser un voire 2 langage, en connaitre 2 ou 3 autres et avoir des notions dans 2 autres mais c'est le maximum. Plus ? On est affabulateur ou alors le pur génie de la création.

On souffre en France de ne former que des ingénieurs et des personnes non spécialisés, au détriment de personnes très spécialisées, et donc très performantes. Tout le monde veut être bon partout, c'est un erreur.
Et à ceux qui me parleront du Cobol qui n'est plus utilisé, je répondrai que à tout âge on peut apprendre, et qu'un excellent spécialiste en Cobol deviendra en quelques années un excellent spécialiste en C++ ou en Delphi.

Et par pitié chers amis et collègues informaticiens, sachez être humble : quand on maîtrise pas, on maîtrise pas. Le manque d'expertise finit toujours par triompher des convictions, aussi fortes fussent-elles. Savoir reconnaître ses limites, c'est se donner la possibilité de les dépasser, et donc de progresser.