Pourquoi le secteur informatique ne peut-il pas livrer rapidement des projets de grande envergure et sans faille, comme dans d’autres secteurs?

509

Après avoir regardé la série MegaStructures de National Geographic , j'ai été surpris de la rapidité avec laquelle de grands projets sont terminés. Une fois que le travail préliminaire (conception, spécifications, etc.) est effectué sur papier, la réalisation de grands projets ne prend que quelques années, voire quelques mois .

Par exemple, l' Airbus A380 "officiellement lancé le 19 décembre 2000" et "début mars 2005" , avait déjà été testé. Il en va de même pour les énormes pétroliers, les gratte-ciel, etc.

En comparant cela aux retards dans l'industrie du logiciel, je ne peux m'empêcher de me demander pourquoi la plupart des projets informatiques sont si lents, ou plus précisément, pourquoi ils ne peuvent pas être aussi rapides et sans faille, à la même échelle, avec suffisamment de personnel?


Des projets tels que l’Airbus A380 présentent à la fois:

  • Principaux risques imprévus: bien qu’il ne s’agisse pas du premier avion construit, il repousse toujours les limites de la technologie et les éléments qui fonctionnaient bien pour les petits avions de ligne risquaient de ne pas fonctionner pour le plus gros en raison de contraintes physiques; De la même manière, on utilise de nouvelles technologies qui n’étaient pas encore utilisées car, par exemple, elles n’étaient pas disponibles en 1969 lorsque le Boeing 747 a été fabriqué.

  • Risques liés aux ressources humaines et à la gestion en général: personnes qui abandonnent au milieu du projet, incapacité de joindre une personne parce qu'elle est en vacances, erreurs humaines ordinaires, etc.

Avec ces risques, les gens réalisent encore des projets tels que ces gros avions de ligne en très peu de temps et, malgré les retards de livraison, ces projets connaissent toujours un franc succès et sont de grande qualité.

En ce qui concerne le développement de logiciels, les projets sont à peine aussi vastes et complexes qu'un avion de ligne (tant sur le plan technique que sur le plan de la gestion) et comportent un peu moins de risques imprévus du monde réel.

Néanmoins, la plupart des projets informatiques sont lents et en retard , et l’ajout de plusieurs développeurs n’est pas une solution (passer d’une équipe de dix développeurs à deux mille permettra parfois de livrer le projet plus rapidement, parfois pas, et parfois ne fera que nuire au projet et augmente le risque de ne pas le terminer du tout).

Ceux qui sont encore livrés peuvent souvent contenir beaucoup de bogues, nécessitant des service packs consécutifs et des mises à jour régulières (imaginez "installer des mises à jour" sur chaque Airbus A380 deux fois par semaine pour corriger les bogues dans le produit d'origine et empêcher le crash de l'avion).

Comment expliquer de telles différences? Est-ce uniquement dû au fait que l'industrie du développement de logiciels est trop jeune pour pouvoir gérer des milliers de personnes sur un seul projet afin de fournir très rapidement des produits à grande échelle et presque sans faille?

Arseni Mourzenko
la source
127
Question interessante. Je suis tenté de dire que la qualité du travailleur moyen dans l'industrie du logiciel est moins qualifiée et moins qualifiée que le génie civil, où chaque ingénieur a obtenu un diplôme rigoureux et intensif et a probablement obtenu sa charte. En outre, l’espace de complexité des logiciels volumineux (par exemple, un système d’exploitation, MS Office) est probablement beaucoup plus vaste que même un avion. Certainement beaucoup plus d'endroits où échouer! Et un dernier point important: la plupart des logiciels fonctionnent plus ou moins, même s'ils étaient mal écrits et très bogués… Certes, le coût d'une défaillance est normalement bien inférieur à celui d'un avion!
Noldorin
155
Trouvez quelqu'un qui travaille réellement dans l'un de ces autres secteurs (mais pas dans les relations publiques) et posez-lui des questions sur les "grands projets irréprochables". Je peux pratiquement garantir que vous gagnerez des éclats de rire douloureux.
Michael Borgwardt
151
La réalisation d'un projet logiciel prend quelques secondes ou minutes; c'est ce qui se passe lorsque vous cliquez sur "compiler" dans votre IDE. D'autre part, la programmation est design . Combien de temps a-t-il fallu pour concevoir l’A380?
Ant
53
Ce programme télévisé est un battage publicitaire. Ils ne diffusent que des projets couronnés de succès. Toute chaîne créera des programmes à l'attention des téléspectateurs.
pandu
117
Imaginez "installer des mises à jour" sur chaque Airbus A380 deux fois par semaine ... "Imaginez des robots ennemis recherchant constamment des vulnérabilités dans l'avion, tandis que des pilotes non entraînés pressent des boutons au hasard. Je parie que vous aurez besoin de correctifs réguliers.
Nathan Long

Réponses:

337

Death March d' Ed Yourdon aborde un certain nombre de ces questions de type méta.

En général, l’industrie du logiciel manque de nombreux éléments, ce qui gêne les grands projets.

  • Normalisation et décomposition des tâches.

    • Cela a certainement été amélioré, mais les structures de conception ne sont toujours pas là pour créer un gros système. À certains égards, les logiciels ne peuvent même pas s’accorder sur ce qui est nécessaire pour un projet donné, encore moins être capable de décomposer les éléments en composants.
    • L'aérospatiale, la construction de bâtiments, l'automobile, etc. ont toutes une architecture très axée sur les composants avec des interfaces relativement étroites pour permettre un développement entièrement parallèle. Le logiciel laisse toujours passer trop de fonds dans les zones correspondantes.
  • Un grand nombre de projets similaires réussis. L'A380 n'était pas le premier grand avion construit par Airbus . Il existe de nombreuses applications logicielles volumineuses, mais beaucoup d’entre elles ont souffert de façon dramatique à un point de vue ou à un autre et ne seraient pas près d’être qualifiées de "réussies".

  • Un grand nombre de concepteurs et de constructeurs qui ont travaillé sur un certain nombre de projets similaires et couronnés de succès. En ce qui concerne le succès du projet, le fait de ne pas avoir le talent humain qui a été là rend les choses très difficiles du point de vue de la répétabilité.

  • "Jamais" construire deux fois la même chose. À bien des égards, un avion est comme n'importe quel autre avion. Il a des ailes, des moteurs, des sièges, etc. Les grands projets de logiciels se répètent rarement. Chaque noyau de système d'exploitation est significativement différent. Regardez la disparité dans les systèmes de fichiers. Et d’ailleurs, combien y at-il d’OS véritablement uniques? Les gros deviennent des clones d'un élément de base à un moment donné. AIX , Solaris , HP-UX , ... héraut de retour à AT & T System V . Windows a eu une quantité incroyable de glisser en avant à chaque itération. Les variantes de Linux reviennent généralement au même noyau que celui commencé par Linus. Je soulève la question, car les variantes ont tendance à se propager plus rapidement que les systèmes d’exploitation propriétaires vraiment uniques.

  • Estimation vraiment mauvaise du projet. Étant donné que le facteur de répétabilité est si faible, il est difficile de prévoir quelle sera sa taille et combien de temps il faudra pour le construire. Étant donné que les gestionnaires de projet et la direction ne peuvent pas mettre la main sur le code et voir réellement ce qui est en train de se faire, des attentes irréalistes concernant les délais sont générées.

  • L’AQ / CQ n’est pas autant mise en avant qu’elle pourrait ou devrait l'être pour des projets plus importants. Cela revient à avoir des interfaces plus lâches entre les composants et à ne pas avoir de spécifications strictes sur le fonctionnement des composants. Ce relâchement entraîne des conséquences inattendues et permet aux insectes de s’infiltrer.

  • Qualifications constamment mesurables. Généralement, les gens parlent du nombre d'années de travail en langage X ou en programmation. Le temps passé est utilisé comme substitut du calibre ou de la qualité des compétences. Comme cela a déjà été mentionné à maintes reprises, il est difficile d'interviewer et de trouver des talents en programmation. Une partie du problème tient au fait que la définition du "bien" reste très subjective.

Je ne veux pas être tout à fait négatif, et je pense que l’industrie du logiciel a fait des progrès considérables par rapport à ce que nous avons été. Des forums comme celui-ci et d'autres ont vraiment contribué à promouvoir la conversation et la discussion des principes de conception. Certaines organisations s'efforcent de normaliser les connaissances de base des ingénieurs en logiciel. Il y a certes matière à amélioration, mais je pense que l'industrie a parcouru un long chemin en assez peu de temps.

