Discussion :

[Invité]

Hum... j'ai pourtant connu 2 ou 3 projets pour lesquels tout refaire était la seule solution (mon boulot courant consiste d'ailleurs a refaire totalement une appli).

Il y a bien évidemment des cas où c'est nécessaire (encore que, il est rare qu'il n'y ait rien à sauver de l'ancien système, ca demande de s'asseoir sur son égo, mais c'est souvent un gros gain de temps quand le projet se met à déraper). Ceci dit, j'ai quelques cas en tête ou la réécriture a tué un logiciel qui marchait, ou créé une telle panique chez les clients que l'entreprise a failli y passer, et a dû reconquérir, quelques années plus tard, les clients qu'elle avait perdu.

Bref c'est une décision risquée, qui serait bien évidemment plus souvent prise si les projets informatiques en général, et les refontes en particulier, n'avaient pas tendance à déraper dans les grandes largeurs...

Quand le système est effectivement trop vieux pour être adapté aux nouvelles normes & nouvelles specs (genre, trop peu de capacités, de variables possibles, etc., manque d'outils), ou que c'est devenu un tel sac de noeuds imbitable (10ans d'évo à l'arrache sans specs, un travail baclé de base, ...), parfois, tout remettre à plat est la seule solution possible.

Tous ces arguments sont valables s'ils sont correctement argumentés. Le problème, c'est que ce sont aussi les excuses qu'invoquera le développeur qui n'a pas envie de se plonger dans le "code des autres", et qui préférerait qu'on le paie à refaire tout le bouzin, comme il veut.

On a tous entendu les

- ah mais c'est du Fortran/Cobol/APL ce n'est plus maintenable! (ben tiens, c'est pas plutôt que tu n'as pas envie de t'y mettre?)
- ah mais ca ne suit pas le paradigme truc ou la norme machine, ça ne passera pas sur les systèmes actuels ! (et à ton avis, comment ça tourne maintenant?)
- ah mais c'est dépendent de telle librairie! (ben oui, tu n'en utilises pas?)
- ah mais c'est codé avec les pieds ! (tu as passé combien de temps dans le source pour porter un tel jugement, ah? deux heures...)
- ah mais c'est du code spaghetti ! (tu veux dire du procédural, j'imagine, c'est sur que 200 objets de 200 lignes dans 200 fichers différents, c'est nettement plus clair que 200 fonctions de 200 lignes)
- ah mais y'a pas de specs ! (le meilleur pour la fin... ben non, ou plutôt si, la spec c'est l'ancien logiciel que tu veux remplacer, ah, il faut aussi qu'on te l'écrive?)

Ces arguments ne sont pas mauvais en soi, mais on a tellement entendu crier au loup... Et puis, ce sont des arguments de développeur, par les devs pour les devs. Ils sont plus difficiles à tenir, parce qu'ils n'apportent aucun bénéfice concret au client, juste des risques de régression et de délai, et qu'ils n'offrent aucune garantie de sécurité à long terme (on a tous vu trop de projets se planter pour y croire)

Et du coup, même quand c'est vrai, qu'il faudrait effectivement tout refaire, ce discours a du mal à passer.

Francois

[DevTroglodyte]

Il y a bien évidemment des cas où c'est nécessaire (encore que, il est rare qu'il n'y ait rien à sauver de l'ancien système, ca demande de s'asseoir sur son égo, mais c'est souvent un gros gain de temps quand le projet se met à déraper). Ceci dit, j'ai quelques cas en tête ou la réécriture a tué un logiciel qui marchait, ou créé une telle panique chez les clients que l'entreprise a failli y passer, et a dû reconquérir, quelques années plus tard, les clients qu'elle avait perdu.

