Cosa possono imparare i programmatori dal settore delle costruzioni? [chiuso]

Parlando con i colleghi dei principi di progettazione e sviluppo del software, ho notato che una delle fonti più comuni per le analogie è l'industria delle costruzioni. Noi costruiamo software e consideriamo la progettazione e la struttura di essere l' architettura .

Uno dei modi migliori per imparare (o insegnare) è attraverso l'analisi delle analogie: quali altre analogie possono essere tratte dalla costruzione? (già di uso comune nel software o meno).

Fornisci una descrizione o la tua esperienza personale su come il concetto di programmazione è simile al concetto di costruzione.

^{[Ringraziamenti ai concetti di programmazione tratti dalle arti e dalle discipline umanistiche per l'idea]}

Ecco da dove provengono i modelli di progettazione.

La persona che presumibilmente ha introdotto il concetto nel mondo era Christopher Alexander nel suo libro "A Pattern Language: Towns, Buildings, Construction" nel 1977 . Da lì, la banda di quattro (GoF) lo raccolse e il resto è storia.

Anche ora durante le lezioni e nello sviluppo di software e nei libri di architettura continuano a prevalere analogie tra il mondo delle costruzioni e il mondo dello sviluppo del software.

Alcune analogie e riferimenti che posso pensare o ricordare:

• Ad esempio, cambiando i requisiti durante la costruzione di un edificio sarebbe forse più evidente per il cliente quanto sia assurdo, ad esempio: "OH, e voglio un garage invece di dove si trova la cucina che hai appena finito".
• Aiuti temporanei come ponteggi (significato nel mondo delle costruzioni | sviluppo software )
• I clienti non possono continuare ad aggiungere funzionalità senza che ciò li costi, molte volte vogliono che le cose vengano fatte gratuitamente e talvolta siamo abbastanza stupidi da accettare; che non poteva proprio accadere nel mondo delle costruzioni (vedi i requisiti strisciare ).
• I ruoli nello sviluppo del software: l'architetto è al centro della progettazione della soluzione; consulente e appaltatore possono essere termini intercambiabili; i lavoratori sono i programmatori.
• Il cliente non può fornire requisiti precisi in entrambi i casi.
• Budget e stime dei tempi sono spesso sbagliati.
• Il prodotto non può essere visto nella sua vera forma fino alla fine .
• Un edificio potrebbe avere difetti di costruzione dopo la costruzione, allo stesso modo in cui il software ha dei bug .
• Se il prodotto è mal fatto, a volte è preferibile demolire e ricominciare da capo piuttosto che ripararlo.
• Non conoscendo i risultati reali e reali di un lavoro di scarsa qualità, il cliente desidera la soluzione più economica .
• Open Source . Stavo solo guardando questo discorso di Doc Searls intitolato " Perché tutti gli affari saranno basati sull'open source " in cui racconta come la comunità delle costruzioni condivide tecniche e conoscenze generali invece di brevettarle in modo molto simile alla comunità open source, anche quando alcune cose negli edifici contiene prodotti proprietari integrati.
• I progetti risultano migliori per tutti se il cliente è coinvolto attivamente .

(Se ne vengono in mente altri, li aggiungerò.)

Ci sono alcuni che non pensano che l'analogia generale sia corretta, una lettura consigliata per questo è The Software Construction Analogy is Broken . Inoltre, c'è una domanda al riguardo su SO intitolata Cosa c'è di sbagliato nell'analogia tra software e costruzione di edifici? .

Abbiamo preso molte parole e idee dall'industria delle costruzioni nel corso della storia dello sviluppo del software, e in effetti probabilmente ne abbiamo prese molte e non credo che ci sia ancora niente da prendere.

Abbiamo seguito l'intero processo con la richiesta da parte dei clienti di una specifica, quindi una pianificazione dell'architetto, quindi la progettazione e infine la codifica delle scimmie che implementano nel settore delle costruzioni, e si è rivelato del tutto fuorviante.

Questo perché quando costruisci una casa, se le tue fondamenta sono sbagliate, sei distrutto. Seriamente fatto. Sollevare un edificio e sostituirne le fondamenta costa più che demolire tutto e ricominciare da capo. Ma nel software è completamente possibile. Ho rifatto un software client in una soluzione client-server senza che l'utente se ne accorga, tranne che ho spostato il modem nella stanza del server. È come sostituire le fondamenta di cemento con una barca mentre gli abitanti dormivano.

Il software non è come la costruzione. Ed è per questo che l'intera industria del software ha iniziato un periodo all'inizio degli anni '70 e l'intero processo "a cascata" di esecuzione dei progetti è stato sostituito con processi agili in appena un paio d'anni.

Quanto a parole, molto viene preso dalla costruzione, nel modo giusto e nel modo sbagliato.

Il framework è il più ovvio che non è già stato preso. E ci sono tubi .

Ho usato questa analogia ... molti progetti software iniziano perché la persona che ha bisogno di software conosce l'equivalente di un "tuttofare", e assumono questa persona per costruirli l'equivalente software di una casetta da giardino. È una piccola, utile piccola applicazione che fa molto bene il suo lavoro.

Il cliente quindi ritorna dal tuttofare, soddisfatto del proprio lavoro, e chiede loro di cambiare il software per fare un'altra cosa. Molte volte, questa nuova funzionalità non ha molto a che fare con la richiesta originale, quindi è quasi come se ti stessero chiedendo di costruire un'altra stanza sul retro del giardino con un ingresso separato.

Quindi vogliono mettere una luce all'interno del capannone, quindi hanno il tuttofare indietro, e gestisce un singolo circuito dal pannello principale della casa, installa un interruttore della luce a catena nel soffitto di ogni stanza e li collega al circuito .

Il cliente decide quindi di voler utilizzare alcuni elettroutensili, ma continua a far saltare l'interruttore, quindi richiamano la persona e deve effettivamente strappare il singolo circuito che correva verso il pannello principale e installare un conduttore più grande e un pannello secondario nel capannone. Ha dovuto far passare il filo due volte e pagare due permessi elettrici, ecc. Questo è inefficiente.

Quindi il cliente chiede qualcosa di assurdo: puoi trasformare la mia casetta da giardino in un garage? Non voglio che tu faccia di nuovo qualsiasi cosa tu abbia fatto ... Voglio solo che tu lo ingrandisca, così posso parcheggiare la macchina lì dentro. Quindi, in molti casi, il tuttofare pensa "il cliente ha sempre ragione" e procede a costruire aggiunte su 3 lati del capannone per renderlo più grande, abbatte il muro tra le pareti divisorie, ecc. Naturalmente, il tetto termina cedimento perché non è costruito correttamente, ecc.

Quindi il cliente non è più così colpito, ma vogliono ancora di più. Chiedono al tuttofare più e più volte di aggiungere solo un'altra stanza, o cambiare questa stanza esistente per fare questo, ecc. Ti ritrovi con qualcosa che assomiglia a The Burrow ed è quasi architettonicamente valido.

Ora la maggior parte delle persone non è abbastanza sciocca da provare questo nel mondo delle costruzioni, ma succede sempre nel mondo del software, perché le persone non fanno queste connessioni:

1. Una persona qualificata per costruire una casetta da giardino davvero piacevole non è necessariamente qualificata per costruire una casa.

2. Se sapessi in anticipo che avresti costruito una casa in più fasi, ma sarebbe solo iniziato come una casetta da giardino, avresti fatto le cose in modo diverso e la casetta sarebbe costata molto di più (avresti versato un pad molto spesso, assicurati di avere un conduttore abbastanza grande per il pieno carico di una casa finita, ecc.).

3. In molti casi, l'aggiornamento da una fase all'altra comporta l'annullamento di gran parte del lavoro svolto in precedenza, rendendolo più costoso di quanto sembri.

4. Nel mondo dell'edilizia, possiamo dare al cliente una buona idea di come sarà il risultato durante la fase di progettazione, ma non abbiamo questa capacità nel mondo del software. Se sei arrivato a quel punto, hai praticamente scritto una parte significativa del software.

Il Manifesto Agile è il risultato del riconoscimento che l'analogia software / costruzione è rotta. Cose come i test unitari automatizzati e i cicli di rilascio iterativo non hanno parallelismi nella costruzione. Queste cose sfruttano il costo quasi zero di passare dalla progettazione al prototipo (lo chiamiamo compilazione o costruzione).

Mi vengono in mente i termini Finish work e Trim .

L'idea che sia giusto approfondire alcune scelte estetiche per quando le principali decisioni strutturali sono complete.

Un vecchio adagio: misura due volte e taglia una volta.

Modifica: c'è una sezione in The Checklist Manifesto di Atul Gawande, che parla della gestione di grandi lavori di costruzione. Quando arrivano ad un punto che è davvero complicato, hanno un incontro con gli esperti coinvolti per rivisitare il problema e vedere se durante il progetto è successo qualcosa che tutti dovrebbero sapere. Probabilmente non possiamo pianificarli con largo anticipo.

Esistono limiti sia nella costruzione che nella programmazione .

Se tu come cliente non puoi fare richieste così ridicole da estendere un edificio alberghiero finito per un fine settimana e mettere un aeroporto nel piano sotterraneo e una pista sul suo attico, perché non puoi accettare che non tutti gli aggiustamenti con il finito software sono possibili? Non è una sfera magica di 0 e 1, è una struttura di costruzione complessa, sebbene irrilevante ma con i suoi limiti.

Ho lavorato nell'edilizia attraverso la scuola e ci sono luoghi in cui non si tratta nemmeno di analogie, si applica lo stesso concetto. Ma spesso, la tentazione del confronto va troppo lontano.

Quando ho lavorato su una stima per un lavoro, sapevo che c'erano medie piuttosto decise su quanto tempo ci sarebbe voluto per fare qualcosa. Ad esempio, per fabbricare vetrine di negozi, abbiamo semplicemente contato il numero di giunti nei telai dai piani e abbiamo avuto una buona idea di quanto tempo ci sarebbe voluto. Proprio come la programmazione, abbiamo dovuto tenere conto delle variabili nei tempi previsti che potrebbero risucchiarti la vita. Ad esempio: far vedere un equipaggio idraulico per scoprire che il parcheggio è stato pavimentato e che non possono entrare nell'edificio a causa dell'asfalto caldo è piuttosto costoso.

Tuttavia, la costruzione ha migliaia di anni di esperienza su cui attingere. Le regole fondamentali del commercio sono guidate dalle stesse leggi della fisica che sono sempre state. I calcoli del carico del vento e del carico morto sono gli stessi di quando venivano eseguiti con le regole delle diapositive. Sono stati apportati miglioramenti negli strumenti e nelle tecniche, ma a un ritmo glaciale rispetto a quello che sperimentiamo.

D'altra parte, stiamo ancora scoprendo che molti dei nostri modelli e pratiche necessitano di margini di miglioramento. Singleton era una buona idea, ora la maggior parte di coloro che ci pensano preferiscono gli schemi IoC / DI.

Ciò di cui ci manca anche la licenza e la certificazione significative. In molte aree, anche solo per essere un riparatore per non parlare di un installatore, un idraulico deve essere autorizzato o lavorare sotto la supervisione di qualcuno che lo è. Per ottenere quella licenza è necessario un certo periodo di lavoro sul campo. Non sto sostenendo la questione a favore o contro la licenza, sto solo sottolineando che è una grande differenza.

Naturalmente in entrambi i campi, un architetto può disegnare qualcosa che non può essere implementato.

Ponteggi , "una struttura temporanea utilizzata per supportare persone e materiale nella costruzione o nella riparazione di edifici e altre grandi strutture". ^{[definizione da Wikipedia]}

Questo concetto funziona perché è possibile creare rapidamente un'impalcatura nella programmazione e fornire funzionalità temporanea fino a quando la struttura reale non sarà a posto.

Conosco alcune aziende edili che lavorano al miglior offerente, eseguono lavori sciatti, si sottraggono a ciò che dovrebbe essere un obbligo di garanzia, si concentrano sulla data e sulla qualità, quindi applicano un profitto ridicolo per il prodotto "finito".

Ma non credo che i programmatori o le agenzie di consulenza abbiano imparato nulla da queste pratiche.

I bug possono finire per essere costosi da morire o addirittura uccidere le persone?

Esistono linee guida di base per progetti di ingegneria complessi di qualsiasi disciplina:

1. importanza della pianificazione, delle stampe blu, del design, ecc.,
2. importanza della matematica sottostante
3. riutilizzo di idee / apprendimento da altri progetti simili
4. utilizzando blocchi predefiniti / componenti creati da qualcun altro
5. correggere i problemi molto presto nel ciclo di vita,
   ecc.,

I punti in comune tra le discipline dell'architettura, dell'ingegneria civile e del software sembrano derivare principalmente dall'assenza di linee di assemblaggio : ogni progetto è unico nel suo genere.

Col tempo

Ma nel settore delle costruzioni, i lavoratori ricevono gli straordinari.

Uso di standard, convenzioni e componenti precostruiti. Non è probabile che si verifichi questo tipo di problema.

Non riesco a trovare nulla sul mercato adatto alle nostre prese personalizzate.

Quando tutto ciò che hai è un martello, tutto sembra un chiodo. :)

Lesioni da sforzo ripetitivo

Sono un rischio professionale in entrambi i settori e devono essere prese precauzioni per prevenirli. Una volta che iniziano, sono difficili da curare.