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

Ecco da dove vengono i modelli di design.

La persona che presumibilmente ha introdotto il concetto al mondo era Christopher Alexander nel suo libro "A Pattern Language: Towns, Buildings, Construction" in 1977 . Da lì, Gang of Four (GoF) lo raccolse e il resto è cronologia.

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

Alcune analogie e riferimenti che posso pensare o ricordare:

• Ad esempio, modifica dei requisiti durante la costruzione di un edificio potrebbe diventare più evidente al cliente quanto questo sia assurdo, ad esempio: "OH, e voglio un garage invece di dove la cucina hai appena finito ".
• Aiuti temporanei come scaffolding (significato in mondo delle costruzioni | sviluppo software )
• I clienti non possono mantenere l'aggiunta di funzioni senza che ciò le costino, molte volte vogliono che le cose vengano fatte gratuitamente e, a volte, siamo abbastanza stupide da accettarle; che proprio non poteva accadere nel mondo delle costruzioni (vedi requisiti di creep ).
• I ruoli nello sviluppo del software: l'architetto è centrale nella 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.
• I budget e le stime temporali sono spesso sbagliati.
• Il prodotto non può essere realmente visto nel suo modulo vero fino alla fine .
• Un edificio potrebbe avere errori di costruzione dopo la costruzione, allo stesso modo il software ha bug .
• Se il prodotto è mal fatto, a volte è preferibile demolire e ricominciare 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é tutto il business sarà basato sull'open source " dove racconta come le tecniche di condivisione condividono le tecniche di costruzione e conoscenza generale invece di brevettarli molto come la comunità open source, anche quando alcune cose negli edifici contengono prodotti proprietari incorporati.
• I progetti risultano migliori per tutti se il cliente è coinvolto attivamente .

(Se ti viene in mente di più, li aggiungerò.)

Ci sono alcuni che non pensano che l'analogia generale sia corretta, una lettura consigliata per questo è L'analogia di costruzione del software è interrotta . Inoltre, c'è una domanda a questo proposito su SO intitolata Che cos'è sbagliato con l'analogia tra software e costruzione di edifici? .

Abbiamo preso molte parole e idee dal settore 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 qualcosa da fare.

Abbiamo preso l'intero processo di fare in modo che i clienti facessero una specifica, poi una pianificazione dell'architetto, poi dei progettisti e, infine, della codifica delle scimmie implementate dall'industria delle costruzioni, e si è rivelato del tutto fuorviante.

Questo perché quando costruisci una casa, se le tue fondamenta sono sbagliate, vieni colpito. Seriamente effed Sollevare un edificio e sostituirlo con le sue 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 in cemento con una barca mentre gli abitanti dormivano.

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

Per quanto riguarda le parole , molto è preso dalla costruzione, giustamente o erroneamente.

Framework è il più ovvio che non sia già stato preso. E ci sono pipe .

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 un capanno da giardino. È una piccola, utile piccola applicazione che fa il suo lavoro molto bene.

Il cliente torna quindi al tuttofare, soddisfatto del loro lavoro, e chiede loro di cambiare il software per fare ancora una cosa. Un sacco di volte, questa nuova funzione non ha molto a che fare con la richiesta originale, quindi è quasi come se ti chiedessero di costruire un'altra stanza sul retro del capannone con un ingresso separato.

Poi vogliono mettere una luce all'interno del capannone, così hanno il retro del tuttofare, e gestisce un singolo circuito dal pannello principale della casa, installa un interruttore della catena di trazione nel soffitto di ogni stanza e li collega al circuito.

Il cliente decide quindi di voler utilizzare alcuni utensili elettrici, ma continua a far saltare l'interruttore, quindi chiama la persona indietro e in realtà deve strappare il circuito singolo che ha eseguito al pannello principale, e installare un dispositivo più grande conduttore e un sotto-pannello nel capannone. Ha dovuto eseguire il filo due volte e pagare per due permessi elettrici, ecc. Questo è inefficiente.

Quindi il cliente chiede qualcosa di assurdo: puoi trasformare il mio capanno da giardino in un garage? Non voglio che tu rifacci tutto quello che hai fatto ... voglio solo che tu lo ingrandisca, così posso parcheggiare la mia 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 finisce su cascante perché non è costruito bene, ecc.