utilisateur53019
la source
23
Il était difficile de choisir une réponse à accepter parmi plusieurs très bonnes réponses, mais j’ai finalement choisi celle-ci malgré le fait qu’elle n’avait pas le plus grand nombre de voix. En fait, cette réponse et celle de m3th0dman expliquent précisément pourquoi il existe une telle spécificité dans l’industrie informatique, ce qui permet de comprendre ce qu’il faut faire à l’avenir pour réduire l’écart. Par rapport à la réponse de m3th0dman, celle-ci semble beaucoup plus détaillée.
Arseni Mourzenko
3
+1, mais permettez-moi simplement d'ajouter que, dans la mesure où le logiciel existe dans le domaine de l'esprit, il offre des possibilités presque infinies , alors que chaque plan construit par chaque constructeur doit faire face aux exigences finies de la réalité.
Spencer Rathbun
5
Très bien répondu. Comme exemple intéressant - imaginons si un grand avion a été conçu et implémenté par un groupe de personnes sans processus ni histoire d’entreprise - des personnes qui viennent juste de se réunir et qui ont créé une entreprise pour construire un avion à l’échelle du 747 à partir de zéro. C'est ainsi que sont réalisés 90% des projets logiciels que j'ai vus. Les 10% restants avec des architectes expérimentés et des entreprises ayant une histoire et des processus semblent avoir beaucoup plus de succès. Contre-exemple, examinons le processus de développement d’un logiciel qui provoque la mort de personnes en cas de défaillance.
Bill K
7
Je pense que vous avez accepté la mauvaise réponse. Danny Woods avait raison, les échecs dans d'autres industries sont tout aussi fréquents et la programmation ne construit pas sa conception. La construction dans le monde logiciel est effectuée par le compilateur et est pratiquement gratuite. Votre question initiale était très éloquente. Une fois le travail préliminaire (conception, spécifications, etc.) effectué sur papier, le travail de conception et de spécification d'une structure physique est une spécification EXACTE décrivant la construction de la structure. La seule chose qui corresponde à celle du logiciel est le code. Le code est design, la compilation est construction.
Michael Brown
5
Mais la question elle-même est imparfaite. Bien que nous devions porter un regard critique sur nos propres lacunes. Il est ridicule de faire comme si le secteur des logiciels était le seul à avoir des projets infructueux. Dire "une fois que tout le design a été fait" est également révélateur. Même si vous n’êtes pas d’accord pour dire que la programmation est une activité de conception, à quelle fréquence voyez-vous une conception détaillée et irréprochable préparée à l’avance pour les logiciels? Les utilisateurs donnent des spécifications floues sur les logiciels, car ils prévoient de pouvoir les modifier si les spécifications ne sont pas correctes sans se soucier de l'impact de ces modifications sur l'ensemble de la solution.
Michael Brown
452

La réponse est étonnamment simple: les « autres industries » n'ont un taux d'échec élevé. Nous comparons simplement les mauvaises choses. Les logiciels d’écriture étant souvent appelés «build», nous les comparons aux phases de fabrication ou de construction d’autres industries. Mais si vous le regardez, ce n'est pas du tout une construction: c'est du design . Les conceptions logicielles sont écrites en code et la construction est réalisée par ordinateur, que ce soit en compilant un logiciel ou en l'interprétant directement à la volée.

De nombreuses conceptions dans d'autres industries prennent beaucoup plus de temps que prévu à l'origine, coûtent beaucoup plus cher ou ne voient tout simplement pas aboutir. Semble familier?

Alors, que faisons-nous lorsque nous planifions un logiciel? Nous sommes toujours en train de concevoir, mais à un stade plus précoce.

Dans le logiciel, il n'y a pas de ligne de fabrication à noter. La construction du composant final est (relativement) bon marché et la réplication de ce produit final est à la fois parfaite et réellement gratuite: vous copiez les artefacts de construction.

Danny Woods
la source
47
Même dans l’industrie mentionnée, Aerospace, le Boeing 787 Dreamliner et le JSF F-35 ont tous deux connu des retards importants. La semaine dernière, un parking s’est effondré dans l’un des principaux centres commerciaux de Sydney. Sydney a des normes de construction très rigoureuses mais des erreurs se produisent.
teambob
23
Mille fois ça. Même le lien de calendrier de la question montre que le projet était en développement depuis 1988. Le code source correspond à la conception: developerdotstar.com/mag/articles/reeves_design.html
pkh
2
De nombreux grands projets comme le F-35, le télescope Hubble, etc. ont pris du retard à cause du développement logiciel. Le Hubble est resté en stockage pendant des années car le logiciel n'était pas prêt.
MrLane
11
@MrLane: Dans le monde réel, cela fonctionne comme ceci. Un calendrier est défini pour le moment où le matériel doit être terminé et le logiciel est censé être fait. Les concepteurs de matériel fournissent un DAI à l’équipe logiciel afin que l’équipe sw puisse écrire leur code sans le matériel. Le matériel diffère beaucoup de son emploi du temps et modifie ses interfaces pour résoudre les problèmes matériels, souvent sans que l’équipe de sw ne soit avertie. Enfin, le type de travail fonctionne et est livré très tard. Bien sûr, le sw ne fonctionne pas à cause de la myriade de "fonctionnalités" inattendues. Parce qu'il est moins coûteux de résoudre les problèmes matériels dans ...
Dunk
11
logiciel, l’équipe sw doit maintenant intégrer les modifications apportées au DAI et proposer des solutions de contournement pour le matériel défectueux. Donc, en plus de la livraison tardive du matériel et de l’équipe sw, elle corrige également du matériel informatique, à qui incombe-t-il du retard? Eh bien, l'équipe des logiciels n'est pas encore terminée. C'est le logiciel qui est en retard. Tout le monde oublie toujours les bordereaux de programmation électrique, mécanique et d'ingénierie des systèmes sur lesquels repose sw, puis qui obligent celui-ci à être réécrit et qui ont des exigences supplémentaires. Tout ce qu'ils voient, c'est que l'équipe sw est encore en train de coder. Ainsi, le logiciel est en retard.
Dunk
180

Pour souligner quelques chiffres:

  1. Modification des exigences après le début de la mise en œuvre ; Par exemple, lorsque le premier Airbus A380 a commencé à être créé à l'usine, je ne peux pas croire que si quelqu'un voulait 200 sièges supplémentaires, ceux-ci y seraient installés; mais dans un grand projet logiciel, même après que les programmeurs aient commencé le développement, 5 types d'utilisateurs supplémentaires peuvent être ajoutés.
  2. Complexité - Les grands projets logiciels sont extrêmement complexes. probablement les projets les plus complexes conçus et développés par l’humanité;
  3. Pas assez de ressources sont dépensées en phase d’architecture et de conception ;
  4. Immaturité sur le terrain - le génie logiciel est une discipline relativement jeune par rapport aux autres ingénieurs; Cela a deux implications: a) Pas beaucoup d'heuristiques et de bonnes pratiques; b) Pas beaucoup de spécialistes très expérimentés;
  5. Manque de preuve mathématique - dans la plupart des cas, les méthodes formelles mathématiques ne sont pas utilisées pour prouver qu'un logiciel fonctionne correctement. au lieu de cela, le test est utilisé. Cela est vrai dans d'autres domaines d'ingénierie qui s'appuient davantage sur les mathématiques; la raison en est la complexité;
  6. Rush - de nombreux gestionnaires ont des délais impossibles à atteindre; donc la qualité du code est placée en second lieu, en raison de la date limite.

Répondant strictement à la question - j'ai tendance à croire que les programmeurs ont de très hautes attentes (en particulier en termes de délai de livraison) et ne comprennent pas exactement à quel point il est difficile de programmer de gros logiciels.

m3th0dman
la source
55
La preuve mathématique formelle dans le logiciel, outre le fait qu'il est souvent pratiquement impossible de faire le bien, n'est finalement rien d'autre que d'écrire le programme deux fois (une fois dans le langage de programmation réel et une fois dans le langage de spécification de preuve formelle) et de vérifier que les versions font exactement la même chose.
tdammers
5
Bien sûr, il existe des outils qui peuvent vous aider à écrire les deux en même temps: Coq supporte "l’extraction de programme" pour extraire un programme dans OCaml ou Scheme d’un programme Coq certifié.
Jkff
66
"Changement des exigences après le début de la mise en oeuvre". J'appelle cela le "problème du déplacement des toilettes". Vous construisez une maison, vous mettez la touche finale à la salle de bain et le propriétaire souhaite installer les toilettes dans un endroit différent. Vous leur donnez l'estimation des coûts. Ils rechignent en disant "pourquoi tant de choses, je veux juste les toilettes à une trentaine de mètres?" Vous expliquez ensuite que vous devez installer une nouvelle tuyauterie, déchirer des murs / sols, etc. pour pouvoir passer aux toilettes. Les modifications tardives sont toujours chères.
Le paresseux DBA
7
Je dirais que tester un avion est en réalité beaucoup plus difficile que de tester un logiciel. Avec l'avion, toute la magie mathématique que vous avez évoquée devient inutile si vous avez pensé que le simulateur logiciel ou les éoliennes que vous avez créées ne reflétait pas vraiment le fonctionnement des choses lorsque vous y êtes. La preuve formelle dans le logiciel n'est qu'un problème difficile, comparée à la preuve formelle en ingénierie qui est impossible.
Lie Ryan
2
Le numéro 1 de votre liste est l’OMI le plus important, j’ajouterais deux choses supplémentaires à cela: à court terme, mais beaucoup d’entre eux rendent le projet très difficile à gérer à long terme. - Les modifications de l'environnement d'exécution du logiciel peuvent être radicalement modifiées en peu de temps. Alors que les bases d'un avion resteront les mêmes (doivent voler en cas de tempête, doivent atterrir sur des pistes solides, ..), un logiciel peut totalement casser, si la nouvelle version de l'OS par exemple.
sydd
140

La prémisse de la question est un peu imparfaite. L’A380 et le Boeing 787 ont été livrés avec des années de retard.

Dans le cas de l’A380, le retard a été causé en grande partie par les unités françaises et allemandes d’Airbus utilisant des versions différentes et légèrement incompatibles du logiciel de conception CATIA . Cette incompatibilité se manifestait par des faisceaux de câblage qui ne convenaient pas à l'avion.

CATIA, le logiciel de conception d’aéronefs le plus utilisé au monde, n’est pas anormal, mais quelqu'un, quelque part, a laissé tomber la configuration.

Le Boeing 787 a également souffert de retards liés aux logiciels, mais la plupart de ses problèmes étaient liés aux nouveaux avions traditionnels, comme le contrôle du poids et la livraison de pièces de qualité inférieure par les fournisseurs.

L’A380 et le B787 ont dû modifier la conception de leurs ailes après que l’aéronef initial eut des problèmes de structure.

