Discussion :

[landry161]

Euh "expliquer" la qualité de ce code, je vois mal comment faire ça sans connaître le manager et l'équipe qui l'a fait, leurs contraintes, leur budget... On ne peut que constater le résultat. Ou spéculer et dire que ce sont des comptables de métier qui ont appris à programmer sur le tas?

Ah oui

[Peut-êtreUneRéponse]

Dans les années 80, une époque que vous n'avez sans doute pas connu , il existait une grande entreprise française, BULL SA, qui sous pilotage du gouvernement français concurrençait les grands fabricants d'infra informatique centralisée, dites Mainframe, avec ses machines DPS* qui tournaient sous GCOS Vs les systèmes MVS/ESA d'IBM (IBM z sous z/OS de nos jours). Tous les clients gouvernementaux et les sociétés industrielles nationalisées sous François Mitterrand (CGE qui deviendra plus tard Alcatel, Thompson, Saint Gobain, Honeywell...) étaient client de BULL SA. Plus de détail ici.

Mais quel rapport avec le schmilblick me diriez-vous? Mais tout!

Comme le souligne @Marsupial, le code de la taxe d'habitation fait référence au système d'exploitation GCOS dans ses commentaires:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
/*============================================================================
   Contrôle de la signature
   la presence d'un commentaire dans la fonction permet de récupérer la valeur
   de la signature dans la compilation sous GCOS
  ============================================================================*/

Et mon petit doigt me dit que la remarque de @Guntha aussi :

Des noms de fichier qui font tous 8 lettres, comme si le programme avait été développé sous DOS???

Bref, le code ne date pas de cette année, et comme le disent certains il a peut-être 20 ans ou plus, avec un nombre incalculable de retouches et modifications par différentes personnes expertes ou pas.

Au final il fonctionne toujours et ma déception est grande chaque mois de novembre depuis tant d'année

Pour les personnes intéressées par l'archéologie voici le User Guide du langage C sous GCOS 7, une des des dernière mise à jour qui date de 2006, à peine 11 ans, une époque où le cloud n'existait que dans le ciel...

[Edrixal]

Par exemple, dans TH-7KSTS.H, on peut lire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 long somrc ; /* somme a recouvrer                      */

À la place, il aurait fallu écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 long somme_a_recouvrer;

Parfois, le commentaire est trop long pour entrer dans le nom de la variable, donc la présence du commentaire peut se justifier. Mais, indépendamment de la présence du commentaire, à moins qu'une variable n'ait une portée très courte, il faut lui donner un nom lisible.

Quand les variables sont mal nommées, ce qui est trop souvent le cas dans ce code, cela oblige à faire des allers-retours quand on lit le code.

Oui et non. Par exemple, quand tu travaille dans le monde de l'assurance, ITT, IPT, EXO, DCPTIA, RC, ect... sont des abréviations qui te parle. Ré-utiliser ses abréviations pour nommer ses variables n'est pas une chose absurde, à partir du moment ou le code écrit reste destiner au monde de l'assurance et donc pour des personnes qui connaissent ses abréviations.

Je ne connais pas spécialement le monde de la finance ou des taxes. Mais peut être qu'il est courant chez eux d'utiliser l'abréviation somrc pour définir une comme à recouvrer. (Pour ne reprendre que l'exemple cité).

Je suis d'accord que ce n'est pas clair au premier abords pour des néophytes de ce monde là. Que le code pourrait être plus lisible pour un plus grand nombre. Mais dans une optiques de travail en groupe qui peuvent avoir leur propre "langage", cela ne me choque pas outre mesure.

Maintenant si quelqu'un peut m'affirmer que somrc ou somme RC ne ce dit pas dans le domaine des taxes/finances et que c'est une abréviation totalement arbitraire ou personnelle au codeur, je rejoint ton avis ^^

[Marco46]

@Peut-êtreUneRéponse

Ok merci, donc 38 ans de dette technique non payée. Sympa.

[Marco46]

Maintenant si quelqu'un peut m'affirmer que somrc ou somme RC ne ce dit pas dans le domaine des taxes/finances et que c'est une abréviation totalement arbitraire ou personnelle au codeur, je rejoint ton avis ^^

On utilise pas d’abréviation pour le nommage c'est un basique, point final. Peu importe les habitudes du métier. On doit être explicite quand on nomme des variables.

[Guntha]

On utilise pas d’abréviation pour le nommage c'est un basique, point final. Peu importe les habitudes du métier. On doit être explicite quand on nomme des variables.

Si on suit ta logique, le langage C lui-même n'obéit pas à cette règle "basique"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
int //au lieu de "integer"
float //au lieu de "floating-point number
main //au lieu de "main function" ou "entry point"
char // au lieu de "character"

Et je ne parle même pas de la libc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
strcmp
strcmp
strcat
memcpy
memchr
malloc
realloc
qsort
fopen
fclose
etc...//On utilise même des abréviations quand on parle français!

Et comment peut-on être plus explicite que le langage métier?

Et si le développement de ce code a vraiment commencé il y a plus de 20/30 ans sur GCOS, je trouve qu'il n'est pas si tarabiscoté que ce à quoi on pourrait s'attendre.

[Pyramidev]

Pour résumer mon avis sur les acronymes et abréviations, je vais m'appuyer sur un autre exemple de TH-7KSTS.H :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

double coeff_FAR_THS_s ; /* coefficient FAR THS du syndicat              */

Dans cet exemple, on devine que les acronymes FAR et THS sont connus du métier, puisqu'ils apparaissent même dans le commentaire.
Je ne suis pas du tout contre la présence des acronymes FAR et THS dans le nom de la variable. Autrement, le nom serait trop long.

Je ne suis pas contre non plus l'abréviation coeff. pour coefficient, car tout le monde la connaît.

Le s final comme abréviation de syndicat, par contre, me semble douteux.
Je pense que la variable aurait dû s'appeler soit coeff_FAR_THS_syndicat, soit coeff_FAR_THS_du_syndicat.

[Pyramidev]

Et je ne parle même pas de la libc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
strcmp
strcmp
strcat
memcpy
memchr
malloc
realloc
qsort
fopen
fclose
etc...//On utilise même des abréviations quand on parle français!