Là j'ai de la chance, le client suit de très très près le développement de l'application (bon en meme temps, vu l'appli, ça vaut mieux )

Le problème, c'est que ce sont aussi les excuses qu'invoquera le développeur qui n'a pas envie de se plonger dans le "code des autres", et qui préférerait qu'on le paie à refaire tout le bouzin, comme il veut.

C'est hélas trop vrai

[GrandFather]

Tous ces arguments sont valables s'ils sont correctement argumentés. Le problème, c'est que ce sont aussi les excuses qu'invoquera le développeur qui n'a pas envie de se plonger dans le "code des autres", et qui préférerait qu'on le paie à refaire tout le bouzin, comme il veut.

L'argument fonctionne dans les deux sens. J'ai aussi vu le cas de développeurs refusant farouchement qu'on touche à un système de technologie ancienne qui présentait pourtant des défauts ; le maintien du statu quo servait, selon le cas, à préserver leur ego et/ou leur emploi, ou encore à éviter de se retrouver en difficulté face à des technologies plus récentes sur lesquelles ils avaient de forts a priori.

Bref, on va peut-être éviter de trop généraliser...

[sevyc64]

Tous ces arguments sont valables s'ils sont correctement argumentés. Le problème, c'est que ce sont aussi les excuses qu'invoquera le développeur qui n'a pas envie de se plonger dans le "code des autres", et qui préférerait qu'on le paie à refaire tout le bouzin, comme il veut.

On a tous entendu les

- ah mais c'est du Fortran/Cobol/APL ce n'est plus maintenable! (ben tiens, c'est pas plutôt que tu n'as pas envie de t'y mettre?)
- ah mais ca ne suit pas le paradigme truc ou la norme machine, ça ne passera pas sur les systèmes actuels ! (et à ton avis, comment ça tourne maintenant?)
- ah mais c'est dépendent de telle librairie! (ben oui, tu n'en utilises pas?)
- ah mais c'est codé avec les pieds ! (tu as passé combien de temps dans le source pour porter un tel jugement, ah? deux heures...)
- ah mais c'est du code spaghetti ! (tu veux dire du procédural, j'imagine, c'est sur que 200 objets de 200 lignes dans 200 fichers différents, c'est nettement plus clair que 200 fonctions de 200 lignes)
- ah mais y'a pas de specs ! (le meilleur pour la fin... ben non, ou plutôt si, la spec c'est l'ancien logiciel que tu veux remplacer, ah, il faut aussi qu'on te l'écrive?)

Ces arguments ne sont pas mauvais en soi, mais on a tellement entendu crier au loup... Et puis, ce sont des arguments de développeur, par les devs pour les devs. Ils sont plus difficiles à tenir, parce qu'ils n'apportent aucun bénéfice concret au client, juste des risques de régression et de délai, et qu'ils n'offrent aucune garantie de sécurité à long terme (on a tous vu trop de projets se planter pour y croire)

D'un autre coté, je te répondrait que si les commerciaux et les consultants écoutaient un peu plus les devs dans ce genre de situation plutôt que d'aller vendre du rêve sans savoir de quoi on cause, sans même savoir si c'est faisable, il y aurait peut-être moins de débordement et de casse à la fin.
Parce que ce qui est vendu, le client le veut. Il ne veut pas savoir que finalement c'est pas possible à faire. Le commercial, lui a touché sa com, quant au dev, il lui reste plus qu'à s'arracher les cheveux pour arriver à faire des miracles pour pas un brouzouf de plus.

Et pourtant je suis dev, et le boulot de consulting ne m’intéresse pas

[backlash]

Je peux t'envoyer mon CV ?

Sans aucun soucis

[Invité]

D'un autre coté, je te répondrait que si les commerciaux et les consultants écoutaient un peu plus les devs dans ce genre de situation plutôt que d'aller vendre du rêve sans savoir de quoi on cause, sans même savoir si c'est faisable, il y aurait peut-être moins de débordement et de casse à la fin.

Sur ce point,et même si je suis également développeur, les torts sont très partagés. D'un côté tu as les commerciaux qui promettent des beaux jours, mais de l'autre tu as les devs qui soient surestiment un peu la performance de la solution qu'ils défendent (je te promets, avec la librairie machinchose...), soit demandent et obtiennent des délais qu'ils ne tiennent pas (ah mais je ne pouvais pas savoir...), soit, et c'est le cas le plus courant, ont tellement pris l'habitude, à chaque fois qu'on leur demande un truc, de dire "ah mais c'est impossible, faudrait tout casser, ca va prendre des mois", avant de revenir l'après midi avec une solution qui marche.

Cette dernière attitude est la pire, parce qu'elle accrédite chez pas mal de chefs de projets (et de commerciaux) l'idée que tout est possible si on tape assez fort sur la tête du développeur.