Les grands projets complexes sont difficiles pour l'homme dans tous les domaines.

Jim au Texas
la source
10
D'accord. Je pense qu’il est faux de penser que le logiciel est "produit plus sournoisement" que le matériel physique, car un mauvais logiciel finit par produire des correctifs très visibles, plus tout le monde doit faire face à un logiciel défectueux. Si un avion est une merde et qu'il doit faire quelques travaux, vous ne le renvoyez pas, les mécaniciens se plaignent généralement dans la plupart des cas, à moins qu'il s'agisse d'un défaut énorme . Et ceux-ci arrivent aussi.
Ben Brocka
6
Je pense que la question demeure, même si les exemples sont imparfaits. Il est statistiquement prouvé que les projets logiciels ont des coûts finaux beaucoup plus importants et prennent beaucoup plus de temps que prévu.
Euphoric
18
Il convient de noter que la conception et la mise en œuvre d’un système d’avions de ligne commerciaux incluent, de manière inhérente, la réalisation d’un projet informatique gigantesque et extrêmement complexe, qui doit être pleinement et correctement fonctionnel.
Pointu
6
Et étant donné que l’A380 avait un rappel important aussi récent que 2010, je ne l’appellerais pas "sans défaut", même à ce moment-là.
Muhammad Alkarouri
3
En outre, de nombreux avions conceptuels ont été financés et annulés au fil des ans, notamment des contrats militaires. Les avions ne sont pas du tout des exemples, car nous n'entendons parler que de nombreux échecs (classifiés) avant de nombreuses années, voire des décennies plus tard.
SilverbackNet
112

Gars gratte-ciel ici. Je ne suis pas sûr de pouvoir répondre à votre question, mais je peux certainement vous éclairer sur divers éléments du fil. Les bâtiments sont en effet très rapides. Une contrainte majeure est la localisation (réglementation). Mais en règle générale, il faut compter 3 à 10 ans pour un bâtiment de grande hauteur.

Je pense que comparer un nouveau bâtiment avec un nouveau projet de logiciel n’est pas très précis. Un nouveau bâtiment est plus proche d’une nouvelle version d’un noyau ou d’un système d’exploitation. À cet égard, le développement logiciel est beaucoup plus rapide. Nous ne construisons jamais à partir de zéro car ce sera une tâche à haut risque que le client ne s’engagerait jamais. La plupart des projets de conception et de développement dans les bâtiments sont dérivés de projets éprouvés et achevés.

Par expérience personnelle, un projet sur dix seulement est jamais construit. Le processus est axé sur le développement plutôt que sur la conception. Ainsi, dès que le prix de l'acier monte en flèche, tout le projet est dépassé ou est conçu, car la conception est la composante la moins coûteuse du processus.

La conception prend un mois de concept à schéma, de deux à six mois pour le développement, six mois de plus pour les détails et les documents de construction par une équipe d'architectes, de consultants en planification, d'ingénieurs en structure, d'ingénieurs en éolienne, d'ingénieurs de services, d'experts-conseils en quantité et en coûts, de géomètres, ingénieurs d'accessibilité et la liste s'allonge ...

L'argument du virtuel contre le physique n'est pas très précis. Nous travaillons également principalement avec des outils virtuels. De plus, nous sommes à la fois éloignés du temps et de l’échelle de notre produit final. Dans la plupart des cas, nous ne pouvons même pas tester certains aspects des bâtiments à l'échelle d'une maquette et nous utilisons la simulation pour tenter de prévoir ce qui pourrait se produire.

En ce qui concerne la complexité, il existe des différences, mais dans l’ensemble, c’est peut-être à peu près la même chose. Nous avons non seulement des unités interdépendantes et de multiples niveaux d’abstractions et d’interfaces à plusieurs niveaux, mais nous sommes également très spécialisés dans de petites parties du processus qui rendent la communication très difficile.

En ce qui concerne l'argument de la conception par rapport au développement, je pense que les deux processus sont conçus par la conception. Il semble bien sur le plan académique de garder ces éléments séparés, mais il n’est pas possible de concevoir si vous ne savez pas comment les choses se passent. Vous augmentez simplement le risque d'échec.

Dans l’ensemble, mon estimation (potentiellement erronée) selon la question de OP est que la programmation est plus un art que l’ingénierie. Pourquoi les gens aimeraient-ils et même le faire gratuitement, y trouveraient-ils expression et élégance? L'informatique est aussi (comme sur l'étain) plus une science que l'ingénierie. Pourquoi voudriez-vous essayer de prouver des algorithmes au lieu de simplement corriger des pièces existantes et de travailler pour que les choses fonctionnent? Pas sûr que cela ait un sens; Je ne suis pas un gars du logiciel.

Un aspect qui me frappe avec la conception et le développement de logiciels concerne le support lui-même. Les ordinateurs rendent le travail centré sur l'homme très peu naturel. Tout est tellement explicite et il y a peu de tolérances. Il est difficile de s'y retrouver mentalement, et certains s'en tirent en se laissant aller à la complexité. Si rien d'autre cela peut avoir quelque chose à voir avec cela?

Le constructeur
la source
2
+1 Merci pour la perspicacité. "concevoir si vous savez comment fonctionnent les choses" -> "concevoir si vous ne savez pas comment les choses fonctionnent"?
tokland
Hé constructeur, j'ai suggéré quelques modifications à ce post, je pense que vous avez d'excellents arguments, j'ai juste essayé de nettoyer une partie de la grammaire.
Steven
Je suis tout à fait d’accord avec le fait que la programmation est plus un art que l’ingénierie. Je trouve souvent la créativité comme un aspect fondamental de la conception de logiciels.
Lanzafame
1
Je ne suis pas d'accord avec l'affirmation selon laquelle un grand projet logiciel et une tour ont une complexité similaire. Compte tenu de mon expérience en tant qu'ingénieur en structure et ingénieur en logiciel, je dirais que la complexité logicielle est beaucoup plus grande. Il y a probablement une foule de raisons à cela, mais celle que je suggérerais est qu'il y a beaucoup de marge de manœuvre en ingénierie; la limite supérieure de la conception de la construction est presque toujours donnée par le coût, et c'est une contrainte douce. Les logiciels doivent être exacts , car les ordinateurs ne traitent pas bien les ambiguïtés. La dalle ne fonctionne pas? Ajoutez une merde d'acier, elle aura raison.
Simon Robb
Certaines personnes conçoivent et construisent des bâtiments pour le plaisir. Ne le dites pas à mon employeur, mais maintenant que j'y pense, certains de mes logiciels ressemblent à ceux de la Sagrada Familia: idiosyncratiques, trop d'ornements, jamais tout à fait terminés; mais de conception intéressante, amusant à construire et à utiliser et toujours debout.
Peter A. Schneider
44

Alors combien de temps a pris la conception de ceux-ci? Année? Deux? Dix ans? La conception est la partie la plus complexe de la construction, la construction elle-même est facile.

Sur la base de cet article , on comprend lentement que le développement logiciel est principalement un processus de conception où le document de conception est le code source lui-même. Et le processus de conception est totalement différent du processus de production. Cela nécessite du personnel expérimenté et est impossible à planifier, car même de petites modifications des exigences peuvent entraîner des modifications énormes de l'architecture globale du projet. Cette compréhension est la base des méthodologies agiles qui se concentrent sur l'amélioration de la qualité du code en tant que document de conception final et sur l'intégration des tests et du débogage dans le processus de conception, tout comme ils testent les modèles d'avion en soufflerie.

La construction elle-même est gérée automatiquement par les compilateurs. Et grâce à cela, nous sommes en mesure de construire des produits complets en quelques minutes.

La raison pour laquelle les projets logiciels sont achevés avec des retards énormes et des coûts exagérés tient au fait que les responsables pensent toujours pouvoir estimer, prévoir et planifier un tel processus de conception. Cela se retourne plus souvent que ce qui est réellement valable. Ils continuent de penser que, en liant les gens à un processus de construction rigide, ils peuvent en quelque sorte améliorer la qualité, même si le résultat final est généralement opposé avec une augmentation des coûts et des délais non respectés.

euphorique
la source
2
"Cette compréhension est la base des méthodologies agiles". Exactement. La méthode de la cascade est logique pour les gratte-ciel: vous voulez que tous les détails du plan soient exacts avant de verser la fondation. Toutefois, si la destruction et la reconstruction de gratte-ciel étaient gratuites et quasi instantanées, à l’instar de la compilation de code, vous utiliseriez probablement un processus itératif.
Nathan Long
22
@NathanLong: Surtout s'ils sortaient de nouvelles formes de béton tous les trois ans et que quelqu'un découvrait comment faire fonctionner plusieurs ascenseurs dans un seul et même arbre. Soudain, l'acier n'était plus cool et tout le monde décidait de construire ses cadres en carbone. fibre. Ce genre de choses se passe tout le temps dans l'industrie du logiciel.
TMN
2
"le développement logiciel est principalement un processus de conception où le document de conception est le code source lui-même", vous venez de m'ouvrir les yeux. Merci.
Fr. Kevin D.
@TMN Imaginez que, lors de la construction d'un gratte-ciel, ils modifient la palette de couleurs de l'intérieur car elle ne semble pas correcte. Cela s’applique à n’importe quel élément du bâtiment. Essayer de faire fonctionner plusieurs ascenseurs sur un seul arbre est une chose, mais il faudrait tester 20 ascenseurs provenant de différents fournisseurs avant même d'essayer de tous les accrocher à l'arbre ...
Loïc Faure-Lacroix
@ LoïcFaure-Lacroix: Les ingénieurs peuvent tester 20 ascenseurs différents. Les développeurs utiliseraient simplement celui décrit dans l'article du blog où ils en ont entendu parler pour la première fois. Ensuite, lorsque le bâtiment a ouvert et qu'il y a eu un problème avec les ascenseurs, ils ont découvert que la société qui les avait construits n'existait plus. Quand ils ont essayé d'obtenir des pièces de rechange d'un autre fournisseur, ils avaient découvert que leurs ascenseurs d'origine utilisaient un puits non standard ...
TMN 10/10
39

