Envoyé par B.AF
bon, là.. j'aurais envie de dire que j'applaudis "des quatre mains".. parce que bien sûr, je fais partie de ceux qui sont d'accord à 100 % sur le fond (autant que sur le "punch" de la formule..) ; oui, c'est clair, je pourrais pas le dire mieux, honnête.
Bon, j'avais dit que j'en avais terminé avec ce fil "C# vs. Java" mais finalement, c'est ce dernier post qui va vraiment cloturé ma contrib, en ne suivant pas, je crois, la voie de la digression ni le hors sujet.
En effet, "ma bottom line" est bien que ce genre de débat n'est pas exactement super bien fondé, mais n'est pas non plus complètement inutile parce qu'il est souvent alimenté par des argumentaires connexes aux questions "langages" proprement dite (p.ex, sur les questions de diversité des outils, de disponibilité des implémentations, de couts des licences, etc) comme nous nous y sommes prêtés sur les 7 ou 8 derniers posts.
Je termine donc sur l'autre "tension" que nous avons plus ou moins consciemment identifiée sur les derniers arguments, reprise donc par B.AF ci dessus ; celle entre :
* l'engagement, la motivation, la valeur du développeur avec son langage favori (et les "recettes" en algorithmique et/ou conception auxquelles il est aguerri)
et
* la puissance potentielle ou effective, passée, présente, ou à venir de l'outillage (langage, EDI, outils de modélisation s'il y a, etc)
Donc, oui, c'est clair : la principale valeur reste du côté de l'homme, le développeur. Mais, comme dit un dicton, dans l'esprit au moins, pour être un bon ouvrier il faut au moins pouvoir disposer des bons outils au bon moment. Bien sûr, il ne faut pas mal interpréter la formule : on ne veut pas dire par là que c'est d'abord l'outil qui fait l'ouvrier, mais plutôt qu'il faut que l'outil soit un minimum adapté aux compétences de l'ouvrier et au travail à effectuer.
Ainsi, si l'ouvrier est très bon, même avec un outil moyen, il peut quand même faire un très bon travail qu'il aura tendance "à se surpasser" et à tirer le meilleur de l'outil qu'un autre ouvrier, qui, bien moins experimenté, ferait moins bien avec un meilleur outil que le premier. Oui, c'est l'idée et c'est ce que je pense tout le monde peut constater dans probablement tous les domaines, et pas seulement l'informatique et la production de logiciel.
Ok pour ça, donc. Maintenant, le problème, c'est qu'on peut trouver des très bons developpeurs qui ont la "malchance" d'etre impliqué dans des projets où, outre le fait qu'ils ne disposent que d'un outillage moyen, voire très moyen, ils se trouvent egalement confrontés a des problématiques, comme le dit B.AF, où ça n'a plus grand chose a voir avec la technique, mais plutot avec les compétences ou desiderata disons, pour etre gentil, pour le moins "irrationnels" de leurs donneurs d'ordres (specifications fonctionnelles visiblement ecrites par des gens qui ne connaissent meme pas le métier, ou specs techniques farfelues qu'eux memes trouvent incongrues en tant que developpeurs face a ce chef de projet ou lead de dev ou architecte qui etait censé etre "réputé très bon", etc..)
Que se passe t-il alors ?
Dans le meilleur des cas, si le developpeur a un peu de charisme, il va pouvoir faire passer le message qu'il faut corriger le tir, ou meme le faire lui meme "en sous marin", par son côté "perfectionniste super motivé", quitte a faire le boulot d'autres, sans meme la compensation salariale a laquelle il pourrait prétendre de bonne foi..
Ce cas est plutot rare, et de toute façon, les bons developpeurs etant avant tout humains, ils finissent par se lasser assez vite de ce genre de situation "tordue" et sautent sur la premiere occasion pour aller voir ailleurs...
Dans la majorité des cas, le bon developpeur va faire "son maximum officiel", sans vraiment se surpasser comme ci dessus ; il sera alors d'apres moi sous utilisé parce qu'il aura accompli des taches peu gratifiantes, sans resoudre des problemes profonds d'analyse ou de conception, en ayant passé bcp trop de temps pour un resultat mediocre, alors qu'il aurait pu faire bcp mieux ailleurs avec d'autres outils et/ou superieurs.
Je parle d'experience.
Promis, ce post aura une fin.Laissez moi donc vous conter, dans les grandes lignes, cette histoire, qui, sur un projet .NET m'a sensibilisé sur l'importance de l'homme, mais aussi du bon outil au bon moment.
En l'espèce, il ne s'agissait pas d'un probleme de mauvaise architecture cible. Il s'est avérée que l'application a très bien fonctionné en production dès le départ et à continuer pendant "longtemps", avec des utilisateurs satisfaits. Bref, globalement, un succès, au moins, technique. Ce n'etait pas non plus un probleme de "lead" ou de lisibilité / coherence des specs.
Ou etait le hic alors ? Eh bien, juste avant un certain lot, "on" (le dev, en premier) s'est aperçu que ce qui avait été vendu (fonctionnalité) était largement plus vaste que ce dont on nous avait parlé, malgré traces ecrites à l'appui. Bien sûr, de la politique était entrée en jeu relativement au client/utilisateur final qu'il fallait absolument satisfaire dans des délais irraisonnables pour ce lot. Bref.
Sur le coup, j'ai personnellement dû travailler avec un "jeune" développeur, en tout cas bien plus jeune que moi, dont la capacité d'analyse, de resolution de problemes (conception et code), et la rapidité de production, ainsi que la qualité du code m'a carrément "soufflé". En 3 mois de dev intense sur ce lot, je crois que je n'ai pas dû lui faire plus de deux remarques "négatives", tout en ne comptant plus le nb de fois où je l'ai complimenté sur le boulot réalisé, pendant et après. Bref, on s'en est sorti.
Mais du coup, j'ai réalisé quelquechose :
notre architecture etait bonne, dès le départ, sans être revolutionnaire, elle etait tout a fait adaptée ; en outre, le projet côté MOE etait intéressant pour nous, donc ; tout le monde etait motivé, CdP compris, c'est tout dire (j / k ) ; mais bon, on s'est donc "fait avoir", il nous a fallu baisser la tete, parce que pour le coup, ce client là, fallait faire "l'impossible" politique et marketeux oblige.. Ce "jeune developpeur" impressionnant, il a donc été "à fond" pendant plus de deux mois avec moi, abattant le travail de peut etre deux ou trois "développeurs normalement bons pour le même age", sur la totale : les trois tiers -- écrans Winforms, objet métiers, façades, règles métiers, préparation des scripts de la BDD, les mappings NHibernate, préparation des jeux de données de test de recettes, etc, etc. bref, la totale ; on a vraiment eu bcp de chance de l'avoir..
Le hic : après avoir sorti la tête de l'eau avec lui, on a réalisé ensemble que peut être 60 voire 70 % du travail de "pissage de code" par lequel nous sommes passé s'est avéré, par notre fidélité même à nos patterns de code à travers les trois tiers.. totalement répétitif, ininteressant.. bref de la plomberie "mécanique" et c'est alors là que j'ai regretté de ne pas avoir eu un meilleur outil dans / ou associé à Visual Studio.
Avec ce développeur, et avec un outil de modélisation et de génération de code (qui nous a donc cruellement manqué) tirant profit de notre architecture cible déjà éprouvée sur les précédents lots, je suis persuadé que nous aurions pu économiser au moins 60 % de notre énergie, ramenant l'objectif de production des nouvelles fonctionnalités à un niveau raisonnable pour le temps imparti.
Et, en extrapolant un peu, avec le même développeur et un tel outil... vu cette experience vécu, je pense sincèrement qu'il n'est pas deraisonnable d'espérer être, façon de parler, "deux fois plus ambitieux" sur le même type de projet.
Donc, oui, on peut avoir un outil surpuissant, si on est pas bon, ou "à coté de la plaque" pour une raison X ou Y, ou tout nouveau venu au domaine, on en fera pas grand chose... voire.. on en fera rien du tout d'utile.
Mais à l'inverse, si on est bon et motivé, l'absence de l'outil "puissant" peut cruellement se faire sentir dans certaines situations de "stress" où on a alors pas d'autre choix que de dépenser une grande quantité d'énergie.
Ne serait ce que pour ça (dépenser son energie à bon escient, et faire en sorte que tout le monde soit le plus détendu qu'il est possible), la modernité et l'adequation de l'outillage aux besoins induits par la chaine de production de code a un instant donné... m'intéresse... significativement.
Franchement, faisons cette expérience de pensée :
vous êtes aguerri, on vous donne un projet .NET plutot "bateau" dont la partie cliente est a base Winforms, le reste de l'architecture etant quelconque ; vous etes en charge de développer les ecrans avec Visual Studio 20xx, dans un premier temps, de maniere classique.. via le designer Winforms ; il y en a un sacré paquet d'ecrans, pour le temps imparti, mais bon, après un rapide coup d'oeil a l'ergonomie "cible" prévue / demandée par les specs, vous vous apercevez que vous maitriser tout les controles "sur le bout des doigts ou presque".. On est le lundi matin, vous vous relevez les manches, et c'est parti... "vous pissez des ecrans" toute la journée et vous etes assez content de vous niveau rythme, mais vous vous dites quand meme que ça va etre chaud... mais bon...
Mardi matin : vous arrivez au bureau et vous ouvrez votre solution ; et là, O "so strange", le designer Winforms n'existe plus dans Visual Studio ; ni la property Window ; ni l'intellisense ... vous cherchez pendant quelques heures ce qui cloche sur votre installation VS... et vous realisez qu'en fait dans l'aide en ligne et sur le web personne ne parle de "designer", "d'intellisense", d'editeur de propriétés etc... c'est comme un cauchemar ; en fait, s'en est un : vous etes dans un autre univers parallèle où ces concepts / outils n'ont pas encore été inventés... Windows existe bel et bien, mais c'est comme si les "anciens" Visual Basic 1.0 (puis 2, 3, etc) et Delphi n'avaient jamais existé pour lancer ce "trend" de programmation "visuelle" / de designers... on en est resté au simple éditeur de code...
Bon courage a vous : vous venez en revanche de retrouver la partie du CdC / specs qui decrit tous les ecrans qu'il vous reste à développer... mais "à l'ancienne", donc -- pré-le début des 90's...
Vous tapez vite et bien, et êtes un champion du copier coller j'espère ?
(Vous vous demandez quand meme comment "on" a pu vous demander de pisser autant d'ecrans avec un tel "NonVisual Studio"... quelque chose cloche forcément... donc, oui : c'est un cauchemar, vous allez bientot vous reveiller, en fait.)
Je sais, c'est caricatural, mais cela n'est pas si éloigné, sur le fond, de la situation que j'ai (nous avons) vécue avec ce développeur. Le gouffre sous nos pieds de l'absence de l'outil qu'il faut dans l'EDI ... au moment où on en a le plus besoin.
Bref. ça fait déjà longtemps.. que ce post est devenu ... trop long.
The very end, donc :
"Tout l'art", a l'instar de l'apparition de Java et C# en leurs temps respectifs, consiste a savoir anticiper "un peu" en projetant une partie du présent et de ses problématiques dans le futur proche ou moins proche (bref, d'imaginer / d'innover), en restant pragmatique, sans chercher a reinventer la theorie des langages, des modeles, etc.. mais en regardant plutot le présent et le passé proche et en se disant :
"mince alors, mais qu'est ce donc qui m'a fait défaut le plus, finalement ? avec quelle fréquence ? et est-ce que je pourrais pas le créer, cet outil qui m'aurait bien aidé, puisque la même problématique a une bonne probabilité de se reproduire ? si oui, en combien de temps je peux le faire ? etc, etc"
Voilà
Répondre avec citation
.
Partager