Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
N'est-ce pas aussi à cause de la vision ultra court terme des décideurs financiers, qui ne sont pas les chefs de service IT ou les opérationnels ?Envoyé par el_slapper
Surtout à des période où les politiques monétaires des banques centrales sont plus restrictives, donc moins de liquidité.
"If the revolution ain't gon' be televised
Then fuck, I'll probably miss it" - Aesop Rock
Faut-il vraiment se féliciter de cela ?
Faut-il vraiment se féliciter de cela ?
Et pourquoi pas des labels Code Équitable, Code Max Havelaar, Code Produit Localement, Code en Circuit Court, Code Artisanal, Code AOP, Code AOC, Code IGP... Non mais !
Je ne sais pas s'il faut s'en feliciter (pour mes patrons certainement que OUI puisque c'est positif sur tous les points pour eux) mais c'est une realité, c'est le metier qui change; il faut juste savoir s'adapter (ou pas) et se dire que chaque metier, tout intellectuel soit il peut etre uberisé un jour ou l'autre. Je n'y croyais pas mais pour ma boite maintenant c'est une realité. Quand tu es dev depuis des années, ben soit tu fais partie des gens qui sont devenus des architectes (auquel cas tu arrives a sauver les meubles), dans le cas ou tu es resté simple developpeur, tu te prends une sacre claque dans la gueule.
Triste constat, certes mais il ne faut pas se voiler la face et faire l'autruche. Ca rend plus humble le metier de developpeur egalement qu'on a tendance a toujours encenser. Personnellement je suis dans la partie archi du fait de l'experience de 30 ans de dev mais je plains les devs qui arrivent maintenant (enfin chez nous ce sont des personnes off shore qui sont contentes d'avoir deja un boulot - d'une certaine façon on fait du travail equitable ...)...
Ben qu'ils passent en archi SOA/micro services et tu verras que tu n'as pas besoin d'ingenieurs pour coder; juste pour architecturer les briques/composants.
Nos devs sont faits a l'ile maurice (parlent francais, coutent 4x moins cher qu'en france minimum); tres bonne communication, d'ailleurs ils viennent regulierement en france pour faire du dev directement dans nos locaux.
Meme si au depart ca a couté un peu pour qu'ils prennent en main nos environnements de dev/outils et regles de dev etc. a un tarif /4 malgré tout tu es gagnant.
pourquoi reprendre leur code ? s'ils ont des templates/patterns de code ca ne pose pas de problemes. Ils sont aussi bon que n'importe quel dev en France (ils se forment souvent aux technos sur internet et sont actifs ce qu'on n'a pas toujours sur les devs en france - triste realité mais je parle de mon vecu. 4 ans qu'on fonctionne comme ca et ils s'auto corrigent d'eux memes - faut arreter avec les cliches qu'ils seraient plus mauvais que des devs en France.
Là on a passé encore un cap puisque depuis cette année c'est vers l'inde qu'on sous traite. Des ingenieurs tres qualifiés en grande quantité qui n'attendent que ca, developper du code (ils ont un tres bon niveau question dev - et nous ont meme proposé des composants techniques de tres bonne facture).
Le developpement est globalisé comme pour beaucoup de metier maintenant.
Quand ca marche pas c'est souvent parce que les gens sont refractaires ou n'y mettent pas de bonne volonté.
Chez nous certains devs se sont ainsi rendus compte qu'ils etaient peut etre pas a leur place et sont passés dans des metiers moins techniques, de la validation systeme, chef de projet ou autre. Par contre effectivement les simples developpeurs eux ont morflé; mais peut on lutter contre une globalisation du travail ? (a part saboter toutes les tentatives de l'entreprise)
Cela fait quelques années que notre métier s'est profondément professionnalisé, industrialisé et rationalisé. De ce fait nous sommes de moins en moins dans du "software craftsmanship".
Quelque part tant mieux. J'ai le sentiment que tellement les technos sont devenues accessibles que les devs ont tendance à se passer des fondamentaux, et ne savent pas ce qu'ils font, ce qu'ils manipulent, ne réfléchissent plus aux précautions à prendre avant de faire mumuse (notamment sur la sécurité, l'évolutivité, le rythme de vie de leurs productions à court / moyen termes).
En tant que responsable de ces bonhommes, au plus j'ai la possibilité de les mettre dans des zones simples et sans surprises où ils n'ont plus à "penser" technique en dehors de ce qui leur est demandé à l'instant T, au moins il y a de mauvaises surprises.
Certains d'entre eux ne connaissent pas certains aspects de notre métier mais rechignent à se former. Ceux là je les impliquent davantage sur du métier. D'autres se lassent vite et sont en manque de défis techniques, donc je prévois des phases de R&D et de veille sinon ils se cassent et ils ont raison.
Avec le temps, des appétences émergent et naturellement l'équipe se scinde en deux : les mecs à features métier et les mecs qui leur donne les cadres, outils, machinerie, archi etc. et le tout avec de la liberté de choisir les sujets qui les intéresse plus que d'autres, s'ils préfèrent y aller à plusieurs ou isolés dans le coin.
En générale lorsqu'il y a des soucis, c'est lorsque les bonhommes ne comprennent pas pourquoi ils doivent faire un truc, n'y trouvent pas de sens. Parfois ils ont raison, il n'y en a pas, parfois c'est parce que ce qui est clair pour nous pour y avoir planché depuis des semaines ne l'est pas aussi facilement pour eux qui tombent sur le sujet d'un coup d'un seul. Alors on prend le temps, à plusieurs et la vie continue sans pression, sans stress.
On peut compter sur plusieurs faits pour arriver à faire ça :
- Nous ne sommes pas sur un marché de niche, donc pas de pression sur le temps
- Nous avons fait une grosse levée de temps et non de fonds, donc pas de pression d'investisseurs
- Ce sont des pilotes de projets qui assurent le commerce, donc connaisseurs de notre écosystème. Donc pas de commerciaux gugusses à vendre du rêve et "maintenant démerdez vous, j'vais en chopper un autre", donc pas de pression client
Les gens ne savent plus prendre le temps de bien faire les choses, et ça c'est bien dommage ! En plus quand on a jamais le temps de rien, finalement on le passe à le perdre et au bout d'un moment on en a plus pour l'essentiel, c'est débile non ?
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
Vital! Les auteurs du rapport on une vision erronée des contraintes comme beaucoup de gens qui disent depuis 30 ans que le code va disparaître demain matin. Or, jusqu'ici, les automatismes ne remplacent pas les développeurs justement parce que la mise au point relève du jugement et de l'astuce humaine. Les tests sont différents à chaque fois. Beaucoup de choses peuvent évoluer dans le process de développement mais je crains que le testing soit le moins facile à optimiser
Un jour, une expérience a été faite dans mon entreprises.
Un logiciel avait été développé en 4 mois par un très mauvais développeur. Il est rempli de bug et inutilisable.
Il fallait que ce logiciel puisse marcher un minimum pour être présentable en démo.
Sur ce projet il y avait 3 personnes clés (le mauvais développeur s'est fait viré et n'était plus là):
- Le chef
- Moi en un développeur du même niveau (on était de la même école…et tous les deux passionnés de C++ Qt)
Le chef voulait qu'on corrige les bugs…ce qui devaient aller plus vite que refaire tout.
Nous on souhaitait pour tout refaire.
Finalement une expérience a été faite. Mon collègue a tenté de corrigé les bugs et le rendre prêt pour la démo. Moi j'ai refais un nouveau logiciel.
On s'est tout les deux donnés à fond car il fallait absolument rectifier le tir pour la démo (moi j'allais servir de roue de secours si mon collègue échouait).
En 3 semaines…mon collègue a réussi à corriger la moitié des bugs de manière à ce que le logiciel soit présentable en démo (mais en trichant)
En un mois, j'ai pu refaire un logiciel nickel, bien testé…qui par la suite a été commercialisé.
=> Des fois il faut mieux recommencer que corriger un truc vraiment dur à corriger.
Pour finir, questions du jour : Faut-il mieux systématiquement réutiliser la roue ? Où des fois est-il mieux de réinventer une nouvelle roue plus performante qui permettra d'avancer plus vite une fois développer ?
Le rapport ne dit pas qu'il ne faut pas faire de maintenance, mais juste qu'on en fait trop. Quand tu dépenses 1 à faire et 10 à maintenir, il y a un problème quelque part.
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
Si le code initial était bon...
Tu te trompes de cible, tu critiques les conséquences mais tu acceptes la cause : drôle de logique. Encore et toujours, le problème n'est pas que les développeurs passent trop de temps en maintenance mais que le code initial est mal fichu.
Si le code initial était bon, les devs ne devraient pas passer "trop de temps" en maintenance.
Et d'accord avec le fait que (tenter de) corriger du code peut prendre plus de temps que tout refaire from scratch (selon mon expérience, en tout cas).
"On n'a pas inventé l'ampoule électrique en améliorant la bougie", Thomas Edison (les traduction sont variables)
Vrai, vrai, vrai. Je flippe quand je lis ces articles (non, Raphael, c'est pas à toi que je m'adresse) :
Introspections technologiques
Les préprocesseurs et moi
Bien utiliser un framework CSS
Un framework CSS ne dispense pas de réfléchir !
Le Mythe du mois-homme
Pas de balle en argent
Loi de Brooks
Combien de devs/intés passent du temps à sauter de CMS en CMS, de framework en framework, de librairie JS en librairie JS en oubliant les fondamentaux, et à utiliser ces CMS, framework et librairies JS... pour faire de sites vitrines de quelques pages ou one page ? Et combien de temps passent-ils à ça ? Vos expériences sur le sujet sont les bienvenues. Sur un site de dev web, je suis même tombé sur des gens (pas des pros, je suppose - enfin, j'espère) qui ne voyaient pas l'intérêt de comprendre leur code et qui trouvaient ça ringard. Je vois aussi de plus en plus de questions basiques posées par des intervenants (pas des pros, je suppose encore - enfin, j'espère) faisant mumuse avec tous les outils précités mais visiblement ignorants des bases du CSS.
Comme évoqué dans un article précédemment mis en lien (Soin et alimentation des ingénieurs informatique (ou pourquoi les ingénieurs sont grincheux), je ne vois pas comment on peut obtenir des bons résultats avec les devs si on ne les implique as dans les projets/si on ne donne pas de sens à leur travail/si on les considère comme des "HTML monkeys".
Si c'était vraiment leur code, ils ne pourraient pas ne pas le comprendre.
Donc ce sont des écervelés tout juste bons à voler le code des autres. Pouvons-nous savoir de quel site de trouducs vous parlez ?
Malheureusement si...
Malheureusement si, s'ils utilisent des outils qui leur évitent le contact avec le code final et qui peuvent amener leurs utilisateurs à faire des bidouillages monstrueux pour résoudre des problèmes triviaux (Ah ! Dreamweaver en mode "création"). Je me demande combien ça peut leur prendre de temps d'acquérir une connaissance de ces outils, outils qu'ils remplaceront x mois plus tard par un autre, le tout peut-être au détriment de l'approfondissement de la connaissance des langages finaux.
Je ne déplore pas l'existence de ces outils (qui suis-je pour ça ?), mais leur usage pour des projets où ils ne sont clairement pas nécessaires, la tendance des gens à rechercher des "balles en argent" (voir lien dans mon post précédent), la tendance de personnes à bosser dans le web sans être des passionnés, etc.
Bon, et puis, hein, j'ai un expérience d'intégration web, c'est tout, je ne connais rien au développement de logiciels et à ses problématiques.
Je suis toujours preneur de tout retour d'info sur ces questions.
Ben non, parce que c'est pas un site de trouducs, et parce que je ne veux pas diffamer le site pour ça, mais il y a parfois des trouducs qui s'y expriment (comme sur tout site permettant les commentaires, et je ne pense vraiment pas que dans les cas que j'ai évoqués plus haut, il s'agissait de professionnels, mais je dois dire que que l'évolution des mentalités dans le domaine de la conception web me préoccupe), ce qui ne vaut pas une condamnation du site.
Et si on commençait par...
Salut,
Je crois, personnellement, que le temps que l'on passe en maintenance n'est jamais que la "conséquence logique" des décisions qui ont été prises lors du développement original.
Combien de développeurs n'ont pas eu "l'extrême plaisir" d'entendre un responsable leur dire "tu peux me prototyper un POC vite fait, pour voir si ca marche", pour voir le code (écrit à l'arrache : l'important, c'est que ca marche pour hier) -- qui n'aurait jamais du se trouver en production -- se muer en ... "définitivement provisoire" (ou provisoirement définitif).
Mais, qui est en cause, dans ce cas là :
- Le type de maintenance qui reprend ce code "provisoirement définitif" parce qu'il ne fait le boulot qu'à moitié
- Le développeur du POC qui aurait du considérer "le risque" que le POC finisse en production comme une certitude, et qui aurait du le coder en conséquence (quitte à y mettre trois fois plus de temps
- ou est-ce le responsable, pour avoir fait passer un développement (dont il avait sans doute besoin
En tant que dev, j'en suis arrivé à accorder une importance capitale à la loi de l'emmerdement universelle, si bien que, quand je lis "il y a un risque que ..." ou "il y a de grandes chances que ...", la probabilité que "quelque chose survienne" peut n'être qu'infinitésimale, je considère systématiquement comme une certitude que "cette chose surviendra".
Si bien que, même si l'on me demande un POC, je n'arrange pour que mon code soit "suffisamment correct" que pour pouvoir passer en production dés le départ.
Cela ne veut pas dire que j'aurai forcément pensé à tout dés le départ, cela veut simplement dire que si ... pardon : quand ... un problème surviendra, le type qui devra le résoudre pourra s'y retrouver facilement.
A priori, cela ne me prendra pas plus de temps d'écrire mon code "correct" que cela n'aurait pris à quelqu'un d'autre d'écrire un code similaire "avec les pieds". Et si différence il y a, elle devrait être minime
Si bien que les développeurs ont -- très certainement -- une responsabilité à prendre! Il serait, à mon sens, plus que temps qu'ils perdent cette habitude de considérer leur code comme "jetable", et qu'il s'habituent à l'idée qu'un "code (soit disant) jetable" n'est rien d'autre qu'un "code définitif" qui s'ignore!!!
Mais les responsables ont eux aussi leur responsabilité à prendre : S'ils nous demandent une preuve de concept, qu'ils acceptent l'idée qu'ils auront "en quelque jours"... Quelque chose qui prouve que le concept fonctionne, dont le code devrait être effacé dés qu'ils ont vu que cela fonctionne, que l'intégration du concept au "reste du projet" doit se faire "dans les règles" et qu'elle prendra -- forcément -- beaucoup plus de temps que les deux ou trois jours nécessaires à la création du POC.
A méditer: La solution la plus simple est toujours la moins compliquée
Mine de rien, les progrès depuis 30 ans ont permis de créer des langages de programmation et des frameworks toujours de plus haut niveau, en poussant l'abstraction toujours plus loin, et en encapsulant ou automatisant pas mal de code bas niveau. Il en est de même pour les prochaines évolutions : l'IA ne nous remplacera pas, mais nous permettra d'automatiser toujours plus de choses, et nous de nous concentrer sur des tâches qui ont plus de plus-value. Je vois très bien, par exemple, des scénarios où une IA pourra nous aider à une meilleure couverture en tests unitaires *, nous aider à déceler en amont des cas d'usage borderlines qu'on aurait jamais soupçonnés mais qui se produiront réellement en production. Ou du mapping de classes moins pète burnes et rédhibitoire à faire (le cas typique où tu fais des régression parce que c'est super chiant à faire). Ou analyser la structure d'un code spaghetti que plus personne ne comprend dans la boîte, et en en tirer des briques de rétro-spec technique à mettre en forme. Mieux évaluer la complexité cyclomatique, les temps de calcul pour un scénario d'usage, les fuites de mémoire potentielles, les risques de sécurité, etc.
On ne crée pas des IA pour automatiser notre propre métier, on les créé pour nous aider.
* : mutation testing, ça existe déjà même si c'est pas industrialisé à ma connaissance
"If the revolution ain't gon' be televised
Then fuck, I'll probably miss it" - Aesop Rock
J'ai dû mal m'exprimer parce que je suis entièrement d'accord avec ta réponse.
J'ai souvent tendance à faire des analogies avec le bâtiment (après tout, pas mal de nos méthodes sont issues de là), et les "chefs" veulent vite montrer "quelque chose" aux clients, aux investisseurs, aux patrons. Comme ça ça les rassure tout le monde rapidement, tous peuvent voir "quelque chose" et se projeter.
Arrive le moment où l'on entame les chiottes, et on s'aperçois que le "truc" n'est pas raccordé à l'eau, les fondations n'ayant jamais été une priorité, car ce qui se passe en dessous, tout le monde s'en fou, personne ne paye pour ça, c'est pas inscrit sur la plaquette de rêve "t'auras des superbes fondations, en inoxydable etc.".
Et c'est là qu'il faut tout péter pour tout reconstruire, juste pour un chiotte de rien du tout. Les gens ne comprennent plus rien.
D'après mes expériences c'est la très grande majorité des causes qui font que le code initial est mal foutu. Par manque de connaissances / expérience, et donc de sensibilité / visibilité de la part des décideurs (clients, chefs etc.), ils veulent voir des choses concrètes et vite avant de décider / co-décider s'ils mettent les moyens dans un archi, des plans, des use cases, enfin tout ce qui n'est pas "code".
C'est comme ça qu'ils font face à l'aspect non déterministe de notre métier (car très très jeune, très mouvant). Et évidemment, on va devoir construire 15 services pour 15 métiers différents, à chaque fois on va repartir de zéro car le précédent il s'est pété la gueule, mais se remettre en question pour mutualiser la prochaine fois ça demande un égo un peu moins surdimensionner, et en général ceux qui se sont pété la gueule sont parti saboter d'autres projets ailleurs (dans l'info ou autre), et de toute façon c'est pas de leur faute, règle numéro 1 d'un bon décideur.
Du coup notre métier est jeune mais il risque de le rester encore un bon moment.
"Heureusement qu'il y avait mon nez, sinon je l'aurais pris en pleine gueule" Walter Spanghero
"Le code il est pourri". Certes, mais est-ce évitable? Est-ce évitable quand on forme les développeurs à la chaine, sans filtrer les gnous à l'entrée(ni à la sortie)? Est-ce evitable quand le temps de bien faire n'est presque jamais donné(vécu par moi, et snas doute par la plupart des gens me lisant)? Quand les développeurs à qui on donne trop de temps vont musarder en cours de route(vécu aussi)? Quand le développement est un effort qui demande des qualités spécifiques, mais qu'on le confie à n'importe qui tellement le besoin est important?
Pur ce qui est des progrès techniques, ben, ils encapsulent des trucs techniques. C'est bien. Mais ça ne répond que partiellement à la fonction première du programmeur : formaliser des suites de décisions logiques compréhensibles par la machine, en partant d'un besoin exprimé en langage naturel. Ca permet d'être plus productifs, parce qu'on ne se trimballe plus les vieilles merdasses techniques d'antan(et moi qui me suis fait pas mal de old tech dans ma carrière, j'apprécie particulièrement. notamment de ne plus avoir à me faire mes propres fonctions de travail sur les dates. Argh). Mais ça ne change pas fondamentalement le problème : quand la suite logique de décisions est mal présentée, elle est imbitable. Et galère à maintenir. Haut niveau ou pas.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Le titre de cet article est incomplet et l'article est trompeur
Pour être correct, il faudrait écrire
Les administrateurs pensent que les développeurs consacrent trop de temps à corriger du mauvais code créé sous des contraintes de temps et de ressources imposés par ces mêmes administrateurs ou à corriger des fonctionnalités mal analysées ou mal communiquées par ces mêmes administrateurs.
Personnellement, la correction du code ne correspond qu'à 2% de mon travail alors que la correction ou l'amélioration de fonctionnalités non prévues au départ représente et engendrant du refactoring peut représenter jusqu'à 70% de mon temps.
Comme vous pouvez le constater, il ne s'agit pas de mauvais code mais de fonctionnalités mal analysées induites par une pression croissante de la classe managériale qui ne tient pas compte des impératifs IT des développeurs.
Progrès ?
Beau discours dans le genre “toujours plus loin, toujours plus haut”, mais je ne vois pas trop le rapport avec le schmilblick. Jusqu’à présent, me semble-t-il, dans le web, les seul domaines où j’ai quelque expérience, le “progrès” s’est toujours traduit par un accroissement de lourdeur et de complexité, un “toujours plus complexe, toujours plus lourd”, qu’il s’agisse de méthodes de conception ou de réalisations.
Un inté d’il y a dix ans transporté à l'époque actuelle serait choqué par le poids moyen des pages web actuelles. Je faisais de l’inté il y a dix ans et avant (une époque bénie où se préoccupait d’alléger le poids des pages web) et je reste choqué. Si ce sont là les résultats de vos niveaux toujours plus hauts et de votre abstraction toujours plus poussée…
Les humains ont en général tendance à faire toujours plus lourd et plus complexe :
Software: It's a Gas
Arrête de faire ton Homer !
Si je m’en réfère à ma propre expérience de contacts avec trop d’utilisateurs lambda, il n’y a, à l’heure actuelle, aucun moyen d’empêcher un mauvais usage d’un bon outil, et plus les outils sont sophistiqués, plus ils sont mésusés :
Bien utiliser un framework CSS
Un framework CSS ne dispense pas de réfléchir !
Aussi, j’espère que vous me pardonnerez si je vous avoue redouter le tandem IA + développeur merdique…
Je crains que votre discours sur le progrès et les IA exprime une quête de la balle en argent :
Pas de balle en argent
Un immense merci !
Ouais, peut-être. En tout cas, j'tai pas compris.
Mais un immense merci pour le commentaire ci-dessus ! Ça fait toujours plaisir de ne pas être seul - mais finalement, beaucoup de commentaire de ce fil vont dans le même sens que les miens, même si ce n'est pas toujours évident à première vue.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager