Was können Programmierer von der Bauindustrie lernen? [geschlossen]

Bei Gesprächen mit Kollegen über Software-Design- und -Entwicklungsprinzipien ist mir aufgefallen, dass die Bauindustrie eine der häufigsten Quellen für Analogien ist. Wir bauen Software und betrachten Design und Struktur als Architektur .

Eine der besten Möglichkeiten zum Lernen (oder Lehren) besteht in der Analyse von Analogien. Welche anderen Analogien lassen sich aus der Konstruktion ziehen? (ob bereits in der Software gebräuchlich oder nicht).

Bitte geben Sie eine Beschreibung oder Ihre persönlichen Erfahrungen bezüglich der Ähnlichkeit des Programmierkonzepts mit dem Konstruktionskonzept an.

^{[Dank an Programmierkonzepte aus den Geisteswissenschaften für die Idee]}

Das ist, woher Designmuster kamen.

Die Person, die angeblich das Konzept der Welt vorstellte, war Christopher Alexander in seinem Buch "Eine Mustersprache: Städte, Gebäude, Bauen" im Jahr 1977 . Von dort aus hat die vierköpfige Bande ( Gang of Four, GoF) es aufgegriffen , und der Rest ist Geschichte.

Auch in Vorlesungen und in Softwareentwicklungs- und Architekturbüchern halten Analogien zwischen der Konstruktions- und der Softwareentwicklungswelt an.

Einige Analogien und Referenzen, die mir einfallen oder in Erinnerung bleiben:

• Wenn sich beispielsweise die Anforderungen während des Baus eines Gebäudes ändern , wird dem Kunden möglicherweise klarer, wie absurd dies ist, z.
• Hilfsmittel wie Gerüste (Bedeutung in der Konstruktionswelt | Softwareentwicklung )
• Kunden können nicht weiter Funktionen hinzufügen, ohne dass dies sie etwas kostet. Oft möchten sie, dass die Dinge kostenlos erledigt werden, und manchmal sind wir dumm genug, dies zu akzeptieren. Das konnte in der Baubranche einfach nicht passieren (siehe Anforderungen schleichen ).
• Die Rollen in der Softwareentwicklung: Der Architekt spielt eine zentrale Rolle beim Entwurf der Lösung. Berater und Auftragnehmer können austauschbare Begriffe sein; Die Arbeiter sind die Programmierer.
• Der Kunde kann in beiden Fällen keine genauen Anforderungen stellen .
• Budgets und Zeitschätzungen sind oft falsch.
• Das Produkt kann erst am Ende wirklich in seiner wahren Form gesehen werden .
• Ein Gebäude kann nach dem Bau Konstruktionsfehler aufweisen , genauso wie Software Fehler aufweist .
• Wenn das Produkt schlecht gemacht ist, ist es manchmal vorzuziehen, es abzureißen und von vorne zu beginnen, als es zu reparieren.
• Da der Kunde nicht über die tatsächlichen und tatsächlichen Ergebnisse einer minderwertigen Arbeit Bescheid weiß, möchte er die billigste Lösung .
• Open Source . Ich habe gerade diesen Vortrag von Doc Searls mit dem Titel " Warum alle Geschäfte auf Open Source basieren " gesehen, in dem er erzählt, wie die Bauindustrie Techniken und allgemeines Wissen teilt, anstatt sie ähnlich wie die Open Source-Community zu patentieren, selbst wenn einige Dinge in Gebäuden sind enthalten eingebaute proprietäre Produkte.
• Projekte werden für alle besser , wenn der Kunde aktiv einbezogen wird .

(Wenn mir mehr einfällt, füge ich sie hinzu.)

Es gibt einige, die die allgemeine Analogie nicht für richtig halten. Eine empfohlene Lektüre hierfür ist The Software Construction Analogy is Broken . Es gibt auch eine Frage zu SO mit dem Titel " Was stimmt nicht mit der Analogie zwischen Software und Baukonstruktion?". .

Wir haben in der gesamten Geschichte der Softwareentwicklung viele Wörter und Ideen aus der Baubranche mitgenommen, und wahrscheinlich haben wir auch viele mitgenommen, und ich glaube, es ist nichts mehr zu nehmen.