D'un autre côté, aujourd'hui, concernant le nommage, la bibliothèque standard du C est vraiment un exemple à ne pas suivre !

[KsassPeuk]

Si on suit ta logique, le langage C lui-même n'obéit pas à cette règle "basique"

Ouais enfin, citer C comme l'exemple de choses à faire, c'est un peu fort de café.

EDIT: grillé, comme quoi.

[el_slapper]

@Peut-êtreUneRéponse

Ok merci, donc 38 ans de dette technique non payée. Sympa.

on peut aussi regarder dans l'autre sens : 38 ans de corrections et d'ajustements qui font que ça marche dans tous les cas. J'ai moi-même travaillé sur du code de 36 ans d'âge, dans le privé, bien plus moche que ça (j'y fais parfois référence), et ça a beau être immonde, ça marche. Ca marche parce-que ça a été confronté au monde réel pendant des dizaines d'années. Ca marche parce-que toutes les erreurs du départ ont été corrigés par des verrues. Moches mais efficaces. Refondre un code pareil, ça n'a rien d'évident. D'ailleurs, j'avais laissé certains morceaux tels quels. Ca marche, ça ne change jamais, pourquoi prendre le risque? J'avais refondu, en plus propre, tout ce qui était susceptible de bouger, et en plus tout ce qui état refondable sans trop de risques. Mais un code de taxe d'assurances illisible, incompréhensible, dont les experts métiers ne savent pas comment il marche, mais qui n'a pas connu de bug depuis plus de 20 ans? Non, je n'allais pas me lancer là-dedans.

Il y a toujours un équilibre à trouver entre refaire au propre et garder ce qui marche. être extrémiste dans un sens ou dans l'autre est contre productif. Dans un sens, parce-qu'effectivement on termine avec des horreurs illisibles. Dans l'autre sens, parce-qu'on prend des risques parfois excessifs au nom de la pureté visuelle du code. Perso, un code un peu moche, un peu dépassé, mais qui s'intègre parfaitement dans un existant ancien et qui tourne comme du papier à musique, ça ne me choque pas. Même si ça n'est pas totalement satisfaisant.

[Marco46]

ça marche.

Mais c'est pas une option que ça marche. C'est hallucinant ça ! Tu veux pas qu'on leur donne une médaille en plus ?

Ca marche, ça ne change jamais, pourquoi prendre le risque?

Parce que le jour où on doit faire une modif pour une raison x ou y on l'a dans l'os.

T'es en train de me dire qu'il est inutile de nettoyer ta cuisine parce que t'arrive encore à faire à bouffer. C'est inacceptable.

Il y a toujours un équilibre à trouver entre refaire au propre et garder ce qui marche.

Il faut arrêter avec cette mentalité détestable. On est des pros, tout ce qu'on livre doit répondre au besoin exprimé, être propre et facile à faire évoluer. Si c'est pas fait comme ça, poubelle on refait. Il y a des gens qui ont pris le temps d'engager ces débats et de trouver des solutions, il faut les lire et intégrer leurs solutions dans nos pratiques, les Oncle Bob, Martin Fowler, Kent Beck, Ian Cooper, etc ... Et il faut adopter la culture DevOps. Si on veut numériser les services de l'état c'est la seule voie possible.

Alors vous allez me dire, calme toi ils viennent seulement d'open sourcer leurs codes. Et bien je dis non, ils n'ont rien open sourcé puisqu'ils ne se servent pas de ces repos. Ils ont juste publier une version x de leur code et ils n'y a aucune stratégie globale, d'un service à l'autre ça publie sur GitLab ou GitHub ou FramaGit, c'est du grand n'importe quoi. On est littéralement au degré ZERO de la numérisation de nos services et ce qui est annoncé depuis que Jupiter est passé en orbite n'est pas vraiment de nature à me rassurer ...

[el_slapper]

Mais c'est pas une option que ça marche. C'est hallucinant ça ! Tu veux pas qu'on leur donne une médaille en plus ?

Il y a "ça marche à peu près", et il y a "ça tourne comme du papier à musique depuis 20 ans, sans une anicroche". Aucun programme tout neuf n'entre dans la deuxième catégorie.

Parce que le jour où on doit faire une modif pour une raison x ou y on l'a dans l'os.

Certes. C'est pour ça que j'ai refait les trois autres quarts de l'appli au propre. Tout ce qui était refaisable et testable a été refait et testé. Ca a été très couteux. Mais effectivement, ça a réglé la dette technique qui coutait cher en intérêts et qui avait un cout en capital modéré. La partie purement comptable, celle que je n'ai paas touchée, ellle, ne coutait strictement rien en intérêts, et aurait couté une blinde en termes de capital investi.

T'es en train de me dire qu'il est inutile de nettoyer ta cuisine parce que t'arrive encore à faire à bouffer. C'est inacceptable.

Ton analogie est fausse. Je nettoie la vitrocéramique à chaque fois que je m'en sers. Si je ne m'en sers pas pendant trois jours, je ne la nettoie pas pendant 3 jours. Et je ne laisse pas ma femme faire, parce-qu'elle ne nettoie pas comme il faut, et que la situation est pire après son passage qu'avant.

Il faut arrêter avec cette mentalité détestable. On est des pros, tout ce qu'on livre doit répondre au besoin exprimé, être propre et facile à faire évoluer. Si c'est pas fait comme ça, poubelle on refait. Il y a des gens qui ont pris le temps d'engager ces débats et de trouver des solutions, il faut les lire et intégrer leurs solutions dans nos pratiques, les Oncle Bob, Martin Fowler, Kent Beck, Ian Cooper, etc ... Et il faut adopter la culture DevOps. Si on veut numériser les services de l'état c'est la seule voie possible.

Je vais reprendre une réponse que j'ai fait ailleurs : toutes ces solutions, c'est bon pour des gens comme toi et moi qui sommes intéresses par faire du bon boulot. Pas pour le programmeur standard(je n'ai pas parlé des mauvais, hein, juste des moyens). Et il n'y a pas assez de bons programmeurs pour faire ça partout. Et, pire, la plupart des décideurs sont bien incapables de faire la différence entre un bon et un moyen.

Et un moyen, je préfère qu'il fasse un verrue moche - qui marchera - plutôt que de se lancer dans un refactoring ou il va tout casser. Il va se sentir maitre du monde, oublier de tester des trucs, éliminer des "verrues" moches mais qui corrigent des busg dangereux, et laisser un champ de ruines derrière lui.

Alors vous allez me dire, calme toi ils viennent seulement d'open sourcer leurs codes. Et bien je dis non, ils n'ont rien open sourcé puisqu'ils ne se servent pas de ces repos. Ils ont juste publier une version x de leur code et ils n'y a aucune stratégie globale, d'un service à l'autre ça publie sur GitLab ou GitHub ou FramaGit, c'est du grand n'importe quoi. On est littéralement au degré ZERO de la numérisation de nos services et ce qui est annoncé depuis que Jupiter est passé en orbite n'est pas vraiment de nature à me rassurer ...

Voilà. L'état ne sait pas recruter des cadors(mais ça, ce n'est ni nouveau no spécifique à notre corps de métier), et adapte donc des méthodes qui sont moins satisfaisantes, mais qui dans son cadre, permettent quand même de fonctionner. Évidemment que les meilleurs ont des décennies d'avance là-dessus. Mais l'état ne peut pas les recruter. Alors il prend des décisions rationnelles, en fonction de ses moyens humains, pour obtenir un résultat qui fonctionne aussi bien que possible pour un cout aussi bas que possible.

Pour revenir au quart de l'appli moche que je n'ai pas refactoré : va expliquer à un financier que tu vas prendre 6 mois pour permettre la maintenance facile d'un composant qui a zéro maintenance depuis 20 ans, et que comme personne ne comprend ce que ça fait, le risque que ça ne marche plus est fort. Il va t'envoyer bouler et il aura raison. Nous sommes des professionnels. Nous sommes payés pour la valeur ajoutée que nous apportons à l'entreprise. Il n'y a aucune valeur ajoutée à se faire plaisir à refaire ce qui marche, surtout quand la probabilité d'une maintenance est très faible. C'est un risque, certes, mais le risque ne change pas avec les années. Le code ne vieillit pas si le fonctionnel en face ne vieillit pas non plus. Ce sera peut-être à faire un jour en cas de besoin, mais peut-être jamais. On ne grille pas 6 mois de boulot pour un risque qu'un gèrera pareil de toutes façons si un jour il se réalise. C'est de la bête gestion de risque financier.

Après, toi, tu apportes un point de vue purement technique, que je peux comprendre. Mais nous ne sommes pas seuls, et la boite doit avancer. Les ressources sont limitées, et il faut les allouer là ou on peut être rentable. Sur les trois quarts que je me suis fadé, il y avait des composants hautement changeants, et les remettre au propre a fait des économies massives sur la maintenance. C'est bien là qu'il fallait intervenir. Là, et pas ailleurs.

[Marco46]

Ton analogie est fausse. Je nettoie la vitrocéramique à chaque fois que je m'en sers. Si je ne m'en sers pas pendant trois jours, je ne la nettoie pas pendant 3 jours. Et je ne laisse pas ma femme faire, parce-qu'elle ne nettoie pas comme il faut, et que la situation est pire après son passage qu'avant.

Ce que je veux dire c'est que c'est pas acceptable de baigner dans son caca. On peut pas se laisser vivre comme ça.

Je vais reprendre une réponse que j'ai fait ailleurs : toutes ces solutions, c'est bon pour des gens comme toi et moi qui sommes intéresses par faire du bon boulot. Pas pour le programmeur standard(je n'ai pas parlé des mauvais, hein, juste des moyens). Et il n'y a pas assez de bons programmeurs pour faire ça partout. Et, pire, la plupart des décideurs sont bien incapables de faire la différence entre un bon et un moyen.

[...]

Voilà. L'état ne sait pas recruter des cadors(mais ça, ce n'est ni nouveau no spécifique à notre corps de métier), et adapte donc des méthodes qui sont moins satisfaisantes, mais qui dans son cadre, permettent quand même de fonctionner. Évidemment que les meilleurs ont des décennies d'avance là-dessus. Mais l'état ne peut pas les recruter.

En l'occurrence on parle de numériser les services de l'état. Il n'y a pas besoin de former 500 000 développeurs, il en faut grand max 20 pour démarrer. Avec seulement le budget annuel de la Hadopi (qui est d'une inutilité affligeante, ça nous déjà couté plus de 100 millions d'euros pour rien cette histoire !) et un petit appel au patriotisme ou au sens civique des citoyens ça serait parfaitement viable et gérable pour une somme tout à fait modique. Même pas besoin d'embaucher, tu prends des contractuels voire les meilleurs freelances possibles pour initier le mouvement et former les fonctionnaires existants.

Ça s'appelle avoir une politique numérique. Ce que n'a pas le gouvernement parce qu'on a des communicants et des tanches aux manettes.

Alors il prend des décisions rationnelles, en fonction de ses moyens humains,

Justifier l'incompétence par la rationalité c'est chaud quand même.

pour obtenir un résultat qui fonctionne aussi bien que possible pour un cout aussi bas que possible.

Ah bah non tu peux pas dire ça. Là vu la politique mise en œuvre sur le cloud par exemple ça va nous couter une blinde et ça va être de la merde. En aucun cas tu peux dire qu'ils cherchent à faire pas cher du mieux possible. Ils font n'importe quoi.

va expliquer à un financier que tu vas prendre 6 mois pour permettre la maintenance facile d'un composant qui a zéro maintenance depuis 20 ans, et que comme personne ne comprend ce que ça fait, le risque que ça ne marche plus est fort. Il va t'envoyer bouler et il aura raison.

Mais le financier il a pas se mêler de ça c'est pas son métier. Le financier il attribue des budgets et ensuite les services se gèrent. Le problème c'est qu'on a mis des financiers qui ne pinent rien à la tête de services techniques.

Nous sommes des professionnels. Nous sommes payés pour la valeur ajoutée que nous apportons à l'entreprise.

C'est très exactement ce que je me tue à expliquer.

Il n'y a aucune valeur ajoutée à se faire plaisir à refaire ce qui marche,

Ça n'a absolument aucun rapport avec ça. Il s'agit d'avoir un service fonctionnel et moderne, au niveau du rang de la 5ème puissance économique mondiale. On est pas la Roumanie bordel.

surtout quand la probabilité d'une maintenance est très faible.

Ça tu n'en sais absolument rien tu n'as pas de boule de cristal pour savoir ce que le pouvoir législatif fera dans le futur. Il faut donc être prêt à évoluer n'importe quand. Always ready to deploy.

Si on avait une vraie politique on engagerait ce gars comme CTO des services informatiques de l'état pour les 10 prochaines années avec ce programme :

Exactement comme un grand club va chercher un grand entraineur avec un pont d'or.

[Pyramidev]

Nous sommes des professionnels. Nous sommes payés pour la valeur ajoutée que nous apportons à l'entreprise. Il n'y a aucune valeur ajoutée à se faire plaisir à refaire ce qui marche, surtout quand la probabilité d'une maintenance est très faible. C'est un risque, certes, mais le risque ne change pas avec les années. Le code ne vieillit pas si le fonctionnel en face ne vieillit pas non plus.

Ça dépend. Même quand le besoin auquel répond le vieux code n'évolue pas, refaire le code a de la valeur ajoutée dans le cas où une partie du code devient réutilisable pour de nouveaux développements.

En effet, quand on fait un nouveau développement, il est plus productif de réutiliser des briques du code existant déjà propres, déjà testées et déjà documentées que de refaire le travail parce que l'existant est une grande boule de boue dont on ne peut rien extraire.

C'est pour ça que le DRY (Don't Repeat Yourself) augmente généralement la productivité.