Sérieusement, je crois qu'il y a énormément de casse et de débordement parce qu'on est, devs, CP et commerciaux, incroyablement mauvais dans l'estimation de nos temps de développement, et qu'on n'a toujours pas trouvé la solution. (Sur ce sujet, je te conseilles Brooks 'the mythical man month', ça date des années 60, mais c'est inégalé)

Francois

[Invité]

J'ai aussi vu le cas de développeurs refusant farouchement qu'on touche à un système de technologie ancienne qui présentait pourtant des défauts.

Oui, on le voit même parfois chez ceux qui ont demandé la réécriture complète, quand ils tombent sur un os, ou un bout de code particulièrement difficile à refaire...

Francois

[souviron34]

Pour une grande part, essentiellement justement de notre vie confortable, une trop grande hygiène, une médication à foison.

Je suis tout à fait d'accord..

Alors on dit que les progrès en hygiène, médecine,etc, font que l'on vit plus longtemps.
NON ! Nos ainées, eux qui ont, d'une part, été confrontés à la dure vie, et qui, aujourd'hui, bénéficient pleinement de ces progrès vivent plus longtemps. Mais on verra ce qu'il en sera pour les générations suivantes, c'est à dire nous qui n'avons pas connus une vie aussi dure. Vivrons nous aussi longtemps dans les mêmes conditions, ou serons nous obligé d'être sous perfusion permanente de médoc, assisté h24 d'appareils divers et variés pour nous maintenir en vie ?

Là aussi et c'est justement ce qui me fait rigoler quand on entend des gens (pas que des jeunes, mais beaucoup ici-même par exemple, dans d'autres discussions parallèles) que on va vivre 100 ans ou plus, et que c'est super...

D'une part je ne suis pas très sûr (pour avoir cotoyé plusieurs couples nonagénaires) que c'est si super que ça de ne plus avoir d'amis (ils sont morts), ni d'enfants (ils sont morts aussi), et que la seule génération avec laquelle tu pourrais encore échanger est au miniimum celle de tes petits-enfants, qui n'a plus guère de points en commun avec la tienne, mais d'autre part que c'est si super que ça de devoir "attendre" la mort (qui viendra inéluctablement) pendant 30 ans sans par exemple pouvoir te déplacer de plus de 10 minutes sans wc à côté - problèmes urinaires - sans pouvoir manger ce que tu aimes - problèmes digestifs - sans pouvoir marcher plus que le tour de ta maison - et encore si elle n'a pas d'escalier - sans pouvoir lire ou même voir... Ou d'avoir à aller tous les 3 jours à l'hosto...

J'avoue que ce genre de "paradis" ne m'attire absolument pas... Et pourtant nous y passerons tous..

Je préfèrerais ne pas avoir à prolonger ce genre d'état...

On a beaucoup gagné en espérance de vie, mais peu en éspérance de vie en bonne santé...

Et pour reprendre l'exemple du compagnonage, justement ça ne s'applique pas à l'informatique pour moi. On retrouve des principes, des algos plus anciens que le plus âgé des séniors, mais il y a aussi tout un tas de choses qui évoluent en permanence et dont il faut tenir compte.

Et ??

Parce qu'on est ancien on ne peut plus se tenir au courant ???

Ce n'est pas parce qu'il existe tout un tas de matériaux nouveaux pour le bâtiment ou la couture qu'un maçon ou un(e) couturier(e) ne sait plus faire ce qu'il faisait avant....

Je me souviens très bien de professeurs qui codaient selon d'anciennes conventions C, qui ne connaissaient pas tel ou tel outil pourtant vraiment utile.

Encore une fois et ??

Le thread sur "utilisez-vous un éditeur et su oui lequel ?" et celui sur "20 grand noms disent ne pas utiliser d'IDE" sont une preuve qu'on peut très bien "coder à l'ancienne" avec de vieux outils et être au moins aussi perfrmant qu'un jeune avec un nouvel outil..

Quant aux conventions, ce sont des conventions.. ça ne touche en rien le fonctionnement du programme..

J'ai l'impression de voir plus souvent des gens qui n'évoluent pas au niveau savoir/technos plutôt par flemme que par choix technique...

