Discussion :

[ayoubf]

Java c'est bien, un langage très utilisé et très matures ; nous construisons de grandes, très grandes architectures avec Java, et sa version destinée aux entreprises "JavaEE".
Ceci étant, il ne faut surtout pas se fermer aux autres technologies, car pour faire de la programmation système, Java peut faire des choses mais pas tout, il ne peut pas accéder aux ressources systèmes comme le langage C par exemple, et ne peut avoir des exécutions plus rapides.

Donc à mon sens, c'est un faux débat car le problème est dans les développeurs qui ne maîtrisent pas (ou pas assez) les principes de base, car au final ce sont les mêmes, le langage au final n'est rien qu'un outil, une syntaxe

Les spécificités d'un langage à un autre sont assez limitées, de plus, il n'est pas nécessaire de connaitre TOUS les aspects d'un langage pour s'acclamer expert dans ce langage, bien au contraire, et cela est une ancienne réflexion de "Douglas Crockford", l'un des gouroux du javascript.

[Jitou]

En 15 ans de carrière j'en ai vu des archi ou des développeurs "Geek" se servir de l'opportunité des projets pour expérimenter leurs nouvelles connaissances sur telle ou telle techno à la mode du moment. Le pb c'est l'après projet où le développeur part sur une autre mission ou pire démissionne et qu'il n'est donc plus joignable, on se retrouve alors avec du code dans une technologie parfaitement inconnue de la nouvelle équipe en place que l'on ne choisi pas toujours avec le turnover qui sévit au sein des SSII. Aussi en y regardant de plus près on trouve du code en réalité mal maîtrisé impossible à maintenir, c'est "expérimental" je le rappel ! Le client lui ne comprenant rien aux technos mis en oeuvre dans son projet trouve inadmissible que l'on arrive pas à maintenir son projet dans des coûts maîtrisés et il a parfaitement raison.

Donc je suis également très réservé sur la nécessité de connaitre une pléthore de langages, nos clients ne nous confie pas des projets de travaux pratique de lycée ! La solution informatique que le client utilise tous les jours et lui permet de gagner de l'argent et doit être traité avec la plus grande attention et surtout professionnalisme.

[TiranusKBX]

En 15 ans de carrière j'en ai vu des archi ou des développeurs "Geek" se servir de l'opportunité des projets pour expérimenter leurs nouvelles connaissances sur telle ou telle techno à la mode du moment. Le pb c'est l'après projet où le développeur part sur une autre mission ou pire démissionne et qu'il n'est donc plus joignable, on se retrouve alors avec du code dans une technologie parfaitement inconnue de la nouvelle équipe en place que l'on ne choisi pas toujours avec le turnover qui sévit au sein des SSII. Aussi en y regardant de plus près on trouve du code en réalité mal maîtrisé impossible à maintenir, c'est "expérimental" je le rappel ! Le client lui ne comprenant rien aux technos mis en oeuvre dans son projet trouve inadmissible que l'on arrive pas à maintenir son projet dans des coûts maîtrisés et il a parfaitement raison.

Donc je suis également très réservé sur la nécessité de connaitre une pléthore de langages, nos clients ne nous confie pas des projets de travaux pratique de lycée ! La solution informatique que le client utilise tous les jours et lui permet de gagner de l'argent et doit être traité avec la plus grande attention et surtout professionnalisme.

la vous parlez du cas extrême ou le programmeur est un aventurier qui adore les gamelles
Déjà commencer un projet sur une techno que l'on maîtrise pas ou à peine c'est suicidaire

[nnovic]

En 15 ans de carrière j'en ai vu des archi ou des développeurs "Geek" se servir de l'opportunité des projets pour expérimenter leurs nouvelles connaissances sur telle ou telle techno à la mode du moment. Le pb c'est l'après projet où le développeur part sur une autre mission ou pire démissionne et qu'il n'est donc plus joignable, on se retrouve alors avec du code dans une technologie parfaitement inconnue de la nouvelle équipe en place que l'on ne choisi pas toujours avec le turnover qui sévit au sein des SSII. Aussi en y regardant de plus près on trouve du code en réalité mal maîtrisé impossible à maintenir, c'est "expérimental" je le rappel ! Le client lui ne comprenant rien aux technos mis en oeuvre dans son projet trouve inadmissible que l'on arrive pas à maintenir son projet dans des coûts maîtrisés et il a parfaitement raison.