Cela dit, la facilité avec laquelle on peut respecter le DRY dépend de la puissance d'abstraction offerte par le langage.

[el_slapper]

Ce que je veux dire c'est que c'est pas acceptable de baigner dans son caca. On peut pas se laisser vivre comme ça.

Mais est-ce à la portée du développeur moyen? Je ne parle pas du lecteur de DVP qui par sa simple présence démontre sa supériorité. Non, je parle du gugusse lambda qui essaye juste de gagner sa vie.

En l'occurrence on parle de numériser les services de l'état. Il n'y a pas besoin de former 500 000 développeurs, il en faut grand max 20 pour démarrer. Avec seulement le budget annuel de la Hadopi (qui est d'une inutilité affligeante, ça nous déjà couté plus de 100 millions d'euros pour rien cette histoire !) et un petit appel au patriotisme ou au sens civique des citoyens ça serait parfaitement viable et gérable pour une somme tout à fait modique. Même pas besoin d'embaucher, tu prends des contractuels voire les meilleurs freelances possibles pour initier le mouvement et former les fonctionnaires existants.

Pour Hadopi, tu prêches un convaincu, je ne reviens pas dessus.

Pour le reste, je crois que tu sous-estimes gravement la difficulté pour une grosse organisation(les grosses boites privées ont toutes le même problème) comme l'état de recruter les meilleurs.

