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

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?

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.

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.

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.

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.

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?

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.

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.

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.

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 ;-)

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.

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.

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).

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".

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.

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.

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.

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.

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.

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 .

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.

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.

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.)

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.

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.

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.

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.

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.

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.)

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.

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.

• Le défaut de conception qui a presque anéanti un gratte-ciel de New York (slate.com)
• Centre Citigroup (wikipedia.com)