Donc je suis également très réservé sur la nécessité de connaitre une pléthore de langages, nos clients ne nous confie pas des projets de travaux pratique de lycée ! La solution informatique que le client utilise tous les jours et lui permet de gagner de l'argent et doit être traité avec la plus grande attention et surtout professionnalisme.

Dans ce cas de figure, j'ai tendance à penser que la faute repose sur les épaules des donneurs d'ordre. S'ils ne posent pas de contrainte sur les choix techniques, c'est leur problème.

[Laurent 1973]

En 15 ans de carrière j'en ai vu des archi ou des développeurs "Geek" se servir de l'opportunité des projets pour expérimenter leurs nouvelles connaissances sur telle ou telle techno à la mode du moment. Le pb c'est l'après projet où le développeur part sur une autre mission ou pire démissionne et qu'il n'est donc plus joignable, on se retrouve alors avec du code dans une technologie parfaitement inconnue de la nouvelle équipe en place que l'on ne choisi pas toujours avec le turnover qui sévit au sein des SSII. Aussi en y regardant de plus près on trouve du code en réalité mal maîtrisé impossible à maintenir, c'est "expérimental" je le rappel ! Le client lui ne comprenant rien aux technos mis en oeuvre dans son projet trouve inadmissible que l'on arrive pas à maintenir son projet dans des coûts maîtrisés et il a parfaitement raison.

Donc je suis également très réservé sur la nécessité de connaitre une pléthore de langages, nos clients ne nous confie pas des projets de travaux pratique de lycée ! La solution informatique que le client utilise tous les jours et lui permet de gagner de l'argent et doit être traité avec la plus grande attention et surtout professionnalisme.

Je dirais meme, que c'est un cas où le manager de ce développeur n'a pas sur le guider pour ne pas courir après 2 lièvres en même temps:

1. Réaliser un projet pour un client avec des besoins et exigence précise
2. Se former sur une nouvelle technologie

Une prestation SSII va proposer essentiellement le point 1: le but est de répondre au client
Le point 2 devrait être proposer par la SSII au développeur lors de ses inter-contrats: c'est un moment idéal pour se former à de nouvelles technologies.

Par contre, faudrait que les SSII aient une vrai politique de formation de ses consultants.
Or, cela a un coût et de toute façon, les développeurs restent pas longtemps: bah il se formeront chez le client en développant le projet !

Et la boucle est bouclé

[tanatiel]

Par contre, faudrait que les SSII aient une vrai politique de formation de ses consultants.
Or, cela a un coût et de toute façon, les développeurs restent pas longtemps: bah il se formeront chez le client en développant le projet !

Et la boucle est bouclé

C'est tellement vrai. La seule vraie formation que j'ai eu dans ma carrière remonte à 15 ans, depuis j'ai toujours eu droit au fameux "pas de formation sans projet"

Alors oui, rien ne vaut la pratique mais tout de même, les SSII sont dans l'extrême pour la plupart. Et j'ai vu plus d'un projet lancé en mode rock'n roll et que c'est au bout de 3 moi de dèv fait par des juniors qu'on se rend compte qu'on a des problèmes de techno non maîtrisée. Parce que connaître un langage ce n'est pas connaître les différents frameworks qui ont été développés dessus, par exemple.

[kdmbella]

J'aimerai bien qu'on m'explique comment faire du développement web en ne maîtrisant qu'un seul langage sauf si on part du principe que par "langage" on entend langage serveur ...
Par ailleurs , dans un environnement aussi versatile que le développement et où parfois le langage à utiliser dépend de l'écosystème du client je voudrais bien voir comment un développeur viendra imposer à une entreprise cliente ayant un SI structurer autour d'un langage bien définit, le langage qu'il maîtrise le mieux !

[RyzenOC]

Après les langages informatiques se ressemble tous, ils ont tous (sauf 1 ou 2 exception) les même structures (tableau, entier...) et même condition (si, pour, tant que...), seul la mise en forme change.

Reste ensuite a connaitre les subtilités des langages.

[Laurent 1973]

je voudrais bien voir comment un développeur viendra imposer à une entreprise cliente ayant un SI structurer autour d'un langage bien définit, le langage qu'il maîtrise le mieux !

Le problème viens plutôt de la relation client-prestataire d'avant vente.

Si le client dit: "je veux et j'exige que mon application soit fait en Fortran 77", c'est son choix.
Là, le prestataire devra alors trouver une équipe de développement spécialiste en Fortran 77 s'il veut emporter le marché - le client accepte aussi de ne pas avoir trop le choix de l'équipe et donc du prix.