Wir haben den gesamten Prozess in Anspruch genommen, Kunden eine Spezifikation erstellen zu lassen, dann einen Architekten zu planen, dann Ingenieure, die Affen aus der Bauindustrie entwerfen und schließlich codieren, und es stellte sich heraus, dass dies völlig fehlgeleitet war.

Dies liegt daran, wenn Sie ein Haus bauen, wenn Ihr Fundament falsch ist, werden Sie effed. Ernsthaft genervt. Ein Gebäude zu heben und seine Fundamente zu ersetzen, kostet mehr, als das Ganze zu verschrotten und von vorne zu beginnen. Aber in der Software ist das durchaus möglich. Ich habe eine Client-Software in eine Client-Server-Lösung umgewandelt, ohne dass der Benutzer etwas bemerkt hat, außer dass ich das Modem in den Serverraum verlegt habe. Das ist, als würde man das Betonfundament durch ein Boot ersetzen, während die Bewohner schliefen.

Software ist nicht wie Konstruktion. Und deshalb hat sich die gesamte Software-Branche zu Beginn der 90er-Jahre aufgeschaltet, und der gesamte "Wasserfall" -Prozess der Projektdurchführung wurde in nur wenigen Jahren durch agile Prozesse ersetzt.

Was die Wörter angeht, so wird dem Bauen zu Recht und zu Unrecht viel entnommen.

Framework ist das offensichtlichste, das noch nicht vergeben ist. Und da sind Pfeifen .

Ich habe diese Analogie verwendet ... viele Softwareprojekte beginnen, weil die Person, die eine Software benötigt, das Äquivalent eines "Handwerkers" kennt, und sie diese Person anstellt, um ihnen das Softwareäquivalent eines Gartenhauses zu erstellen. Es ist eine kleine, nützliche kleine Anwendung, die ihre Arbeit sehr gut macht.

Der Kunde kehrt dann zufrieden mit seiner Arbeit zum Heimwerker zurück und bittet ihn, die Software zu ändern, um noch etwas zu tun. Häufig hat diese neue Funktion nicht viel mit der ursprünglichen Anfrage zu tun, sodass es fast so ist, als würden Sie gebeten, einen weiteren Raum auf der Rückseite des Gartenhauses mit separatem Eingang zu errichten.

Dann wollen sie ein Licht in den Schuppen bringen, damit sie den Heimwerker zurück haben, und er führt einen einzelnen Stromkreis von der Haupttafel im Haus aus, installiert einen Zugkettenlichtschalter in der Decke jedes Raumes und verbindet sie mit dem Stromkreis .

Der Kunde entscheidet dann, dass er einige Elektrowerkzeuge betreiben möchte, aber der Leistungsschalter wird immer wieder durchgebrannt, sodass er die Person zurückruft und tatsächlich den einzelnen Stromkreis herausreißen muss, den er zum Hauptpanel geführt hat, und einen größeren Leiter und ein Kabel installieren muss Unterblech im Schuppen. Er musste den Draht zweimal verlegen und zwei elektrische Genehmigungen usw. bezahlen. Dies ist ineffizient.

Dann bittet der Kunde um etwas Absurdes: Kannst du mein Gartenhaus in eine Garage verwandeln? Ich möchte nicht, dass Sie etwas wiederholen, was Sie getan haben ... Ich möchte nur, dass Sie es größer machen, damit ich mein Auto dort parken kann. In vielen Fällen denkt der Heimwerker dann, "der Kunde hat immer Recht" und baut weitere Anbauten auf drei Seiten des Schuppens, um ihn größer zu machen, stößt die Wand zwischen den Trennwänden ab usw. Natürlich endet das Dach durchhängen, weil es nicht richtig gebaut ist, etc.

Der Kunde ist also nicht mehr so ​​beeindruckt, aber er möchte immer noch mehr. Sie bitten den Heimwerker immer wieder, nur einen weiteren Raum hinzuzufügen oder diesen vorhandenen Raum zu ändern, um dies zu tun, usw. Am Ende entsteht etwas, das wie The Burrow aussieht und architektonisch ungefähr so ​​gut klingt.

