Discussion :

[Glutinus]

Haha, chez un de mes clients, la responsable livraison était aux 4/5ème et ne travaillait pas le mardi.
La démarche était que si on voulait une livraison, c'était envoyer le plan de livraison le lundi, pour qu'elle valide le mardi, ou l'envoyer le jeudi, pour qu'elle le valide le vendredi.

Des fois on avait une livraison prête le lundi soir, mais elle voulait le recevoir dans sa boite mail le lundi - c'était le process, et elle le suivait bêtement sans se poser des questions.

Du coup on s'est dit que c'était rapé. Sauf que le mercredit à 17h30 en passant devant sa porte, on la voyait en sortir...
- Mais t'es pas au 4/5ème ce mercredi ?
- Ha non, je l'ai déplacé à vendredi.

Du coup, personne n'était au courant qu'elle était là, elle s'enfermait dans son bureau avec son sandwich et passait la journée sans que personne ne sache qu'elle était là...

Donc finalement on ne pouvait pas faire la validation le vendredi et il fallait attendre la semaine d'après

CQFD

[el_slapper]

Mais comment les développeurs java faisaient leur qualification sur l'environnement de recette ? Chez nous on a un environnement de dev, un environnement de pré-prod + la prod, la mise en pré-prod est faite par le CP en une heure sans avoir à demander d'autorisation (par contre côté web services et bdd c'est plus long), et il nous est arrivé d'en faire 4 par jour à l'approche d'une mise en production.

Ils souffraient. Pas le droit à l'erreur - ou alors on prend une semaine dans la vue. Le pire, c'est que les grands chefs voulaient mettre en place le même processus niveau COBOL, soi-disant pour maitriser le process de livraison. Le seul résultat, c'est que quand la MOA a demandé le même devis au JAVA et au COBOL, le COBOL était deux fois moins cher... et avait un taux moyen de retard deux fois inférieur, aussi. Mais je ne crois que ça n'était ni lié à la qualité des développeurs(dusse mon orgueil en souffrir), ni aux qualités intrinsèques des langages(même si j'adore le COBOL et que je déteste le JAVA, c'est purement subjectif et de mauvaise foi).

La logique derrière ce genre de connerie, c'est "le process doit être maitrisé". Ca ne prend pas en compte l'extrême complication des logiciels internes - qui sont juste trop gros pour entrer dans une tête, même une tête de programmeur. Permettre au programmeur de rattraper rapidement ses conneries, donc, au final, tolérer qu'il en fasse, c'est juste accepter qu'il est humain et ne peut pas tout planifier d'un coup. Même moi(voire surtout moi), j'ai des limites cognitives bien en dessous de ce qu'il faudrait pour que tout soit bon du premier coup. Mais pour les grands chefs, c'est inacceptable. On doit maitriser le process, ne jamais être surpris, avoir tout planifié, et ne jamais improviser. Et la marmotte, elle fait la mise en production sans casse, sans surprise, tel que ça a été conçu, à la virgule près.

Sans compter le confort mental : j'ai fait une connerie? du Dev à la prod en passant par l'intégration et l'homologation, j'ai 4 livraisons de une minute chacune(chrono en main). Je sais que je peux retomber sur mes pattes. J'ai confiance. Le dev JAVA, il a peur - parcequ'à la moindre boulette, il en a pour une semaine pour réparer - et la peur est mauvaise conseillère.

Je répète : on avait des devis deux fois plus courts, et des dépassements moyens de 5 à 10%, là ou ils frôlaient les 20%. Juste à cause de ça. J'aurais détesté être à leur place.

[Laurent 1973]

Ils souffraient. Pas le droit à l'erreur - ou alors on prend une semaine dans la vue. Le pire, c'est que les grands chefs voulaient mettre en place le même processus niveau COBOL, soi-disant pour maitriser le process de livraison. Le seul résultat, c'est que quand la MOA a demandé le même devis au JAVA et au COBOL, le COBOL était deux fois moins cher... et avait un taux moyen de retard deux fois inférieur, aussi. Mais je ne crois que ça n'était ni lié à la qualité des développeurs(dusse mon orgueil en souffrir), ni aux qualités intrinsèques des langages(même si j'adore le COBOL et que je déteste le JAVA, c'est purement subjectif et de mauvaise foi).

La logique derrière ce genre de connerie, c'est "le process doit être maitrisé". Ca ne prend pas en compte l'extrême complication des logiciels internes - qui sont juste trop gros pour entrer dans une tête, même une tête de programmeur. Permettre au programmeur de rattraper rapidement ses conneries, donc, au final, tolérer qu'il en fasse, c'est juste accepter qu'il est humain et ne peut pas tout planifier d'un coup. Même moi(voire surtout moi), j'ai des limites cognitives bien en dessous de ce qu'il faudrait pour que tout soit bon du premier coup. Mais pour les grands chefs, c'est inacceptable. On doit maitriser le process, ne jamais être surpris, avoir tout planifié, et ne jamais improviser. Et la marmotte, elle fait la mise en production sans casse, sans surprise, tel que ça a été conçu, à la virgule près.

Sans compter le confort mental : j'ai fait une connerie? du Dev à la prod en passant par l'intégration et l'homologation, j'ai 4 livraisons de une minute chacune(chrono en main). Je sais que je peux retomber sur mes pattes. J'ai confiance. Le dev JAVA, il a peur - parcequ'à la moindre boulette, il en a pour une semaine pour réparer - et la peur est mauvaise conseillère.

Je répète : on avait des devis deux fois plus courts, et des dépassements moyens de 5 à 10%, là ou ils frôlaient les 20%. Juste à cause de ça. J'aurais détesté être à leur place.

Si je comprend bien ton retour d’expérience, les deux équipes étaient surtout différenciées par leur processus d'organisation.

Là où vous étiez très responsabilisé en COBOL avec une démarche DevOp bien intégrée, les Javaistes étaient englués dans une organisation lourde, bureaucratique et fastidieuse.
Intéressant comme comparaison je trouve.
Si tu pouvais plus détailler un peu plus les 2 processus, cela serait très instructif je pense.

J'imagine aussi que l'ambiance de travail devait être radicalement différente dans ces deux équipes.
Ça donnerai même presque envie de se mettre au COBOL pour rejoindre ton équipe

[el_slapper]

Si je comprend bien ton retour d’expérience, les deux équipes étaient surtout différenciées par leur processus d'organisation.

Pas seulement. La plupart ds cobolistes(même si il ya des exceptions) ne sont pas des informaticiens diplômés. La plupart des Javaïstes le sont. C'est une manière différente d'aborder les problèmes.

Là où vous étiez très responsabilisé en COBOL avec une démarche DevOp bien intégrée, les Javaistes étaient englués dans une organisation lourde, bureaucratique et fastidieuse.

Disons que la bureaucratie avait reculé devant la rébellion de mes prédécesseurs(et des MOA qui trouvaient bien pratique de pouvoir faire passer un truc imprévu en loucedé, si il n'était pas trop gros). "être responsabilisé", dans un grand compte, ça veut dire en prendre plein la gueule quand ça va mal. Pas avoir la liberté dons nous jouissions plus par inadvertance que par décision des grands chefs.

(.../...)Si tu pouvais plus détailler un peu plus les 2 processus, cela serait très instructif je pense.

En JAVA : les gens font leurs développements, puis ils les confient à la cellule d'intégration, qui prépare un livrable, qui le confie à une autre équipe, qui fait le build, le tout avec des piles effroyables de documents à chaque étape. En plus, ils n'avaient pas le droit de créer de classes. Il devaient faire avec l'existant, avec interdiction de dépasser, ou alors attendre que l'urbaniste les autorise à créer une nouvelle classe(avec, là aussi, des montagnes de paperasses signées par un nombre à deux chiffres de chefs).

En COBOL : la MOA passe un coup de fil au développeur, qui demande un mail avec sa chef en copie(oui, tous les chefs étaient des dames). 30 minutes plus tard, mail en main, il commence le développement. Si c'est un truc rapide, 2 heures plus tard, c'est en intégration, ou le dev teste, et 2 heures plus tard, c'est en homologation, ou la MOA teste. Puis la MOA envoie un mail de validation(si c'est bon, hein). 5 minutes plus tard, le composant est en prod. La chef a reçu 2 mails, et le développeur ne sait même pas si elle les a lus. Personne d'autre n'est intervenu.

c'était plus compliqué quand il fallait intervenir sur les JCL(nos scripts), ou sur les SPITAB(nos tables de référence). Là, il fallait faire des demandes aux équipes techniques. Pour le coup, généralement, ion évitait au maximum de les changer. Mais on avait de la chance : le délai pour les JCL officiel était de 15 jours, généralement, c'était fait en deux jours ouvrables. Par contre, pour les SPITAB, c'était long et douloureux, donc on trichait souvent: nos tables de paramétrage étaient en dur dans les programmes, c'était bien plus facile et rapide à modifier que des tables de paramétrage propres.

C'est horrible, hein? Mais il faut comprendre la MOA : entre "tu as la main pour faire comme tu veux les paramètres que tu veux, mais ça sera pris en compte dans 3 semaines", et "donne nous les nouveaux paramétrages, ça sera pris en compte dans 3 heures", la voie de la facilité est difficile à éviter.

J'imagine aussi que l'ambiance de travail devait être radicalement différente dans ces deux équipes.

oui. Après, eux, ils avaient le droit de recruter en masse, pas nous. Mais heureusement.....

Ça donnerai même presque envie de se mettre au COBOL pour rejoindre ton équipe

Bof, tout ceci a été dissous et confié à un prestataire extérieur. Mais quoique JAVA aurait fait joli sur mon CV, à aucun prix je n'aurait accepté d'en faire dans ces conditions. Parceque quand les MOA nous demandaient des trucs en urgent, généralement, ils avaient de très bonnes raisons. Et pouvoir répondre au quart de tour, c'était quand même sacrément confortable.

Le truc, c'est qu'avec une bonne gestion de conf(et nous en avions une excellente), TOUT ce que nous faisions était traçé. Donc un contrôle a postériori était toujours possible. Ce qui faisait que non, nous n'étions pas des cowboys. Nous étions des professionnels, surveillés comme il se doit dans un établissement qui gère des sous. Toute erreur devait être expliquée, et pouvait être traçés par un tiers. Toute faute était facile à démontrer. Dans ces conditions là, pourquoi demander à des chefs qui de toutes façons n'avaient pas de compétences techniques de tout valider? Ma chef me donnait mes priorité, et vérifiait que le backlog d'incidents était géré avec professionnalisme. Le reste? On réglait nôtre linge sale en famille. Ca aidait aussi beaucoup que nous étions tous des vétérans, des survivants. Un pack de débutants mal encadrés aurait sans doute été peu efficace, dans ces conditions.

En en fait, on en arrive à la vraie raison de la bureaucratie : les chefs partent du principe qu'ils ont des nullards, qu'il faut cornaquer fortement pour avancer un peu. C'est un mauvais calcul : les nullards n'avancent pas du tout, même fortement cornaqués. Et les bons sont juste freinés quand on les cornaque. Et les moyens sont rares, en fait, ils deviennent vite bons...ou chefs.

[Invité]

L'expérience consiste en intensité, non en durée.
Thomas Hardy

Et pour éclairer le débat junior/sénior et le écarts de salaires qui peuvent écarter les seconds des rangs des SSII, je dirai que l'essentiel et de justifier cet écart.
Je vais employer des mots qui sont peut-être durs mais je suis quadra et donc ça s'applique à moi également.
Personne, je dis bien personne n’accepte de payer plus cher le même service.
Essayez d'aller vendre le même pain que le boulanger d'en face ne serait-ce que 20% plus cher. Vous en vendrez beaucoup ?
On accepte ce surcoût car le service/bien est plus joli, fiable, classe, bon, valorisant, ... mais en aucun cas sans raison.
Si nous (quadra/quinqua) voulons mériter cette surcote il faut la mériter.
Rester à l'écoute des techno, du marché et compenser une hypothétique baisse d'intellect par la sagesse, l'instinct, l'expérience, la claivoyance, l'aura, ...
Et je doute que le mensonge et la manipulation, comme j'ai pu le lire dans ce post, soient les valeurs dont notre société a besoin.

[Luckyluke34]

L'auteur du blog d'origine confond simplement senior et bon développeur. Le problème, c'est que bon développeur est une notion très subjective, il cite des qualités mais on pourrait en enlever ou en rajouter.

Dans tous les domaines, et y compris étymologiquement, senior veut juste dire "qui a vécu plus longtemps". Je ne vois pas pourquoi ça serait différent en développement. C'est juste les gens qui font un amalgame instinctif entre senior et qualité mais ce n'est pas intrinsèquement lié.

Il faudrait trouver un autre terme pour nommer ce qu'il décrit. A la limite, je préfère vétéran qui reflète mieux la capacité à prendre des décisions tactiques éclairées par une expérience passée parfois douloureuse. Ou sinon, suffixer "senior" par le sous-domaine de l'informatique où on se situe, s'il existe des critères d'excellence et de "seniorité" communément admis dans ce sous-domaine (et je pense que ça n'existe pas à l'heure actuelle).