Mais si le client dit "je veux la meilleur solution au moindre coût pour mon application".
Là, le prestataire fera une proposition technologique en fonction des compétences de son équipe disponible afin de rentrer dans le budget du client - et la concurrence peut être plus féroce.

Et puis, il peux y avoir des nuances entre ces deux situations, avec une négociation technologique entre le SI du client et les développeurs.

Mais c'est sur que si les deux, client et prestataire, ne sont pas d'accord sur la technologie choisi, on va au crash.

[Cincinnatus]

Tout d'abord, le titre de l'article est trompeur, puisque ce n'est pas le fait de connaître (jusqu'à maîtriser) plusieurs langages qui est jugé négativementp par Sam Atkinson, mais le fait d'apprendre de nouveaux lanagages en cours de projet (en contradiction avec l'affirmation précédente ("cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question »").
Par contre, je suis en accord avec lui pour penser que cela permet d'avoir différentes approches de la programmation, qui peuvent se transposer d'un langage à l'autre. La programmation fonctionnelle est apparue dans Java mais était connue depuis longtemps grâce à de nombreux autres langages (comme Javascript, parmi les plus connus, ou Groovy et Scala sur JVM).
Concrétement, nous apprenons tout au long d'un projet (sinon on n'aurait même pas besoin de cycle en V (pourquoi valider si on sait qu'on a bien fait ce qu'il fallait)) ; les méthodes agiles et le Lean n'auraient jamais existé... alors qu'elles mettent justement l'accent sur la découverte, des besoins du client bien sûr, mais en l'occurence des techniques logicielles (les spikes de XP).

Concernant Bugayenko, ok, les développeurs font partie des ressources d'un projet logiciel. Mais une partie intelligente, qui évolue en cours de projet. Et comme tout projet est sujet à des changements, définir toutes les ressources à l'initiation du projet est totalement illusoire, sauf à se cantonner à des domaines très restreints et répétitifs... Il n'y a plus alors qu'à utiliser des usines logicielles en lieu et place des développeurs humains. Bonne chance pour ce type de projet, mais très peu pour moi.

[vosaray]

Impressionnant ... de bêtise ... de la part de qqn qui travaille pour un établissement bancaire , ou la créativité est en général externalisée cela ne m’étonne pas vraiment.

[psclcnrd]

Pas du tout d'accord.

Quand on bosse dans certains domaines, et que l'on reste cantonné dans des applis JAVA, peut être.
Mais dans mon domaine,les SIG, il faut connaitre le python, le C#, le PL/SQL, HTML, et pour certaines liaisons avec des base, PHP (voir un peu de Perl pour des imports particuliers).

Je pense que si l'on est pas ouvert sur d'autres technologies, on s'enferme dans le langage dans lequel on bosse, et on est moins réceptif et imaginatif aux problèmes du client.
Du coup, pour apprendre d'autres langages, on est moins rapidement productif, et effectivement, cela à un coup au niveau du projet.

[stendhal666]

Je voulais intervenir dans ce fil de discussion, mais comme ma réponse s'allongeait, s'allongeait... j'en ai fait un billet de blog.

[nnovic]

Billet intéressant. Pour info, le "pointy hairy boss" (chef avec les cheveux pointus) est un des personnages principaux de Dilbert.

[stendhal666]

Billet intéressant. Pour info, le "pointy hairy boss" (chef avec les cheveux pointus) est un des personnages principaux de Dilbert.

Aaaah! C'était vraiment mystérieux pour moi... Merci!

[stendhal666]

C'est merveilleux Dilbert!
Merci vraiment de m'avoir fait connaître!

[Saverok]

Je pense que si l'on est pas ouvert sur d'autres technologies, on s'enferme dans le langage dans lequel on bosse, et on est moins réceptif et imaginatif aux problèmes du client.

En quoi les choix technologiques sont un frein aux réflexions métier ?

Je dirai même que c'est l'inverse.
Si tu es à l'aise avec ta techno car tu la maîtrise à fond, ça te libère du temps pour t’intéresser aux problèmes de fond du métier car tu passes moins de temps sur des problématiques purement techniques (donc le client se contrefout royalement)

Le temps que tu passes à maîtriser une nouvelle techno et/ou à résoudre des problèmes techniques, c'est du temps que tu ne peux pas passer à réfléchir aux besoins et problématiques de tes utilisateurs.