Jetzt sind die meisten Leute nicht dumm genug, dies in der Konstruktionswelt zu versuchen, aber es passiert die ganze Zeit in der Softwarewelt, weil die Leute diese Verbindungen nicht herstellen:

1. Eine Person, die für den Bau eines wirklich schönen Gartenhauses qualifiziert ist, muss nicht unbedingt für den Bau eines Hauses qualifiziert sein.

2. Wenn Sie im Voraus wüssten, dass Sie ein Haus schrittweise bauen würden, dies aber nur als Gartenhaus anfangen würde, würden Sie die Dinge anders machen, und der Gartenhaus würde viel mehr kosten (Sie würden ein Haus einschenken) Stellen Sie sicher, dass Sie einen Leiter haben, der groß genug ist für die volle Ladung eines fertigen Hauses usw.).

3. In vielen Fällen muss beim Upgrade von einer Phase zur nächsten ein Großteil der zuvor geleisteten Arbeit rückgängig gemacht werden, wodurch die Kosten höher ausfallen, als es den Anschein hat.

4. In der Konstruktionswelt können wir dem Kunden eine gute Vorstellung davon geben, wie das Ergebnis während der Konstruktionsphase aussehen wird, aber wir haben diese Fähigkeit in der Softwarewelt nicht. Wenn Sie es bis zu diesem Punkt geschafft haben, haben Sie im Grunde einen bedeutenden Teil der Software geschrieben.

Das Agile Manifest ist das Ergebnis der Anerkennung, dass die Software / Konstruktions-Analogie gebrochen ist. Dinge wie automatisierte Unit-Tests und iterative Release-Zyklen haben keine Parallele im Aufbau. Diese Dinge nutzen die nahezu Null-Kosten für den Übergang vom Entwurf zum Prototyp (wir nennen es Kompilieren oder Erstellen).

Die Begriffe " Arbeit beenden" und " Trimmen" fallen mir ein.

Die Idee, dass es in Ordnung ist, einige ästhetische Entscheidungen zu verschieben, wenn die wichtigsten strukturellen Entscheidungen abgeschlossen sind.

Ein altes Sprichwort: Zweimal messen und einmal schneiden.

Bearbeiten: Es gibt einen Abschnitt im Checklisten-Manifest von Atul Gawande, in dem es um die Verwaltung großer Bauaufträge geht. Wenn sie zu einem Punkt kommen, der wirklich kompliziert ist, treffen sie sich mit den beteiligten Experten, um das Problem erneut zu untersuchen und festzustellen, ob während des Projekts etwas passiert ist, über das jeder Bescheid wissen sollte. Wir können sie wahrscheinlich nicht so weit im Voraus planen.

Einschränkungen bestehen sowohl bei der Konstruktion als auch bei der Programmierung .

Wenn Sie als Kunde nicht die lächerlichen Anforderungen stellen können, ein fertiggestelltes Hotelgebäude über ein Wochenende zu verlängern und einen Flughafen in die unterirdische Etage und eine Landebahn auf seinem Penthouse zu legen, warum können Sie dann nicht akzeptieren, dass nicht alle Anpassungen mit der Fertigstellung abgeschlossen sind? Software sind möglich? Es ist keine magische Kugel aus Nullen und Einsen, es ist eine komplexe Konstruktionsstruktur, obwohl immateriell, aber mit ihren Einschränkungen.

Ich habe durch die Schule im Bau gearbeitet und es gibt Orte, an denen es nicht einmal Analogien gibt, das gleiche Konzept gilt. Aber oft geht die Vergleichsversuchung viel zu weit.

Als ich an einem Kostenvoranschlag für einen Job arbeitete, wusste ich, dass es ziemlich genaue Durchschnittswerte dafür gibt, wie lange es dauern würde, etwas zu tun. Für die Herstellung von Schaufenstern zum Beispiel haben wir einfach die Anzahl der Fugen in den Rahmen aus den Plänen gezählt und hatten eine ziemlich gute Idee, wie lange das dauern würde. Genau wie beim Programmieren mussten wir im Zeitplan Variablen berücksichtigen, die Ihnen das Leben rauben könnten. Zum Beispiel: Es ist ziemlich teuer, wenn eine Klempnermannschaft auftaucht und feststellt, dass der Parkplatz gepflastert ist und sie nicht in das Gebäude gelangen können, weil der heiße Asphalt im Weg ist.

