- Les changements d’exigences et l’incertitude, le travail itératif et les solutions de fortune, souvent considérés comme propres au logiciel, sont aussi courants dans l’ingénierie traditionnelle ; les deux domaines ont plus de points communs que de différences
- L’opposition « ingénierie traditionnelle = Waterfall, logiciel = Agile » est trop simpliste. La fabrication physique impose beaucoup de conception en amont en raison du coût élevé des itérations, mais les tunnels, le génie civil et l’électronique utilisent aussi le développement progressif et l’adaptation sur le terrain
- L’ingénierie traditionnelle subit elle aussi des problèmes qui bouleversent les plans, comme la faillite d’un fournisseur, l’évolution des équipements de fabrication ou des caractéristiques de sol inattendues ; il est donc difficile de considérer que seul le logiciel est particulièrement imprévisible
- La vraie différence tient à la forte cohérence et à la rapidité de modification du logiciel, ainsi qu’à des contraintes relativement souples. Les produits physiques doivent composer avec les variations des matériaux, l’usure, des contraintes dures comme la résistance ou la taille, et des changements difficiles à annuler
- La rapidité des corrections facilite l’expérimentation et la validation, mais peut aussi pousser à contourner par du code des défauts physiques. Chaque discipline d’ingénierie peut apprendre des méthodes de conception, de vérification et d’automatisation des autres
Les arguments de défense selon lesquels le logiciel serait spécial
- Un réservoir pétrolier n’est pas un ballon rempli de pétrole, mais une structure rocheuse poreuse ; il est donc difficile de savoir si une perte soudaine de pression vient d’une cavité locale ou d’une ouverture vers la mer
- On injecte des coquilles de noisettes dans de petites cavités pour les combler progressivement, équilibrer la pression et vérifier si l’on se trouve bien à l’intérieur de la structure
- Le fait qu’en Norvège les compagnies pétrolières soient les plus gros acheteurs de coquilles de noisettes montre que l’ingénierie traditionnelle dépend elle aussi de matériaux inattendus et de réponses sur le terrain
- Quand on compare logiciel et ingénierie traditionnelle, on dévalorise parfois le logiciel par rapport à l’ingénierie en invoquant les licences ou la rigueur, tout en en faisant un domaine spécial qu’on ne pourrait pas comprendre dans le cadre général de l’ingénierie
- L’argument selon lequel les exigences changent exceptionnellement vite et qu’il ne serait donc pas nécessaire d’appliquer une planification en amont et des méthodes d’ingénierie fonctionne comme un mécanisme de défense
- Le mouvement NoEstimates cherche à supprimer l’estimation elle-même, au motif que l’estimation logicielle serait difficile contrairement à l’ingénierie traditionnelle
- Mais la plupart des problèmes considérés comme douloureux dans le logiciel existent aussi dans d’autres disciplines d’ingénierie, et les ingénieurs ayant pratiqué les deux voient leurs métiers comme fondamentalement proches
Cinq différences souvent citées
- Traiter toute l’ingénierie traditionnelle comme un seul domaine, ou l’assimiler au génie civil, efface les différences entre ses sous-disciplines
- Les différences généralement avancées entre logiciel et ingénierie traditionnelle sont les suivantes
- L’ingénierie traditionnelle serait adaptée au Waterfall, le logiciel à l’Agile
- L’ingénierie traditionnelle serait prévisible, tandis que le logiciel serait difficile à prévoir
- L’ingénierie serait surtout de la fabrication et le code de la conception, donc « le code est la conception »
- L’ingénierie traditionnelle serait plus rigoureuse que l’ingénierie logicielle
- Le logiciel évoluerait beaucoup plus vite que l’ingénierie traditionnelle
- Certaines de ces différences sont réelles, mais la plupart sont fausses ou omettent le contexte essentiel nécessaire au jugement
La distinction simpliste entre Waterfall et Agile
- Selon le récit le plus répandu, Winston Royce aurait créé le Waterfall en 1970 en s’inspirant des procédés de construction, et cette méthode vulnérable aux changements d’exigences aurait été remplacée en 2001 par l’Agile Manifesto
- En réalité, le Waterfall n’a pas été aussi rigide ni aussi universel qu’on l’imagine aujourd’hui
- Dans les années 1970 et 1980, les développeurs utilisaient des plans provisoires ou plusieurs modèles progressifs comme le Spiral Model et le V Model
- L’Agile ressemble davantage au résultat naturel des tendances de l’époque qu’à une révolution en rupture
- Il est vrai que l’ingénierie traditionnelle consacre davantage de temps à la conception en amont et aux essais séparés, mais cela vient de l’économie du coût des itérations plutôt que de la rigidité du Waterfall
- Plus une itération prend du temps et coûte cher, plus il est rationnel de planifier longtemps une seule intervention
- Si une carte électronique ne fonctionne pas du premier coup, il faut la renvoyer à l’usine, ce qui peut ajouter plusieurs milliers de livres sterling et deux semaines de délai
- La frontière entre conception et réalisation n’est pas claire non plus
- Les maquettes à échelle réduite des ingénieurs civils ou les maquettes en argile grandeur nature que les ingénieurs automobiles fabriquent pour tester l’esthétique et l’aérodynamique peuvent être vues à la fois comme conception et comme réalisation
- D’autres industries ont aussi des méthodes proches de l’Agile
- La nouvelle méthode autrichienne de construction de tunnels repose sur le développement itératif et l’improvisation sur le terrain
- Le Handbook of Industrial Engineering met l’accent sur la collaboration interservices et le retour client rapide
- Une fois la construction commencée, le génie civil évolue lui aussi vers une communication ouverte et une adaptation centrée sur la résolution des problèmes de chantier
L’ingénierie traditionnelle est elle aussi difficile à prévoir
- En ne regardant qu’un pont ou un produit fini, on oublie facilement les frictions, les dépassements de coûts et les retards survenus pendant le processus
- Un mur monté avec un pouce d’erreur ou la faillite d’un fournisseur critique suffit à ébranler un plan
- Le logiciel donne l’impression que le framework ou le langage dominant change tous les un ou deux ans, mais l’ingénierie traditionnelle connaît elle aussi des changements d’outils et d’environnements de production
- Quand une fonderie de semi-conducteurs introduit de nouveaux équipements de fabrication, les plans de conception de puces changent aussi
- Même si ce n’est pas aussi rapide que les bibliothèques logicielles, cela ne signifie pas qu’il n’y a pas de changement
- Il arrive aussi qu’une souveraineté territoriale change pendant des travaux, qu’une procédure éprouvée échoue soudainement et définitivement, ou que de nouveaux faits soient découverts en fin de développement
- Si, après avoir commencé les fondations d’un pont, on découvre qu’un sol particulier gèle autrement que prévu et se liquéfie excessivement lors d’un séisme, il faut reprendre la conception depuis le début
- L’idée que seul le logiciel serait particulièrement imprévisible vient d’une méconnaissance du travail réel dans les autres disciplines d’ingénierie
L’affirmation « le code est la conception »
- « Le code est la conception » était une réaction à l’idée selon laquelle il suffirait de créer un modèle UML parfait, puis de générer automatiquement le code
- Nick Coghlan, développeur core de CPython et ancien ingénieur d’intégration systèmes chez Boeing, y voit une différence fondamentale entre le logiciel et son ancien travail
- Il coordonnait plusieurs équipes de systèmes indépendants, comme des avions, le contrôle aérien et des réseaux d’antennes, afin qu’elles créent des interfaces compatibles
- Pour un ingénieur en semi-conducteurs, tout le processus, du premier schéma de circuit du CPU à la puce finale sortie de la fonderie, relève de la conception ; la fabrication peut être une étape relativement simple consistant à transmettre le design et à recevoir la puce
- Si une puce ou un produit mécanique fini présente un défaut, il faut modifier la conception ; conception et fabrication ne sont donc pas séparées
- Le « fettling » en mécanique consiste à ajuster la conception aux petites imperfections du processus de fabrication
- La fabrication modifie la conception, et la conception modifiée modifie à son tour la fabrication, créant une boucle
- Le périmètre de la conception lui-même est flou
- Vue d’ensemble d’architecture, spécifications formelles et plans détaillés sont tous des niveaux différents de conception
- Dans des projets complexes, comme ce plan de pont, des détails répétés existent à plusieurs niveaux
- La caractéristique consistant à consacrer l’essentiel du temps et des coûts à la construction concerne surtout certaines branches du génie civil centrées sur les ponts et les bâtiments ; on ne peut pas la généraliser à toute l’ingénierie traditionnelle
- Le génie civil couvre aussi les nombreux domaines nécessaires à la construction des villes et ne se limite donc pas aux ponts et aux bâtiments
Les malentendus sur la rigueur
- L’opposition selon laquelle l’ingénierie traditionnelle raisonnerait soigneusement à partir des premiers principes tandis que le logiciel dépendrait du copier-coller ne reflète pas le travail réel
- La rigueur apparemment plus faible du logiciel n’est pas seulement une question de culture ; elle peut être un compromis rationnel lié aux propriétés matérielles qui rendent l’implémentation et les tests faciles
- La manière la plus simple de vérifier une hypothèse consiste souvent à l’implémenter directement et à l’exécuter
- Le fait de collecter rapidement des informations empiriques est en soi une méthode de validation rigoureuse
- L’hypothèse selon laquelle les produits de l’ingénierie traditionnelle seraient plus cohérents et plus systématiques que le logiciel n’est pas correcte non plus
- Le logiciel est parfois en avance en matière de conservation des traces et de validation exhaustive
- Les informations essentielles de l’ingénierie traditionnelle sont souvent stockées dans des fichiers Excel ou de vieilles armoires à dossiers, où elles vieillissent ou s’abîment
- Beaucoup d’ingénieurs de l’ingénierie traditionnelle aimeraient adopter les tests automatisés considérés comme évidents dans le logiciel
- Dans les structures physiques aussi, on continue à utiliser des solutions de fortune, par exemple en ajoutant des équerres quand c’est nécessaire
Vraie différence 1 : la cohérence
- Le logiciel étant entièrement synthétisé par la logique et ne s’usant pas comme un ressort, il est bien plus cohérent que les autres productions de l’ingénierie
- Si une fonction de tri ne trie que 95 % d’une liste de nombres dont les entrées ne sont pas anormales, il serait difficile de considérer cela comme un comportement normal
- Les matériaux et composants physiques présentent par défaut des écarts par rapport aux valeurs théoriques
- Les résistances existent de 1 Ω à plusieurs centaines de millions d’Ω, et leurs bandes de couleur indiquent la valeur théorique de résistance
- Des bandes verte, bleue et rouge signifient 5 600 Ω, mais avec une bande de tolérance dorée, la valeur réelle peut différer de jusqu’à 5 %
- Sur 100 résistances identiques, certaines peuvent valoir 5 320 Ω et d’autres 5 880 Ω, ce qui impose de les mesurer individuellement
- Si l’on tient compte de l’usure et des variations de température, les écarts deviennent encore plus complexes
- Tous les matériaux physiques ont des problèmes similaires, et le fabricant de vis Fastenal avertit lui aussi de ne pas utiliser de vis en acier inoxydable dans des plaques d’aluminium
Vraie différence 2 : la vitesse de changement
- Le logiciel peut être modifié beaucoup plus rapidement que les autres systèmes d’ingénierie
- Dans l’ingénierie traditionnelle, après avoir partagé une spécification, il faut attendre la fabrication et l’installation par une usine ou un atelier d’usinage, puis plusieurs semaines d’essais
- Certains changements d’ingénierie ont un coût clair, par exemple 5 000 dollars retirés du budget à chaque modification
- Après une modification de code, toute la suite de tests peut être exécutée en quelques secondes
- Parmi les domaines non logiciels, le génie chimique offrait la vitesse la plus proche, mais même un basculement à l’échelle de la minute restait difficile à imaginer
- Si les autres disciplines d’ingénierie utilisent de plus en plus le logiciel dans leurs outils de conception et leurs simulations, c’est aussi parce qu’il permet de prototyper rapidement des idées avant leur réalisation
- Cette capacité de modification rapide a aussi des aspects négatifs
- Lorsqu’un problème d’électronique ou de mécanique n’est pas complètement résolu, la pression se concentre sur les ingénieurs logiciel pour le compenser par un contournement dans le code
- Cette dépendance peut avoir des conséquences fatales
- Deux crashs de Boeing 737 MAX en 2019 ont fait plus de 300 morts
- Les enquêtes ont pointé comme cause des bugs du MCAS, le système automatique de commande de vol
- Au lieu de corriger par une conception physique un problème de caractéristiques aérodynamiques découvert tardivement sur l’avion, Boeing a ajouté le MCAS
Vraie différence 3 : les contraintes et les changements irréversibles
- Les produits de l’ingénierie traditionnelle ont des limites physiques impératives, comme le poids, la résistance mécanique, la résistivité ou la température
- Dans la conception de puces, on peut négocier avec d’autres équipes des marges temporelles correspondant à des fractions de nanoseconde
- Le logiciel a lui aussi des contraintes, comme la capacité mémoire, une réponse de capteur en 10 cycles ou des limites d’appels API
- Toutefois, les contraintes logicielles sont souvent des contraintes souples : plus on les dépasse, plus l’état se dégrade, ce qui permet parfois d’ajuster un peu les limites pour gagner en vitesse de développement ou utiliser un algorithme plus simple
- Les contraintes de l’ingénierie traditionnelle sont souvent des contraintes dures : si on les dépasse, le produit ne fonctionne pas
- Une boîte à peine trop large ne peut pas passer par une porte
- Dans le cas d’un convoyeur à vis destiné à une installation de forage pétrolier qui dépassait de quelques pouces la hauteur de la pièce, il était impossible de réduire l’équipement ou de relever le plafond à cause des quatre étages au-dessus
- On a percé un trou dans le plafond pour faire entrer l’équipement, puis installé une boîte autour du trou pour éviter que les personnes de l’étage supérieur trébuchent
- Ce changement est resté de façon permanente dans la structure de l’installation et doit continuer à être pris en compte dans toutes les modifications ultérieures
- Les ingénieurs logiciel peuvent revenir sur des solutions temporaires, mais dans l’ingénierie traditionnelle, les expédients physiques deviennent facilement des structures permanentes
Différent, mais pas spécial
- Le logiciel a ses propres problèmes de sécurité, mais chaque domaine a ses difficultés spécifiques : la météo pour le génie civil, les propriétés chimiques pour le génie chimique, par exemple
- Toutes les disciplines d’ingénierie valorisent la réflexion abstraite en amont, le travail organisé et les expédients appropriés, et font face à des exigences changeantes et à des inconnues imprévisibles
- Chaque discipline est isolée des autres : de même qu’un ingénieur logiciel connaît mal la mécanique, un ingénieur chimiste peut difficilement connaître le travail réel des autres disciplines d’ingénierie
- Parce que le logiciel n’est pas spécial, il peut apprendre d’autres disciplines d’ingénierie des manières de s’améliorer, et l’ingénierie traditionnelle peut aussi apprendre du logiciel en matière de traçabilité, de vérification et d’automatisation
- L’article suivant, Ce que l’ingénierie peut nous apprendre et ce qu’elle peut apprendre de nous, traite des leçons concrètes que les deux camps peuvent s’échanger
1 commentaires
Avis sur Lobste.rs
Je suis d’accord avec une grande partie de l’article, mais il est trop optimiste quant à la rigueur du génie logiciel. Aujourd’hui encore, il n’est pas acquis que les tests automatisés, en particulier des tests robustes à plusieurs niveaux, fassent partie du processus de développement ; on considère parfois les développeurs eux-mêmes comme le seul point de contrôle, ou bien les organisations traitent les procédures comme des obstacles et les suppriment.
Le secteur réinvente la roue tous les quelques années sans systématiser les bonnes pratiques éprouvées. Même ce qui est standardisé se limite le plus souvent à un vocabulaire commun assez lâche, dont le sens varie beaucoup d’une entreprise à l’autre ; « agile » et « test » en sont des exemples typiques. Beaucoup de développeurs pensent aux tests comme à de simples tests unitaires ; certains y incluent les tests de composants et d’intégration, mais dans certaines entreprises on déploie en production après n’avoir passé que cela.
Comme dans un commentaire que j’ai écrit précédemment, dans une organisation saine, la revue de code devrait être l’une des plusieurs procédures responsables de la qualité, et non l’unique porte d’entrée décidant d’un déploiement en production. Dans beaucoup d’équipes et d’entreprises, les procédures d’assurance qualité après la fusion du code ont pratiquement disparu.
Il ne s’agit pas de diluer la responsabilité, mais d’intégrer la qualité dans les processus dès avant l’écriture du code. Il faut des sessions Three Amigos où plusieurs métiers discutent des spécifications et des exigences, du développement piloté par les tests, de l’analyse statique intégrée à l’IDE et à chaque point de contrôle, ainsi que des spécialistes de l’assurance qualité et de l’automatisation des tests distincts des développeurs.
En génie civil, une seule personne n’est pas à la fois concepteur, constructeur et unique responsable d’un pont. Il existe plusieurs étapes : calculs et documentation, contre-vérification, approbation par les pouvoirs publics, audits et inspections pendant la construction ; même une maison individuelle passe par des plans, des validations, des permis et des inspections. Les catastrophes d’ingénierie sont elles aussi souvent des échecs de l’ensemble du processus, qui n’a pas su les arrêter à plusieurs étapes.
Si l’on veut comparer le développement logiciel au génie civil, il faut aussi reconnaître que le niveau de procédure n’est pas du tout le même. Dans bien des cas, on est au mieux plus proche d’un promoteur immobilier qui construit les maisons les moins chères en contournant les exigences légales.
Par conséquent, dans le logiciel généraliste, hors domaines comme les logiciels de contrôle d’IRM, le compromis entre le coût des tests et de la vérification et leurs effets ne peut qu’être différent de celui du génie civil.
Les trois articles sont excellents, je recommande de les lire. On peut aussi consulter les discussions passées :
https://lobste.rs/s/fv8swh/crossover_project (présentation du projet)
https://lobste.rs/s/lmvroa/are_we_really_engineers (nouvelle discussion)
https://lobste.rs/s/8j8sdc/are_we_really_engineers (autre nouvelle discussion)
Cette conférence de Glenn Vanderburg est également très pertinente.
La plus grande différence entre le développement logiciel et l’ingénierie traditionnelle est la friction liée au changement. Le logiciel peut être modifié à un coût relativement faible et il est flexible, ce qui ouvre des possibilités entièrement nouvelles.
Plus l’ingénierie traditionnelle produit de simulations, plus elle peut, dans les limites physiques et chimiques, élargir ses possibilités de changement d’une manière proche du logiciel.
La phrase « pour une fonction de tri, on ne s’attend pas à ce qu’elle ne trie une liste de nombres non pathologique qu’avec 95 % de probabilité » s’applique désormais bel et bien au code généré par les LLM. Il fonctionne la plupart du temps, mais pas toujours.
Je me demande pourquoi ~hwayne a désactivé son compte.