Et encore une fois et ???

LE BUT de la fabrication d'un logiciel c'est qu'il marche et qu'il fasse vite et bien ce qu'on demande..

Si ces gens sont parfaitement opérationnels avec leurs outils /technos, pourquoi faudrait-il qu'ils en utilisent d'autres sous prétexte qu'elles sont "plus neuves" ??

Pour faire un pont comme le pont de Millau ou la dernière tour à Londres ou Dubai, tu peux utiliser des nouveaux matériaux, mais le fond du problème est de savoir comment on construit un pont ou une tour - avec tous les calculs essentiels qui en découlent, et qui sont paramétrés en fonction des caractéristiques des matériaux...

Un architecte d'il y a 150 ans et un d'aujourd'hui doivent avoir les mêmes connaissances, et un bon d'hier serait toujours bon aujourd"hui, même sans auto-cad et logiciel de simu 3D...

L'argument fonctionne dans les deux sens. J'ai aussi vu le cas de développeurs refusant farouchement qu'on touche à un système de technologie ancienne qui présentait pourtant des défauts ; le maintien du statu quo servait, selon le cas, à préserver leur ego et/ou leur emploi, ou encore à éviter de se retrouver en difficulté face à des technologies plus récentes sur lesquelles ils avaient de forts a priori.

Bref, on va peut-être éviter de trop généraliser...

Oui, on le voit même parfois chez ceux qui ont demandé la réécriture complète, quand ils tombent sur un os, ou un bout de code particulièrement difficile à refaire...

C'est exact, et je dois dire que j'ai eu une expérience où j'ai tiré mon chapeau à l'équipe de dev.. et je continue à le faire 17 ans après...

En gros on est arrivé en leur disant que ce qu'ilsavaient fait était entièrement à refaire..

Evidemment, on serait arrivé comme certaines interventions ici le préconisent, on se serait fait jeter proprement.. On s'est un peu fait jeter.. Mais nos arguments , nos discussions, et une certaine diplomatie ont permis de faire "voir la lumière" à une équipe de 60 dev travailant sur le projet depuis 10 ans... Alors tous n'ont pas suivi, mais une grande part, et j'ai admiré leur contrôle de leur égo...

Sérieusement, je crois qu'il y a énormément de casse et de débordement parce qu'on est, devs, CP et commerciaux, incroyablement mauvais dans l'estimation de nos temps de développement, et qu'on n'a toujours pas trouvé la solution. (Sur ce sujet, je te conseilles Brooks 'the mythical man month', ça date des années 60, mais c'est inégalé)

D'ailleurs, le dernier échec du tir de missile il y a 3 jours est une démonstration imparable...

Sur tous les plans, parce que la DCN utilise justement des normes soi-disant strictes, soi-disant "à jour", etc etc....

[ymoreau]

Parce qu'on est ancien on ne peut plus se tenir au courant ???

Ce n'est pas ce que j'ai dit. Mais à ce niveau là l'ancien devra apprendre autant que le nouveau, ce n'est pas l'ancien qui transmettra ce savoir en particulier (je parle uniquement des nouveautés évidemment...).

Le thread sur "utilisez-vous un éditeur et su oui lequel ?" et celui sur "20 grand noms disent ne pas utiliser d'IDE" sont une preuve qu'on peut très bien "coder à l'ancienne" avec de vieux outils et être au moins aussi perfrmant qu'un jeune avec un nouvel outil..

Ce qui est probablement vrai dans certains ne le sera pas dans tous. Les nouvelles technos ont parfois des avantages indéniables, les nouvelles pratiques aussi. Et je suis convaincu qu'il existe donc aussi des cas où un "à l'ancienne expérimenté" est moins intéressant à long terme qu'un jeune et son nouvel outil.
C'était d'ailleurs aussi un sujet d'actu un jour : Le compilateur C optimise aussi bien l'exécutable qu'un développeur assembleur expérimenté.

LE BUT de la fabrication d'un logiciel c'est qu'il marche et qu'il fasse vite et bien ce qu'on demande..