Quindi il cliente non è più così colpito, ma vuole ancora di più. Chiedono al tuttofare più e più volte di aggiungere solo un'altra stanza, o di cambiare la stanza esistente per farlo, ecc. Finisci con qualcosa che assomiglia a The Burrow ed è 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 un capanno da giardino davvero carino non è necessariamente qualificata per costruire una casa.

2. Se sapessi in anticipo che stavi per costruire una casa in più fasi, ma sarebbe solo iniziato come un capanno da giardino, avresti fatto le cose in modo diverso e il capannone sarebbe costato molto di più (versavi un pad molto spesso, assicurati di avere un conduttore abbastanza grande per il carico completo 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 dovrebbe sembrare.

4. Nel mondo della costruzione, 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 il software / analogia di costruzione è rotto. Cose come test unitari automatizzati e cicli di rilascio iterativi non hanno paralleli nella costruzione. Queste cose si avvantaggiano del costo quasi nullo 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 escludere 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 Il Manifesto di Checklist di Atul Gawande, che parla della gestione di grandi lavori di costruzione. Quando arrivano a un punto che è davvero complicato, hanno un incontro con gli esperti coinvolti per rivisitare il problema e vedere se qualcosa durante il progetto si è verificato che tutti dovrebbero sapere. Probabilmente non possiamo pianificarli con largo anticipo.

I limiti esistono sia nella costruzione che nella programmazione .

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

Ho lavorato nella costruzione attraverso la scuola e ci sono luoghi in cui non sono nemmeno le analogie, vale lo stesso concetto. Ma spesso, la tentazione del confronto va troppo oltre.

Quando ho lavorato su una stima per un lavoro, sapevo che c'erano medie abbastanza precise su quanto tempo ci sarebbe voluto per fare qualcosa. Ad esempio, per la realizzazione di vetrine di negozi, abbiamo semplicemente contato il numero di giunti nei telai rispetto ai piani e avevamo una buona idea quanto tempo ci sarebbe voluto. Proprio come la programmazione, abbiamo dovuto tenere conto delle variabili nel programma, anche se ciò potrebbe risucchiarti la vita. Per esempio: avere un equipaggio idraulico mostra di scoprire che il parcheggio è in asfalto e che non possono entrare nell'edificio perché l'asfalto caldo sulla strada è piuttosto costoso.

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

D'altra parte, stiamo ancora scoprendo che molti dei nostri schemi e pratiche hanno bisogno di margini di miglioramento. Singleton era una buona idea, ora la maggior parte di chi la pensa preferisce gli schemi IoC / DI.

Anche dove ci manca è una licenza e una certificazione significative. In molte aree, anche solo per essere un riparatore e tanto meno un installatore, un idraulico deve essere autorizzato o lavorare sotto la supervisione di qualcuno che lo è. Per ottenere quella licenza richiede un certo periodo di tempo lavorando in campo. Non sto facendo il caso a favore o contro le licenze, solo sottolineando come è un'enorme differenza.

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

Scaffolding , "una struttura temporanea utilizzata per supportare persone e materiali nella costruzione o nella riparazione di edifici e altre strutture di grandi dimensioni". ^{[definizione da wikipedia]}

Questo concetto funziona perché è possibile creare rapidamente un scaffolding in programmazione e fornire funzionalità temporanee fino la struttura reale è a posto.

Conosco alcune società di costruzioni che le fattorie lavorano per l'offerente più basso, fanno lavori sciatti, sottraggono ciò che dovrebbe essere un obbligo di garanzia, si concentrano sulla data sulla qualità e poi fanno pagare un profitto ridicolo per il prodotto "finito".

Ma non penso che i programmatori o le agenzie di consulenza abbiano imparato qualcosa da quelle pratiche.

Gli errori possono finire per essere costosi come l'inferno o addirittura uccidere persone?

Ci sono linee guida di base per progetti ingegneristici 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 costruiti da qualcun altro
5. correggere i problemi molto presto nel ciclo di vita
   ecc.

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

Overtime

Ma nel settore delle costruzioni, i lavoratori ottengono i loro straordinari retribuiti.

Uso di standard, convenzioni e componenti prefabbricati. Non è probabile che ti imbatti in questo tipo di problema.

I can't find anything in the market that fits our custom built sockets.

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

Lesioni da sforzi ripetitivi

Sono un rischio professionale in entrambe le industrie e devono essere prese precauzioni per prevenirli. Una volta che iniziano, sono difficili da curare.