O que os programadores podem aprender com a indústria da construção? [fechadas]

Ao conversar com colegas sobre princípios de design e desenvolvimento de software, notei que uma das fontes mais comuns de analogias é a indústria da construção. Nós construir software e consideramos a concepção e estrutura para ser a arquitetura .

Uma das melhores maneiras de aprender (ou ensinar) é através da análise de analogias - que outras analogias podem ser extraídas da construção? (já em uso comum em software ou não).

Forneça uma descrição ou sua experiência pessoal sobre como o conceito de programação é semelhante ao conceito de construção.

^{[Crédito aos conceitos de programação retirados das artes e humanidades pela idéia]}

É daí que surgiram os padrões de design.

A pessoa que supostamente apresentou o conceito ao mundo foi Christopher Alexander em seu livro "A Pattern Language: Towns, Buildings, Construction" em 1977 . A partir daí, o Gang of Four (GoF) o pegou , e o resto é história.

Mesmo agora, durante palestras e livros sobre arquitetura e desenvolvimento de software, as analogias entre o mundo da construção e o mundo do desenvolvimento de software continuam prevalecendo.

Algumas analogias e referências que posso pensar ou lembrar:

• Por exemplo, alterar os requisitos durante a construção de um edifício talvez se torne mais evidente para o cliente como isso é absurdo, por exemplo: "OH, e eu quero uma garagem em vez de onde está a cozinha que você acabou de terminar".
• Auxílios temporários como andaimes (significado no mundo da construção | desenvolvimento de software )
• Os clientes não podem continuar adicionando recursos sem que isso lhes custe, muitas vezes eles querem coisas feitas de graça e, às vezes, somos burros o suficiente para aceitar; isso simplesmente não poderia acontecer no mundo da construção (veja os requisitos de fluência ).
• Os papéis no desenvolvimento de software: o arquiteto é central para o design da solução; consultor e contratado podem ser termos intercambiáveis; os trabalhadores são os programadores.
• O cliente não pode fornecer requisitos precisos nos dois casos.
• Orçamentos e estimativas de tempo geralmente estão errados.
• O produto não pode realmente ser visto em sua verdadeira forma até o final .
• Um edifício pode ter falhas de construção após a construção, da mesma forma que o software apresenta bugs .
• Se o produto estiver mal feito, às vezes é preferível demolir e recomeçar do que consertá-lo.
• Sem conhecer os resultados reais e reais de um trabalho de baixa qualidade, o cliente deseja a solução mais barata .
• Código aberto . Eu estava assistindo essa palestra do Doc Searls chamada " Por que todos os negócios serão baseados em código aberto ", onde ele conta como a comunidade da construção compartilha técnicas e conhecimentos gerais, em vez de patentea-los da mesma forma que a comunidade de código aberto, mesmo quando algumas coisas em edifícios contêm produtos proprietários incorporados.
• Os projetos resultam melhores para todos se o cliente estiver envolvido ativamente .

(Se mais vierem à sua mente, eu os adicionarei.)

Há quem não pense que a analogia geral esteja correta, uma leitura recomendada para isso é The Software Construction Analogy is Broken . Além disso, há uma pergunta sobre isso no SO intitulada O que há de errado com a analogia entre software e construção civil? .

Pegamos muitas palavras e idéias da indústria da construção ao longo da história do desenvolvimento de software e, de fato, provavelmente levamos a muitas, e acho que não há mais nada a ser levado.

Levamos todo o processo de ter clientes fazendo uma especificação, depois um arquiteto planejando, depois engenheiros projetando e finalmente codificando macacos implementados na indústria da construção, e isso acabou sendo totalmente equivocado.

Isso ocorre porque, quando você constrói uma casa, se sua fundação está errada, você fica destruído. Sério effed. Elevar um prédio e substituir suas fundações custa mais do que desfazer tudo e começar de novo. Mas no software é completamente possível. Eu refiz um software cliente em uma solução cliente-servidor sem que o usuário percebesse nada, exceto que mudei o modem para a sala do servidor. É como substituir a fundação de concreto por um barco enquanto os habitantes dormiam.

Software não é como construção. E é por isso que toda a indústria de software se ativou no início dos anos ruins e todo o processo "em cascata" de execução de projetos foi substituído por processos ágeis em apenas alguns anos.