Ça s'appelle avoir une politique numérique. Ce que n'a pas le gouvernement parce qu'on a des communicants et des tanches aux manettes.

En quoi est-ce différent de tous les gouvernements du monde? (à part peut-être les portuguais, et encore)?

Justifier l'incompétence par la rationalité c'est chaud quand même.

Tu prends un raccourci. Ce que je dis, c'est qu'une structure de la taille d'un état, pour qui l'informatique n'est pas le cœur de métier(google, j'aurais un autre discours, évidemment), n'a pas les moyens de recruter les meilleurs. Et est donc contrainte de mettre en place des stratégies qui seraient sous-optimales avec des gens haut-de-gamme(je n'ai rien à redire sur ta démonstration), mais qui ont l'avantage de fonctionner même avec des gens de qualité moyenne.

Ah bah non tu peux pas dire ça. Là vu la politique mise en œuvre sur le cloud par exemple ça va nous couter une blinde et ça va être de la merde. En aucun cas tu peux dire qu'ils cherchent à faire pas cher du mieux possible. Ils font n'importe quoi.

ça, je suis moins au courant. Je parlais juste du sujet du thread, le code source du calculateur de la taxe d'habitation. Qui a certes des scories, mais qui fonctionne en fonction des contraintes (techniques et surtout non-techniques) qui pèsent sur eux.

Mais le financier il a pas se mêler de ça c'est pas son métier. Le financier il attribue des budgets et ensuite les services se gèrent. Le problème c'est qu'on a mis des financiers qui ne pinent rien à la tête de services techniques.

Ben si. Il doit gérer l'attribution des budgets. Si il faut 170 jours pour refondre la partie pourrie qui coute une blinde en maintenance, et 180 jours pour refondre la partie pourrie qui n'a jamais besoin de maintenance, eh bien c'est son rôle d'arbitrer. Moi, je me suis borné à lui présenter les contraintes et les opportunités. Dans ce cas précis, le choix était évident.

Je vais retourner ton argument, pour te montrer que la transversalité des décisions est importante. Imagine un commercial. Son boulot, c'est de vendre du logiciel(prestation ou projet, peu importe). Le développeur, lui, son boulot, c'est de faire le projet ou la prestation vendue. Bien. Est-ce que laisser le commercial vendre ce qu'il veut, au prix qu'il veut, avec les délais qu'il veut, sans contrôle du développeur, c'est une bonne idée? On a ça, parfois, ici, et on a du mal à dresser nos commerciaux pour qu'ils prennent en compte nos remarques. Certains commencent à comprendre que d'autres corps de métier sont importants.

En fonction de sa profitabilité, une boite aura un budget technologies de l'information. Il est important d'utiliser ce budget au mieux pour assurer l'efficacité du service aujourd'hui et demain. Parfois, ça peut inclure des refontes. Parfois, non. Dans le temps ou le blog de Steve Yegge était encore accessible, il racontait que le code source d'Amazon était une vraie merde. Ils ont coupé pour aller au plus vite. Et ils ont conquis le monde. Parcequ'ils ont fait du code pourri. Ca leur coute une blinde aujourd'hui en maintenance, mais leur patron est l'homme le plus riche du monde. Ceux qui ont pris le temps de faire proprement sont morts.

Dis autrement, les considérations techniques ne sont pas les seules à prendre en compte

C'est très exactement ce que je me tue à expliquer.

Sauf que tu ne prends en compte qu'une seule facette de la situation. J'adore quand je peux faire propre, mais il faut parfois savoir danser.