Imaginez, au beau milieu de la conception de l’Airbus A380, une personne interpellée lors d’une réunion a déclaré: «Hé, pourriez-vous le construire en tant que triplan? D'autres se sont joints à eux en disant: "Ouais, oui. Un triplan. Plus d'ailes, c'est mieux." Les trois années suivantes sont consacrées à la transformation de la conception de l’A380 en un triplan. Lors d'une autre réunion, quelqu'un a dit: "Un triplan? C'est vieux. Nous voulons un biplan. Il suffit d'enlever une des ailes."

Ou imaginez, au beau milieu d'un projet de construction de pont, quelqu'un dit: «Hé, nous venons de passer un accord avec une compagnie de transport. Ils ont besoin que le pont soit encore plus haut de 40 pieds, car leurs navires sont beaucoup plus grands. Corrigez-le. Merci. . "

Ce ne sont là que quelques-unes des raisons pour lesquelles les projets logiciels, grands et petits, aboutissent à un échec alarmant.

Kennah
la source
8
C'est exactement ce qui se passe. Les types de gestion ou les clients changent d’avis toutes les 10 secondes, ce qui frustre les développeurs. J'ai quitté mon dernier emploi à cause d'une merde comme celle-ci
Erin Drummond
3
Cela me vient à l’esprit: youtube.com/watch?v=BKorP55Aqvg&feature=kp
miraculixx le
21

En tant que personne ayant une formation en ingénierie mécanique travaillant dans l'informatique, je me suis souvent interrogée sur les raisons du faible taux de réussite en informatique.

Comme d’autres dans ce fil, j’ai souvent attribué les échecs à l’immaturité de l’informatique, au manque de normes détaillées (oui, je suis sérieux, avez-vous déjà vérifié la feuille standard d’un simple boulon?) Et au manque de normes composants et modules.

D'autres industries, comme la construction de bâtiments ou la construction navale, ont également beaucoup plus de "sentiers battus": la connaissance et l'expérience d'un prototype de solution particulier, qui - sous une forme personnalisée - est réutilisée encore et encore. Vous êtes-vous déjà demandé pourquoi des bâtiments, des navires ou des avions de tailles et d’objets différents se ressemblaient autant? (il y a des exceptions à la règle de cours ...)

En effet, ces prototypes sont bien documentés, bien compris, généralement utilisés et ont fait leurs preuves. Pas parce que cela ne pouvait pas être fait autrement. En informatique, la normalisation est rarement le cas: les projets (de grande taille) ont tendance à réinventer des composants, en effectuant des recherches et des livraisons en même temps et avec les mêmes personnes!

Celles-ci conduisent inévitablement à des produits uniques, dont le développement et le service coûtent cher, sont sujets aux erreurs et échouent de manière imprévisible dans des conditions incertaines. Et pour cette raison, bien sûr, ces produits sont beaucoup plus rapidement obsolètes, consignés par écrit et remplacés à des coûts tout aussi élevés par des produits légèrement meilleurs. Ce dont l'informatique a besoin, c'est l'équivalent de la révolution industrielle, qui a transformé les artisans du moyen âge en usines performantes.

Cela dit, certains facteurs rendent l’informatique vraiment unique. Contrairement aux autres industries mentionnées, l'informatique est vraiment omniprésente: elle est utilisée dans tous les aspects de notre vie moderne. C'est donc un petit miracle que l'informatique ait réalisé autant de progrès et soit capable de produire les résultats escomptés.

Peter Mortensen
la source
5
+1 Bon exemple pour la normalisation (feuille standard d'un simple boulon). En informatique, rares sont les composants normalisés. Prenez les formulaires d'inscription: chaque site Web réinvente le leur, et rares sont les développeurs qui savent comment leur formulaire d'inscription se comporte avec unicode, avec des chaînes vides, avec des chaînes trop longues, etc.
Arseni Mourzenko
1
@MainMa: pauvre exemple, créez-vous vos boutons, zones de texte, zones d'option, zones d'option à partir de divs? Non, vous réutilisez les éléments de formulaire du navigateur. et les navigateurs utilisaient les éléments de formulaire du système d'exploitation.
Lie Ryan
4
Je parlais plutôt des internes, pas des contrôles. Prenez un site Web au hasard. Pouvez-vous utiliser des caractères chinois pour le mot de passe? Pouvez-vous utiliser des mots de passe de 25 caractères? Que se passera-t-il si vous mettez un espace dans le mot de passe ou le nom d'utilisateur? Tout cela pourrait être normalisé, mais ce n'est pas le cas, et chaque personne réinvente la roue pour chaque projet, souvent de manière erronée, c'est-à-dire pas de hachage et / ou de salage, ou des mots de passe limités à seize caractères (exemple: MSN), etc.
Arseni Mourzenko
4
Changer l'informatique "d'artisans" en "usines" peut ne pas être possible. Les usines exécutent un processus déjà créé. Les ouvriers d'une usine exécutent leur processus avec peu ou pas de pensée humaine. C'est pourquoi de nombreuses usines ont remplacé les humains par des robots. En logiciel, vous n'exécutez pas un processus, mais en créez un. La création d'un logiciel s'apparenterait davantage à la conception de l'usine et de ses processus qu'à la gestion de l'usine. Bien que la création de logiciels puisse tirer parti des normes, elle ne peut fondamentalement pas devenir une usine.
mike30
@ArseniMourzenko c'est une mauvaise comparaison que de comparer les "fiches techniques des boulons" (outils, équipements) aux "normes relatives aux formulaires d'enregistrement". Les formulaires d'inscription ressembleraient davantage à "un toit" ou à "une porte d'entrée" (en fait, il existe une multitude de façons de les fabriquer). Ce à quoi un boulon se compare ressemble plus à un comportement de pipeline de processeur. C’est loin de ce dont nous avons besoin: système d’exploitation fiable (avec des caractéristiques rigoureusement définies, et non "les données risquent de heurter le disque en fonction des options de montage utilisées") et outils de développement identiques (ils doivent pouvoir contrôler 90% du code pour des tests standard). propriétés)
sehe
15

J'ai peur de ne pas être d'accord avec votre déclaration.

Airbus et Boeing sont deux exemples d'entreprises qui construisent des avions. Combien y a-t-il d'entreprises qui construisent des avions? Très peu, si vous comparez cela au nombre d'entreprises qui construisent des logiciels.

Il est tout aussi facile de visser un projet d'avion que de visser un projet logiciel. Si seule la barrière à l'entrée était aussi basse dans l'industrie de la construction aéronautique que dans celle du logiciel, vous verrez certainement de nombreux projets d'avion échoués.

Regarde les voitures. Il existe des fabricants de haute qualité qui construisent des automobiles très durables et très avancées (par exemple, Land Rover, Mercedes) et d'autres qui construisent des voitures qui ne dureront pas un an sans devoir les réparer (par exemple, Kia ou Cherry). C’est un exemple parfait d’industrie où les barrières à l’entrée sont légèrement inférieures, si vous avez commencé à avoir des acteurs plus faibles.

Le logiciel n'est pas différent. Vous avez beaucoup de produits bogués, par contre, Windows, Office, Linux, Chrome ou Google Search sont des projets de très haute qualité livrés à temps et avec un niveau de qualité similaire à celui d'un avion.

L’autre élément qui manque à beaucoup de gens est la quantité de maintenance nécessaire à l’entretien d’une voiture, d’un pétrolier ou d’un avion que nous considérons comme une réalité. Chaque avion doit subir un contrôle technique avant chaque décollage. Vous devez vérifier votre voiture tous les quelques kilomètres et effectuer des tâches régulières, telles que le changement d'huile, le remplacement des pneus.

Le logiciel a besoin de cela aussi. Si seules les personnes consacraient autant de temps aux diagnostics, à la prévention ou à l’audit de l’état et de la qualité des logiciels qu’elles le font avec des produits mécaniques / physiques, je m'attendrais à bien moins de déclarations comme celles-ci. Lisez-vous les journaux de votre application à chaque fois avant de le lancer? Eh bien ... si c'était un avion, vous devriez le faire ;-)

Karim Agha
la source
5
Windows n'a souvent pas été livré à temps (Longhorn, alias Windows Vista, était censé être disponible en 2003). Je ne sais pas à propos d'Office, mais la plupart des autres projets de logiciels que vous avez mentionnés explicitement n'ont pas de calendrier, ou leur calendrier de publication est si fréquent qu'ils incluent les fonctionnalités prêtes dans la version et repoussent tout le reste jusqu'à ce qu'il soit prêt. .
Ken Bloom
2
C’est un meilleur exemple de logiciel de haute qualité: 420 000 lignes et sans bug: le logiciel qui a propulsé la navette spatiale . Remarquez que l’obtention de ce type de qualité entraînait des coûts énormes.
dodgy_coder
@dodgy_coder, Construire un avion sûr n'est pas bon marché non plus ;-)
Karim Agha
1
@PaulNathan decent est très subjectif;)
James Khoury le
3
@KarimA: Construire un avion sûr n'est pas bon marché, mais le logiciel est un élément essentiel de la sécurité d'un aéronef ... Une partie importante de la conception de l'aéronef est en réalité la conception de logiciel!
étonnement
10

Les blocs de construction numériques peuvent être 1 ou 0. Il n'y a pas d'intermédiaire.