Quanto às palavras, muito é retirado da construção, certa e erradamente.

O framework é o mais óbvio ainda não adotado. E há canos .

Eu usei essa analogia ... muitos projetos de software começam porque a pessoa que precisa de algum software conhece o equivalente a um "trabalhador braçal", e eles contratam essa pessoa para construir o equivalente em software a um abrigo de jardim. É um aplicativo pequeno e útil que faz seu trabalho muito bem.

O cliente, em seguida, volta ao trabalhador manual, satisfeito com seu trabalho, e pede que ele mude o software para fazer mais uma coisa. Muitas vezes, esse novo recurso não tem muito a ver com a solicitação original, então é quase como se eles estivessem pedindo para você construir outra sala na parte de trás do galpão do jardim com uma entrada separada.

Então eles querem colocar uma luz dentro do galpão, para que eles tenham o ajudante de volta, e ele dirige um único circuito no painel principal da casa, instala um interruptor de corrente no teto de cada quarto e os conecta ao circuito .

O cliente decide então que deseja usar algumas ferramentas elétricas, mas ele continua acionando o disjuntor, então eles ligam para a pessoa de volta e ele realmente precisa interromper o único circuito que executou no painel principal e instalar um condutor maior e um sub-painel no galpão. Ele teve que passar o fio duas vezes e pagar por duas licenças elétricas, etc. Isso é ineficiente.

Então o cliente pede algo absurdo: você pode transformar meu galpão em uma garagem? Não quero que você refaça tudo o que fez ... Só quero que você a torne maior para que eu possa estacionar meu carro lá. Então, em muitos casos, o faz-tudo pensa "o cliente está sempre certo" e passa a acrescentar três lados do galpão para torná-lo maior, derrubando a parede entre as divisórias, etc. É claro que o teto termina flacidez porque não foi construído corretamente, etc.

Portanto, o cliente não está mais tão impressionado, mas ainda quer mais. Eles pedem repetidamente ao técnico para adicionar mais uma sala ou alterar a sala existente para fazer isso etc. Você acaba com algo que se parece com The Burrow e é tão arquitetonicamente bom.

Agora, a maioria das pessoas não é tola o suficiente para tentar isso no mundo da construção, mas isso acontece o tempo todo no mundo do software, porque as pessoas não fazem essas conexões:

1. Uma pessoa qualificada para construir um galpão de jardim realmente agradável não é necessariamente qualificada para construir uma casa.

2. Se você soubesse antecipadamente que iria construir uma casa em etapas, mas só iria começar como um abrigo de jardim, você faria as coisas de maneira diferente e o abrigo de jardim custaria muito mais (você colocaria uma almofada muito grossa, certifique-se de executar um condutor grande o suficiente para a carga total de uma casa pronta, etc.).

3. Em muitos casos, a atualização de um estágio para outro envolve desfazer muito do trabalho que foi feito anteriormente, tornando-o mais caro do que parece.

4. No mundo da construção, podemos dar ao cliente uma boa idéia de como será o resultado durante a fase de design, mas não temos essa capacidade no mundo do software. Se você chegou a esse ponto, basicamente escreveu uma parte significativa do software.

O Manifesto Ágil é o resultado de reconhecer que a analogia de software / construção está quebrada. Coisas como testes de unidade automatizados e ciclos de liberação iterativos não têm paralelo na construção. Essas coisas tiram vantagem do custo quase zero de ir do design ao protótipo (chamamos de compilação ou construção).

Os termos Concluir trabalho e Aparar vêm à mente.

A ideia de que é aceitável adiar algumas escolhas estéticas para quando as principais decisões estruturais estiverem completas.

Um velho ditado: meça duas vezes e corte uma vez.

Edit: Há uma seção no The Checklist Manifesto de Atul Gawande, que fala sobre o gerenciamento de grandes trabalhos de construção. Quando eles chegam a um ponto realmente complicado, eles se reúnem com os especialistas envolvidos para revisar o problema e verificar se ocorreu alguma coisa durante o projeto que todos deveriam conhecer. Provavelmente não podemos planejá-los com antecedência.