Ça n'a absolument aucun rapport avec ça. Il s'agit d'avoir un service fonctionnel et moderne, au niveau du rang de la 5ème puissance économique mondiale. On est pas la Roumanie bordel.

Merci de ne pas insulter la Roumanie.

Ça tu n'en sais absolument rien tu n'as pas de boule de cristal pour savoir ce que le pouvoir législatif fera dans le futur. Il faut donc être prêt à évoluer n'importe quand. Always ready to deploy.

C'est bien gentil, mais ça suppose, encore une fois, qu'on est parti sur de bonnes bases dès le départ, et qu'on a jamais dévié. La vraie vie est un poil plus compliquée que celà. J'essaye toujours de faire ça. Partout ou c'est possible.

Si on avait une vraie politique on engagerait ce gars comme CTO des services informatiques de l'état pour les 10 prochaines années avec ce programme :

Exactement comme un grand club va chercher un grand entraineur avec un pont d'or.

Ben oui, sauf que l'informatique est un métier de l'invisible. Autant il est facile de dire que Kylian Mbappé est meilleur que Franck Honorat(plus rapide, meilleur dribbleur, meilleure frappe de loin, meilleur sens du jeu.....), même pour le vulgum pecus, autant il faut vraiment être un spécialiste pour apprécier Martin Fowler à sa juste valeur. Même une majorité de professionnels ne sauront pas te dire qui sont Robert Martin ou Martin Fowler. Encore moins ce qui en fait des références. Alors des politiciens dont le métier, en démocratie représentative, est de se faire élire(ce que je déplore, mais c'est un autre sujet), fatalement, ils n'auront pas le niveau. Ce n'est pas spécifique à Macron, c'est le système politique qui veut ça. D'ailleurs, même dans la "méritocratie" chinoise, je ne suis pas sur qu'ils soient beaucoup plus au courant.

Dans le monde réel, les décideurs sont des tanches, qui recrutent des gens moyens, et ces gens moyens ont quand même fait des logiciels qui marchent. Pas de manière optimale, loin s'en faut, mais ça reste gérable. Ce n'est pas vrai partout. Loin s'en faut.

[Marco46]

Mais est-ce à la portée du développeur moyen? Je ne parle pas du lecteur de DVP qui par sa simple présence démontre sa supériorité. Non, je parle du gugusse lambda qui essaye juste de gagner sa vie.

Je ne pense pas que le lecteur developpez soit supérieur de quelque manière, sinon peut être en curiosité. Quand au développeur moyen qu'est ce que tu veux que ça me foute. Je te parle de prendre une poignée dans les bons pour démarrer la numérisation de l'administration proprement.

Pour le reste, je crois que tu sous-estimes gravement la difficulté pour une grosse organisation(les grosses boites privées ont toutes le même problème) comme l'état de recruter les meilleurs.

On est la France. Si on veut recruter les meilleurs on recrutera les meilleurs parce que :

- on est blindé de thunes rapporté à ce que ça couterait
- on est ultra attractif (propose à Martin Fowler un taro à 6 chiffres et un logement de fonction aux frais de la princesse dans les beaux quartiers de la plus belle ville du monde, à mon avis au minimum il va se gratter la tête)

Rapporté au budget de l'état ça couterait rien et ça représente des gains potentiels à neuf chiffres à terme. Ça s'appelle un investissement.

En quoi est-ce différent de tous les gouvernements du monde? (à part peut-être les portuguais, et encore)?

Mais je m'en fous des autres, je te parle de la France. Si tu te contente de rester moyen parce que les autres sont moyens tu traverseras jamais la rue ! (Aaaarg je me macronise !)

Tu prends un raccourci. Ce que je dis, c'est qu'une structure de la taille d'un état, pour qui l'informatique n'est pas le cœur de métier(google, j'aurais un autre discours, évidemment), n'a pas les moyens de recruter les meilleurs. Et est donc contrainte de mettre en place des stratégies qui seraient sous-optimales avec des gens haut-de-gamme(je n'ai rien à redire sur ta démonstration), mais qui ont l'avantage de fonctionner même avec des gens de qualité moyenne.

L'informatique n'est pas un cœur de métier, pas plus que l'écriture manuscrite ou le boulier. C'est un moyen, une technologie.

Ben si. Il doit gérer l'attribution des budgets. Si il faut 170 jours pour refondre la partie pourrie qui coute une blinde en maintenance, et 180 jours pour refondre la partie pourrie qui n'a jamais besoin de maintenance, eh bien c'est son rôle d'arbitrer. Moi, je me suis borné à lui présenter les contraintes et les opportunités. Dans ce cas précis, le choix était évident.

Pour combler la dette il va falloir investir, c'est un fait. Pour le reste :

1- Il ne devrait pas y avoir besoin de refondre quoi que ce soit. Ça doit toujours être nickel. C'est pas une option. Pour arriver à cet état de l'art il faut investir (payer la dette).
2- Les considérations techniques n'ont pas à remonter jusqu'aux budgets. On te donne un budget pour rendre un service, tu rends le service que tu peux en fonction du budget.

Je vais retourner ton argument, pour te montrer que la transversalité des décisions est importante. Imagine un commercial. Son boulot, c'est de vendre du logiciel(prestation ou projet, peu importe). Le développeur, lui, son boulot, c'est de faire le projet ou la prestation vendue. Bien. Est-ce que laisser le commercial vendre ce qu'il veut, au prix qu'il veut, avec les délais qu'il veut, sans contrôle du développeur, c'est une bonne idée? On a ça, parfois, ici, et on a du mal à dresser nos commerciaux pour qu'ils prennent en compte nos remarques. Certains commencent à comprendre que d'autres corps de métier sont importants.

Je ne vois pas le rapport.

En fonction de sa profitabilité, une boite aura un budget technologies de l'information. Il est important d'utiliser ce budget au mieux pour assurer l'efficacité du service aujourd'hui et demain. Parfois, ça peut inclure des refontes. Parfois, non. Dans le temps ou le blog de Steve Yegge était encore accessible, il racontait que le code source d'Amazon était une vraie merde. Ils ont coupé pour aller au plus vite. Et ils ont conquis le monde. Parcequ'ils ont fait du code pourri. Ca leur coute une blinde aujourd'hui en maintenance, mais leur patron est l'homme le plus riche du monde. Ceux qui ont pris le temps de faire proprement sont morts.

