Pourquoi l'industrie informatique ne peut-elle pas livrer rapidement de grands projets 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 les grands projets sont achevés. Une fois que les travaux préliminaires (conception, spécifications, etc.) sont effectués sur papier, la réalisation elle-même d'énormes projets ne prend que quelques années ou parfois quelques mois .
Par exemple, Airbus A380"officiellement lancé le 19 décembre 2000" et "début mars 2005" , l'avion a déjà été testé. Il en va de même pour les énormes pétroliers, les gratte-ciel, etc.
En comparant cela avec les 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 personnes?
Des projets tels que l'Airbus A380 présentent à la fois:
Risques imprévus majeurs: bien que ce ne soit pas le premier avion construit, il repousse toujours les limites de la technologie et les choses qui fonctionnaient bien pour les petits avions de ligne pourraient ne pas fonctionner pour le plus gros en raison de contraintes physiques; de la même manière, de nouvelles technologies sont utilisées qui n'étaient pas encore utilisées, car par exemple elles n'étaient pas disponibles en 1969 lors de la fabrication du Boeing 747.
Risques liés aux ressources humaines et à la gestion en général: personnes qui quittent en milieu de projet, incapacité à joindre une personne parce qu'elle est en vacances, erreurs humaines ordinaires, etc.
Avec ces risques, les gens réalisent toujours des projets comme ces gros avions de ligne dans un très court laps de temps , et malgré les retards de livraison, ces projets réussissent toujours énormément et d'une grande qualité.
En ce qui concerne le développement de logiciels, les projets sont à peine aussi grands et compliqués qu'un avion de ligne (à la fois techniquement et en termes de gestion), et présentent des risques un peu moins imprévus du monde réel.
Pourtant, la plupart des projets informatiques sont lents et tardifs , et ajouter plus de développeurs au projet n'est pas une solution (passer d'une équipe de dix développeurs à deux mille permettra parfois de livrer le projet plus rapidement, parfois non, et parfois ne fera que nuire au projet et augmentera 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 du produit d'origine et empêcher l'avion de s'écraser).
Comment expliquer ces différences? Est-ce uniquement dû au fait que l'industrie du développement logiciel est trop jeune pour pouvoir gérer des milliers de personnes sur un seul projet afin de livrer très rapidement des produits à grande échelle, presque sans défaut?
Ed Yourdon's Death March aborde un certain nombre de ces questions de type méta.
En général, l'industrie du logiciel manque beaucoup des éléments suivants, ce qui gêne les grands projets.
Normalisation et ventilation des éléments de travail.
- Cela s'est certainement amélioré, mais les constructions de conception ne sont toujours pas là pour faire éclater un grand système. À certains égards, le logiciel ne peut même pas s'entendre sur ce qui est nécessaire pour un projet donné, et encore moins être capable de décomposer les choses en composants.
- L'aérospatiale, la construction de bâtiments, l'automobile, etc. ont tous des architectures très axées sur les composants avec des interfaces raisonnablement étroites pour permettre un développement entièrement parallèle. Le logiciel autorise toujours trop de saignement dans les zones correspondantes.
Un grand nombre de projets similaires réussis. L'A380 n'était pas le premier gros avion construit par Airbus . Il existe de nombreuses applications logicielles volumineuses, mais bon nombre d'entre elles ont souffert de façon dramatique sous certains aspects ou sous l'autre et ne pourraient pas être qualifiées de "réussies".
Un grand corps de concepteurs et de constructeurs qui ont travaillé sur un certain nombre de projets similaires et réussis. En lien avec la réussite du projet, le fait de ne pas avoir le talent humain qui a été là, cela 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 tout autre avion. Il a des ailes, des moteurs, des sièges, etc. Les grands projets logiciels se répètent rarement. Chaque noyau de système d'exploitation est considérablement différent. Regardez la disparité des systèmes de fichiers. Et d'ailleurs, combien d'OS vraiment uniques existe-t-il? Les gros deviennent des clones d'un élément de base à un moment donné. AIX , Solaris , HP-UX , ... annonce de retour à AT&T Système V . Windows a eu une quantité incroyable de glisser vers l'avant à chaque itération. Les variantes Linux retournent généralement au même noyau que Linus a commencé. J'en parle, car les variantes ont tendance à se propager plus rapidement que les systèmes d'exploitation propriétaires vraiment uniques.
Vraiment mauvaise estimation de projet. Étant donné que le facteur de répétabilité est si faible, il est difficile de prévoir sa taille et le temps nécessaire à la construction. Étant donné que les chefs de projet et la direction ne peuvent pas mettre la main sur le code et voir réellement ce qui est fait, des attentes irréalistes concernant les délais sont générées.
L'AQ/CQ n'est pas mis en avant aussi fortement qu'il pourrait ou devrait l'être pour les grands projets. Cela revient à avoir des interfaces plus lâches entre les composants et à ne pas avoir de spécifications rigides sur la façon dont les composants doivent fonctionner. Ce relâchement permet des conséquences inattendues et des bogues qui s'introduisent.
Qualifications constamment mesurables. Généralement, les gens parlent du nombre d'années qu'ils ont travaillé en langage X ou en programmation. Le temps passé est utilisé comme substitut au calibre ou à la qualité des compétences. Comme cela a été mentionné à plusieurs reprises auparavant, il est difficile d'interviewer et de trouver de bons talents en programmation. Une partie du problème est 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 importants par rapport à notre situation actuelle. Des forums comme celui-ci et d'autres ont vraiment aidé à promouvoir la conversation et la discussion des principes de conception. Il existe des organisations qui travaillent à normaliser les connaissances "de base" des ingénieurs logiciels. Il y a certainement place à amélioration, mais je pense que l'industrie a parcouru un long chemin dans un laps de temps raisonnablement court.
La réponse est étonnamment simple: ces "autres industries" do ont un taux d'échec élevé. Nous comparons simplement les mauvaises choses. Le logiciel d'écriture est souvent appelé "build", et nous le comparons donc aux phases de fabrication ou de construction dans d'autres industries. Mais si vous le regardez, ce n'est pas du tout de la construction: c'est design. Les conceptions logicielles sont écrites en code et la construction se fait 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, coûtent beaucoup plus cher ou ne sont tout simplement pas achevées. Semble familier?
Alors, que faisons-nous lorsque nous planifions un logiciel? Eh bien, nous concevons toujours, mais à un stade plus précoce.
Dans le logiciel, il n'y a pas de ligne de fabrication. La construction du composant final est (relativement) bon marché et la réplication de ce produit final est à la fois parfaite et efficace - vous copiez les artefacts de construction.
Pour signaler quelques chiffres:
- Modification des exigences après le début de la mise en œuvre; par exemple, lorsque le premier Airbus A380 a commencé à être créé en usine, je ne peux pas croire que si quelqu'un voulait 200 sièges de plus, ceux-ci y seraient mis; mais dans un grand projet logiciel, même après que les programmeurs ont commencé le développement, 5 autres types d'utilisateurs peuvent être ajoutés.
- Complexité - les grands projets logiciels sont extrêmement complexes; probablement les projets les plus complexes du genre humain conçus et développés;
- Pas assez de ressources sont dépensées en phase d'architecture et de conception;
- immaturité de terrain - le génie logiciel est une discipline relativement jeune par rapport aux autres sœurs du génie; cela a deux implications: a) Pas autant d'heuristiques et de bonnes pratiques; b) Pas autant de spécialistes très expérimentés;
- Manque de preuves mathématiques - dans la plupart des cas, les méthodes mathématiques formelles ne sont pas utilisées pour prouver qu'un logiciel fonctionne comme requis; à la place, le test est utilisé. Cela est vrai dans d'autres domaines du génie qui dépendent davantage des mathématiques; la raison en est la complexité;
- Rush - de nombreux managers ont des délais impossibles à atteindre; la qualité du code vient donc en deuxième position, en raison de la date limite.
Répondre strictement à la question - j'ai tendance à croire que d'autres ont des attentes très élevées (en particulier dans le délai de livraison) de la part des programmeurs et ne comprennent pas exactement à quel point la programmation de gros logiciels est difficile.
La prémisse de la question est un peu défectueuse. L'A380 et le Boeing 787 ont tous deux été livrés avec des années de retard.
Dans le cas de l'A380, une grande partie du retard a été causé par les unités françaises et allemandes d'Airbus utilisant versions différentes et légèrement incompatibles de CATIA logiciel de conception. Cela s'est manifesté de manière incompétente par des faisceaux de câbles qui ne convenaient pas tout à fait à l'avion.
Il n'y avait rien de mal avec CATIA, qui est le logiciel de conception d'avions le plus utilisé, mais quelqu'un a quelque part laissé tomber la configuration du logiciel.
Le Boeing 787 a également souffert de retards liés au logiciel, mais la plupart de ses problèmes étaient des problèmes de nouveaux avions plus 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 leurs conceptions d'ailes après que l'avion initial eut des problèmes structurels.
Les grands projets complexes sont difficiles pour les humains dans tous les domaines.
Mec gratte-ciel ici. Je ne sais pas si je peux répondre à votre question, mais je peux sûrement faire la lumière sur divers éléments du fil. Les bâtiments se produisent en effet très rapidement. Une contrainte majeure est l'environnement local (réglementations). Mais en général, il faut 3 à 10 ans pour un grand bâtiment du début à la fin.
Je pense que comparer un nouveau bâtiment avec un nouveau projet 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 de logiciels est beaucoup plus rapide. Nous ne construisons jamais à partir de zéro car ce sera une tâche à haut risque pour laquelle le client ne s'inscrira jamais. La plupart de la conception et du développement des bâtiments dérivent de projets éprouvés et achevés.
Par expérience personnelle, un seul projet sur dix est jamais construit. Le processus est axé sur le développement plutôt que sur la conception, de sorte que dès que quelque chose comme le prix de l'acier augmente, l'ensemble du projet est par la fenêtre ou conçu, car la conception est la composante bon marché du processus.
La conception prend un mois pour le concept au schéma, deux à six mois pour le développement de la conception, un autre six mois 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 éoliens, d'ingénieurs de services, de consultants en quantité et en coût, d'arpenteurs, ingénieurs en accessibilité et la liste continue ...
L'argument du virtuel contre le physique n'est pas très précis. Nous travaillons également principalement avec des outils virtuels, et en outre, 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 de la maquette et nous utilisons la simulation pour essayer de prédire ce qui pourrait arriver.
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. Nous avons non seulement des unités interdépendantes et de multiples niveaux d'abstractions et d'interfaces à plusieurs niveaux, mais les gens sont également très spécialisés dans les petites parties du processus qui rendent la communication très difficile.
Quant à l'argument de la conception par rapport au développement, je pense que les deux processus sont conçus par la conception. Cela semble académique Nice de les garder séparés, mais il n'est pas possible de concevoir si vous ne savez pas comment les choses fonctionnent. Vous augmentez simplement le risque d'échec.
Dans l'ensemble, mon estimation (potentiellement erronée) selon la question de l'OP est que la programmation est plus un art que l'ingénierie. Pourquoi les gens prendraient-ils du plaisir et même le feraient-ils 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 assembler des pièces existantes et travailler pour que les choses fonctionnent? Je ne sais pas si cela a un sens; Je ne suis pas un logiciel.
Un aspect qui me frappe dans 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 donc très explicite et il y a peu de tolérances. Il est difficile de se débrouiller mentalement, et certains s'en tirent en déversant la complexité à l'intérieur. Si rien d'autre ne peut y être pour quelque chose?
Alors combien de temps leur a fallu la conception? An? Deux? Dix ans? La conception est la partie la plus complexe de la construction de quelque chose, la construction elle-même est facile.
Basé sur 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. Il nécessite des personnes expérimentées et est impossible à planifier, car même de petites modifications des exigences peuvent entraîner d'énormes changements dans l'architecture globale du projet. Cette compréhension est la base de méthodologies agiles qui se concentrent sur l'amélioration de la qualité du code comme document de conception final et sur l'intégration des tests et du débogage dans le processus de conception, tout comme ils testent des modèles d'avion dans des souffleries.
La construction elle-même est gérée automatiquement par les compilateurs. Et grâce à cela, nous pouvons construire des produits entiers en quelques minutes.
La raison pour laquelle les projets logiciels sont terminés avec d'énormes retards et des coûts gonflés est que les gestionnaires pensent toujours qu'ils peuvent estimer, prévoir et planifier un tel processus de conception. Cela se retourne plus souvent qu'il n'est réellement valide. Ils pensent toujours qu'en liant les gens à un processus de construction rigide, ils peuvent en quelque sorte augmenter la qualité même si le résultat final est généralement opposé avec des coûts accrus et des délais manqués.
Imaginez, au milieu de la conception de l'Airbus A380, quelqu'un s'incline dans une réunion et dit: "Hé, pourrait-il le construire comme un triplan?" D'autres se sont joints pour dire: "Ouais, ouais. Un triplan. Plus d'ailes, c'est mieux." Les trois années suivantes sont passées à transformer le design de l'A380 en triplan. Lors d'une autre réunion, quelqu'un dit: "Un triplan? C'est vieux. Nous voulons un biplan. Retirez simplement une des ailes."
Ou imaginez, au milieu d'un projet de construction de pont, quelqu'un dit: "Hé, nous venons de conclure un accord avec une compagnie maritime. Ils ont besoin que le pont soit encore 40 pieds plus haut, parce que leurs navires sont beaucoup plus hauts. Réparez-le. Merci . "
Ce ne sont que quelques-unes des raisons pour lesquelles les projets logiciels, petits et grands, se soldent par un échec à un rythme alarmant.
En tant que personne ayant une formation en génie mécanique travaillant en informatique, je me suis souvent posé des questions sur les raisons du faible taux de réussite en informatique.
Comme d'autres dans ce fil, j'ai aussi 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 standardisé composants et modules.
D'autres industries, comme la construction de bâtiments ou la construction navale, ont également bien plus de "sentiers battus": la connaissance et l'expérience d'un prototype de solution particulier, qui - sous forme personnalisée - est réutilisé à maintes reprises. Vous êtes-vous déjà demandé pourquoi des bâtiments, des navires ou des avions de taille et de destination différentes se ressemblaient d'une manière ou d'une autre? (il y a bien sûr des exceptions à la règle ...)
En effet, ces prototypes sont bien étudié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 standardisation est rarement le cas: les (grands) projets ont tendance à réinventer les composants, à faire de la recherche et de la livraison en même temps et avec les mêmes personnes!
Ceux-ci conduisent inévitablement à des produits uniques, qui sont coûteux à développer et à entretenir, sont sujets aux erreurs et échouent de manière imprévisible dans des conditions incertaines. Et à cause de cela, bien sûr, ces produits sont beaucoup plus rapides, obsolètes, écrits et remplacés à des coûts tout aussi importants 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 efficaces.
Cela dit, il existe cependant des facteurs qui rendent l'informatique vraiment unique. Contrairement à ces autres industries mentionnées, l'informatique est vraiment omniprésente: elle est utilisée dans chaque aspect de notre vie moderne. C'est donc un petit miracle que l'informatique ait réalisé autant de progrès et soit capable de fournir les résultats qu'elle fait.
Je crains d'être en désaccord avec votre déclaration.
Airbus et Boeing sont deux exemples d'entreprises qui construisent des avions. Combien y a-t-il d'entreprises qui fabriquent des avions? Très peu, si vous le comparez au nombre d'entreprises qui construisent des logiciels.
Il est aussi facile de visser un projet d'avion que de visser un projet logiciel. Si seule la barrière à l'entrée était si basse dans l'industrie de la construction aéronautique que dans l'industrie du logiciel, vous verrez certainement de nombreux projets d'aéronefs échoués.
Regardez les voitures; Il y a des fabricants de haute qualité qui construisent des automobiles très durables et très avancées (pensez Land Rover, Mercedes) et il y en a qui construisent des voitures qui ne dureront pas un an sans avoir à les réparer (pensez Kia ou Cherry). Ceci est un exemple parfait d'une industrie avec une barrière d'entrée légèrement inférieure, si vous commencez à avoir des joueurs plus faibles.
Le logiciel n'est pas différent. Vous avez beaucoup de produits buggy, en revanche, Windows, Office, Linux, Chrome ou Google Search sont des projets de très haute qualité qui ont été livrés à temps et avaient un niveau de qualité similaire à celui d'un avion.
L'autre point 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 plusieurs kilomètres et le faire régulièrement, comme changer l'huile, changer les pneus.
Le logiciel en a également besoin. Si seulement les gens passaient autant de temps sur l'état et la qualité des logiciels de diagnostic, de prévention ou d'audit que sur les produits mécaniques/physiques, je m'attendrais à beaucoup moins de déclarations comme celles-ci. Lisez-vous les journaux de votre application à chaque fois avant de la lancer? Eh bien .. si c'était un avion, il faudrait 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, tout changement, même minime, peut entraîner une panne drastique.
Je me suis souvent demandé la même chose. C'est certainement ça sent (occasionnellement) comme si nous étions un groupe d'amateurs qui n'ont aucune 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, devons être responsables de ce que nous créons.
Je pense que nous sommes dans une entreprise où les erreurs sont bon marché . Le logiciel de correction est bon marché par rapport à la reconstruction d'un gratte-ciel ou au rappel de chaque téléphone portable vendu.
Cela a créé une culture où les bogues font partie de la vie quotidienne . Ils sont acceptés avec un haussement d'épaules. Bien que certains bogues soient probablement inévitables, devraient-ils dominer notre travail quotidien ? Je comprends parfaitement les gestionnaires qui ne pensent pas que l'assurance qualité en vaut la peine, précisément parce qu'ils s'attendent à des bogues de toute façon. Je ne comprends pas les programmeurs qui ne font aucun effort pour produire du code sans erreur, car la correction des bogues est ennuyeuse.
Essentiellement, je crois que c'est un problème de culture et j'espère qu'il va changer.
Les normes et pratiques d'ingénierie sont très différentes en informatique (en tant qu'industrie indépendante) qu'en aérospatiale . Cela est peut-être plus facile à comprendre en considérant la réaction des professionnels de l'informatique lorsqu'ils rencontrent des documents de normes pour l'informatique dans l'aérospatiale . Par exemple, les Joint Strike Fighter C++ Standards qui ont fait leur chemin sur Internet ces derniers temps.
Beaucoup expriment leur perplexité ou leur démission nostalgique (souhaitons que nous puissions faire de cette façon); et beaucoup répondent avec ridicule, affirmant qu'il n'y a aucun moyen pratique de livrer des produits de consommation de cette manière. Cela peut même être vrai, compte tenu des attentes, non pas des consommateurs, mais de la direction. Il y a beaucoup de méfiance pour les codeurs qui ne font que coder et coder 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 être complices d'un monde imaginaire de choses vraiment simples assemblées de manière créative (par opposition à un monde de choses difficiles qui se fait vraiment bien).
Quelques trucs de moi:
1- Normes et pièces: Ce sont des avions fabricants, pas des développeurs. Je ne suis pas tout à fait sûr, mais je suppose que beaucoup de pièces sont externalisées. Ils ne construisent pas leurs propres appareils électroniques, ils obtiennent des sièges d'une entreprise, les moteurs sont probablement développés ailleurs, etc.
Les projets logiciels, en revanche, partent presque toujours de zéro avec seulement quelques petits cadres/assistants en place.
2- Le temps de frapper le marché: le temps n'est pas un problème critique pour les avions. Je parie que la conception de l'Airbus a été finalisée des années avant sa fin, et ils ont choisi de négliger toutes les percées majeures qui pourraient se produire à cette époque. (Idem pour les constructeurs automobiles, par exemple, la technologie de pointe qu'ils développent actuellement arrivera dans les rues dans 5 à 10 ans.)
Pour les logiciels, vous devez être très agile, si je démarre un énorme projet maintenant et que je prends trois ans pour le développer sans aucun changement, les chances sont assez élevées que je me fie à une technologie qui n'est plus disponible ou que mon produit est complètement obsolète. À son tour, cela pose beaucoup de problèmes.
3- Cycle de sortie et versions. - Un avion doit être complètement terminé lorsqu'il est "sorti". Il n'y a pas de versions bêta stables, de versions nocturnes ou similaires. De plus, une fois terminé, il ne peut être modifié que de manière modeste. Vous ne pouvez pas ajouter un niveau supplémentaire avec 100 sièges à un boeing existant, ce n'est tout simplement pas possible.
D'un autre côté, les logiciels ont des changements incrémentiels qui ne sont souvent que des "builds 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 contient 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 eu des milliers d'années pour développer nos méthodes et techniques pour la mise en œuvre de projets physiques. La "construction" de logiciels, qui nécessite un ensemble de compétences entièrement nouveau et différent, 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" dans votre esprit des choses qui n'ont aucune réalité physique. Cela vous oblige à analyser et à résumer de nombreuses informations avant même de savoir à quoi votre produit est censé ressembler et les étapes qu'il faudra 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 panne ou d'un bug logiciel que lors d'une ingénierie physique. Si une poutre se boucle, vous voyez où elle se bloque et vous voyez les supports qui la maintiennent et qui échouent, 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 le firmware partout, remplacez-le mentalement par un logiciel.
Par rapport à quoi?
Le firmware 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 chasse haute performance est un équilibre délicat de besoins contradictoires: gamme de carburant vs performances. Vitesse vs poids. Il semble qu'à la fin des années 70, les combattants étaient à peu près aussi lourds que jamais. Les entrepreneurs, toujours à la recherche de profits plus importants, ont cherché en vain quelque chose qu'ils pouvaient ajouter qui coûtait cher, mais qui ne pesait rien.
La réponse: le firmware. Coût infini, masse nulle. L'avionique représente désormais plus de la moitié du coût d'un chasseur. C'est un morceau de changement quand on considère le dernier chasseur américain, le F-22, coûte un tiers frais d'un milliard de dollars. Augustine glousse presque de joie quand il raconte cette histoire.
Mais pourquoi les logiciels sont-ils si chers? Tom DeMarco a déjà répondu à cette question par ces trois mots: par rapport à quoi? Il a poursuivi en discutant des analyses de rentabilisation relativement ennuyeuses, mais cette réponse a résonné dans mon esprit pendant 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 coûte 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, levé sans vergogne de Wikipédia et non vérifié pour l'exactitude:
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]); }Il ne s'agit que de 110 personnages non spatiaux, peut-être lancés dans une heure ou deux. Supposons que nous ne disposions pas de logiciel et que nous devions implémenter un tri à l'aide d'une autre stratégie. Combien cela coûterait-il?
Un ingénieur en mécanique peut se vanter que sa profession a construit des trieurs 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, plutôt moins que notre extrait de code pourrait gérer même sur un Z80 4 MHz. Le modèle 82, bien sûr, ne triait qu'une colonne d'une carte à la fois; trier complètement un jeu de cartes pourrait prendre des dizaines de passes.
Combien de temps at-il fallu pour concevoir et construire cette bête? Des années, sans aucun doute. Et sa fonctionnalité est dérisoire par rapport à notre code qui est tellement plus rapide et qui peut gérer de gigantesques ensembles de données. Mais c'était en 1949. Combien de temps faudrait-il pour créer une sorte de bulle à partir de composants électroniques - sans FPGA et VHDL, ni CPU?
En une heure, j'ai réussi un schéma de principe approximatif, un au-dessus du niveau de la puce (les blocs ont des noms comme "additionneur", "verrouillage 16 bits" et autres). Mais la logique de séquençage est clairement assez compliquée, donc je viens de lancer un PLD, en supposant qu'à un moment donné, il ne serait pas trop difficile d'écrire les équations appropriées. Et, oui, peut-être que cela enfreint la règle de la logique non programmable, mais concevoir et déboguer toute cette logique en utilisant des portes dans un laps de temps raisonnable est aussi peu probable que le gaz de seau.
En supposant des mots et des adresses de 16 bits, le circuit aura besoin d'une douzaine de verrous, additionneurs, etc., de 16 bits. Plus de mémoire. Et je n'ai aucune idée de la façon dont les données non triées arrivent dans le 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 juste par l'acte d'écrire le prototype de fonction.
La traduction du schéma fonctionnel en schéma peut prendre un jour. Ensuite, il y a le temps de concevoir et de produire un PCB, de commander et de charger des pièces (et de modifier la conception pour faire face aux problèmes de fin de vie inattendus mais inévitables), puis bien sûr de faire fonctionner le circuit. Nous pourrions parler de semaines d'efforts et de beaucoup d'argent pour la carte, les pièces et l'équipement de test approprié.
Tout cela pour remplacer 7 petites lignes de code. Peu de vrais programmes intégrés sont inférieurs à 10 000; beaucoup dépassent le million. Quelle quantité de matériel et quelle ingénierie faudrait-il pour remplacer un vrai programme informatique de très grande taille?
Considérez un vrai programme comme une feuille de calcul. Combien de circuits faudrait-il pour en fabriquer un sans processeur? Cela pourrait être la taille d'une ville.
Le firmware 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 patron vous demande avec irritation pourquoi le logiciel prend autant de temps, vous savez quoi dire. Par rapport à quoi?
Donc là! Le logiciel/micrologiciel a une complexité inégalée.
Les grands projets se produisent souvent dans les grandes organisations. Si vous n'avez jamais travaillé dans une grande organisation, il y a une chose qui garantit la performance et la productivité: la bureaucratie.
Étonnamment, de nombreuses personnes ne savent pas ce qu'est la bureaucratie (elle est souvent confondue avec la politique), ni même si/quand elles ont un problème de bureaucratie.
Nous avons récemment conclu un projet pour implémenter l'authentification par carte à puce. Il était initialement estimé à trois mois. Cela a pris 15 mois. Il n'y avait pas de coût, de budget, de portée ou de raisons techniques pour le retard. La portée était en fait assez étroite - uniquement pour les comptes avec des privilèges élevés (comptes d'administrateur), environ 1 200 comptes au total.
Un autre facteur important est vos partenaires commerciaux. Cela inclurait les fournisseurs. Si vos partenaires ont un problème qui introduit un retard dans votre projet, il n'y a pas beaucoup d'options qui permettront de résoudre le problème de retard. Ils ne travaillent pas directement pour vous, et vous ne pourrez peut-être pas renvoyer cette personne à un partenaire qui pourrait en être la cause. Le partenaire peut être licencié, ou faire l'objet de sanctions financières ou de dissuasion, mais cela ne change pas le fait que le projet a subi un retard. C'est précisément ce qui s'est produit avec Boeing lorsqu'ils ont entrepris une stratégie d'approvisionnement gigantesque avec le Boeing 787 Dreamliner .
J'ai une version plus courte pour vous:
Tout ce qui est facile à faire ou rationalisé, nous écrivons un programme pour le faire à notre place.
Et puis combattez avec le méta-processus à la place.
Ce n'est pas vraiment vrai en soi, mais chaque jour, des milliers de blogs sont créés, 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 - certains d'entre eux sont mentionnés ici - mais je voulais ajouter ce point à la discussion.
Le génie logiciel et la gestion sont fondamentalement différents de beaucoup d'autres domaines d'ingénierie. Les 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 un coût marginal essentiellement nul; tout le coût se trouve dans l'élaboration de la première copie.
En raison de la relative jeunesse de l'ingénierie et de la gestion logicielles en tant que discipline, il existe des informations erronées et des faussetés qui sont toujours considérées comme des faits ( voir cette référence ), ce qui entrave le développement logiciel et l'ingénierie dans son ensemble.
Tous les développeurs ne sont pas créés également. 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 de déclarations logiques supplémentaires peuvent augmenter le risque. Ces risques peuvent entraîner de mauvais comportements 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 s'enfuient.
Manque de responsabilité ... Les gens sont poursuivis en justice 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 construction des cathédrales prenait jusqu'à 100 ans.
Certains avions Airbus ont besoin d'un million de lignes de code pour fonctionner.
Plus vous améliorez quelque chose, plus vous obtenez d'amélioration, alors donnez à l'industrie du logiciel quelques siècles d'erreur d'essai pour aller mieux, et nous verrons combien il faut pour développer un énorme projet solide sans bogues ou des défauts.
La plupart des grands projets ont un haut degré de séparabilité des sous-projets, où 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 tourne mal dans un sous-projet, tout l'effort n'est pas remis en question; il vous suffit de rechercher d'autres moyens de terminer le sous-projet (par exemple, utiliser un moteur différent).
Ceci est possible mais difficile, à la fois dans la pratique et dans le cadre de la nature humaine, dans les projets logiciels.
En partie, d'autres industries ont appris à la dure que ce type de séparabilité est une bonne chose. Par exemple, si vous allez 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 ne fonctionnent qu'avec des ailes de conception particulière, puis si vous essayez de passer à Pratt et Whitney, vous devez repenser l'intégralité de votre aile de fond en comble (ce qui, à son tour, nécessite une refonte complète du fuselage, ce qui vous oblige à acheter des sièges différents, ce qui vous oblige à acheter un système de divertissement en vol différent, lequel...). Il peut y avoir quelques liens - vous ne pouvez pas simplement changer de moteur sans souci - mais les grands projets fonctionnent généralement mieux lorsque de telles choses sont minimisées.
Je postule que les grands projets logiciels conçus comme un cluster de petits projets logiciels avec des interfaces propres entre eux pas échouent particulièrement souvent, tant que le gros 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. Autrement dit, le implémentation est très différent. Tout en construisant par exemple un énorme camion-citerne, vous effectuez de nombreuses tâches relativement simples (pas faciles!), Telles que souder des pièces ensemble par un robot ou à la main, resserrer tous les écrous et boulons, peindre, faire la décoration en portant dans tous l'équipement et le mobilier et autres. Tout cela est très simple des trucs à faire, 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 les informations d'identification utilisateur stockant une partie du produit? Quelles bibliothèques et quels outils pouvez-vous utiliser? Avec quelles bibliothèques et outils connaissez-vous? Comment allez-vous exactement écrire la fonction de hachage + salage et comment vous assurez-vous qu'elle est sécurisée? Vous pouvez le faire de tant de façons qu'il est impossible de définir une pratique réelle modèles de conception pour ce genre de choses. Oui, lesdits modèles de conception existent à plus petite échelle en tant que "meilleures pratiques", mais chaque système logiciel est très différent des autres, et le les progrès et les changements sur le terrain à un rythme si rapide qu'il est pratiquement impossible de suivre.
Lors de la construction d'une maison, vous ne rencontrez pas vraiment de problèmes tels que vous vous rendez compte que les principaux murs de soutien semblent insuffisants et doivent être remplacés, ce qui vous oblige à démolir les progrès jusqu'à présent et à partir de la base en refaisant les murs de soutien . Vous abordez ces problèmes lors de la phase conception, car il est relativement simple de prévoir le type de murs de soutien dont votre bâtiment a besoin.
Ce n'est pas le cas avec les logiciels. Vous ne pouvez pas vraiment concevoir l'ensemble du produit comme une seule entité, puis l'implémenter. Le processus de conception logicielle est généralement itératif, et les objectifs et les exigences changent au fur et à mesure que le produit est mis en œuvre et testé. Le développement logiciel dans son ensemble est un processus itératif dans lequel les choses changent généralement au moment le moins attendu, et de nombreuses fois de tels changements imposent des défis qui nécessitent plus de travail, plus de complexité et malheureusement et finalement plus d'argent, de temps et de travail acharné pour avoir raison.
Donc, en substance, la raison pour laquelle il est difficile de livrer de grands projets et d'estimer les délais et les feuilles de route du projet est que le développement de logiciels et en particulier la conception de travail sont très très complexes des champs. La complexité est le problème racine.
Airbus A38 n'a pas été un projet réussi comme vous l'avez mentionné. Il se trouve que je travaille dans une entreprise de CAO/FAO, et on m'a dit que (nous avions aussi le projet Airbus) a été retardé de quelques années, car ils utilisaient différentes versions de logiciels dans différentes entreprises. Autrement dit, différentes parties étaient conçues dans différentes parties du monde. Et lors de l'intégration, ils ont appris que tout le design ne pouvait pas être intégré, ils doivent donc le repenser en une seule version. Je ne pense donc pas que cela ait réussi. S'il était venu 2-3 ans auparavant, cela aurait changé la donne pour Airbus.
En ce qui concerne également les logiciels robustes, vous regardez n'importe quel avion, voiture (ABS, EPS, climatisation, etc.) ou navette spatiale, ils ont plus de 50% de logiciels qui les exécutent et croyez-moi, ils sont très robustes. C'est juste que nous sommes plus proches des logiciels, et il y a beaucoup plus de logiciels, donc nous voyons plus d'erreurs.
Visitez: http://www.globalprojectstrategy.com/lessons/case.php?id=2 et découvrez le succès de l'Airbus A380.
Ingénieur logiciel ici, avec une formation d'ingénieur, et une femme qui travaille dans la construction. Nous avons eu de longues discussions (et arguments) sur les différences de nos emplois.
Le génie logiciel consiste à concevoir de nouvelles choses . Presque tout ce qui est basique a été fait quelque part dans une bibliothèque open source. Dans presque tous les emplois où un ingénieur 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 choses qui seraient autrement dans une "bibliothèque" de logiciels sont déjà entièrement conçues. Vous voulez construire une tour? Copiez et collez simplement 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 pourrait être utilisé pour programmer quelque chose de plus visible, comme un réseau social .
Il n'y a pas beaucoup de nouveaux designs en ingénierie; un ingénieur extrêmement qualifié est quelqu'un qui peut transformer une conception existante en quelque chose de nouveau ou l'améliorer. Mais presque tous les programmeurs sont censés modifier les conceptions, les pirater ou créer quelque chose de nouveau.
Revoyez à quel point les normes ont complètement changé, de Assembly à C en C++ à Java, JavaScript, C #, PHP, etc. Il n'y a pas beaucoup de code qui peut être recyclé il y a 10 ou 20 ans. C'est très différent de dire ... l'industrie automobile ou aéronautique quand vous pouvez continuer à améliorer les conceptions depuis des décennies.
La gestion de projet est notoirement difficile dans les logiciels . Les estimations de temps sont mieux faites par les gens qui font le travail, mais quand ils sont occupés à faire des estimations, ils 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 va pas de l'avant. En revanche, si vous vouliez construire une voiture, vous pouvez simplement embaucher différentes personnes pour assembler les pneus, le châssis, la batterie, le moteur, etc. Les frameworks orientés objet et existants rendent cela possible, mais cela peut ne pas être pratique lorsque vous concevez tout à partir de zéro.
Des échecs peuvent être autorisés dans le logiciel . Les tests peuvent être coûteux. Dans le logiciel, il est très tentant de sauter tous ces tests, alors que vous pouvez simplement corriger un plantage. Dans la plupart des formes d'ingénierie, un "crash" peut être fatal.
Vous avez des méthodes de programmation qui utilisent des tests approfondis, comme programmation extrême (qui était en fait utilisé sur les mégaprojets logiciels). Mais avec des délais serrés (qui peuvent être rendus plus serrés exprès), il est tentant de sauter toute cette programmation et de se lancer avec des bugs. Le style Joel Spolsky de "toujours corriger tous les bugs" fera gagner plus de temps à long terme, mais les indisciplinés ignoreront cela et échoueront.
Les petits projets sont meilleurs . Ma femme m'a demandé un jour de trouver un emploi dans une grande entreprise. Cela a abouti à un argument selon lequel les grandes entreprises sont de mauvaises entreprises ... pour elle, une grande entreprise avait beaucoup de ressources, d'expérience, de gestion de projet fonctionnelle et de bonnes procédures. Pour moi, une grande entreprise est un dinosaure, où la plupart de votre temps est consacré à la correction du code, au test et à la documentation.
J'ai vu des projets informatiques d'un million de dollars réalisés par moins de 10 personnes. Plus de gens auraient ralenti le projet et ajouté une bureaucratie inutile. WhatsApp est un exemple de "petit" projet qui vaut des milliards de dollars. Ce n'est pas que les grands projets ne sont pas possibles, mais vous n'avez tout simplement pas besoin de milliers de personnes pour produire des milliards de dollars de logiciels.
La définition de "grand projet" est biaisée.
Un grand projet, techniquement, peut être livré à temps, et parfaitement, étant donné 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 serais en désaccord avec vous. Les ordinateurs sont extrêmement compliqués. L'installation et la configuration d'utilisateurs sur un système d'exploitation peuvent parfois être difficiles, et vous n'avez même pas écrit le système d'exploitation ou construit le matériel.
Les projets dont vous parlez sont d'énormes projets , semblables à l'exploration spatiale. Comment savez-vous combien de temps il faut pour développer le voyage inter-galactique? Sur quel modèle la basons-nous? Vous avez les connus connus, les inconnus connus, les inconnus connus et enfin, les inconnus inconnus, qui se trouvent 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 sera couronnée de succès (ou judicieuse) 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 pour construire une base lunaire, et déciderait qu'un Starbucks "compléterait" vraiment l'expérience pour les visiteurs. Je ne pense pas que le problème soit l'industrie du logiciel, mais les attentes placées sur .
Bien que ce ne soit pas la seule chose qui pourrait être mentionné, je pense qu'une chose fondamentale mérite d'être soulignée. La plupart des produits sont destinés à s'adapter au comportement existant. Même un produit qui constitue une percé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/quoi que ce soit pour le faire. Oui, il y a souvent certains effets secondaires sur le comportement existant également (par exemple, obtenir du carburant pour la voiture au lieu 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 modifient pas le comportement des utilisateurs (par exemple, leur permettent de faire leur travail beaucoup plus facilement) sont fondamentalement garantis comme un échec complet dès le premier jour. Pire encore, les grands projets logiciels ne se contentent pas impliquer le comportement des utilisateurs à un niveau individuel, mais le comportement de grands groupes - souvent l'ensemble de l'organisation.
En bref, la conception du logiciel lui-même est souvent la partie la plus simple du travail. La partie difficile est de repenser les emplois des gens pour eux. C'est difficile au départ; le faire d'une manière qui non seulement fonctionnera, mais sera également accepté est encore plus difficile.
Une raison qui n'a pas vraiment été abordée dans les autres questions est que le domaine du logiciel 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 des logiciels est un cycle de rétroaction positive car des logiciels (langages de programmation, outils de construction, IDE) sont utilisés pour construire des logiciels. C'est l'exemple le plus évident de la loi de Ray Kurzweil d'accélération des retours, entraînant une progression à une vitesse exponentielle. Une fois que vous avez maîtrisé un framework, un langage de programmation, un protocole de communication, c'est 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, remplacerions la technologie du moteur pour chaque nouveau modèle par quelque chose qui vient d'être 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 se double d'un cinéma entièrement immersif, d'une arène de paintball et d'une boîte de nuit avec une pièce sombre une fois votre voyage de travail terminé. La même chose! (La société qui a construit des avions qui vous ont fait passer de A à B de manière fiable s'est mise un an après celle avec le cinéma , paintball et boîte de nuit sont sortis.)