¿Qué pueden aprender los programadores de la industria de la construcción? [cerrado]

Al hablar con colegas sobre el diseño de software y los principios de desarrollo, noté que una de las fuentes más comunes de analogías es la industria de la construcción. Nosotros construimos software y tenemos en cuenta el diseño y estructura a la arquitectura .

Una de las mejores formas de aprender (o enseñar) es a través del análisis de analogías: ¿qué otras analogías se pueden extraer de la construcción? (ya sea de uso común en software o no).

Proporcione una descripción, o su experiencia personal, sobre cómo el concepto de programación es similar al concepto de construcción.

^{[Crédito a los conceptos de programación tomados de las artes y humanidades para la idea]}

De ahí provienen los patrones de diseño.

La persona que supuestamente introdujo el concepto en el mundo fue Christopher Alexander en su libro "A Pattern Language: Towns, Buildings, Construction" en 1977 . A partir de ahí, la Banda de los Cuatro (GoF) lo recogió , y el resto es historia.

Incluso ahora, durante las conferencias y en el desarrollo de software y libros de arquitectura, prevalecen las analogías entre el mundo de la construcción y el mundo del desarrollo de software.

Algunas analogías y referencias que puedo pensar o recordar:

• Por ejemplo, si cambia los requisitos durante la construcción de un edificio, tal vez sea más evidente para el cliente cuán absurdo es esto, por ejemplo: "OH, y quiero un garaje en lugar de donde está la cocina que acaba de terminar".
• Ayudas temporales como andamios (significado en el mundo de la construcción | desarrollo de software )
• Los clientes no pueden seguir agregando funciones sin que les cueste, muchas veces quieren que las cosas se hagan de forma gratuita, y a veces somos lo suficientemente tontos como para aceptar; eso simplemente no podría suceder en el mundo de la construcción (ver los requisitos progresivos ).
• Los roles en el desarrollo de software: el arquitecto es fundamental para el diseño de la solución; consultor y contratista pueden ser términos intercambiables; Los trabajadores son los programadores.
• El cliente no puede proporcionar requisitos precisos en ambos casos.
• Los presupuestos y las estimaciones de tiempo a menudo son incorrectos.
• El producto no puede verse realmente en su forma verdadera hasta el final .
• Un edificio puede tener fallas de construcción después de la construcción, de la misma manera que el software tiene errores .
• Si el producto está mal hecho, a veces es preferible demolerlo y comenzar de nuevo que arreglarlo.
• Sin conocer los resultados reales y reales del trabajo de baja calidad, el cliente quiere la solución más barata .
• Open Source . Estaba viendo esta charla de Doc Searls llamada " Por qué todos los negocios se basarán en código abierto ", donde cuenta cómo la comunidad de la construcción comparte técnicas y conocimientos generales en lugar de patentarlos como la comunidad de código abierto, incluso cuando hay cosas en los edificios. contener productos patentados integrados.
• Los proyectos resultan mejores para todos si el cliente participa activamente .

(Si se me ocurren más, los agregaré).

Hay quienes no piensan que la analogía general es correcta, una lectura recomendada para esto es The Analogy Construction Analogy está rota . Además, hay una pregunta sobre esto en SO titulada ¿Qué tiene de malo la analogía entre el software y la construcción de edificios? .

Hemos tomado muchas palabras e ideas de la industria de la construcción a lo largo de la historia del desarrollo de software, y de hecho probablemente tomamos muchas, y no creo que quede nada por tomar.

Tomamos todo el proceso de tener clientes haciendo una especificación, luego un arquitecto planificando, luego ingenieros diseñando y finalmente codificando monos implementados desde la industria de la construcción, y resultó ser completamente equivocado.

Esto se debe a que cuando construyes una casa, si tu base está equivocada, te quedas sin energía. Seriamente sangrado. Levantar un edificio y reemplazar sus cimientos cuesta más que desechar todo y comenzar de nuevo. Pero en software es completamente posible. He rehecho un software de cliente en una solución cliente-servidor sin que el usuario note nada, excepto que trasladé el módem a la sala de servidores. Eso es como reemplazar la base de concreto con un bote mientras los habitantes dormían.

El software no es como la construcción. Y es por eso que toda la industria del software se convirtió en un momento al comienzo de los travesuras y todo el proceso "en cascada" de ejecutar proyectos fue reemplazado por procesos ágiles en solo un par de años.