Ca n'a rien à voir, tu parles de conquérir un marché alors qu'on parle de fournir un service public. Quel est l'intérêt de faire de la merde pour être plus rapide ... Que qui ?

Je comprends très bien l'argument que tu développes et même si il est fondamentalement discutable (puisque ça dépend d'abord de la compétence des techos, des bons vont plus vite en faisant propre) il n'a pas de réalité ici puisqu'il n'y a aucun marché à conquérir.

Dis autrement, les considérations techniques ne sont pas les seules à prendre en compte

Elles sont fondamentales puisqu'elles définissent le champ du possible.

Sauf que tu ne prends en compte qu'une seule facette de la situation. J'adore quand je peux faire propre, mais il faut parfois savoir danser.

Si tu sais faire propre tu ne seras pas plus rapide en faisant crade. C'est quand tu galères à faire propre que tu fais crade pour aller plus vite. Ou alors tu parles à très très court terme mais ça n'a aucun sens à l'échelle d'un projet.

Merci de ne pas insulter la Roumanie.

Ce n'est pas une insulte de dire que la Roumanie n'a pas le même développement que le notre. Je viens de vérifier on est pas 5ème mais 7ème selon le FMI. La Roumanie est 50ème sur environ 200. C'est l'idée.

C'est bien gentil, mais ça suppose, encore une fois, qu'on est parti sur de bonnes bases dès le départ, et qu'on a jamais dévié. La vraie vie est un poil plus compliquée que celà. J'essaye toujours de faire ça. Partout ou c'est possible.

C'est pour ça qu'on doit investir pour mettre tout ça à niveau.

Ben oui, sauf que l'informatique est un métier de l'invisible. Autant il est facile de dire que Kylian Mbappé est meilleur que Franck Honorat(plus rapide, meilleur dribbleur, meilleure frappe de loin, meilleur sens du jeu.....), même pour le vulgum pecus, autant il faut vraiment être un spécialiste pour apprécier Martin Fowler à sa juste valeur. Même une majorité de professionnels ne sauront pas te dire qui sont Robert Martin ou Martin Fowler. Encore moins ce qui en fait des références. Alors des politiciens dont le métier, en démocratie représentative, est de se faire élire(ce que je déplore, mais c'est un autre sujet), fatalement, ils n'auront pas le niveau. Ce n'est pas spécifique à Macron, c'est le système politique qui veut ça. D'ailleurs, même dans la "méritocratie" chinoise, je ne suis pas sur qu'ils soient beaucoup plus au courant.

Macron a des conseillés. Par ailleurs si Mounir Mahjoubi n'a jamais entendu parler de Martin Fowler, d'oncle Bob, de Software Craftmanship et de DevOps alors il n'a rien à faire à son poste. C'est comme si le président de la FIFA ignorait qui était Messi ou Ronaldo. Inconcevable.

[el_slapper]

Je ne pense pas que le lecteur developpez soit supérieur de quelque manière, sinon peut être en curiosité. Quand au développeur moyen qu'est ce que tu veux que ça me foute. Je te parle de prendre une poignée dans les bons pour démarrer la numérisation de l'administration proprement.

Là, on est dans un monde idéal. J'adorerais que ça se passe comme ça. Mais on a un existant à gérer.

(.../...)Rapporté au budget de l'état ça couterait rien et ça représente des gains potentiels à neuf chiffres à terme. Ça s'appelle un investissement.

Ah on est d'accord sur le principe. Sauf que est-ce que ce gouvernement - ou un autre - est capable de mener cet investissement à bien? J'ai comme un doute.

Mais je m'en fous des autres, je te parle de la France. Si tu te contente de rester moyen parce que les autres sont moyens tu traverseras jamais la rue ! (Aaaarg je me macronise !)

Tout le monde n'est pas moyen puisque les portugais sont bons(pas forcément pour longtemps, m'enfin.....). Maintenant, c'est là qu'on voit que Macron est très fort en communication : même quand il raconte des billevesées(ce qui lui arrive quand même assez souvent), il marque les esprits et imprime sa marque. Et comme il est très fort en communication, il a pris la place. C'est le système qui veut ça. La vraie question, ce n'est pas de dire que Macron n'est pas plus compétent que le premier Mélenchon venu(ou Fillon, ou Wauquiez, ou Hamon, ou Le Pen.....). C'est de se demander comment on peut transformer le système pour qu'il remette la compétence à sa juste place. Et je n'ai pas la solution. Si tu as des idées, je suis preneur. Mais ça ne sera pas une solution technique.

L'informatique n'est pas un cœur de métier, pas plus que l'écriture manuscrite ou le boulier. C'est un moyen, une technologie.

Certes, mais qui est le cœur de métier de certains(GAFA), le support du cœur de métier d'autres(banques, en particulier - leur métier est le pognon, et tout le pognon est dématérialisé de nos jours), et un simple outil de simplification pour les autres. L'état est dans la troisième catégorie. Qu'on y trouve moins de gens sensibilisés est une probabilité statistique forte.

Pour combler la dette il va falloir investir, c'est un fait. Pour le reste :

1- Il ne devrait pas y avoir besoin de refondre quoi que ce soit. Ça doit toujours être nickel. C'est pas une option. Pour arriver à cet état de l'art il faut investir (payer la dette).
2- Les considérations techniques n'ont pas à remonter jusqu'aux budgets. On te donne un budget pour rendre un service, tu rends le service que tu peux en fonction du budget.

Sauf quand la considération technique a un impact direct sur le budget. Encore une fois, les 180 jours, ils ont été alloués à d'autres tâches. Aussi utiles. La technocratie, c'est un mal, tu sais. Vieux proverbe :

Il y a trois manières de faire faillite.
La plus rapide, le jeu
La plus agréable, les femmes
La plus systématique, les ingénieurs

cette vieille blague n'est pas apparue par hasard. Si tu laisse les clefs aux ingénieurs sans vérifier(ou à tout autre corps de métier, d'ailleurs) sans les contrôler, ben, ça part en couille.