Der Bau kann jedoch auf tausende Jahre Erfahrung zurückgreifen. Die Grundregeln des Handels werden von denselben Gesetzen der Physik bestimmt, die sie schon immer waren. Windlast- und Totlastberechnungen sind dieselben wie zu dem Zeitpunkt, als sie mit Rechenschiebern durchgeführt wurden. Es wurden Verbesserungen an Werkzeugen und Techniken vorgenommen, die jedoch im Vergleich zu unseren Erfahrungen einen rasanten Tempo erreichen.

Andererseits stellen wir immer noch fest, dass viele unserer Muster und Praktiken noch verbesserungswürdig sind. Früher war Singleton eine gute Idee, heute bevorzugen die meisten, die darüber nachdenken, IoC / DI-Muster.

Was uns auch fehlt, ist eine sinnvolle Lizenzierung und Zertifizierung. In vielen Bereichen muss ein Klempner eine Lizenz haben oder unter der Aufsicht von jemandem arbeiten, der es ist, um nur ein Handwerker oder gar ein Installateur zu sein. Um diese Lizenz zu erhalten, ist eine gewisse Zeit im Feld erforderlich. Ich mache keine Argumente für oder gegen die Lizenzierung, sondern weise nur darauf hin, dass dies ein großer Unterschied ist.

Natürlich kann ein Architekt in beiden Bereichen etwas zeichnen, das nicht umgesetzt werden kann.

Gerüste , "eine temporäre Struktur zur Unterstützung von Menschen und Material beim Bau oder der Reparatur von Gebäuden und anderen großen Strukturen." ^{[Definition aus Wikipedia]}

Dieses Konzept funktioniert, weil ein Gerüst in der Programmierung schnell erstellt werden kann und temporäre Funktionalität bietet, bis die eigentliche Struktur vorhanden ist.

Ich kenne einige Baufirmen, die auf dem Bauernhof für den niedrigsten Preis arbeiten, schlampige Arbeit verrichten, sich vor der Verpflichtung zur Gewährleistung drücken, sich auf das Datum der Qualität konzentrieren und dann einen lächerlichen Gewinn für das "fertige" Produkt verlangen.

Aber ich glaube nicht, dass Programmierer oder Beratungsagenturen etwas aus diesen Praktiken gelernt haben.

Käfer können teurer werden oder sogar Menschen töten?

Es gibt grundlegende Richtlinien für komplexe Ingenieurprojekte aller Disziplinen:

1. Wichtigkeit von Planung, Blaupausen, Design usw.
2. Bedeutung der zugrunde liegenden Mathematik
3. Wiederverwenden von Ideen / Lernen aus ähnlichen Projekten
4. Verwendung vorgefertigter Bausteine ​​/ Komponenten, die von einer anderen Person erstellt wurden
5. Beheben von Problemen sehr früh im Lebenszyklus
   usw.,

Die Gemeinsamkeiten zwischen Architektur, Bauwesen und Softwaretechnik scheinen hauptsächlich auf das Fehlen von Fließbändern zurückzuführen zu sein : Jedes Projekt ist für sich ein Unikat.

Im Laufe der Zeit

Aber in der Bauindustrie werden die Überstunden bezahlt.

Verwendung von Standards, Konventionen und vorgefertigten Komponenten. Es ist unwahrscheinlich, dass Sie auf ein solches Problem stoßen.

Ich kann nichts auf dem Markt finden, das zu unseren kundenspezifischen Steckdosen passt.

Wenn Sie nur einen Hammer haben, sieht alles aus wie ein Nagel. :)

Repetitive Belastungsverletzungen

Sie sind in beiden Branchen ein Berufsrisiko, und es müssen Vorkehrungen getroffen werden, um dies zu verhindern. Sobald sie anfangen, sind sie schwer zu heilen.