Interview de ma mère, programmeuse COBOL sur mainframe (2016)
(ezali.substack.com)Interview de ma mère, programmeuse COBOL sur mainframe
- Ma mère travaille depuis avant ma naissance dans l’une des plus grandes banques de l’UE.
- Le monde de la programmation bancaire est totalement différent de celui que la plupart des gens connaissent.
- Si ma mère et son équipe arrêtaient de travailler, la banque ferait faillite en quelques semaines.
1991
- Ma mère a commencé une formation interne chez Nordbanken (aujourd’hui Nordea).
- Elle a passé divers tests, dont un test de QI, un test psychologique et un test de multitâche.
- Elle a débuté comme programmeuse COBOL sur mainframe IBM et, 25 ans plus tard, elle occupe toujours le même poste dans la même banque.
COBOL
- COBOL n’est pas un langage de programmation sophistiqué comme le Haskell fonctionnel ou le Golang orienté concurrence.
- COBOL est un langage impératif et procédural, et il est orienté objet depuis 2002.
- Dans le contexte de la programmation sur mainframe, très peu de gens connaissent COBOL.
Base de données
- La base de données principale s’appelle IMS, une base de données hiérarchique créée par IBM pour le programme Apollo.
- Une migration vers DB2 est en cours de tentative, mais c’est un chantier qui prendra des années.
- La base de données DB2 contient actuellement environ 10 To de données.
Batch
- Environ 80 % du système est constitué de traitements batch.
- Les traitements batch s’exécutent à des horaires précis ou à intervalles réguliers, pour traiter des données ou les transmettre à d’autres banques ou institutions.
Problèmes auxquels les banques font face
- Les banques qui utilisent des mainframes ont de nombreux problèmes à gérer.
- Les programmeurs vieillissent, et il faut 2 à 3 ans avant qu’une nouvelle recrue puisse travailler de façon autonome.
- Il existe des programmes vieux de plusieurs décennies, et personne ne sait ce qu’ils font.
Dernier mot
- Il est très intéressant de voir quelles nouvelles technologies Nordea et les autres banques adopteront dans les années à venir.
Q & A
- Pourquoi avoir choisi la programmation COBOL sur mainframe IBM ? Parce qu’elle voulait travailler avec des ordinateurs.
- Quel a été le pire moment d’une journée de travail ? Un collègue a oublié un point dans un module système critique, et la banque est restée hors service pendant 16 heures.
- Quel sera l’avenir des banques ? Elles ont conscience qu’elles doivent remplacer les mainframes par quelque chose de moderne.
- Quels défis avez-vous rencontrés en tant que femme programmeuse dans les années 90 ? Aucun problème.
- Est-ce ennuyeux de travailler sur la même base de code pendant plus de 20 ans ? Construire de nouveaux systèmes a toujours été amusant.
- Est-ce effrayant d’écrire du code pour une banque ? Très effrayant, mais l’environnement de test est solide, donc dans la plupart des cas tout se passe bien.
- Avez-vous déjà commis une grosse erreur pour la banque ? En 1997, elle a fait une erreur qui permettait de retirer illégalement de l’argent d’un compte d’épargne retraite.
- Comment est l’environnement de travail ? Ils sont passés de bureaux individuels à un open space, ce qu’elle déteste profondément.
L’avis de GN⁺
- Les mainframes et le langage COBOL jouent encore un rôle important dans l’industrie financière, et l’expertise sur ces technologies a beaucoup de valeur.
- La complexité des systèmes bancaires et la dépendance à des technologies anciennes rendent la transition vers de nouveaux systèmes difficile, ce qui constitue un défi majeur.
- Cette interview montre que, malgré la rapidité de l’évolution technologique, certains secteurs utilisent encore des technologies anciennes, ce qui crée un contraste intéressant.
1 commentaires
Avis de Hacker News
La soumission HN originale de 2016 était https://news.ycombinator.com/item?id=12096250
Si vous cherchez d’autres lectures sur le thème « le monde de la programmation bancaire est un univers complètement différent de celui auquel la plupart d’entre nous sont habitués », An oral history of Bank Python est aussi très intéressant : https://calpaterson.com/bank-python.html
C’était aussi passé sur HN à l’époque : https://news.ycombinator.com/item?id=29104047
https://news.ycombinator.com/item?id=12097032
On entend souvent dire que « si vous êtes un programmeur mainframe de 20 ans, votre âge a une valeur énorme et vous serez très bien payé », mais en réalité la rémunération est généralement moyenne, voire inférieure à la moyenne, ce qui crée un problème de vivier de talents
Ce qui a vraiment de la valeur, ce n’est pas la compétence en soi, du type « connaître COBOL », mais la connaissance organisationnelle de l’immense logique métier accumulée dans le COBOL. Un développeur moyen peut apprendre COBOL, mais quand un programmeur COBOL retraité revient avec un contrat à 500 000 dollars par an, ce n’est pas à cause de COBOL : c’est à cause de la connaissance institutionnelle accumulée
Si les banques et les institutions payaient réellement très cher les jeunes programmeurs mainframe, le problème démographique actuel serait moins marqué
Le projet étant jugé presque terminé, l’équipe de réécriture s’était suffisamment familiarisée avec COBOL pour que l’on considère pouvoir faire le reste sans lui. Mais en pratique, même si elle comprenait COBOL, sa connaissance institutionnelle restait indispensable. Au final, il est revenu à temps partiel, à un tarif de consultant absurdement élevé, jusqu’à la fin de la transition, tout en poursuivant ses études doctorales pour monter en compétence
Un programmeur correct peut lire et suivre un programme COBOL. Mais il ne saura pas pourquoi un export critique plante pendant l’extraction de données pour une déclaration 10-K. Parce que quelqu’un avait supposé qu’un certain nombre d’enregistrements ne dépasserait jamais 3000, et avait codé en dur une erreur si cette valeur était dépassée
En réalité, j’étais payé nettement moins que dans mon précédent emploi d’installation d’infrastructures de câblage physique, c’est-à-dire de fibre optique et d’Ethernet cuivre, et si j’avais choisi ce poste, c’était surtout parce qu’il y avait la climatisation au bureau. Ce n’était pas un métier dont je voulais faire ma carrière
Quand j’ai travaillé chez un fournisseur cloud comme administrateur systèmes Windows intermédiaire au support téléphonique client, je gagnais près de 30 % de plus que comme junior mainframe en banque/assurance. Même si c’était une compétence rare dans un secteur à forte valeur, le travail sur mainframe était bien moins rémunéré, et dans cette entreprise les développeurs mainframe étaient les développeurs les moins bien payés à tous les niveaux d’expérience. Les seuls à être correctement rémunérés étaient les contractuels indépendants qui avaient travaillé 30 ans avant de prendre leur retraite
Mais les salaires de ce type de poste sont désastreux par rapport à ce que l’on peut obtenir avec d’autres technologies, et la vie moderne pousse fortement à chercher une meilleure rémunération
Ce programme proposait le tarif de marché « équitable » pour les postes débutants du secteur, et permettait de passer par 2 ou 3 équipes ou départements durant la première année. À la fin, si l’entreprise vous plaisait toujours, le candidat pouvait choisir l’équipe qu’il rejoindrait en CDI, mais sans augmentation de salaire ; à ce stade, les personnes qui n’avaient pas réussi à produire rapidement avaient déjà été filtrées
Du point de vue de l’entreprise, le résultat était excellent. Elle pouvait employer pour 60 000 à 70 000 dollars par an de jeunes programmeurs plus compétents en COBOL que leurs nouveaux collègues, tandis que les collègues seniors ou présents depuis longtemps touchaient selon les cas 200 000 à 400 000 dollars
Ma grand-mère programmait avec des cartes perforées, mais je ne sais pas sur quel matériel, et il est trop tard pour lui demander. Mon père a beaucoup fait de Fortran et de COBOL sur des mainframes soviétiques, puis beaucoup de travaux liés à l’an 2000 aux États-Unis
L’objet le plus cool dans tout ça, c’est une sortie imprimée d’un programme Fortran que mon père avait autrefois déchirée en trois morceaux pour envelopper un grand film 64 mm de photos de montagne qu’il avait prises. Elle venait probablement d’un mainframe Minsk-32 ; le programme s’appelle MATR1, manipule des matrices, et les commentaires mentionnent le relief. Elle est maintenant encadrée au mur près de mon établi
J’ai moi-même codé toute ma vie dans plusieurs langages, et maintenant mon ado s’intéresse au code au lycée avec Java et Python. En route vers la 4e génération de programmeurs
Si l’on dit vrai en affirmant que c’est le poste le plus important de la banque du point de vue technique, alors, compte tenu de la part de marché de Nordea en Suède et dans les pays nordiques, la disparition de cette équipe pourrait ébranler l’économie suédoise, voire nordique. Cela aurait sans doute aussi un effet non négligeable sur l’UE.
Depuis que j’ai lu cet article, je me demande sans cesse si les programmeurs COBOL qui font tourner ce type de banques ne constituent pas, dans plusieurs grandes économies du monde, un bus factor massivement sous-estimé. Je me demande aussi quel est le plan de secours dans une telle situation.
[0] https://en.wikipedia.org/wiki/Nordea
Je pense que la perte de connaissances institutionnelles a été un facteur majeur dans cette catastrophe.
Si l’on ajoute à cela la hausse des ventes de SUV, plus dangereux pour les piétons et les cyclistes, il est presque étonnant que les banques s’effondrent à cause d’une mauvaise comptabilité et de fraudes plutôt qu’à cause de programmeurs morts.
Le passage où elle dit : « j’avais mon propre bureau, et maintenant on nous a déplacés dans un open space où l’on s’assoit où l’on veut, et je déteste ça » résonne étrangement fort, même sans avoir jamais travaillé sur mainframe.
Quand la chaise, la position et la luminosité des écrans, la hauteur du bureau, etc. sont réglées pour soi, le concept même de hot desking devient absurde. J’aimerais qu’on l’abandonne officiellement.
Quand je travaillais comme consultant en intégration de systèmes dans les services financiers, je devais souvent m’intégrer à ce type de systèmes bancaires cœur.
En général, négocier une interface entièrement nouvelle entraînait tellement de frictions techniques, métier et de conformité réglementaire qu’un projet pouvait facilement prendre un ou deux ans de retard, voire plus ; on essayait donc de réutiliser les points d’intégration existants de projets précédents.
L’intégration consistait le plus souvent à transmettre des documents structurés avant une certaine heure le soir, pour des traitements batch nocturnes. Les documents de données à base d’offsets comportaient, par conception, des zones encore non attribuées prévues pour de futures mises à jour et utilisations ; quand une nouvelle information était nécessaire, on négociait quels octets pouvaient être utilisés.
Côté extraction de données, on cherche parfois une API plus « moderne », mais il ne faut pas trop s’attendre à du REST finement découpé. On se retrouve souvent en réunion avec les équipes réglementation et conformité pour trouver comment éviter de coûteux développements nouveaux.
Au passage, les responsables conformité étaient souvent bien plus pragmatiques et orientés solution que l’IT. Il était parfois plus difficile de convaincre notre équipe que le libellé d’une règle ne devait pas forcément être interprété littéralement de la manière la plus restrictive que de se mettre d’accord avec la conformité.
Si l’on imagine cette couche d’intégration s’accumuler pendant des décennies, à travers des centaines de projets, on commence pour la première fois à comprendre pourquoi le remplacement d’un système cœur est si difficile.
Ma belle-mère a passé toute sa carrière dans le service IT d’une compagnie d’assurance. Elle n’a pas beaucoup programmé, mais avec le temps elle est devenue une source de connaissance métier.
Elle a beaucoup d’histoires d’autrefois. Avant les vrais systèmes informatiques, tout était bien sûr stocké sous forme de documents physiques, et son premier projet après l’université consistait à faire le tour de bureaux satellites pour réorganiser le système de classement des agences conformément à la nouvelle stratégie définie par le siège.
Pendant que l’équipe sortait littéralement tous les documents, les réétiquetait puis les remettait en place, l’activité de l’agence concernée s’arrêtait, et le projet entier a pris plus d’un an. Cela a un peu changé ma façon de voir mon propre travail.
J’aurais dû parler davantage avec ma grand-mère avant qu’elle ne soit atteinte de démence. Je savais qu’elle était mathématicienne et programmeuse, mais lors d’une brève conversation il y a quelques années, elle m’a dit qu’en Union soviétique elle travaillait au calcul des orbites de satellites.
J’espère au moins qu’il s’agissait bien de satellites.
À 20 ans, elle a obtenu une licence de mathématiques en trois ans, et dans les années 1970 elle programmait des ordinateurs avec des cartes perforées.
Aujourd’hui, elle n’arrive même plus à nouer ses lacets de façon fiable. Je vous encourage à consigner les réussites et les récits de vie de vos proches avant qu’il ne soit trop tard.
Elle est facile à utiliser, propose beaucoup de questions prérédigées, et vous pouvez aussi créer les vôtres. Vous enregistrez directement sur votre téléphone et, si vous le souhaitez, vous pouvez téléverser l’entretien à la Bibliothèque du Congrès des États-Unis.
https://storycorps.org/participate/storycorps-app/
Ma grand-mère a eu 95 ans cette année. Elle va encore tous les jours dans un institut de recherche de l’ex-bloc soviétique pour écrire des simulations numériques en Fortran et Maple.
Ses collègues ne veulent toujours pas qu’elle parte à la retraite, et elle la repousse elle-même chaque année. Ses connaissances en analyse numérique et en mathématiques sont remarquables, et j’en suis vraiment fier.
Son premier poste de programmation était dans une entreprise de transport, où de nombreux programmeurs travaillaient depuis 15 à 20 ans ou plus ; une bonne partie d’entre eux assuraient surtout la maintenance du COBOL qui faisait tourner l’activité.
Parmi ces programmeurs seniors, il y avait beaucoup de femmes, et dans le groupe senior elles semblaient représenter plus de 50 %. Ce qui était triste, c’est que, chez les jeunes programmeurs, il y avait encore pas mal de femmes, mais la majorité était des hommes.
Comme cette entreprise recrutait surtout dans les écoles d’ingénieurs locales, cela ressemblait à un exemple intéressant de la baisse, au fil du temps, du nombre de femmes entrant dans les filières de génie logiciel.