[JCB001]

J'ai lu l'article de Bugayenko, c'est intéressant en particulier quand il relate que chaque bug trouvé est récompensé financièrement... c'est une excellente motivation.
Par contre quand il dit que le travail n'est pas une école... oui... mais il faut quand même se former... il ne s'agit pas de passer d'un extrême à l'autre.
En effet les technologies bougent, il est souvent dans l'intérêt d'un projet d'utiliser des nouveaux outils, on ne peut pas changer une équipe comme si les salariés étaient de simple outils comme des marteaux et des tournevis...
Il y a quelques années je suis arrivé sur un projet java ancien où aucun test unitaire n'existait, chaque MEP était truffée de bugs.
Alors on a mis en place JUNIT, je m'y suis frotté, j'ai appris les bases rapidement, cela a demandé plusieurs heures initialement puis d'autres heures pour avoir une architecture à peu près propre.
Cela a permis d'avoir un produit de meilleure qualité.
On aurait pu embaucher temporairement un développeur connaissant JUNIT mais cela aurait couté plus cher (rien que de sélectionner un candidat, faire passer des entretiens c'est des heures, lui fournir un nouveau PC, lui expliquer l'architecture du projet... ) pour un outil relativement simple et dans tous les cas il faut faire un transfert de connaissance avec les autres membres de l'équipe et donc les former....


Autre exemple : changement de version d'un langage, comment Bugayenko fait si le nouveau langage apporte des plus réels ? il change toute l'équipe avec toute sa connaissance acquise depuis des mois sur l'entreprise, le projets parce qu'il vaut mieux travailler sur java 8 que java 7 et que personne sur place ne connait java 8 ? c'est ridicule (attention je ne dis pas qu'on change de version à la légère non plus, encore moins au milieu d'un projet).

Un bon marteau n'importe quel magasin de bricolage en a en stock, un ingénieur avec les bonnes compétences c'est différent... et on ne remplace pas un ingénieur comme on remplace un marteau... un marteau n'a ni connaissance ni expérience, un développeur oui.

[Laurent 1973]

J'ai lu l'article de Bugayenko, c'est intéressant en particulier quand il relate que chaque bug trouvé est récompensé financièrement... c'est une excellente motivation.

Oula, très pervesif comme pratique.
Enfin, heureusement, aucun développeur ne va s’amuser à rajouter exprès des bug afin de se toucher une prime pour corriger sa "boulette"

En dehors de l'agissement "frauduleux", cela peux avoir une tendance faire changer dans le mauvais sens l’intérêt des développeur pour le produit.
"A non, je n'ai pas ajouter la nouvelle fonctionnalité que l'on devait livrer hier au nouveau client, hier j'ai corrigé 3 fautes d'orthographes dans le logiciel - au faite, la prime, c'est toujours 100€/bug? "

En général, de donner une prime à quelqu'un pour qu'il fasse correctement son travail, c'est la meilleur façon de casser une métrique qui pourrait être intéressante:

• Donnez une prime à un développeur pour avoir un ratio code/commentaire élevé dans vos sources: et vous retrouverez l’œuvre intégrale d'Alexandre Dumas (père et fils) dans git.
• Donnez une prime à un manager pour réduire les nombres de tickets "critiques": et les nouveaux bug se retrouvent déclasser.
• Donnez une prime à un commercial, et il vous vendra une fonctionnalité infaisable dans les délais.

Par contre, donner une prime sur quelque chose dont ce n'est pas le métier à un salarié, ça deviens intéressant: prime de vente pour un développeur qui trouve un nouveau client, prime de cooptation pour l'arriver d'un collaborateur, ...

Et sinon, ce que je pense qui marche le mieux: un intéressement direct au vente du produit sur lequel on travail.
Là, si l'équipe touche une prime sur les bonnes ventes, elle deviens très motivé à ce que le produit deviennent encore meilleur.

[GeoffreyOnRails]

En général, de donner une prime à quelqu'un pour qu'il fasse correctement son travail, c'est la meilleur façon de casser une métrique qui pourrait être intéressante:

• Donnez une prime à un développeur pour avoir un ratio code/commentaire élevé dans vos sources: et vous retrouverez l’œuvre intégrale d'Alexandre Dumas (père et fils) dans git.
• Donnez une prime à un manager pour réduire les nombres de tickets "critiques": et les nouveaux bug se retrouvent déclasser.
• Donnez une prime à un commercial, et il vous vendra une fonctionnalité infaisable dans les délais.