Une conception mécanique a un niveau de tolérance. Je peux mettre un rivet de moins que parfait dans un pont et il ne tombera probablement pas, cependant, dans le code, même une seule fois où mettre un 0 où un 1 devrait être peut échouer tout le programme.

En raison de la nature logique et interactive de l'informatique, toute modification, même minime, peut conduire à un échec drastique.

Ashpool
la source
21
Une fois, j'ai entendu quelqu'un dire: "La construction serait comme une programmation si, lorsque vous placez la dernière poignée de porte sur la maison à l'envers, toute la maison explose".
Morgan Herlocker
9

Je me suis souvent demandé la même chose. Il a certainement se sent (occassionally) comme nous sommes un groupe d'amateurs qui n'ont pas la moindre idée de ce que nous faisons. Je n'aime pas les explications qui blâment les gestionnaires ou d'autres facteurs externes - nous, les développeurs, devrions être responsables de ce que nous créons.

Je pense que nous sommes dans une entreprise où les erreurs sont peu coûteuses . Les logiciels de correction ne coûtent pas cher, comparés à la reconstruction d'un gratte-ciel ou au rappel de chaque téléphone portable vendu.

Cela a créé une culture dans laquelle les insectes font partie de la vie quotidienne . Ils sont acceptés avec un haussement d'épaules. Certains insectes sont probablement inévitables, mais devraient-ils dominer notre travail quotidien ? Je comprends tout à fait les gestionnaires qui ne pensent pas que l’assurance qualité en vaut la peine, précisément parce qu’ils s’attendent à des bogues. Je ne comprends pas les programmeurs qui ne font pas tous les efforts pour produire du code sans erreur, car la correction des bogues est ennuyeuse.

Je crois qu’il s’agit d’un problème de culture et j’espère que cela changera.

waxwing
la source
5
Comprenez-vous les programmeurs qui ne font pas tous les efforts pour produire du code sans erreur, parce que cela prendrait deux fois plus de temps et que la direction leur souffle de mettre en œuvre ces nouvelles fonctionnalités hier?
Bêta
4
Cela ne devrait-il pas être aussi le cas d'autres industries? Je ne nie pas que les facteurs externes n'existent pas, mais je crois qu'un changement doit venir de l'intérieur. Si les ingénieurs en logiciel assumaient leur rôle d’experts dans leur domaine, leurs recommandations et leurs estimations seraient respectées et non devinées par la direction. Ou suis-je naïf?
waxwing
2
Je suis souvent surpris lorsque je visite occasionnellement un client et que je le regarde utiliser le produit que je programme. Il y a des bogues et des fonctionnalités qui rendent leur travail très difficile, et en tant que programmeur, je vois combien cela pourrait être amélioré pour l'utilisateur, mais l'utilisateur ne s'en est jamais plaint, car il pense que cela n'en vaut pas la peine. pour le signaler.
étonnement
7

Les normes et les pratiques d'ingénierie sont très différentes dans l'informatique (en tant qu'industrie indépendante) que dans l' aérospatiale . Ceci est peut-être plus facilement compris en considérant la réaction des professionnels de l'informatique lorsqu'ils rencontrent des documents de normalisation pour l' informatique dans l'aérospatiale . Par exemple, les normes Joint Strike Fighter C ++ qui ont récemment fait leur chemin sur Internet.

Beaucoup expriment leur mécontentement ou leur démission nostalgique (nous voudrions pouvoir le faire de cette façon); et beaucoup réagissent avec ridicule, affirmant qu'il n'y a pas de moyen pratique de fournir des produits de consommation de cette manière. Cela peut même être juste, compte tenu des attentes, non pas des consommateurs, mais de la direction. Il y a beaucoup de méfiance à l'égard des codeurs qui codent et codent pendant quelques semaines sans rien démontrer. Dieu aide le codeur qui conçoit simplement quelque chose pendant deux semaines. Ce n'est pas le cas avec les avions.

Dans le logiciel, les gens s'attendent vraiment à avoir quelque chose en ce moment. Bien sûr, le raisonnement va, il faudra un peu de temps pour que ce soit vraiment solide; mais ne pouvons-nous pas avoir quelque chose de complexe décrit en termes simples en une semaine? On apprend aussi que les choses complexes décrites en termes honnêtes et complexes excitent rarement l'imagination; et ainsi de nombreux ingénieurs finissent par se rendre complices d'un monde imaginaire où des choses très simples sont mises en place de manière créative (par opposition à un monde de choses dures bien exécutées).

solides
la source
5

Quelques trucs de moi:

1- Normes et pièces: Ce sont des constructeurs d' avions , pas des développeurs. Je ne suis pas tout à fait sûr, mais je suppose que beaucoup de pièces sont sous-traitées. Ils ne construisent pas leurs propres instruments / instruments électroniques, ils obtiennent des sièges de certaines sociétés, les moteurs sont probablement développés ailleurs, etc.

Par contre, les projets logiciels partent presque toujours de zéro avec seulement quelques petits cadres / assistants en place.

2- Il est temps d'arriver sur le marché: le temps n'est pas un problème pour les avions. Je parie que la conception de l’Airbus a été finalisée bien des années avant son achèvement, et ils ont choisi de négliger les avancées majeures qui pourraient survenir à cette époque. (Idem pour les constructeurs automobiles, par exemple, la technologie de pointe qu'ils développent actuellement tombera dans les rues dans 5 à 10 ans.)

Pour les logiciels, vous devez être très agile. Si je lance un énorme projet maintenant et que je prends trois ans pour le développer sans aucun changement, il y a de fortes chances pour que je compte sur une technologie qui n’est plus disponible ou sur un produit totalement obsolète. Ceci à son tour pose beaucoup de problèmes.

3- Cycle de publication et versions. - Un avion doit être complètement terminé lorsqu'il est "libéré". Il n'y a pas de versions bêta stables, de versions nocturnes ou similaires. De plus, une fois que c'est fait, il ne peut être modifié que de façon modeste. Vous ne pouvez pas ajouter un niveau supplémentaire de 100 sièges à un boeing existant, ce n'est tout simplement pas possible.

Les logiciels, en revanche, comportent des modifications incrémentielles qui ne sont souvent que des "constructions qui fonctionnent", mais pas nécessairement des produits finis. De plus, en informatique, il n’est pas rare de dire "hé, ajoutons un autre compartiment à bagages à notre avion qui peut contenir 50 tonnes supplémentaires".

racoonie
la source
5

Je pense que la réponse est assez simple:

1) La construction et la mise en œuvre physiques existent depuis aussi longtemps que les gens - nous avons mis des milliers d'années à développer nos méthodes et techniques de mise en œuvre de projets physiques. La «construction» de logiciels, qui nécessite un ensemble de compétences entièrement nouvelles et différentes, n’a pas plus de 50 ans - nous n’avons pas encore eu le temps de tout comprendre.

2) La construction virtuelle est plus difficile - vous devez «voir» des choses dans votre esprit qui n'ont aucune réalité physique. Vous devez analyser et résumer de nombreuses informations avant même de savoir à quoi votre produit est censé ressembler et les étapes à suivre pour le créer. Ce n'est pas le cas lors de la construction d'un pont ou d'un bâtiment.

3) Il est souvent beaucoup plus difficile de trouver la source d’une défaillance ou d’un bogue logiciel que lors d’une ingénierie physique. Si une poutre se déforme, vous voyez où elle se bloque, ainsi que les supports qui la retiennent et tombent en panne, etc. lois de la physique et des mathématiques à la manière des structures physiques.

vecteur
la source
4

Je vais essayer de répondre en utilisant une copie textuelle d'un article de la muse intégrée de Jack Ganssle. Bien que cela indique un micrologiciel partout, il suffit de le remplacer mentalement par un logiciel.

Comparé à quoi?

Le micrologiciel est la chose la plus chère de l'univers. Dans son merveilleux livre "Augustine's Laws", Norman Augustine, ancien PDG de Lockheed Martin, raconte une histoire révélatrice d’un problème rencontré par la communauté de la défense. Un avion de combat hautes performances représente un équilibre délicat entre des besoins contradictoires: autonomie en termes de carburant et performances. Vitesse par rapport au poids Il semble qu'à la fin des années 70, les combattants étaient à peu près aussi lourds qu'ils ne l'auraient jamais été. Les entrepreneurs, toujours à la recherche de profits plus importants, cherchaient en vain quelque chose qu’ils pourraient ajouter qui coûterait cher, mais qui ne pèse rien.

La réponse: firmware. Coût infini, masse zéro. L'avionique représente maintenant plus de la moitié du coût d'un chasseur. C'est un gros morceau de changement quand on considère le dernier avion de combat américain, le F-22, coûte un joli tiers de milliard. Augustine glousse de joie quand il raconte cette histoire.

Mais pourquoi les logiciels sont-ils si chers? Tom DeMarco a un jour répondu à cette question avec ces trois mots: comparé à quoi? Il a ensuite abordé des cas d’affaires relativement ennuyeux, mais cette réponse me tient à l’esprit depuis des années. Comparé à quoi? Avec les logiciels, nous créons régulièrement des comportements de produits d’une complexité sans précédent. Bien sûr, le code est cher. Mais jamais dans l'histoire de la civilisation, personne n'a construit quelque chose d'aussi complexe.

Considérez le type de bulle suivant, soulevé sans vergogne de Wikipedia et non vérifié pour la précision:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

C'est un simple 110 caractères non-espace, peut-être jeté dans une heure ou deux. Supposons que nous n’ayons pas de logiciel et que nous devions mettre en œuvre une sorte en utilisant une autre stratégie. Combien cela coûterait-il?