Dit autrement : ce n'est pas parce-qu'on a pas l'influence qu'on devrait avoir qu'on mérite d'avoir les mains libres et de ne rendre de comptes à personne. Les contre-pouvoirs sont essentiels dans toute organisation. Ici, un projet stratégique mais que la direction a un peu oublié a pris un an et demie de retard parce-qu'en l'absence de tout contrôle, des ayatollahs de la perfection technique ont refondu leur code pour atteindre la "perfection". Résultat, l'outil fonctionne beaucoup moins bien, et nous plombe de partout. Aucun corps de métier n'est à l'abri de l'hubris, le notre pas plus qu'un autre.

Je comprends très bien l'argument que tu développes et même si il est fondamentalement discutable (puisque ça dépend d'abord de la compétence des techos, des bons vont plus vite en faisant propre) il n'a pas de réalité ici puisqu'il n'y a aucun marché à conquérir.

non, mais il y a des objectifs à atteindre.

Elles sont fondamentales puisqu'elles définissent le champ du possible.

Certes, mais entre différents possibles, il faut choisir. Un jour, j'ai du faire la partie recyclage d'une chaine. On recevait des paquets de fichier, et parfois il y avait des erreurs en entrée. L'appli ayant été codée avec 35% du budget demandé, quand il y avait des erreurs, booooom. Donc j'ai mis en place un recyclage propre. Après, il était possible d'accepter tous les enregistrements OK, et de ne rejeter que les KO, ou de rejeter tout fichier avec au moins une erreur en bloc. J'étais partisan le la première solution. Mais j'ai proposé les deux, et le métier a préféré la deuxième(ça facilitait leur vie, semble-t-il, de tout régénérer). Ce n'était pas à moi de décider. Il en fallait une des deux(le statu quo n'était pas acceptable, et j'ai risqué mes fesses pour le faire sauter), mais le choix de laquelle, ultimement, n'a pas à être technique.

Si tu sais faire propre tu ne seras pas plus rapide en faisant crade. C'est quand tu galères à faire propre que tu fais crade pour aller plus vite. Ou alors tu parles à très très court terme mais ça n'a aucun sens à l'échelle d'un projet.

ça dépend des circonstances. J'adore faire propre quand je peux. On ne m'a pas toujours laissé le choix. Et certains ne sont pas capables de faire propre.

Macron a des conseillés. Par ailleurs si Mounir Mahjoubi n'a jamais entendu parler de Martin Fowler, d'oncle Bob, de Software Craftmanship et de DevOps alors il n'a rien à faire à son poste. C'est comme si le président de la FIFA ignorait qui était Messi ou Ronaldo. Inconcevable.

On en revient au problème structurel dont je parlais ci-dessus. La manière dont les grosses structures sont gérées ne favorisent pas l'éclosion de la compétence. Tant qu'on aura pas réglé ce problème(et je ne sais pas faire), ce que je décris(et toi aussi dans cette dernière intervention) sera le monde réel, et il faudra se le farcir. Tel qu'il est, et non pas tel que nous souhaiterions qu'il soit.

[Marco46]

Là, on est dans un monde idéal. J'adorerais que ça se passe comme ça. Mais on a un existant à gérer.

C'est pas un monde idéal ça existe des bonnes équipes. Les GAFA, en particuliers Facebook et Google en sont intégralement constituées. C'est pas des générations spontanées. Mais un bon ça se paie ou ça se forme. On peut parfaitement démarrer petit, c'est même toujours ce qu'il faut faire au démarrage, et conserver les équipes existantes pour gérer le legacy.

Certes, mais qui est le cœur de métier de certains(GAFA), le support du cœur de métier d'autres(banques, en particulier - leur métier est le pognon, et tout le pognon est dématérialisé de nos jours), et un simple outil de simplification pour les autres. L'état est dans la troisième catégorie. Qu'on y trouve moins de gens sensibilisés est une probabilité statistique forte.

Le cœur de métier des GAFA c'est de vendre les données personnelles que les gens leurs donnent gracieusement en utilisant leurs services ou de vendre des services B2B en se basant sur ces données personnelles. C'est ça leur cœur de métier (enfin surtout Google et Facebook). C'est des receleurs de data si tu préfères. Si t'as l'occasion de discuter avec un ancien Googler (ou de le lire) je t'invite à lui demander quelle est la priorité de la boite. C'est simplement de vendre de la pub. Rien d'autre ne compte, tout est organisé pour presser le citron autant que possible.

Sauf quand la considération technique a un impact direct sur le budget. Encore une fois, les 180 jours, ils ont été alloués à d'autres tâches. Aussi utiles. La technocratie, c'est un mal, tu sais. Vieux proverbe :

Non parce que tu pré-supposes que la personne qui va attribuer les budgets va aller dans le détail des projets alors qu'il ne s'agit que de rendre un service.

Ce que j'exprime c'est le même genre de revendication qu'ont certains praticiens hospitaliers à propos du budget de la sécu et du paiement à l'acte. C'est une mesure budgétaire et qui se révèle extrêmement inefficace et contre productive. En gros ils disent soit on redéfini le propos de la sécurité sociale et sa mission n'est plus de s'occuper de la santé des gens mais de faire du bénéfice, soit vous nous confier une enveloppe et on se démerde avec, et surtout vous ne vous mêlez pas des aspects techniques (médicaux du coup). Ce qui est entrain de faire péter les plombs aux PH c'est justement que des managers qui ne pinent rien à leur métier viennent leur expliquer la vie. Et c'est du grand grand n'importe quoi et ce n'est pas viable à moyen terme, on est au bord de l'explosion. Bref, c'est un peu pareil dans l'info quand des managers viennent se mêler des questions technique. Ce ... n'est pas ... leur ... métier ! Point final.

cette vieille blague n'est pas apparue par hasard. Si tu laisse les clefs aux ingénieurs sans vérifier(ou à tout autre corps de métier, d'ailleurs) sans les contrôler, ben, ça part en couille.

Pour moi c'est du même ordre que les évaluations par des managers. Ils ne sont pas capables d'évaluer ils ne comprennent rien. On est peut être évalué que par ses pairs, pas par des analphabètes.

Dit autrement : ce n'est pas parce-qu'on a pas l'influence qu'on devrait avoir qu'on mérite d'avoir les mains libres et de ne rendre de comptes à personne.