Si ces gens sont parfaitement opérationnels avec leurs outils /technos, pourquoi faudrait-il qu'ils en utilisent d'autres sous prétexte qu'elles sont "plus neuves" ??
(...)
Un architecte d'il y a 150 ans et un d'aujourd'hui doivent avoir les mêmes connaissances, et un bon d'hier serait toujours bon aujourd"hui, même sans auto-cad et logiciel de simu 3D...

Sur le moment oui. Seulement il serait idiot de ne pas tenir compte du tout du long terme, de la facilité à maintenir/faire évoluer, de la compatibilité avec de futurs systèmes etc.
Et tu réduis le progrès à "auto-cad", mais pour moi l'ancien architecte utiliserait peut être une façon de construire et des matérieux qui ont 50 ans de durée de vie quand entre temps on a découvert de quoi avoir un pont solide pour 5 siècles mais qu'il n'en savait rien. C'est trop réducteur de dire "le nouveau fait pareil de façon différente", le nouveau peut faire beaucoup plus que cela (toujours dans certains cas).

Je ne dis pas qu'il faut toujours utiliser les nouveaux outils et mettre au placard l'expérience et certains principes qui sont toujours valables. Il faut un peu des deux.

[souviron34]

Sur le moment oui. Seulement il serait idiot de ne pas tenir compte du tout du long terme, de la facilité à maintenir/faire évoluer, de la compatibilité avec de futurs systèmes etc.
Et tu réduis le progrès à "auto-cad", mais pour moi l'ancien architecte utiliserait peut être une façon de construire et des matérieux qui ont 50 ans de durée de vie quand entre temps on a découvert de quoi avoir un pont solide pour 5 siècles mais qu'il n'en savait rien. C'est trop réducteur de dire "le nouveau fait pareil de façon différente", le nouveau peut faire beaucoup plus que cela (toujours dans certains cas).

Et c'est justement sur ce point que s'exerce la plus grande réticence des séniors...

Parce que justement, le sénior pense beaucoup plus à long terme - par force et expérience - que le jeune... *

Et que justement il a vu passer des modes et des langages.. et des problèmes de compatibilité...

C'est précisément sur le point de la pérennité et compatibilité à long terme que l'expérience sert... et que le "nouvel outil" et (souvent, pas toujours) pire que l'ancien...

Encore une fois, il suffit simplement de regarder que ce soit sur ce fil "Actualités" que de manière générale. Il ne se passe pas 1 mois sans qu'on nous annonce "le nouvvel outil qui fait", "la nouvelle méthodologie qui", "le nouveau paradigme qui", "on va bientôt avoir", etc etc...

Et c'est précisément sur ce point que la pondération intervient....


* : 1 an quand tu as 25 ans c'est 1/8 ième de ta vie d'adulte.... Quand tu en as 50 c'est 1/32 ième.... 4 fois plus court...

[enneite2]