Un ingénieur en mécanique pourrait se vanter d'avoir construit des trieuses bien avant les ordinateurs. Considérez le trieur de cartes modèle 82 d’IBM datant de 1949 ( http://www.columbia.edu/acis/history/sorter.html ) avec un débit de 650 cartes par minute, un résultat inférieur à celui que notre extrait de code pourrait gérer même sur 4 MHz. Z80. Bien entendu, le modèle 82 ne triait qu'une colonne d'une carte à la fois; trier complètement une plate-forme pourrait prendre des dizaines de passes.

Combien de temps a-t-il fallu pour concevoir et construire cette bête? Des années sans doute. Et sa fonctionnalité est dérisoire comparée à notre code beaucoup plus rapide et capable de gérer des jeux de données gigantesques. Mais c'était en 1949. Combien de temps faudrait-il pour créer une sorte de bulle à partir de composants électroniques - sans FPGA ni VHDL, ni processeur?

En une heure, j’ai réussi à obtenir un diagramme approximatif, au-dessus du niveau de la puce (les blocs portent des noms tels que "additionneur", "verrouillage 16 bits", etc.). Mais la logique de séquençage est clairement assez compliquée, alors je viens de lancer une PLD, en supposant qu'à un moment donné, il ne serait pas trop difficile d'écrire les équations appropriées. Et, oui, cela enfreint peut-être la règle de la logique non programmable, mais concevoir et déboguer toute cette logique en utilisant des barrières dans un laps de temps raisonnable est aussi improbable que de l’argent à la va-vite.

En supposant des mots et des adresses de 16 bits, le circuit aura besoin d’une douzaine de verrous, d’additionneurs, etc., de 16 bits. Plus de mémoire. Et je ne sais pas du tout comment les données non triées arrivent dans la RAM ou comment les résultats sont exportés. Ce sont des exigences de conception non spécifiées. La solution logicielle seule résout naturellement ces exigences simplement en écrivant le prototype de fonction.

Traduire le schéma de principe approximatif en schéma peut prendre une journée. Ensuite, le temps est venu de concevoir et de produire un circuit imprimé, de commander et de charger des pièces (et de modifier la conception afin de traiter les problèmes de fin de vie inattendus mais inévitables), puis de faire fonctionner le circuit. Nous pourrions parler de semaines d’efforts et d’argent pour le conseil, les pièces et l’équipement d’essai approprié.

Tout cela pour remplacer 7 petites lignes de code. Peu de programmes embarqués réels ont moins de 10 000; beaucoup dépassent le million. Combien de matériel et d’ingénierie seraient nécessaires pour remplacer un programme informatique réel de très grande taille?

Considérons un vrai programme comme un tableur. Combien de circuits faudrait-il pour en fabriquer un sans processeur? Cela pourrait être la taille d'une ville.

Le micrologiciel est la chose la plus chère de l’univers, mais uniquement en raison de la complexité inimaginable des problèmes qu’il résout. Mais c'est beaucoup moins cher que n'importe quelle alternative. Ainsi, lorsque votre supérieur vous demande avec irritation pourquoi le logiciel est si long, vous savez quoi dire. Comparé à quoi?

Donc là! Les logiciels / micrologiciels présentent une complexité sans précédent.

Vaibhav Garg
la source
3

L'ingénierie logicielle et la gestion sont fondamentalement différentes de beaucoup d'autres domaines d'ingénierie. Les produits livrables ne sont pas physiques et le processus de production est le processus de conception et de développement. La création d’une autre copie d’un logiciel a essentiellement un coût marginal nul; tous les coûts sont liés au développement du premier exemplaire.

En raison de la jeunesse relative de l’ingénierie et de la gestion des logiciels en tant que discipline, certaines informations erronées et mensonges sont toujours considérées comme des faits ( voir cette référence ) qui entravent le développement et l’ingénierie logiciels dans leur ensemble.

joshin4colours
la source
3
+1 sur l'immaturité du développement logiciel. Le génie civil a eu quelques milliers d'années pour développer ses pratiques. L’aérospatiale en a eu une centaine et s’appuie sur d’autres disciplines du génie. Le logiciel est encore jeune. C'est aussi normalement mal compris. Les enfants peuvent créer des ponts au-dessus des ruisseaux ou créer des avions en papier lorsqu'ils sont enfants - il n'en va pas de même pour les logiciels.
Andy Burns
3

Tous les développeurs ne sont pas créés égaux. Certains sont bons, d'autres non.

Essayez de lire le code des autres tout le temps pour avoir une idée de ce que je dis. Trop d'énoncés logiques supplémentaires peuvent augmenter les risques. Ces risques peuvent conduire à des comportements malsains ou à des bugs. Pas assez d'instructions logiques et maintenant vous avez des références nulles. Le bon programmeur comprend cela et sait quand faire quoi et où. Mais personne n'est parfait. Les choses sont complexes. Ajoutez le travail mal pensé des autres et il est facile de voir comment les projets se dérobent.

Le duc
la source
3

Les cathédrales avaient besoin de 100 ans pour être construites.

Un avion Airbus nécessite 1 million de lignes de code pour fonctionner.

Plus vous avez progressé, plus vous avez progressé. Donnez à l'industrie du logiciel quelques siècles d'essai pour améliorer, et nous verrons à quel point il est nécessaire de développer un projet solide et sans bogues. ou des défauts.

NotGaeL
la source
La cathédrale de Cologne a été commencée en 1248 et achevée en 1880. 632 ans.
gnasher729
3

Les grands projets se produisent souvent dans de grandes organisations. Si vous n'avez jamais travaillé dans une grande entreprise, il y a une chose qui est garantie pour nuire aux performances et à la productivité: la bureaucratie.

Étonnamment, beaucoup de gens ne savent pas ce qu'est la bureaucratie (elle est souvent confondue avec la politique), ni même si / quand ils ont un problème de bureaucratie.

Nous avons récemment conclu un projet visant à mettre en œuvre l'authentification par carte à puce. Il a été initialement estimé à trois mois. Cela a pris 15 mois. Il n'y avait aucun coût, budget, portée ou raisons techniques pour ce retard. La portée était en réalité assez étroite - seulement pour les comptes avec des privilèges élevés (comptes d'administrateur), environ 1 200 comptes au total.

Vos partenaires commerciaux sont un autre facteur important. Cela inclurait les vendeurs. Si vos partenaires ont un problème introduisant un retard dans votre projet, peu d'options résolvent réellement le problème. Ils ne travaillent pas directement pour vous et vous ne pourrez peut-être pas virer cette personne contre un partenaire qui pourrait en être la cause. Le partenaire peut être licencié ou faire l'objet de pénalités financières ou de mesures dissuasives, mais cela ne change rien au fait que le projet a subi un retard. C’est précisément ce qui s’est passé avec Boeing lorsqu’il a adopté une stratégie d’achat gigantesque avec le Boeing 787 Dreamliner .

Greg Askew
la source
3

J'ai une version plus courte pour vous:

Quoi que ce soit facile à faire, ou rationalisé, nous écrivons un programme pour le faire à la place de nous.

Et combattez ensuite avec le méta-processus.

Ce n'est pas tellement vrai en soi, mais chaque jour des milliers de blogs sont mis en place, au lieu d'écrire des moteurs de blog. Chaque jour ouvrable, des milliers de macros Excel sont écrites au lieu d'écrire des applications de base de données spécialement conçues pour celles-ci.

Il y a beaucoup d'autres facteurs, dont certains sont mentionnés ici, mais je voulais ajouter ce point à la discussion.

Aadaam
la source
Je suis d'accord. Les grands programmes peuvent être livrés sans faille et dans les délais, car ils ont été réalisés cent fois en trois décennies. Par exemple, un éditeur de texte.
Droogans
Non seulement cela, mais la manière dont nous livrons les programmes volumineux sans faille, consistait simplement à télécharger l'ancien programme à partir de son site Web et à en faire une copie. Mais pour une raison quelconque, cela ne compte pas comme un grand projet logiciel réussi.
bdsl
3

Absence de responsabilité ... Des personnes sont poursuivies lorsqu'un avion s'écrase. L'industrie du logiciel décline toute responsabilité en cas de défaut logiciel, créant ainsi un manque d'incitation à créer un produit robuste et sûr.

GreyGeek
la source
1
Je le dis depuis longtemps. Si vous étiez poursuivi en justice lorsque votre application était bloquée, le code serait beaucoup plus robuste ... bugs et révisions qui cassent d'autres choses. Les poursuivre pour les heures perdues et la qualité augmentera rapidement.
Vecteur le
Si c'était le cas, les coûts augmenteraient et les fonctionnalités diminueraient.
Jim G.
1
@ JimG. La question portait sur la fiabilité, ni sur les caractéristiques ni sur le prix. Bien sûr, le fait de rendre le produit plus fiable introduira plus de contraintes dans votre espace de conception et d’autres aspects (fonctionnalité et coût) pourraient en souffrir.
GreyGeek
4
Et le coût d'un Boeing 737 est compris entre 50 et 80 millions de dollars. Vous payez chaque fois que vous obtenez un paiement-- payez-vous chaque fois que vous ouvrez Office? Si je me faisais payer chaque fois que quelqu'un utilisait mon logiciel, je me consacrerais à la fiabilité.
FlavorScape
1
@ Jim G: Je préférerais avoir une version stable d'un produit plutôt que cinq versions merdiques.
Giorgio
2

La plupart des grands projets ont un degré élevé de séparabilité des sous-projets, dans lesquels vous pouvez définir un petit nombre de contraintes de conception. l'ensemble du projet fonctionnera lorsque ces sous-projets seront terminés. Si quelque chose ne va pas dans un sous-projet, tous les efforts ne sont pas remis en question; vous recherchez simplement d'autres moyens de mener à bien le sous-projet (par exemple, utilisez un moteur différent).

Ceci est possible mais difficile, à la fois dans la pratique et dans la nature humaine, dans les projets de logiciels.

En partie, d'autres industries ont appris à leurs dépens que cette séparabilité est une bonne chose. Par exemple, si vous envisagez d'utiliser des moteurs d'avion Rolls Royce, vous n'avez pas besoin d'utiliser des boulons et des points de fixation Rolls Royce spéciaux qui fonctionnent uniquement avec des ailes ayant une conception particulière. Ensuite, si vous essayez de passer à Pratt and Whitney, vous devez redessiner entièrement votre aile (ce qui nécessite à son tour une refonte complète du fuselage, ce qui nécessite l'achat de sièges différents, ce qui nécessite l'achat d'un autre système de divertissement en vol, lequel...). Il peut y avoir quelques liens - vous ne pouvez pas simplement échanger les moteurs sans souci - mais les gros projets fonctionnent généralement mieux lorsque ces choses sont réduites au minimum.