Existem limitações tanto na construção quanto na programação .

Se você, como cliente, não pode fazer exigências tão ridículas que prolonga um edifício acabado de hotel no fim de semana e coloca um aeroporto no piso subterrâneo e uma pista em sua cobertura, por que você não pode aceitar que nem todos os ajustes com o acabamento software é possível? Não é uma bola mágica de 0s e 1s, é uma estrutura de construção complexa, embora imaterial, mas com suas limitações também.

Eu trabalhei na construção através da escola e há lugares onde nem sequer são analogias, o mesmo conceito se aplica. Mas, muitas vezes, a tentação da comparação vai longe demais.

Quando trabalhei em uma estimativa de emprego, sabia que havia médias bastante firmes de quanto tempo levaria para fazer alguma coisa. Para fabricar vitrines de lojas, por exemplo, simplesmente contamos o número de juntas nos quadros dos planos e tivemos uma boa idéia de quanto tempo isso levaria. Assim como a programação, tivemos que levar em consideração as variáveis ​​programadas, embora isso pudesse sugar sua vida. Por exemplo: ter uma equipe de encanamento aparecendo para descobrir que o estacionamento está sendo pavimentado e eles não podem entrar no prédio por causa do asfalto quente no caminho, é bastante caro.

No entanto, a construção tem milhares de anos de experiência para aproveitar. As regras fundamentais do comércio são dirigidas pelas mesmas leis da física que sempre foram. Os cálculos de carga de vento e carga morta são os mesmos de quando estavam sendo feitos com regras de slide. Melhorias em ferramentas e técnicas surgiram, mas em um ritmo glacial em comparação com o que experimentamos.

Por outro lado, ainda estamos descobrindo que muitos de nossos padrões e práticas precisam de espaço para melhorias. Singleton costumava ser uma boa ideia, agora a maioria dos que pensa a respeito prefere padrões de IoC / DI.

O que também nos falta é o significativo licenciamento e certificação. Em muitas áreas, mesmo para ser apenas um reparador e muito menos um instalador, um encanador deve ser licenciado ou trabalhar sob a supervisão de alguém que é. Para obter essa licença, é necessário um certo período de tempo trabalhando em campo. Não estou argumentando a favor ou contra o licenciamento, apenas apontando como é uma enorme diferença.

Obviamente, em ambos os campos, um arquiteto pode desenhar algo que não pode ser implementado.

Andaimes , "uma estrutura temporária usada para apoiar pessoas e materiais na construção ou reparo de edifícios e outras grandes estruturas". ^{[definição da wikipedia]}

Esse conceito funciona porque um andaime na programação pode ser criado rapidamente e fornece funcionalidade temporária até que a estrutura real esteja em vigor.

Conheço algumas empresas de construção que trabalham com o menor lance, fazem trabalhos mal feitos, evitam o que deveria ser um dever de garantia, concentram-se na data e não na qualidade e cobram um lucro ridículo pelo produto "acabado".

Mas não acho que programadores ou agências de consultoria tenham aprendido nada com essas práticas.

Bugs podem acabar sendo caros pra caramba, ou até matar pessoas?

Existem diretrizes básicas para projetos de engenharia complexos de qualquer disciplina:

1. importância do planejamento, projetos, design etc.,
2. importância da matemática subjacente
3. reutilizando idéias / aprendendo com outros projetos semelhantes
4. usando componentes / componentes de construção prontos criados por outra pessoa
5. corrigir problemas muito cedo no ciclo de vida,
   etc.,

Os pontos em comum entre as disciplinas de arquitetura, engenharia civil e engenharia de software parecem resultar principalmente da ausência de linhas de montagem : todo projeto é único por si só.

Ao longo do tempo

Mas na indústria da construção, os trabalhadores recebem horas extras.

Uso de padrões, convenções e componentes pré-construídos. É provável que você não encontre esse tipo de problema.

Não consigo encontrar nada no mercado que se encaixe nos nossos soquetes personalizados.

Quando tudo que você tem é um martelo, tudo parece um prego. :)

Lesões por esforço repetitivo

Eles são um risco ocupacional em ambos os setores e devem ser tomadas precauções para evitá-los. Uma vez que eles começam, eles são difíceis de curar.