Bon ça va, à 35 ans, j'arrive encore à trouver n emploi avec augmentation de salaire à la clef (en région parisienne).
Ca me rassure. Par contre, ce n'est pas en SSII, je les ai d'ailleurs toujours fuit et je les fuirai tout au long de ma carrière.
En France, c'est vrai qu'il y a trop peu de poste chez des clients finaux par rapport aux postes en SSII.
Par contre à 35 ans (déjà vieux), sans avoir publié de CV sur internet , je me fais contacter chaque semaine par des SSII ou agences WEB qui essaient de me débaucher (comment ont-ils fait pour m'insérer dans leurs listings, ils sont très forts!!! ).
Donc : OUF! il me reste quelques années.

Par contre ce qui est vrai , c'est qu'il vaut mieux se mettre à jour continuellement : auto-formation, DIF, formation continue, veille technologique ...
ET ça , ce n'est pas une question d'âge mas de mentalité.

Par exemple un jeune qui entre dans une école et qui en sort 3 à 5 ans plus tard, les outils qu'il a utilisé en début de cycle scolaire sont déjà dépassés!
A peine arrivé sur le marché du travail, il est déjà trop vieux!

PS : les vieux sans diplôme, pensez à faire valider vos acquis par une VAE, ça demande du travail supplémentaire mais ça en vaut le coût.

[gangsoleil]

Ce qui est probablement vrai dans certains ne le sera pas dans tous. Les nouvelles technos ont parfois des avantages indéniables, les nouvelles pratiques aussi. Et je suis convaincu qu'il existe donc aussi des cas où un "à l'ancienne expérimenté" est moins intéressant à long terme qu'un jeune et son nouvel outil.

Il y a bien sur des cas, comme il existe des cas ou l'utilisation d'une machine virtuelle est plus performante qu'une compilation.
Mais dans la majeur partie des cas, les programmes "a l'ancienne" font mieux que les programmes developpes dans des editeurs modernes qui generent un peu de code, embarquent des bouts de code inutils, et encore d'autres joyeusetes de ce genre.

C'était d'ailleurs aussi un sujet d'actu un jour : Le compilateur C optimise aussi bien l'exécutable qu'un développeur assembleur expérimenté.

"Le" compilateur C n'existe pas. Et je suis certain de trouver des cas faux, malgre mon pietre niveau d'assembleur -- mais je n'ai pas trouve le lien

Je ne dis pas qu'il faut toujours utiliser les nouveaux outils et mettre au placard l'expérience et certains principes qui sont toujours valables. Il faut un peu des deux.

Oui, il faut un peu des deux, en se souvenant que sur toute la partie nouvelle, le projet va essuyer les platres.

[ymoreau]

@souviron34 je ne dis pas le contraire, il faut un certain recul par rapport aux "nouveautés". Mais ce qui a déjà été dénoncé dans le fil et que je voulais souligner, c'est que l'abus se fait aussi dans l'autre sens. A trop se méfier de ce qui est nouveau sans prendre la peine de l'étudier il arrive aussi que des bonnes nouveautés soient ignorées au profit de "ce qu'on connaît déjà" même si c'est une perte à long terme (jusqu'au moment fatal où ce sera trop tard et qu'il faudra repartir de zéro).
Mais ça c'est avant tout une question de mentalité bien entendu. Il y a aussi des jeunes qui n'ont pas enlevé les oeillères que leur prof leur a posé. Je pense juste que le problème se creuse avec le temps (et donc l'âge). Et pas de bol, c'est régulièrement que ce genre d'individu a pris du grade et impose a façon de faire à toute une équipe.

[souviron34]

@souviron34 je ne dis pas le contraire, il faut un certain recul par rapport aux "nouveautés". Mais ce qui a déjà été dénoncé dans le fil et que je voulais souligner, c'est que l'abus se fait aussi dans l'autre sens. A trop se méfier de ce qui est nouveau sans prendre la peine de l'étudier il arrive aussi que des bonnes nouveautés soient ignorées au profit de "ce qu'on connaît déjà" même si c'est une perte à long terme

Oui mais je remet ici ce que j'ai rajouté comme note plus haut, si tu as lu on post avant que je l'édite :

* : 1 an quand tu as 25 ans c'est 1/8 ième de ta vie d'adulte.... Quand tu en as 50 c'est 1/32 ième.... 4 fois plus court..

Dans notre domaine nous sommes abreuvés depuis 15 ans de "nouveautés"... Alors pour un jeune 15 ans c'est long, et ça fait "pleins" de nouveautés... Pour un vieux c'est beaucoup plus court, et sur le total des "nouveautés" présentées bien peu résistent ou sont utiles à long terme - à moins de tout refaire ce qui, encore une fois - n'est pas ce que souhaite une entreprise, sauf si c'est une SSII...

[GrandFather]

Il me semble que Brassens avait écrit une chanson qui permettrait de trancher définitivement le débat...

[Invité]

Il me semble que Brassens avait écrit une chanson qui permettrait de trancher définitivement le débat...

Euh, Corneille, avant...

Marquise, si mon visage
A quelques traits un peu vieux
Souvenez-vous qu’à mon âge
Vous ne vaudrez guère mieux.

Le temps aux plus belles choses
Se plaît à faire un affront
Et saura faner vos roses
Comme il a ridé mon front.

Le même cours des planètes
Règle nos jours et nos nuits :
On m’a vu ce que vous êtes ;
Vous serez ce que je suis.

Cependant j’ai quelques charmes
Qui sont assez éclatants
Pour n’avoir pas trop d’alarmes
De ces ravages du temps.

Vous en avez qu’on adore ;
Mais ceux que vous méprisez
Pourraient bien durer encore
Quand ceux-là seront usés.

Ils pourront sauver la gloire
Des yeux qui me semblent doux,
Et dans mille ans faire croire
Ce qui me plaira de vous.

Chez cette race nouvelle
Où j’aurai quelque crédit
Vous ne passerez pour belle
Qu’autant que je l’aurai dit.

Pensez-y belle Marquise :
Quoi qu’un grison fasse effroi,
Il vaut bien qu’on le courtise
Quand il est fait comme moi.

Et la réponse de Brassens n'est pas fatalement la chose la plus intelligente qu'il ait trouvée... (parce qu'au bout du bout, on ne se souvient de mademoiselle du Parc qu'autant que Corneille l'a dit...)

[jouana]

Les jeunes qui apprennent vite c'est super pour le coté malléable de la ressource sur des taches ingrates ce qui représente quand même une grosse partie de l'informatique de gestion.

Après les anciens ont l'expertise et c'est une chose indispensable dans un projet le soucis c'est les coups.

Dans un monde qui va vers la production rapide, technique de court terme pour du long terme et baisse de qualité pour livraison rapide ...

La réalité c'est plus un ancien plein d'experience = 2/3 jeunes :s

D’où l'augmentation de production par réduction de la qualité

Bonne journée tout le monde

[GrandFather]

Et la réponse de Brassens n'est pas fatalement la chose la plus intelligente qu'il ait trouvée... (parce qu'au bout du bout, on ne se souvient de mademoiselle du Parc qu'autant que Corneille l'a dit...)

C'est Tristan Bernard qui a ajouté la strophe dont tu parles à Stances à Marquise, Brassens n'a fait qu'une mise en musique.

Mais ce n'est pas à cette chanson que je faisais référence, plutôt celle avec la phrase « l'âge ne fait rien à l'affaire » juste avant le refrain...

[bruneltouopi]

Bien Je tiens à préciser que les 80% du noyau etait justement ce qui rendait les applications fonctionnels.
Le contexte est le suivant Le chef de projet bien sur j'ai eu la chance de travailler avec celui qui a concu ce noyeau il était dans le boite depuis 8 ans.Lui il avait envie de migrer en JAVA mais ne savait coder.il était très passionné par ce qu'il pouvait faire en JAVA et étant déjà très expérimenté en VB6.
Nous avons travailler ensemble j'ai simplement retraduit les fonctionnalités du noyeau déjà existant.Mais bien sur je ne vais pas dire ici ce que c'est un serveur AS 400 donc oui ce noyau a été éprouvé.

En fait je voulait dire que je respecte enormément les séniors car moi de même quand il y'a des stagiaires j'essaye de comprendre cela.

Mais j'ai aussi eu la chance d'avoir à mes cotés un Frère senior et je puisses vous dire que avoir des années d'expérience voulait aussi dire qu'il bossait depuis des années sur même systèmes.
Bah cela ne l'empèchait pas de me filer ses projets d'entreprise que je fais à la maison.Bien sur je suis finalement entré dans la boité et sorti du noir.

En fait c'est pour dire qu'il y'a des seniors certes très expérientés mais très cantonnés dans leur système au point de ne plus avoir une autre vision souvent optimale des choses.

C'est que j'ai vécu dans certaines structures ou je suis arrivé.
Exemple vous vous rendez compte qu'une application fait en 2002 sous SQL 2000 et VB6.bah il y'avais pas de foreign key et autre.bah on passait des nuits pour lancer un certain nombre de taches.bah je ne veux même dire ce qu'on a fait alors que ces seniors étaient si reticent

[el_slapper]

(.../...)La réalité c'est plus un ancien plein d'experience = 2/3 jeunes :s(.../...)

Mais est-ce que l'ancien est 2-3 fois plus fort que quand il était jeune? Pas tant que ça, je le crois. La différence, c'est que les gens qui ne sont pas fait pour ce métier disparaissent avec les années. Et que les vieux qui restent, c'étaient les plus adaptés.

On trouve des petits jeunes aussi doués que les anciens, mais ils sont noyés dans la masse. Des anciens pas très bons, je n'en ai pas croisé des masses. Des gamins, par centaines. Mais d'autres étaient aussi bons que les anciens.