Je postule que les grands projets logiciels conçus comme un cluster de petits projets logiciels avec des interfaces propres entre eux ne vont pas échouer particulièrement souvent, tant que le grand projet est réellement résolu par le cluster de petits projets. (Il est possible de se tromper à cet égard.)

Rex Kerr
la source
2

La construction de systèmes logiciels est très différente de la construction de structures physiques. C'est-à-dire que la mise en œuvre est très différente. Par exemple, si vous construisez un énorme camion-citerne, vous effectuez de nombreuses tâches relativement simples (comme si ce n’était pas facile!), Telles que souder des pièces entre elles par un robot ou à la main, serrer tous les écrous et les boulons, peindre, faire la décoration en emportant toutes les pièces. l'équipement et le mobilier et autres. Tout cela est très simple , vraiment.

Cependant, en ce qui concerne les logiciels, cela devient beaucoup plus complexe . Par exemple, comment implémentez-vous exactement la connexion sécurisée et la partie stockant les informations d'identification du produit? Quelles bibliothèques et quels outils pouvez-vous utiliser? Avec quelles bibliothèques et quels outils connaissez-vous? Comment écrivez-vous exactement la fonction de hachage + salage et comment vous assurez-vous qu'elle est sécurisée? Vous pouvez le faire de tant de manières qu'il est impossible de définir des modèles de conception pratiques pour ce genre de choses. Oui, ces modèles de conception n'existent à plus petite échelle que les « meilleures pratiques », mais chaque système logiciel unique est très différent des autres, et les progrès sur le terrain et les changements à un rythme si rapide qu'il est essentiellement impossible de suivre.

Lors de la construction d'une maison, vous ne rencontrez pas vraiment de problèmes de ce type car vous réalisez que les principaux murs de soutènement semblent insuffisants et doivent être remplacés, ce qui vous oblige à démolir les avancées jusqu'à présent et à partir de la base en refaisant les murs de soutènement. . Vous vous attaquez à ces problèmes dès la phase de conception , car il est relativement simple de prévoir le type de murs de support dont votre bâtiment a besoin.

Ce n'est cependant pas le cas avec les logiciels. Vous ne pouvez pas vraiment concevoir le produit dans son ensemble comme une seule entité et ensuite le mettre en œuvre. Le processus de conception logicielle est généralement itératif et les objectifs et les exigences changent à mesure que le produit est mis en œuvre et testé. Le développement de logiciels dans son ensemble est un processus itératif dans lequel les choses changent habituellement quand on s'y attend le moins et ces changements imposent souvent des défis qui exigent plus de travail, plus de complexité et, en définitive, plus d'argent, de temps et d'efforts acharnés pour réussir.

Donc, en gros, la raison pour laquelle il est difficile de réaliser de grands projets et d’estimer les échéanciers et les feuilles de route des projets est que le développement de logiciels et en particulier la conception fonctionnelle sont des domaines très complexes . La complexité est le problème fondamental.

zxcdw
la source
+1, et pour aller plus loin dans l’idée, c’est un manque d’appréciation de la complexité de la part de personnes extérieures au secteur qui conduit à des attentes irréalistes, une politique irrationnelle et une conception improvisée. Le secteur public au Royaume-Uni en est un parfait exemple. Par exemple, dans le cas d’un bâtiment public, la direction essaie d’obtenir une conception parfaite avec l’opinion d’un expert, une vaste consultation et une planification de projet étanche avant de couper le gazon. Mais placez les mêmes personnes devant un nouveau système informatique et vous constaterez des modifications de dernière minute des exigences, du schéma de base de données, de l'interface utilisateur ... "Cela peut être difficile? C'est juste un peu de frappe"
Julia Hayward
1

La définition de "grand projet" est biaisée.

Techniquement, un grand projet peut être livré à temps, et sans faille, sachant que c'est quelque chose qui a été construit de nombreuses fois au fil des ans.

  • Un clone de Pac-Man.
  • Une calculatrice
  • Un éditeur de texte

Je suis sûr que vous pensez ... "mais ce sont de petits projets! Un éditeur de texte est simple ." Je ne suis pas d'accord avec vous. Les ordinateurs sont scandaleusement compliqués. Il peut parfois être difficile d'installer et de configurer des utilisateurs sur un système d'exploitation, et vous n'avez même pas écrit le système d'exploitation ni construit le matériel.

Les projets dont vous parlez sont des projets gigantesques , apparentés à l'exploration spatiale. Comment savez-vous combien de temps il faut pour développer les voyages inter-galactiques? Sur quel modèle nous basons-nous? Vous avez les connus connus, les inconnus connus, les connus inconnus et, enfin, les inconnus inconnus, qui apparaissent souvent dans le développement de logiciels.

Je pense que le problème est une attente. Ce n’est pas parce que la technologie existe que son utilisation aura du succès (ou de l’utilité de l’utiliser) pendant un certain temps. Si d'autres industries se comportaient comme les industries du logiciel, nous aurions des aspirateurs à trou noir à vendre d'ici la fin de la décennie. Ou un "visionnaire" aurait les ressources nécessaires pour construire une base lunaire, et déciderait qu'un Starbucks compléterait réellement l'expérience des visiteurs. Je ne pense pas que le problème est l'industrie du logiciel, mais les attentes placées sur lui.

Droogans
la source
Aspirateurs à trou noir? Qu'en est-il de la sécurité fonctionnelle?
Peter Mortensen
Manque de sécurité fonctionnelle? C'est une fonctionnalité! Nous préconisons l'utilisation de structures immuables lorsque vous essayez de nettoyer quelque chose avec un aspirateur à trou noir.
Jeu de Droogans
1