En cuanto a las palabras, se toma mucho de la construcción, correcta e incorrectamente.

El marco es el más obvio que aún no se ha tomado. Y hay pipas .

He usado esta analogía ... muchos proyectos de software comienzan porque la persona que necesita algún software sabe el equivalente de un "personal de mantenimiento", y contrata a esta persona para construir el equivalente de software de un cobertizo de jardín. Es una pequeña aplicación pequeña y útil que hace su trabajo muy bien.

Luego, el cliente vuelve al personal de mantenimiento, satisfecho con su trabajo, y le pide que cambie el software para hacer una cosa más. Muchas veces, esta nueva característica no tiene mucho que ver con la solicitud original, por lo que es casi como si le pidieran que construya otra habitación en la parte trasera del cobertizo del jardín con una entrada separada.

Luego quieren poner una luz dentro del cobertizo, por lo que tienen de vuelta al personal de mantenimiento, y él ejecuta un solo circuito desde el panel principal de la casa, instala un interruptor de luz de cadena en el techo de cada habitación y los conecta al circuito .

Luego, el cliente decide que quiere ejecutar algunas herramientas eléctricas, pero sigue soplando el disyuntor, por lo que llama a la persona y él tiene que extraer el circuito único que ejecutó al panel principal, e instalar un conductor más grande y un subpanel en el cobertizo. Tuvo que pasar el cable dos veces y pagar dos permisos eléctricos, etc. Esto es ineficiente.

Entonces el cliente pide algo absurdo: ¿puedes convertir mi cobertizo de jardín en un garaje? No quiero que vuelvas a hacer nada que hayas hecho ... Solo quiero que lo hagas más grande para que pueda estacionar mi auto allí. Luego, en muchos casos, el personal de mantenimiento piensa que "el cliente siempre tiene la razón" y procede a construir adiciones en 3 lados del cobertizo para hacerlo más grande, derriba la pared entre las particiones, etc. Por supuesto, el techo termina caído porque no está construido correctamente, etc.

Entonces, el cliente ya no está tan impresionado, pero todavía quiere más. Le piden al personal de mantenimiento una y otra vez que solo agregue una habitación más, o cambie esta habitación existente para hacer esto, etc. Usted termina con algo que se parece a The Burrow y es casi tan arquitectónicamente sólido.

Ahora, la mayoría de las personas no son lo suficientemente tontas como para intentar esto en el mundo de la construcción, pero sucede todo el tiempo en el mundo del software, porque las personas no hacen estas conexiones:

1. Una persona calificada para construir un cobertizo de jardín realmente agradable no está necesariamente calificada para construir una casa.

2. Si supiera de antemano que iba a construir una casa por etapas, pero que solo comenzaría como un cobertizo de jardín, haría las cosas de manera diferente y el cobertizo del jardín costaría mucho más (derramaría un almohadilla realmente gruesa, asegúrese de ejecutar un conductor lo suficientemente grande como para la carga completa de una casa terminada, etc.).

3. En muchos casos, la actualización de una etapa a otra implica deshacer gran parte del trabajo que se realizó anteriormente, lo que lo hace más costoso de lo que parece.

4. En el mundo de la construcción, podemos darle al cliente una buena idea de cómo será el resultado durante la etapa de diseño, pero no tenemos esa capacidad en el mundo del software. Si llegaste a ese punto, básicamente has escrito una parte significativa del software.

El Manifiesto Ágil es el resultado de reconocer que la analogía del software / construcción está rota. Cosas como las pruebas unitarias automatizadas y los ciclos de lanzamiento iterativos no tienen paralelo en la construcción. Estas cosas aprovechan el costo casi nulo de pasar del diseño al prototipo (lo llamamos compilación o construcción).

Los términos Finalizar trabajo y Recortar vienen a la mente.

La idea de que está bien diferir algunas elecciones estéticas para cuando las principales decisiones estructurales estén completas.

Un viejo adagio: medir dos veces y cortar una vez.

Editar: Hay una sección en el Manifiesto Lista de verificación de Atul Gawande, que habla sobre la gestión de grandes trabajos de construcción. Cuando llegan a un punto que es realmente complicado, tienen una reunión con los expertos involucrados para volver a examinar el problema y ver si ha ocurrido algo durante el proyecto que todos deberían saber. Probablemente no podamos planificarlos con tanta anticipación.

