Que peuvent apprendre les programmeurs de l'industrie de la construction? [fermé]

En discutant avec des collègues des principes de conception et de développement de logiciels, j'ai remarqué que l'une des sources d'analogies les plus courantes est l'industrie de la construction. Nous construisons des logiciels et nous considérons la conception et la structure comme l' architecture .

L'une des meilleures façons d'apprendre (ou d'enseigner) consiste à analyser les analogies - quelles autres analogies peuvent être tirées de la construction? (qu'il soit déjà couramment utilisé dans les logiciels ou non).

Veuillez fournir une description, ou votre expérience personnelle, concernant la façon dont le concept de programmation est similaire au concept de construction.

^{[Crédit aux concepts de programmation empruntés aux arts et aux sciences humaines pour l'idée]}

C'est de là que viennent les modèles de conception.

La personne qui aurait présenté le concept au monde était Christopher Alexander dans son livre "A Pattern Language: Towns, Buildings, Construction" en 1977 . De là, le Gang of Four (GoF) l'a ramassé , et le reste appartient à l'histoire.

Même aujourd'hui, pendant les conférences et dans le développement de logiciels et les livres d'architecture, les analogies entre le monde de la construction et le monde du développement de logiciels continuent de prévaloir.

Quelques analogies et références auxquelles je peux penser ou me rappeler:

• Par exemple, en changeant les exigences pendant la construction d'un bâtiment, il deviendrait peut-être plus évident pour le client à quel point c'est absurde, par exemple: "OH, et je veux un garage au lieu de la cuisine que vous venez de terminer".
• Aides temporaires telles que les échafaudages (ce qui signifie dans le monde de la construction | développement de logiciels )
• Les clients ne peuvent pas continuer à ajouter des fonctionnalités sans que cela leur coûte, beaucoup de fois ils veulent que les choses soient faites gratuitement, et parfois nous sommes assez stupides pour accepter; cela ne pouvait tout simplement pas se produire dans le monde de la construction (voir le fluage des exigences ).
• Les rôles dans le développement logiciel: l'architecte est au cœur de la conception de la solution; consultant et entrepreneur peuvent être des termes interchangeables; les travailleurs sont les programmeurs.
• Le client ne peut pas fournir d'exigences précises dans les deux cas.
• Les budgets et les estimations de temps sont souvent erronés.
• Le produit ne peut pas être vraiment vu dans sa vraie forme jusqu'à la fin .
• Un bâtiment peut avoir des défauts de construction après sa construction, de la même manière que le logiciel a des bogues .
• Si le produit est mal fait, il est parfois préférable de le démolir et de recommencer que de le réparer.
• Ne connaissant pas les résultats réels et réels d'un travail de mauvaise qualité, le client souhaite la solution la moins chère .
• Open Source . Je regardais juste cette conférence de Doc Searls intitulée " Pourquoi toutes les entreprises seront basées sur l'open source " où il raconte comment la communauté de la construction partage les techniques et les connaissances générales au lieu de les breveter un peu comme la communauté open source, même lorsque certaines choses dans les bâtiments contiennent des produits propriétaires intégrés.
• Les projets s'avèrent meilleurs pour tout le monde si le client est activement impliqué .

(Si plus me vient à l'esprit, je les ajouterai.)

Il y en a qui ne pensent pas que l'analogie générale est correcte, une lecture recommandée pour cela est L'analogie de la construction logicielle est brisée . En outre, il y a une question à ce sujet sur SO intitulée Quel est le problème avec l'analogie entre le logiciel et la construction de bâtiments? .

Nous avons pris beaucoup de mots et d'idées de l'industrie de la construction tout au long de l'histoire du développement de logiciels, et en fait, nous en avons probablement pris beaucoup, et je ne pense pas qu'il reste quelque chose à prendre.

Nous avons pris tout le processus consistant à faire établir des spécifications par les clients, puis à planifier les architectes, puis à concevoir les ingénieurs et enfin à coder les singes à mettre en œuvre dans l'industrie de la construction, et cela s'est avéré totalement erroné.

En effet, lorsque vous construisez une maison, si votre fondation est mauvaise, vous êtes effed. Sérieusement effed. Pour soulever un bâtiment et le remplacer, ses fondations coûtent plus cher que de démanteler le tout et de recommencer. Mais dans le logiciel, c'est tout à fait possible. J'ai refait un logiciel client en une solution client-serveur sans que l'utilisateur ne remarque quoi que ce soit, sauf que j'ai déplacé le modem dans la salle des serveurs. C'est comme remplacer la fondation en béton par un bateau pendant que les habitants dormaient.

Le logiciel n'est pas comme la construction. Et c'est pourquoi toute l'industrie du logiciel s'est allumée à une époque au début des années 2000 et tout le processus «en cascade» de l'exécution des projets a été remplacé par des processus agiles en quelques années seulement.

Quant aux mots, beaucoup est tiré de la construction, à tort et à raison.

Le cadre est le plus évident pas encore pris. Et il y a des tuyaux .

J'ai utilisé cette analogie ... beaucoup de projets logiciels commencent parce que la personne qui a besoin d'un logiciel connaît l'équivalent d'un "bricoleur", et ils embauchent cette personne pour leur construire l'équivalent logiciel d'un abri de jardin. C'est une petite application utile qui fait très bien son travail.

Le client retourne ensuite chez le bricoleur, satisfait de son travail, et lui demande de changer de logiciel pour faire encore une chose. Souvent, cette nouvelle fonctionnalité n'a pas grand-chose à voir avec la demande d'origine, c'est donc presque comme s'ils vous demandaient de construire une autre pièce à l'arrière de l'abri de jardin avec une entrée séparée.

Ensuite, ils veulent mettre une lumière à l'intérieur du hangar, donc ils ont le bricoleur en arrière, et il exécute un seul circuit à partir du panneau principal de la maison, installe un interrupteur d'éclairage à chaîne à tirer au plafond de chaque pièce et les connecte au circuit .

Le client décide alors qu'il veut faire fonctionner des outils électriques, mais il continue de faire sauter le disjoncteur, alors il rappelle la personne et il doit en fait arracher le seul circuit qu'il a dirigé vers le panneau principal, et installer un conducteur plus gros et un sous-panneau dans la remise. Il a dû passer deux fois le fil et payer deux permis d'électricité, etc. C'est inefficace.

Le client demande alors quelque chose d'absurde: pouvez-vous transformer mon abri de jardin en garage? Je ne veux pas que tu refasses tout ce que tu as fait ... Je veux juste que tu l'agrandisses pour que je puisse y garer ma voiture. Ensuite, dans de nombreux cas, le bricoleur pense que "le client a toujours raison" et procède à des ajouts sur 3 côtés du hangar pour l'agrandir, fait tomber le mur entre les cloisons, etc. Bien sûr, les extrémités du toit jusqu'à s'affaisser parce qu'il n'est pas construit correctement, etc.

Le client n'est donc plus si impressionné, mais il en veut toujours plus. Ils demandent au bricoleur encore et encore d'ajouter simplement une pièce de plus, ou de changer cette pièce existante pour le faire, etc. Vous vous retrouvez avec quelque chose qui ressemble à The Burrow et qui est à peu près aussi solide sur le plan architectural.

Maintenant, la plupart des gens ne sont pas assez stupides pour essayer cela dans le monde de la construction, mais cela arrive tout le temps dans le monde du logiciel, car les gens ne font pas ces connexions:

1. Une personne qualifiée pour construire un abri de jardin vraiment agréable n'est pas nécessairement qualifiée pour construire une maison.

2. Si vous saviez à l'avance que vous alliez construire une maison par étapes, mais que cela ne commencerait que comme un abri de jardin, vous feriez les choses différemment et l'abri de jardin coûterait beaucoup plus cher (vous verseriez un pad très épais, assurez-vous d'avoir un conducteur suffisamment gros pour la pleine charge d'une maison finie, etc.).

3. Dans de nombreux cas, la mise à niveau d'une étape à une autre implique l'annulation d'une grande partie du travail effectué précédemment, ce qui le rend plus cher qu'il n'y paraît.

4. Dans le monde de la construction, nous pouvons donner au client une bonne idée de ce à quoi le résultat ressemblera pendant la phase de conception, mais nous n'avons pas cette capacité dans le monde du logiciel. Si vous en êtes arrivé à ce point, vous avez essentiellement écrit une partie importante du logiciel.

Le Manifeste Agile est le résultat de la reconnaissance que l'analogie logiciel / construction est rompue. Des choses comme les tests unitaires automatisés et les cycles de publication itératifs n'ont pas de parallèle dans la construction. Ces choses profitent du coût presque nul de passer de la conception au prototype (nous l'appelons compilation ou construction).

Les termes Terminer le travail et Trim viennent à l'esprit.

L'idée qu'il est acceptable de différer certains choix esthétiques lorsque les principales décisions structurelles sont terminées.

Un vieil adage: Mesurez deux fois et coupez une fois.

Edit: Il y a une section dans le manifeste liste de contrôle par Atul Gawande, qui parle de la gestion des grands travaux de construction. Lorsqu'ils arrivent à un point vraiment compliqué, ils ont une réunion avec les experts impliqués pour revoir le problème et voir si quelque chose s'est produit pendant le projet que tout le monde devrait savoir. Nous ne pouvons probablement pas les planifier aussi longtemps à l'avance.

Des limitations existent à la fois dans la construction et la programmation .

Si vous, en tant que client, ne pouvez pas faire des demandes aussi ridicules que d'agrandir un bâtiment d'hôtel fini pendant un week-end et de mettre un aéroport dans le sous-sol et une piste sur son penthouse, pourquoi ne pouvez-vous pas accepter que tout ajustement avec le fini logiciels sont possibles? Ce n'est pas une boule magique de 0 et de 1, c'est une structure de construction complexe, bien qu'immatérielle mais avec ses limites aussi.

J'ai travaillé dans la construction par le biais de l'école et il y a des endroits où ce n'est même pas des analogies, le même concept s'applique. Mais souvent, la tentation de la comparaison va beaucoup trop loin.

Quand je travaillais sur une estimation pour un emploi, je savais qu'il y avait des moyennes assez fermes sur le temps qu'il faudrait pour faire quelque chose. Pour fabriquer des vitrines de magasin par exemple, nous avons simplement compté le nombre de joints dans les cadres à partir des plans et avions une assez bonne idée du temps que cela prendrait. Tout comme la programmation, nous devions tenir compte des variables dans le calendrier, mais cela pourrait vous aspirer la vie. Par exemple: demander à une équipe de plomberie de se rendre compte que le parking est pavé et qu'elle ne peut pas entrer dans le bâtiment à cause de l'asphalte chaud sur le chemin est assez cher.

Cependant, la construction a des milliers d'années d'expérience sur lesquelles s'appuyer. Les règles fondamentales du métier sont dictées par les mêmes lois de la physique qu'elles ont toujours été. Les calculs de charge de vent et de charge morte sont les mêmes qu'ils étaient lorsqu'ils étaient effectués avec des règles de glissement. Des améliorations ont été apportées aux outils et aux techniques, mais à un rythme glacial par rapport à ce que nous vivons.

D'un autre côté, nous découvrons toujours que bon nombre de nos modèles et pratiques ont besoin d'être améliorés. Singleton était une bonne idée, maintenant la plupart des gens qui y pensent préfèrent les modèles IoC / DI.

Là où nous manquons également, c'est de licences et de certifications significatives. Dans de nombreux domaines, même pour être un réparateur et encore moins un installateur, un plombier doit être agréé ou travailler sous la supervision de quelqu'un qui l'est. Pour obtenir cette licence, il faut un certain temps de travail sur le terrain. Je ne plaide pas pour ou contre l'octroi de licences, je le souligne simplement car c'est une énorme différence.

Bien sûr, dans les deux domaines, un architecte peut dessiner quelque chose qui ne peut pas être implémenté.

Échafaudage , "une structure temporaire utilisée pour soutenir les personnes et les matériaux dans la construction ou la réparation de bâtiments et d'autres grandes structures." ^{[définition de wikipedia]}

Ce concept fonctionne car un échafaudage en programmation peut être rapidement créé et fournit des fonctionnalités temporaires jusqu'à ce que la structure réelle soit en place.

Je connais des entreprises de construction qui exploitent des fermes pour le plus bas soumissionnaire, effectuent des travaux bâclés, évitent ce qui devrait être la garantie, se concentrent sur la date plutôt que sur la qualité, puis facturent un bénéfice ridicule pour le produit «fini».

Mais je ne pense pas que les programmeurs ou les agences de conseil n'aient rien appris de ces pratiques.

Les insectes peuvent finir par coûter cher, voire tuer des gens?

Il existe des directives de base pour les projets d'ingénierie complexes de toute discipline:

1. importance de la planification, des plans, de la conception, etc.,
2. importance des mathématiques sous-jacentes
3. réutiliser des idées / apprendre d'autres projets similaires
4. en utilisant des blocs de construction / composants prêts à l'emploi construits par quelqu'un d'autre
5. corriger les problèmes très tôt dans le cycle de vie,
   etc.,

Les points communs entre les disciplines de l'architecture, du génie civil et du génie logiciel semblent provenir principalement de l' absence de chaînes de montage : chaque projet est unique à lui seul.

Heures supplémentaires

Mais dans l'industrie de la construction, les travailleurs sont rémunérés pour leurs heures supplémentaires.

Utilisation de normes, conventions et composants prédéfinis. Vous n'êtes pas susceptible de rencontrer ce genre de problème.

Je ne trouve rien sur le marché qui correspond à nos prises sur mesure.

Lorsque tout ce que vous avez est un marteau, tout ressemble à un clou. :)

Lésions de traction répétitives

Ils représentent un risque professionnel dans les deux secteurs et des précautions doivent être prises pour les éviter. Une fois qu'ils commencent, ils sont difficiles à guérir.