Bien que ce ne soit pas la seule chose qui puisse être mentionnée, je pense qu’un élément fondamental mérite d’être souligné. La plupart des produits sont conçus pour s’adapter au comportement existant. Même un produit qui constitue une avancée radicale (par exemple, la voiture) est généralement conçu pour s’adapter au comportement existant, et le rend simplement un peu plus simple / plus facile / moins cher / peu importe. Oui, il y a souvent des effets secondaires sur le comportement existant (par exemple, obtenir de l'essence pour la voiture plutôt que de la nourriture pour les chevaux), mais la plupart de ces derniers ont tendance à être un effet secondaire assez mineur.

En revanche, presque tous les logiciels qui ne changent pas le comportement des utilisateurs (par exemple, les laissent faire leur travail beaucoup plus facilement) sont fondamentalement garantis comme un échec complet dès le premier jour. Pire, les grands projets logiciels impliquent le comportement des utilisateurs au niveau individuel, mais le comportement de grands groupes - souvent la totalité de l'organisation.

En bref, la conception du logiciel lui-même est souvent la partie la plus facile du travail. La partie difficile est de redéfinir les emplois des gens pour eux. C'est difficile de commencer avec; Le faire d'une manière qui fonctionnera non seulement mais qui sera également acceptée est beaucoup plus difficile encore.

Jerry Coffin
la source
1

L’Airbus A380 n’a pas été un projet réussi, comme vous l’avez mentionné. Il se trouve que je travaille dans une société de CAO / FAO et on m'a dit que celui-ci (nous avions aussi le projet Airbus) était retardé de quelques années, car ils utilisaient une version différente du logiciel dans une société différente. Autrement dit, différentes parties ont été conçues dans différentes parties du monde. Et tout en intégrant, ils ont appris que tout le design ne pouvait pas être intégré, ils devaient donc le redéfinir dans une version. Donc, en regardant cela, je ne pense pas que cela a réussi. Si cela s'était passé 2 ou 3 ans auparavant, cela aurait changé la donne pour Airbus.

Également en ce qui concerne les logiciels robustes, vous regardez tous les avions, voitures (ABS, EPS, climatisation, etc.) ou les navettes spatiales; ils ont plus de 50% des logiciels qui les exécutent et, à mon avis, ils sont très robustes. C'est simplement que nous sommes plus proches des logiciels et qu'il y a beaucoup plus de logiciels, nous voyons donc plus d'erreurs dans ceux-ci.

Visitez le site http://www.globalprojectstrategy.com/lessons/case.php?id=23 et découvrez le succès remporté par Airbus A380.

Peter Mortensen
la source
1

Ingénieur logiciel ici, avec une formation en ingénierie et une femme qui travaille dans la construction. Nous avons eu de longues discussions (et arguments) sur les différences entre nos emplois.

Le génie logiciel consiste à concevoir de nouvelles choses . Presque tout ce qui est fondamental a été fait quelque part dans une bibliothèque open source. Dans presque tous les emplois où un ingénieur en logiciel est embauché, elle doit concevoir quelque chose qui n'existe pas.

Dans quelque chose comme la construction et la plupart des formes d'ingénierie, les éléments qui seraient autrement dans une "bibliothèque" de logiciels sont déjà entièrement conçus. Voulez-vous construire une tour? Il suffit de copier et coller les plans d'une structure existante, avec quelques modifications.

En fait, l'une des principales raisons pour lesquelles j'ai décidé de ne pas devenir ingénieur est que vous passez la plupart de votre temps à concevoir une amélioration de 10% d'une invention existante, alors que ce même temps pouvait être utilisé pour programmer quelque chose de plus visible, comme un réseau social. .

Il n'y a pas beaucoup de nouvelles conceptions en ingénierie; Un ingénieur extrêmement qualifié est une personne capable de transformer un projet existant en un produit nouveau ou de l'améliorer. Mais presque tous les programmeurs sont censés modifier les conceptions, les pirater ou créer quelque chose de nouveau.

Examinez à quel point les normes ont complètement changé: d' assemblage à C, C ++ à Java, JavaScript, C #, PHP, etc. Il n’ya pas beaucoup de code pouvant être recyclé il ya 10 ou 20 ans. C'est très différent de dire ... dans le secteur de l'automobile ou de l'aéronautique, lorsque vous pouvez continuer à améliorer vos conceptions depuis des décennies.

La gestion de projet est notoirement difficile en logiciel . Ce sont les personnes qui font le travail qui font le mieux les estimations de temps , mais quand elles sont en train de faire des estimations, elles n'écrivent pas de code . Cela incite les gens à éviter toute gestion de projet.

Souvent, beaucoup de code dépend de personnes spécifiques, et si ces personnes sont en retard ou incapables d'exécuter, le code ne progresse pas. En revanche, si vous voulez construire une voiture, vous pouvez simplement embaucher des personnes différentes pour assembler les pneus, le châssis, la batterie, le moteur, etc. Ceci est possible grâce aux frameworks existants et orientés objet, mais cela peut ne pas être pratique lorsque vous concevez tout à partir de zéro.

Les échecs peuvent être autorisés dans le logiciel . Les tests peuvent être coûteux. Dans le logiciel, il est très tentant d’éviter tous ces tests lorsque vous pouvez réparer un crash. Dans la plupart des techniques, un "crash" peut être fatal.

Vous avez des méthodes de programmation qui utilisent des tests approfondis, comme la programmation extrême (qui était en fait utilisée sur les mégaprojets logiciels). Mais avec des délais serrés (qui peuvent être volontairement raccourcis), il est tentant de sauter toute cette programmation et de la lancer avec des bugs. Le style de Joel Spolsky consistant à "corriger systématiquement tous les bugs" permettra de gagner plus de temps à long terme, mais les indisciplinés ignoreront cela et échoueront.

Les petits projets sont meilleurs . Une fois, ma femme m'a demandé de travailler dans une grande entreprise. Cela a abouti à un argument selon lequel les grandes entreprises étaient de mauvaises entreprises… pour elle, une grande entreprise disposait de beaucoup de ressources, d'expérience, d'une gestion de projet fonctionnelle et de procédures adéquates. Pour moi, une grande entreprise est un dinosaure, où vous consacrez la plus grande partie de votre temps à la correction du code, au test de celui-ci et à la documentation.

J'ai déjà vu moins de 10 personnes travailler sur des projets informatiques d'un million de dollars. Plus de gens auraient ralenti le projet et ajouté une bureaucratie inutile. WhatsApp est un exemple de "petit" projet valant des milliards de dollars. Ce n'est pas que les gros projets ne soient pas possibles, mais vous n'avez simplement pas besoin de milliers de personnes pour produire des milliards de dollars en logiciels.

Muz
la source
0

Une des raisons qui n'a pas vraiment été abordée dans les autres questions est que le domaine des logiciels innove à une vitesse qui ne se produit que rarement dans le monde basé sur les matériaux.

Une des raisons à cela est que l'évolution du logiciel est un cycle de retour positif, car un logiciel (langages de programmation, outils de développement, IDE) est utilisé pour créer un logiciel. C'est l'exemple le plus évident de la loi de Ray Kurzweil sur l' accélération des rendements, entraînant des progrès à une vitesse de plus en plus rapide. Une fois que vous avez maîtrisé un cadre, un langage de programmation et un protocole de communication, il est temps de passer au suivant.

Si les avions étaient construits comme des logiciels, nous changerions le matériau avec tous les autres modèles, doublerions leur capacité et leur vitesse tous les 18 mois, remplaçons la technologie des moteurs pour chaque nouveau modèle par quelque chose d'inventé, tout en ajoutant la possibilité de nager et de rechercher des extraterrestres. la vie.

Oh, et idéalement, il écoute les commandes vocales et fait également office de salle de cinéma, de paintball et de boîte de nuit entièrement immersive avec une pièce sombre une fois votre voyage de travail terminé. La même chose! (La société qui a construit les avions qui vous a fourni de A à B de manière fiable est tombée en panne un an après la sortie de celle avec la fonction cinéma, paintball et discothèque.)

Peter A. Schneider
la source
Je ne comprends pas votre point. Premièrement, beaucoup de langues sont assez vieilles. Java a plus de vingt ans. Python a presque trente ans. Oui, il y a de nouvelles langues, mais ce n'est pas comme si nous abandonnions tous une langue pour passer à une nouvelle tous les deux ans. Si l’adoption d’un nouveau cadre, l’EDI ou le langage peut être un facteur de lenteur pour une équipe, je ne trouve pas non plus ceux qui utilisent des outils familiers rapidement. Et l'industrie aéronautique? Des avions comme le Boeing 787 comportent de nombreuses nouveautés difficiles à mettre en œuvre.
Arseni Mourzenko
@ArseniMourzenko Eh bien, Java était populaire pour la programmation de clients Web après sa publication et pour la création d'interface graphique lorsque swing a été publié, mais les deux modes n'ont duré que quelques années. Heck, il n'y avait pas de WWW avant les années 1990. La programmation Web est où les avions étaient en 1910 ou plus. Mais ce rythme est en cours.
Peter A. Schneider
-1

Pour moi, le principal problème auquel le génie logiciel est confronté concerne les cas d'utilisation, les utilisateurs et les plates-formes croisées.

Cas d'utilisation

Combien de cas d'utilisation un avion a-t-il? La majeure partie consiste simplement à voler d'un endroit à un autre. Peut-être y en a-t-il d'autres, comme le radar, le contrôle de la circulation, etc., mais le cas d'utilisation est clair et peu détaillé. En génie logiciel, nous sommes confrontés à des exigences peu claires et à des utilisateurs qui ne savent pas ce qu’ils veulent. Différents utilisateurs ont besoin d'une configuration / d'un flux différents, un avion peut-il être personnalisé selon les souhaits de l'utilisateur (je souhaite disposer d'un téléviseur et d'un réfrigérateur!)?

Utilisateur

Qui exploite un avion? Un pilote, un copilote, des stewards (si comptés) et des opérateurs de la tour. Ils sont tous des pros et leurs descriptions de travail sont claires. Les logiciels sont utilisés par les noobs et les nuls, sans parler des pirates informatiques et des pirates, tout en restant compatibles avec d’autres modules (tels que OpenID ou Google AdSense ). Si un avion peut être exploité par des mannequins tout en survivant de missiles ou de voleurs de ninja, vous pouvez dire que cet avion a la même qualité de logiciel.

Plates-formes croisées

Un avion ne vole que dans le ciel terrestre. Je ne suis pas sûr de savoir comment ils gèrent le climat brumeux ou venteux ou chaud, froid et humide, mais un avion n'est pas conçu pour voler à un niveau de gravitation différent (je serai étonné s'il peut voler jusqu'à Mars ). Parfois, une application doit survivre à différentes plates-formes, telles que Internet Explorer, Google Chrome , Firefox et Safari pour navigateur (par exemple Opera ), ou Windows XP / 7/8, ou Linux pour OS. Sans parler des appareils mobiles et des résolutions et orientations différentes.

Fendy
la source
-1

Si vous pensez que d’autres industries réalisent des projets sans incident, vous devriez lire l’histoire du bâtiment Citigroup Centre construit en 1977. Même après près de 7 ans de planification et de construction, le bâtiment a été achevé avec un grave défaut de conception qui aurait provoqué un effondrement du bâtiment. tempête attendue tous les 16 ans.

En d'autres termes, chaque année, le Centre Citicorp était sur place, il y avait environ une chance sur 16 que celui-ci s'effondre.

Les concepteurs d'origine n'étaient pas au courant des problèmes, mais heureusement, un étudiant en train d'étudier l'immeuble s'est fait prendre.

tout semblait aller bien - jusqu'à ce que, comme le raconte LeMessurier, il reçut un appel téléphonique. Selon LeMessurier, un étudiant de premier cycle en architecture l'a contacté en 1978 avec une affirmation audacieuse au sujet de l'immeuble de LeMessurier: le centre Citicorp pourrait souffler dans le vent.

Les réparations ont été faites littéralement en couverture de nuit et ont impliqué le moins de personnes possible afin de préserver le secret du défaut de conception.

Un plan d'évacuation d'urgence a été préparé pour le rayon de 10 pâtés de maisons entourant le bâtiment.

Ils ont soudé toute la nuit et ont démissionné au lever du jour, juste au moment où les occupants de l'immeuble sont retournés au travail.

L’histoire est restée secrète jusqu’à ce que l’écrivain Joe Morgenstern ait entendu la nouvelle lors d’une soirée et interviewé LeMessurier. Morgenstern a révélé l'histoire dans The New Yorker en 1995.

Ce qui pose la question combien d'autres défauts de conception mortels dans des projets ont été réparés ou ignorés secrètement sans reconnaissance publique.

cmcginty
la source