J'ai jamais dit qu'on devait pas rendre des comptes. Ne pas rendre de compte c'est par définition être irresponsable. On est pas des hommes politiques on est des informaticiens. Bien sûr qu'on doit rendre des comptes !

non, mais il y a des objectifs à atteindre.

C'est au contraire et précisément la seule variable qui est ajustable. Un budget est par définition un stock fini, et la qualité est non-négociable puisque c'est la manière la moins couteuse de fonctionner. On ne peut donc arbitrer que le scope. C'est la base de base de chez la base de la base pour se moderniser à moindre coup avec un maximum d'efficacité.

ça dépend des circonstances. J'adore faire propre quand je peux. On ne m'a pas toujours laissé le choix.

C'est tout le propos du Software Craftmanship, personne n'a le droit de te donner un tel ordre, pas plus qu'on a le droit de dire à un médecin de mettre l'hygiène de côté pour gagner du temps.

Et certains ne sont pas capables de faire propre.

---> Pôle Emploi. On a autre chose à faire et on a besoin de seulement quelques dizaines de personnes.

On en revient au problème structurel dont je parlais ci-dessus.

Le véritable problème avec les politiques c'est qu'ils sont plus préoccupés par leur carrière que par l'intérêt général. Les gesticulations actuelles de Collomb pour la Mairie de Lyon et de quelques autres "marcheurs" pour la mairie de Paris (dont Mounir Mahjoubi d'ailleurs, je viens d'apprendre ça !) sont à vomir. Ils sont ministres depuis à peine un an qu'ils veulent déjà passer à autre chose. Ils n'ont aucun sens des responsabilités ni aucune décence. C'est vraiment affolant les mecs sont satellisés.

[el_slapper]

(J'élague un peu, je m'aperçois qu'on dit plusieurs fois la même chose)...

C'est au contraire et précisément la seule variable qui est ajustable. Un budget est par définition un stock fini, et la qualité est non-négociable puisque c'est la manière la moins couteuse de fonctionner. On ne peut donc arbitrer que le scope. C'est la base de base de chez la base de la base pour se moderniser à moindre coup avec un maximum d'efficacité.

Dans un monde idéal dont nous sommes loin. On a un gars qui part à la retraite la semaine prochaine. Il essaye de passer ses connaissances. Mais on a des projets urgents, et certains lui demandent de rester productif. C'est évidemment la chose à ne pas faire, mais on peut comprendre l'assistante commerciale sous pression d'un client.

Et je parle aussi de systèmes gigantesques qui ont été mis en place bien avant que toutes les "bonnes pratiques" soient mises en place. Et dont la "mise au normes" serait d'un cout qui mettrait la boite sur la paille. Et qui marchent. C'est bien de se dire que sur les nouveaux composants, on va faire propre, mais sur les vieux nanards?

C'est tout le propos du Software Craftmanship, personne n'a le droit de te donner un tel ordre, pas plus qu'on a le droit de dire à un médecin de mettre l'hygiène de côté pour gagner du temps.

Certes. Mais aucun de mes chefs n'a jamais su ce que c'était. Je suis dans le monde réel, et le serment d'Hippocrate pour les développeurs, ce n'est pas pour demain.

---> Pôle Emploi. On a autre chose à faire et on a besoin de seulement quelques dizaines de personnes.

Ce qui est le pendant du suivant :

Le véritable problème avec les politiques c'est qu'ils sont plus préoccupés par leur carrière que par l'intérêt général. Les gesticulations actuelles de Collomb pour la Mairie de Lyon et de quelques autres "marcheurs" pour la mairie de Paris (dont Mounir Mahjoubi d'ailleurs, je viens d'apprendre ça !) sont à vomir. Ils sont ministres depuis à peine un an qu'ils veulent déjà passer à autre chose. Ils n'ont aucun sens des responsabilités ni aucune décence. C'est vraiment affolant les mecs sont satellisés.

et la question a un trilliard d'euros : tous ces gens là, on en fait quoi? Parce-que pour le coup, les incapables, on les retrouve notamment en politique, ou dans les hiérarchies intermédiaires(c'est le principe de Dilbert), parce-qu'il faut bien en faire quelque chose. Je suis attiré par le concept "on en garde que les meilleurs", mais le sort des non-meilleurs est toujours le grand impensé de ce concept. Je parle parfois du gnou qui renommait les champs quand ils ne les trouvait pas(parce-qu'il regardait dans la mauvaise table), il est désormais chef de projet senior. Petit joueur comparé aux politiciens que tu cite, mais le fait de se faire virer pour incompétence technique a été un coup de booster à sa carrière.

C'est un sujet complexe, que je ne suis pas sur de totalement maitriser. D'un coté, il est bon de garder les meilleurs pour faire avancer le boulot. Toi, moi, les autres, avons tous vu la différence entre des équipes avec une locomotive et 5 gnous, et des équipes avec 6 locomotives. De l'autre, tout le monde croit être parmi les meilleurs, et mériter une place tout en haut. Et pour y parvenir, comme ils n'ont aucune compétence(je suis ministre, je ne sais rien faire, comme dans la folie des grandeurs), eh bien ils passent leur temps à grenouiller. Et comme ils grenouillent, ils montent. Leur seule compétence, c'est de gérer leur carrière. Et c'est en les virant parce-qu'ils ne savaient rien faire qu'on les a lancé sur cette voie.

Comme je te disais, le problème de fonds est structurel, et je n'ai pas la solution. Mais ce n'est pas en tapant sur telle ou telle personne qui fait des sottises que tu vas corriger le problème. D'autres attendent la place. D'autres incapables, dont nous ne voulont pas dans nos équipes, et qui veulent une place au soleil quand même. Et je ne sais pas quoi faire de ces gens.

[Guntha]

C'est pas un monde idéal ça existe des bonnes équipes. Les GAFA, en particuliers Facebook et Google en sont intégralement constituées.

Toi, t'as jamais du travailler sur Android. Tout ce qui le constitue, des outils aux API bas niveau, est infect.
Et aussi n'avoir jamais utilisé un produit Google. Gmail est quand même le seul client mail que je connaisse qui ait besoin d'un écran de chargement au démarrage!