Par contre, donner une prime sur quelque chose dont ce n'est pas le métier à un salarié, ça deviens intéressant: prime de vente pour un développeur qui trouve un nouveau client, prime de cooptation pour l'arriver d'un collaborateur, ...

Et sinon, ce que je pense qui marche le mieux: un intéressement direct au vente du produit sur lequel on travail.
Là, si l'équipe touche une prime sur les bonnes ventes, elle deviens très motivé à ce que le produit deviennent encore meilleur.

Je suis assez en désaccord sur ce point, malgré le nombre de pouces verts. (pas taper )

Au contraire, je pense que lorsque c'est possible, la prime doit être au plus près du travail de la personne. Une prime sur le résultat de mon entreprise qui contient dix milles salariés, ça n'est pas ce qui me pousse dans mon quotidien. Sur des cycles de développement un peu long, l'impact de mon travail sur la vente de mon produit peut ne se faire sentir que dans quelques années, le temps qu'une release sorte, que les clients l'utilisent, qu'ils en parlent autour d'eux, qu'une décision d'achat soit prise suite à ça...

Le problème, selon moi, c'est plutôt l'absence de métrique objective permettant de juger de la qualité du travail d'un développeur à l'instant t (ou d'un commercial, d'un manager...). La qualité (ou plutôt la non-qualité du code), on la ressent souvent longtemps après le travail réalisé.. Du coup, soit on a une mesure objective (par exemple : ratio code/commentaire élevé) mais mauvaise ou très incomplète, et on se retrouve avec un effet pervers (les oeuvres de proust dans git), soit on est obligé de donner la prime en fonction du travail perçu par le manager, avec tous les problèmes que ça pose (se faire bien voir risquant de devenir le plus important que bien faire, et si le manager ne comprend rien à la technique ou n'a pas le temps de vérifier ce qui se passe, c'est la cata).

Ceci dit, les primes ne sont pas les seules sources de motivations, et ne sont pas les non plus seules à pouvoir produire ce genre d'effet délètère. Je me souviens d'une histoire (il me semble chez Microsoft il y a très longtemps, mais je voudrais pas dire de bêtises) où les devs étaient extremement préssés pour sortir de nouvelles fonctionnalités, mais avaient plus de temps pour réparer les bugs (priorité du management). Du coup, pour une fonction qui retourne la taille de police, ils mettaient une valeur pour passer le test (return 12; ), la qualité disait "on a trouvé un bug", et ils implémentaient tranquillement la fonctionnalité en "bug fix". Eviter la pression du management conduisait au même effet qu'aurait pu avoir une prime sur le temps mis pour implémenter une feature ou le nombre de bugs corrigés.



Pour revenir au sujet de l'article, il faut voir dans quel contexte est l'auteur : leurs "salariés" sont plutôt des freelance payés au ticket, et toute tâche se résume en la complétion de petits tickets et/ou la création de nouveaux tickets pour demander quelque chose. Aucune communication entre personnes travaillant sur le projet en dehors d'un commentaire sur un ticket. C'est du travail à la chaîne. Outre les inquiétudes sur les comportements que cela peut introduire (personne ne fera mieux que la qualité/performance/maintenabilité minimale vérifiée et passer les tests, sans même parler de malveillance/tricherie), leur hypothèse derrière ça est de considérer que les employés peuvent partir du jour au lendemain, et que tout investissement sur eux est perdu.

C'est assez différent d'une société qui considère ses employés comme des ressources sur lesquelles on peut investir, que ce soit à l'occasion d'un projet ou sur des formations, car on considère qu'elles vont rester un certain temps, et que du coup les gains de productivités créés pourront être rentabilisés.

Pour moi, cela peut se justifier quand on fait appel à des experts freelance au prix fort sur un délai court, mais pas pour la plupart des gens, ni en continu. Et encore, je trouverai bien souvent plus pertinent d'être payé un peu moins, et de considérer que 10 ou 20% du temps de travail servira à monter en compétences (trouver une nouvelle librairie pertinente, échanger à la machine à café avec l'expert d'à côté), que de séparer strictement apprentissage et réalisation.

Mais si ils trouvent des gens qui sont satisfaits de bosser dans ce contexte, très bien, en tout cas je trouve l'expérience intéressante... de l'extérieur