Existen limitaciones tanto en la construcción como en la programación .

Si usted, como cliente, no puede hacer demandas tan ridículas como extender un edificio de hotel terminado durante un fin de semana y colocar un aeropuerto en el piso subterráneo y una pista de aterrizaje en su penthouse, ¿por qué no puede aceptar que no todo ajuste con el acabado? Qué software es posible? No es una bola mágica de 0s y 1s, es una estructura de construcción compleja, aunque inmaterial pero también con sus limitaciones.

Trabajé en la construcción en la escuela y hay lugares donde ni siquiera son analogías, se aplica el mismo concepto. Pero a menudo, la tentación de comparación va demasiado lejos.

Cuando trabajé en una estimación para un trabajo, supe que había promedios bastante firmes sobre cuánto tiempo tomaría hacer algo. Para la fabricación de escaparates, por ejemplo, simplemente contamos el número de juntas en los marcos de los planos y tuvimos una idea bastante buena de cuánto tiempo tomaría eso. Al igual que la programación, teníamos que tener en cuenta las variables en el horario, aunque eso podría quitarte la vida. Por ejemplo: hacer que un equipo de plomería se presente para descubrir que el estacionamiento está pavimentado y no pueden ingresar al edificio porque el asfalto caliente en el camino es bastante costoso.

Sin embargo, la construcción tiene miles de años de experiencia para aprovechar. Las reglas fundamentales del comercio se rigen por las mismas leyes de la física que siempre han sido. Los cálculos de carga de viento y carga muerta son los mismos que cuando se realizaban con reglas de cálculo. Han aparecido mejoras en las herramientas y técnicas, pero a un ritmo glacial en comparación con lo que experimentamos.

Por otro lado, todavía estamos descubriendo que muchos de nuestros patrones y prácticas necesitan margen de mejora. Singleton solía ser una buena idea, ahora la mayoría de los que lo piensan prefieren los patrones IoC / DI.

También nos faltan las licencias y certificaciones significativas. En muchas áreas, incluso para ser un reparador y mucho menos un instalador, un plomero debe tener licencia o trabajar bajo la supervisión de alguien que lo sea. Para obtener esa licencia se requiere una cierta cantidad de tiempo trabajando en el campo. No estoy defendiendo a favor o en contra de las licencias, solo lo señalo, ya que es una gran diferencia.

Por supuesto, en ambos campos, un arquitecto puede dibujar algo que no se puede implementar.

Andamios , "una estructura temporal utilizada para apoyar a personas y materiales en la construcción o reparación de edificios y otras estructuras grandes". ^{[definición de wikipedia]}

Este concepto funciona porque un andamiaje en la programación se puede crear rápidamente y proporciona una funcionalidad temporal hasta que la estructura real esté en su lugar.

Conozco algunas empresas de construcción que trabajan con el mejor postor, hacen trabajos descuidados, eluden lo que debería ser un deber de garantía, se centran en la fecha sobre la calidad y luego cobran una ganancia ridícula por el producto "terminado".

Pero no creo que los programadores o las agencias de consultoría hayan aprendido nada de esas prácticas.

¿Los errores pueden terminar siendo caros como el infierno, o incluso matar personas?

Existen pautas básicas para proyectos de ingeniería complejos de cualquier disciplina:

1. importancia de la planificación, planos, diseño, etc.
2. importancia de las matemáticas subyacentes
3. reutilizando ideas / aprendiendo de otros proyectos similares
4. utilizando bloques de construcción / componentes listos para usar construidos por otra persona
5. corregir problemas muy temprano en el ciclo de vida,
   etc.

Los aspectos comunes entre las disciplinas de arquitectura, ingeniería civil y de software parecen provenir principalmente de la ausencia de líneas de ensamblaje : cada proyecto es único por sí mismo.

A través del tiempo

Pero en la industria de la construcción, a los trabajadores se les paga su tiempo extra.

Uso de estándares, convenciones y componentes preconstruidos. No es probable que se encuentre con este tipo de problema.

No puedo encontrar nada en el mercado que se ajuste a nuestros enchufes personalizados.

Cuando todo lo que tienes es un martillo, todo parece un clavo. :)

Lesiones por esfuerzo repetitivo

Son un riesgo laboral en ambas industrias, y se deben tomar precauciones para evitarlos. Una vez que comienzan, son difíciles de curar.