¿Por qué la industria de TI no puede entregar proyectos grandes e impecables tan rápido como en otras industrias?

509

Después de ver la serie MegaStructures de National Geographic , me sorprendió lo rápido que se completan los grandes proyectos. Una vez que el trabajo preliminar (diseño, especificaciones, etc.) se realiza en papel, la realización de grandes proyectos lleva unos pocos años o, a veces, algunos meses .

Por ejemplo, Airbus A380 "lanzado formalmente el 19 de diciembre de 2000" y "a principios de marzo de 2005" , el avión ya fue probado. Lo mismo ocurre con los grandes petroleros, rascacielos, etc.

Comparando esto con los retrasos en la industria del software, no puedo dejar de preguntarme por qué la mayoría de los proyectos de TI son tan lentos, o más precisamente, por qué no pueden ser tan rápidos e impecables, en la misma escala, si se les da suficiente gente.


Proyectos como el Airbus A380 presentan ambos:

  • Principales riesgos imprevistos: si bien este no es el primer avión construido, aún supera los límites de la tecnología y las cosas que funcionaron bien para los aviones más pequeños pueden no funcionar para el más grande debido a restricciones físicas; de la misma manera, se utilizan nuevas tecnologías que aún no se usaban, porque, por ejemplo, no estaban disponibles en 1969 cuando se realizó el Boeing 747.

  • Riesgos relacionados con los recursos humanos y la gestión en general: personas que renuncian en medio del proyecto, incapacidad para comunicarse con una persona porque está de vacaciones, errores humanos comunes, etc.

Con esos riesgos, las personas aún logran proyectos como esos grandes aviones en un período de tiempo muy corto y, a pesar de los retrasos en la entrega, esos proyectos aún tienen un gran éxito y una alta calidad.

Cuando se trata del desarrollo de software, los proyectos no son tan grandes y complicados como un avión (tanto en términos técnicos como de gestión), y tienen riesgos ligeramente menos imprevistos del mundo real.

Aún así, la mayoría de los proyectos de TI son lentos y tardíos , y agregar más desarrolladores al proyecto no es una solución (pasar de un equipo de diez desarrolladores a dos mil a veces permitirá entregar el proyecto más rápido, a veces no, y a veces solo dañará el proyectar y aumentar el riesgo de no terminarlo en absoluto).

Los que aún se entregan a menudo pueden contener muchos errores, que requieren paquetes de servicio consecutivos y actualizaciones periódicas (imagine "instalar actualizaciones" en cada Airbus A380 dos veces por semana para corregir los errores en el producto original y evitar que el avión se estrelle).

¿Cómo pueden explicarse tales diferencias? ¿Se debe exclusivamente al hecho de que la industria de desarrollo de software es demasiado joven para poder administrar a miles de personas en un solo proyecto con el fin de ofrecer productos a gran escala y casi sin fallas muy rápido?

Arseni Mourzenko
fuente
127
Interesante pregunta. Estoy tentado a decir que la calidad del trabajador promedio en la industria del software es menos calificada y calificada que, por ejemplo, la ingeniería civil, donde cada ingeniero ha completado un título riguroso e intensivo y probablemente también obtuvo su estatuto. Además, el espacio de complejidad del software grande (por ejemplo, un sistema operativo, MS Office) es probablemente mucho mayor incluso que un avión. ¡Ciertamente muchos más lugares para fallar! Y un último punto importante: la mayoría del software funciona más o menos, incluso si está mal escrito y tiene muchos errores ... ¡ciertamente el costo de la falla es normalmente mucho menor que un avión!
Noldorin
155
Encuentre a alguien que realmente trabaje en cualquiera de esas otras industrias (pero no en relaciones públicas) y pregúnteles sobre "grandes proyectos sin fallas". Prácticamente puedo garantizar que ganarás una risa dolorida.
Michael Borgwardt
151
La realización de un proyecto de software lleva segundos o minutos; es lo que sucede cuando haces clic en "compilar" en tu IDE. Por otro lado, la programación es diseño . ¿Cuánto tiempo llevó diseñar el A380?
Ant
53
Ese programa de televisión es una exageración. Solo transmiten proyectos exitosos. Cualquier canal creará programas para la atención de los espectadores.
pandu
117
"imagine" instalar actualizaciones "en cada Airbus A380 dos veces por semana ..." Imagine que los robots enemigos constantemente exploran el avión en busca de vulnerabilidades mientras los pilotos no entrenados presionan botones al azar. Apuesto a que necesitarías parches regulares.
Nathan Long

Respuestas:

337

La Marcha de la Muerte de Ed Yourdon toca varias de estas preguntas de metatipo.

En general, la industria del software carece de muchos de los siguientes, lo que se interpone en el camino de grandes proyectos.

  • Estandarización y desglose de elementos de trabajo.

    • Esto ciertamente ha mejorado, pero las construcciones de diseño todavía no están ahí para romper un gran sistema. De alguna manera, el software ni siquiera puede ponerse de acuerdo sobre lo que se necesita para un proyecto determinado, y mucho menos poder dividir las cosas en componentes.
    • Aeroespacial, construcción de edificios, auto, etc. todos tienen arquitecturas muy basadas en componentes con interfaces razonablemente ajustadas para permitir un desarrollo completamente paralelo. El software todavía permite demasiada sangría en las áreas correspondientes.
  • Un gran cuerpo de proyectos exitosos y similares. El A380 no fue el primer gran avión que construyó Airbus . Hay muchas aplicaciones de software grandes por ahí, pero muchas de ellas han sufrido dramáticamente en algún aspecto u otro y no se acercan a ser llamadas "exitosas".

  • Un gran cuerpo de diseñadores y constructores que han trabajado en una serie de proyectos similares y exitosos. En relación con el problema del proyecto exitoso, no contar con el talento humano que ha estado allí hace que las cosas sean muy difíciles desde el punto de vista de la repetibilidad.

  • "Nunca" construyendo lo mismo dos veces. En muchos sentidos, un avión es como cualquier otro avión. Tiene alas, motores, asientos, etc. Los grandes proyectos de software rara vez se repiten. Cada núcleo del sistema operativo es significativamente diferente. Mire la disparidad en los sistemas de archivos. Y para el caso, ¿cuántos sistemas operativos realmente únicos hay? Los grandes se convierten en clones de un elemento base en algún momento. AIX , Solaris , HP-UX , ... Herald de nuevo a AT & T System V . Windows ha tenido una increíble cantidad de arrastre hacia adelante en cada iteración. Las variantes de Linux generalmente vuelven al mismo núcleo que Linus comenzó. Lo menciono, porque las variantes tienden a propagarse más rápido que los sistemas operativos patentados verdaderamente únicos.

  • Muy mala estimación del proyecto. Dado que el factor de repetibilidad es tan bajo, es difícil proyectar qué tan grande terminará siendo y cuánto tiempo tomará construir algo. Dado que los gerentes de proyectos y la Administración no pueden poner sus manos en el código y realmente ver lo que se está haciendo, se generan expectativas poco realistas con respecto a los plazos.

  • QA / QC no se enfatiza tanto como podría o debería ser para proyectos más grandes. Esto se remonta a tener interfaces más flexibles entre los componentes y no tener especificaciones rígidas sobre cómo deberían funcionar los componentes. Esa soltura permite consecuencias no deseadas y la aparición de errores.

  • Calificaciones consistentemente medibles. En general, las personas hablan de la cantidad de años que han trabajado en lenguaje X o en programación. El tiempo en se está utilizando como sustituto del calibre o la calidad de la habilidad. Como se ha mencionado muchas veces antes, es difícil entrevistar y encontrar buenos talentos de programación. Parte del problema es que la definición de "bueno" sigue siendo muy subjetiva.

No pretendo ser todo negativo, y creo que la industria del software ha avanzado significativamente desde donde hemos estado. Foros como este y otros realmente han ayudado a promover la conversación y la discusión de los principios de diseño. Hay organizaciones que trabajan para estandarizar el conocimiento "básico" para los ingenieros de software. Ciertamente hay margen de mejora, pero creo que la industria ha recorrido un largo camino en un período de tiempo razonablemente corto.

usuario53019
fuente
23
Fue difícil elegir una respuesta para aceptar entre varias respuestas muy buenas, pero finalmente seleccioné esta a pesar de que no tiene los votos más altos. De hecho, tanto esta respuesta como la de m3th0dman precisamente por qué hay tanta especificidad en la industria de TI, ayudan a comprender qué hacer en el futuro para cerrar la brecha. En comparación con la respuesta de m3th0dman, esta parece mucho más detallada.
Arseni Mourzenko
3
+1, pero podría agregar que dado que el software existe en el ámbito de la mente, tiene posibilidades casi infinitas , mientras que cada plano que se construye debe lidiar con los requisitos finitos de la realidad.
Spencer Rathbun
55
Muy bien contestado. Como un ejemplo interesante, imagine si un avión grande fue diseñado e implementado por un grupo de personas sin proceso o historial de la compañía, personas que simplemente se unieron y formaron un negocio para construir un avión en la escala de un 747 desde cero. Así es como se realiza el 90% de los proyectos de software que he visto. El otro 10% con arquitectos experimentados y empresas con historia y proceso parece ser mucho más exitoso. Para un contraejemplo, observe el proceso de desarrollo detrás del software que hace que las personas mueran cuando falla.
Bill K
77
Creo que aceptaste la respuesta incorrecta. Danny Woods tenía razón, las fallas en otras industrias son tan frecuentes y la programación no está construyendo su diseño. La construcción en el mundo del software la realiza el compilador y es prácticamente gratuita. Su pregunta original fue muy reveladora Una vez que el trabajo preliminar (diseño, especificaciones, etc.) se realiza en papel, el trabajo de diseño y especificación de una estructura física es una especificación EXACTA de cómo construir la estructura. Lo único que coincide con eso en el mundo del software es el código. El código es diseño, la compilación es construcción.
Michael Brown
55
Pero la pregunta en sí es defectuosa. Si bien necesitamos hacer una mirada crítica hacia nuestras propias deficiencias. Es absurdo actuar como si la industria del software fuera la única que tiene proyectos fallidos. Decir "una vez que todo el diseño se ha hecho" también es revelador. Incluso si no está de acuerdo con que la programación es una actividad de diseño, ¿con qué frecuencia ve por adelantado un diseño detallado y revestido de hierro para el software? Las personas dan especificaciones difusas sobre el software porque anticipan poder cambiar el software si las especificaciones no eran correctas sin preocuparse de cómo esos cambios podrían afectar la solución completa.
Michael Brown
452

La respuesta es sorprendentemente simple: esas 'otras industrias' no tienen una alta tasa de fracaso. Solo estamos comparando las cosas equivocadas. El software de escritura a menudo se llama 'construir', por lo que lo comparamos con las fases de fabricación o construcción en otras industrias. Pero si lo miras, no es construcción en absoluto: es diseño . Los diseños de software están escritos en código, y la construcción se realiza mediante computadoras, ya sea compilando software o interpretándolo directamente sobre la marcha.

Muchos diseños en otras industrias tardan más de lo estimado originalmente, cuestan mucho más o simplemente nunca se completan. ¿Suena familiar?

Entonces, ¿qué hacemos cuando planificamos software? Bueno, todavía estamos diseñando, pero en una etapa anterior.

En software, no hay una línea de fabricación notable. La construcción del componente final es (comparativamente) barata, y la replicación de ese producto final es perfecta y efectivamente gratuita: copia los artefactos de construcción.

Danny Woods
fuente
47
Incluso en la industria que mencionó el OP, Aerospace, el Boeing 787 Dreamliner y el JSF F-35 tuvieron retrasos significativos. La semana pasada, un estacionamiento colapsó en uno de los principales centros comerciales de Sydney. Sydney tiene estándares de construcción muy rigurosos pero ocurren errores.
teambob
23
Mil veces esto. Incluso el enlace del cronograma de la pregunta muestra que el proyecto estaba en desarrollo desde 1988. El código fuente es el diseño: developerdotstar.com/mag/articles/reeves_design.html
pkh
2
Muchos proyectos grandes como el F-35, el telescopio Hubble, etc., se retrasaron debido al lado del desarrollo del software. El Hubble en realidad permaneció almacenado durante años porque el software no estaba listo.
MrLane
11
@MrLane: en el mundo real funciona así. Se establece un cronograma para cuándo se supone que se debe hacer el hardware y se supone que se debe hacer el software. Los diseñadores de hardware proporcionan un ICD al equipo de software para que el equipo de sw pueda escribir su código sin el hardware. El hardware pierde mucho su horario y cambia sus interfaces para solucionar los problemas de hardware, con frecuencia sin notificar al equipo de sw. Finalmente, el tipo de trabajo funciona y se entrega muy tarde. Por supuesto, el sw no funciona debido a la gran cantidad de inesperadas "características" de hw. Porque es más barato solucionar problemas de hardware en ...
Dunk
11
software, el equipo de sw ahora tiene que incorporar los cambios al ICD y proponer soluciones para el hardware defectuoso. Entonces, además de que hw se entregó muy tarde y ahora el equipo de sw también está arreglando el hardware defectuoso, ¿quién tiene la culpa de llegar tarde? Bueno, el equipo de software aún no ha terminado. Es el software que llega tarde. Todos siempre se olvidan de los resbalones de programación de ingeniería eléctrica, mecánica y de sistemas de los que dependía el sw y que luego obligaban a reescribir el sw y tener requisitos adicionales. Todo lo que ven es que el equipo sw todavía está codificando. Por lo tanto, el software llega tarde.
Dunk
180

Para señalar algunas cifras:

  1. Cambio de requisitos después de que comenzó la implementación ; por ejemplo, cuando se comenzó a crear el primer Airbus A380 en la fábrica, no puedo creer que si alguien quisiera 200 asientos más, esos se colocarían allí; pero en un gran proyecto de software, incluso después de que los programadores comenzaron el desarrollo, se pueden agregar 5 tipos más de usuarios.
  2. Complejidad : los grandes proyectos de software son extremadamente complejos; probablemente los proyectos más complejos diseñados y desarrollados por la humanidad;
  3. No se gastan suficientes recursos en la fase de arquitectura y diseño ;
  4. Inmadurez de campo : la ingeniería de software es una disciplina relativamente joven en comparación con otras hermanas de ingeniería; esto tiene dos implicaciones: a) No hay tantas heurísticas y buenas prácticas; b) No tantos especialistas con mucha experiencia;
  5. Falta de prueba matemática : en la mayoría de los casos, los métodos matemáticos formales no se utilizan para demostrar que un software funciona como se requiere; en su lugar se usa la prueba. Esto es válido en otros campos de ingeniería que dependen más de las matemáticas; la razón de esto es la complejidad;
  6. Acometida : muchos gerentes tienen plazos inalcanzables; entonces la calidad del código se coloca en segundo lugar, debido a la fecha límite.

Respondiendo estrictamente a la pregunta: tiendo a creer que otros tienen expectativas muy altas (especialmente en el tiempo de entrega) de los programadores y no entienden exactamente cuán difícil es programar un software grande.

m3th0dman
fuente
55
La prueba matemática formal en software, además del hecho de que a menudo es prácticamente imposible hacer lo correcto, no es más que escribir el programa dos veces (una en el lenguaje de programación real y otra en el lenguaje de especificación de prueba formal) y verificar que ambas Las versiones hacen exactamente lo mismo.
tdammers
55
tdammers, existen herramientas que pueden ayudarlo a escribir ambas cosas a la vez: Coq admite la "extracción de programas" para extraer un programa en OCaml o Scheme de un programa certificado de Coq.
jkff
66
"Cambio de requisitos después de iniciada la implementación". Yo llamo a esto el "problema de mover el baño". Usted está construyendo una casa, está dando los últimos toques al baño y el propietario quiere el inodoro en un lugar diferente. Les das el costo estimado. Se niegan, diciendo "¿por qué tanto, solo quiero el baño a 8 pies de distancia?". Luego, explica que debe instalar una nueva tubería, rasgar paredes / pisos, etc. para poder ir al baño. Los cambios tardíos siempre son caros.
The Lazy DBA
77
Yo diría que probar un avión es en realidad mucho más difícil que probar un software. Con el avión, toda la magia matemática que conjuraste resulta inútil cuando crees que el simulador de software o las turbinas eólicas que creaste realmente no reflejan la forma en que funcionan las cosas cuando estás allí. La prueba formal en software es solo un problema difícil, en comparación con la prueba formal en ingeniería que es imposible.
Lie Ryan
2
El n. ° 1 en su lista es la OMI más importante, le agregaría dos cosas más: -Se pueden hacer muchos cambios importantes en un corto período de tiempo (por ejemplo, '¡cambiemos el protocolo de comunicación!'), Eso no romperá nada a corto plazo, pero muchos de estos hacen que el proyecto sea muy difícil de administrar a largo plazo. - Los cambios en el entorno donde se ejecuta el software pueden cambiar drásticamente en poco tiempo. Si bien las premisas básicas para un avión se mantendrán igual (debe volar en tormentas, debe aterrizar en pistas sólidas, ...), un software puede romperse totalmente, por ejemplo, si sale la nueva versión del sistema operativo.
sydd
140

La premisa de la pregunta es un poco defectuosa. Tanto el A380 como el Boeing 787 fueron entregados con años de retraso.

En el caso del A380, gran parte del retraso fue causado por las unidades francesas y alemanas de Airbus que usaban versiones diferentes y ligeramente incompatibles del software de diseño CATIA . Esto se manifestó de manera incompatible como arneses de cableado que no se ajustaban bien al avión.

No hubo nada malo con CATIA, que es el software de diseño de aviones más utilizado, pero alguien en algún lugar dejó caer la bola de configuración del software.

El Boeing 787 también sufrió retrasos relacionados con el software, pero la mayoría de sus problemas fueron problemas de aviones nuevos más tradicionales, como el control de peso y la entrega de piezas de calidad inferior por parte de los proveedores.

Tanto el A380 como el B787 tuvieron que modificar sus diseños de ala después de que el avión inicial tuvo problemas estructurales.

Los grandes proyectos complejos son difíciles para los humanos en todos los campos.

Jim en Texas
fuente
10
Convenido. Creo que existe una falsa actitud de que el software se "produce más descuidadamente" que el material físico porque el software malo termina con soluciones que son muy visibles, además de que todos tienen que lidiar con software dañado. Si un avión es un pedazo de basura y tienen que hacer un trabajo en él, no lo devuelves, es solo algo de lo que los mecánicos se quejan entre sí en la mayoría de los casos, a menos que sea un gran defecto. Y eso también sucede.
Ben Brocka
66
Creo que la pregunta sigue en pie a pesar de que los ejemplos son defectuosos. Está estadísticamente probado que los proyectos de software tienen costos finales mucho mayores y tardan mucho más de lo previsto.
Eufórico
18
Cabe señalar que el diseño e implementación de un sistema de avión comercial inherentemente incluye la finalización de un proyecto de TI masivo y enormemente complicado, uno que tiene que ser completamente y correctamente funcional.
Puntiagudo
66
Y dado que el A380 tuvo un retiro importante tan reciente como 2010, no lo llamaría "perfecto" incluso entonces.
Muhammad Alkarouri
3
Además, MUCHOS aviones conceptuales han sido financiados y cancelados a lo largo de los años, particularmente contratos militares. Los aviones no son buenos ejemplos en absoluto, porque no escuchamos sobre muchas de las fallas (clasificadas) hasta muchos años o décadas después.
SilverbackNet
112

Rascacielos aquí. No estoy seguro si puedo responder a su pregunta, pero seguramente puedo arrojar algo de luz sobre varios elementos en el hilo. Los edificios de hecho ocurren muy rápido. Una limitación importante es la configuración regional (regulaciones). Pero, en general, un edificio alto tarda de 3 a 10 años de principio a fin.

Creo que comparar un nuevo edificio con un nuevo proyecto de software no es muy preciso. Un nuevo edificio está más cerca de una nueva versión de un núcleo o sistema operativo. A este respecto, el desarrollo de software es mucho más rápido. Nunca construimos desde cero, ya que esta será una tarea de alto riesgo para la que el cliente nunca se registraría. La mayor parte del diseño y desarrollo en edificios se deriva de proyectos probados y terminados.

Por experiencia personal, solo se construye uno de cada diez proyectos. El proceso se basa en el desarrollo y no en el diseño, por lo que en el momento en que sube el precio del acero, todo el proyecto se pierde o se diseña, ya que el diseño es el componente barato del proceso.

El diseño lleva un mes desde el concepto hasta el esquema, de dos a seis meses para el desarrollo del diseño, otros seis meses para los detalles y documentos de construcción por un equipo de arquitectos, consultores de planificación, ingenieros estructurales, ingenieros de viento, ingenieros de servicios, consultores de cantidad y costo, topógrafos, ingenieros de accesibilidad y la lista continúa ...

El argumento de virtual versus físico no es muy preciso. También trabajamos principalmente con herramientas virtuales y, además, estamos lejos del tiempo y de la escala de nuestro producto final. En la mayoría de los casos, ni siquiera podemos probar aspectos de edificios en escala de maquetas y usamos simulación para intentar predecir lo que puede suceder.

En cuanto a la complejidad, existen diferencias, pero en general es más o menos lo mismo. No solo tenemos unidades interrelacionadas y múltiples niveles de abstracciones escalonadas e interfaces, sino que también las personas están muy especializadas en pequeñas partes del proceso que dificultan la comunicación.

En cuanto al argumento de diseño versus desarrollo, creo que ambos procesos están construidos por diseño. Suena académicamente agradable mantenerlos separados, pero no es posible diseñar si no sabes cómo funcionan las cosas. Simplemente aumenta el riesgo de fracaso.

En general, mi estimación (potencialmente incorrecta) según la pregunta de OP es que la programación es más un arte que la ingeniería. ¿Por qué la gente se deleita e incluso lo hace gratis, encuentra expresión y elegancia en él? La informática también es (como en la lata) más ciencia que ingeniería. ¿Por qué tratarías de probar algoritmos en lugar de simplemente unir partes existentes y trabajar para que las cosas funcionen? No estoy seguro si esto tiene algún sentido; No soy un chico de software.

Un aspecto que me sorprende con el diseño y desarrollo de software es el medio en sí. Las computadoras hacen que el trabajo centrado en el ser humano sea muy poco natural. Todo es muy explícito y hay pocas tolerancias. Es difícil trabajar mentalmente para evitar esto, y algunos se salen con la suya volcando la complejidad. Si nada más, esto puede tener algo que ver con eso?

El constructor
fuente
2
+1 Gracias por la información. "diseñar si sabes cómo funcionan las cosas" -> "diseñar si no sabes cómo funcionan las cosas"?
tokland el
Hola constructor, sugerí algunas ediciones a esta publicación, creo que tienes excelentes puntos, solo intenté limpiar algo de gramática.
Steven
Definitivamente estoy de acuerdo con el punto de que la programación es más un arte que la ingeniería. A menudo encuentro la creatividad como un aspecto central en el diseño de software.
Lanzafame
1
No estoy de acuerdo con la afirmación de que un gran proyecto de software y una torre tienen una complejidad similar; según mi experiencia trabajando como ingeniero estructural y como ingeniero de software, diría que la complejidad del software es mucho mayor. Probablemente haya una serie de razones para esto, pero la que sugeriría es que hay mucho margen de maniobra en ingeniería; el límite superior del diseño de construcción casi siempre viene dado por el costo, y esa es una restricción suave. El software debe ser exacto , ya que las computadoras no manejan bien la ambigüedad. Losa no funciona? Agregue un montón de acero, ella tendrá razón.
Simon Robb
Algunas personas diseñan y construyen edificios por placer. No se lo digas a mi empleador, pero ahora que lo pienso, parte de mi software es como la Sagrada Familia: idiosincrásicos, demasiados adornos, nunca terminados; pero de diseño interesante, divertido de construir y usar y aún en pie.
Peter A. Schneider
44

Entonces, ¿cuánto tiempo llevó el diseño de esos? ¿Año? ¿Dos? ¿Diez años? El diseño es la parte más compleja de construir algo, la construcción en sí es fácil.

Con base en este artículo , se comprende lentamente que el desarrollo de software es principalmente un proceso de diseño donde el documento de diseño es el código fuente en sí. Y el proceso de diseño es totalmente diferente del proceso de producción. Requiere personas con experiencia y es imposible de planificar, ya que incluso pequeños cambios en los requisitos pueden dar lugar a grandes cambios en la arquitectura general del proyecto. Esta comprensión es la base de metodologías ágiles que se centran en mejorar la calidad del código como documento de diseño final y tomar las pruebas y la depuración como parte del proceso de diseño, al igual que prueban modelos de aviones en túneles de viento.

La construcción en sí es manejada automáticamente por los compiladores. Y gracias a eso, podemos construir productos completos en cuestión de minutos.

La razón por la cual los proyectos de software se terminan con grandes retrasos y costos inflados es porque los gerentes todavía piensan que pueden estimar, predecir y planificar un proceso de diseño de este tipo. Esto falla más de lo que en realidad es válido. Todavía piensan que al vincular a las personas en un proceso de construcción rígido, de alguna manera pueden aumentar la calidad, aunque el resultado final es mayormente opuesto con el aumento de los costos y los plazos vencidos.

Eufórico
fuente
2
"Esta comprensión es la base para metodologías ágiles". Exactamente. El método de cascada tiene sentido para los rascacielos: desea que cada detalle en el plano esté justo antes de verter la base. Pero si derribar y reconstruir rascacielos fuera gratuito y casi instantáneo, como lo es compilar código, probablemente usaría un proceso iterativo.
Nathan Long
22
@NathanLong: Especialmente si salieron con nuevas formas de concreto cada tres años, y alguien descubrió cómo se podían ejecutar múltiples ascensores en un solo eje, y de repente el acero ya no era genial y todos decidieron construir sus estructuras de carbono fibra. Cosas así suceden todo el tiempo en la industria del software.
TMN
2
"el desarrollo de software es principalmente un proceso de diseño en el que el documento de diseño es el código fuente en sí", me acaba de abrir los ojos. Gracias.
Bro Kevin D.
@ TMN Imagínese si al construir un rascacielos, cambiarían la paleta de colores del interior porque no se ve bien. Que se aplican a cualquier componente del edificio. Intentar hacer funcionar múltiples ascensores en un solo eje es una cosa, pero tendrías que probar 20 ascensores de diferentes proveedores antes de intentar conectarlos a todos al eje ...
Loïc Faure-Lacroix
@ LoïcFaure-Lacroix: los ingenieros podrían probar 20 ascensores diferentes, los desarrolladores simplemente usarían el descrito en la publicación del blog donde se enteraron por primera vez. Luego, cuando el edificio se abrió y hubo un problema con los ascensores, descubrieron que la compañía que los construyó ya no existía. Cuando intentaban obtener reemplazos de un proveedor diferente, descubrían que sus ascensores originales usaban un eje no estándar ...
TMN
39

Imagínese, en medio del diseño del Airbus A380, alguien habló en una reunión y dijo: "Heh, ¿podría construirlo como un triplano?" Otros se unieron para decir: "Sí, sí. Un triplano. Más alas son mejores". Los próximos tres años se dedican a convertir el diseño del A380 en un triplano. En otra reunión, alguien dice: "¿Un triplano? Eso es viejo. Queremos un biplano. Simplemente quite una de las alas".

O imagine, en medio de un proyecto de construcción de un puente, alguien dice: "Heh, acabamos de llegar a un acuerdo con una compañía naviera. Necesitan que el puente sea otros 40 pies más alto, porque sus barcos son mucho más altos. Arreglenlo. Gracias ".

Estas son solo algunas de las razones por las cuales los proyectos de software, grandes y pequeños, terminan en fracaso a un ritmo alarmante.

Kennah
fuente
8
Esto es exactamente lo que sucede. Los tipos de gestión o los clientes cambian de opinión cada 10 segundos, lo que frustra a los desarrolladores. Renuncié a mi último trabajo debido a una mierda como esta
Erin Drummond
3
Esto me viene a la mente: youtube.com/watch?v=BKorP55Aqvg&feature=kp
miraculixx
21

Como alguien con experiencia en ingeniería mecánica que trabaja en TI, a menudo me he preguntado las razones de la baja tasa de éxito en TI.

Como otros en este hilo, a menudo también he atribuido las fallas a la inmadurez de TI, la falta de estándares detallados (sí, lo digo en serio, ¿alguna vez has revisado la hoja estándar de un simple perno?) Y la falta de estandarización componentes y módulos.

Otras industrias, como la construcción de edificios o la construcción de barcos también tienen mucho más "caminos trillados": conocimiento y experiencia de un prototipo de solución particular, que, en forma personalizada, se reutiliza una y otra vez. ¿Alguna vez se preguntó por qué los edificios, barcos o aviones de diferentes tamaños y propósitos se parecen de alguna manera? (hay excepciones a la regla, por supuesto ...)

Eso es porque esos prototipos están bien investigados, bien entendidos, generalmente utilizados y tienen un historial probado. No porque no se pueda hacer de otra manera. En TI, la estandarización rara vez es el caso: ¡los proyectos (grandes) tienden a reinventar componentes, realizando investigaciones y entregas al mismo tiempo y con las mismas personas!

Estos inevitablemente conducen a productos únicos, que son caros de desarrollar y mantener, son propensos a errores y fallan de manera impredecible bajo condiciones inciertas. Y debido a esto, por supuesto, estos productos son mucho más rápidos y obsoletos, se escriben y se reemplazan a costos igualmente grandes por solo un poco mejores. Lo que necesita es el equivalente de la revolución industrial, que convirtió a los artesanos de mediana edad en fábricas eficientes.

Dicho esto, hay factores que hacen que la TI sea realmente única. A diferencia de esas otras industrias mencionadas, la TI es realmente omnipresente: se usa en todos los aspectos de nuestra vida moderna. Por lo tanto, es un pequeño milagro que TI haya logrado tanto progreso y sea capaz de entregar los resultados que logra.

Peter Mortensen
fuente
55
+1. Buen ejemplo para la estandarización (hoja estándar de un tornillo simple). En TI, son raros los componentes que están normalizados. Tome los formularios de inscripción: cada sitio web reinventar su propia, y pocos son los desarrolladores que saben cómo se comporta el formulario de inscripción con Unicode, con cadenas vacías, con cuerdas demasiado tiempo, etc.
Arseni Mourzenko
1
@MainMa: mal ejemplo, ¿creas tus botones, cuadros de texto, cuadros de opciones, cuadros de opciones de divs? No, reutiliza los elementos de formulario del navegador; y los navegadores usaron los elementos de formulario del sistema operativo.
Lie Ryan
44
Más bien estaba hablando de lo interno, no de los controles. Toma un sitio web al azar. ¿Puedes usar caracteres chinos para la contraseña? ¿Puedes usar contraseñas de 25 caracteres? ¿Qué sucederá si coloca un espacio en blanco en la contraseña o el nombre de usuario? Todo esto podría normalizarse, pero no lo es, y cada persona está reinventando la rueda para cada proyecto, a menudo mal, es decir, sin hash y / o salazón, o contraseñas limitadas a dieciséis caracteres (ejemplo: MSN), etc.
Arseni Mourzenko
44
Puede que no sea posible cambiar la TI de "artesanos" a "fábricas". Las fábricas están ejecutando un proceso que ya se ha creado. Los trabajadores en una fábrica ejecutan su proceso con poco o ningún pensamiento humano. Muchas fábricas han reemplazado a los humanos con robots debido a este hecho. En el software no está ejecutando un proceso, sino creando uno. Crear software sería más parecido a diseñar la fábrica y sus procesos en lugar de ejecutar la fábrica. Aunque la creación de software podría beneficiarse de los estándares, no puede convertirse fundamentalmente en una fábrica.
mike30
@ArseniMourzenko es una mala comparación comparar "hojas de datos para tornillos" (es decir, herramientas, equipos) con "estándares de formularios de registro". Los formularios de registro serían más como "un techo" o "una puerta de entrada" (de hecho, hay muchísimas maneras de hacerlos). Con lo que se compara un tornillo es más como el comportamiento de una tubería de procesador. No está cerca de lo que necesitamos: sistema operativo confiable (con características rigurosamente definidas, no "los datos pueden llegar al disco dependiendo de las opciones de montaje utilizadas") y las herramientas de desarrollo ídem (deben poder verificar el 90% del código para el estándar propiedades)
sehe
15

Me temo que no estoy de acuerdo con su declaración.

Airbus y Boeing son dos ejemplos de compañías que construyen aviones. ¿Cuántas compañías que construyen aviones hay? Muy pocos, si lo comparas con cuántas empresas crean software.

Es igualmente fácil atornillar un proyecto de avión que atornillar un proyecto de software. Si solo la barrera de entrada fuera tan baja en la industria de construcción de aeronaves como lo es en la industria del software, seguramente verá muchos proyectos de aeronaves fallidos.

Mira los carros; Hay fabricantes de alta calidad que fabrican automóviles muy duraderos y altamente avanzados (piense en Land Rover, Mercedes) y hay otros que construyen autos que no durarán un año sin tener que repararlos (piense en Kia o Cherry). Este es un ejemplo perfecto de una industria con una barrera de entrada ligeramente más baja, en la que comienzas a tener jugadores más débiles.

El software no es diferente. Tiene muchos productos defectuosos, por otro lado, Windows, Office, Linux, Chrome o Google Search son proyectos de muy alta calidad que se entregaron a tiempo y tenían un nivel de calidad similar al de un avión.

El otro punto que muchas personas pierden es cuánto mantenimiento se necesita para mantener un automóvil, un camión cisterna o un avión que simplemente tomamos como un hecho de la vida. Cada avión debe someterse a un chequeo técnico antes de cada despegue. Debe revisar su automóvil cada varias millas y hacer cosas regulares como cambiar el aceite, cambiar las llantas.

El software también lo necesita. Si solo la gente pasara tanto tiempo en el estado y la calidad del software de diagnóstico, prevención o auditoría como lo hacen con productos mecánicos / físicos, esperaría muchas menos declaraciones como estas. ¿Lees los registros de tu aplicación cada vez que la ejecutas? Bueno .. si fuera un avión tendrías que hacerlo ;-)

Karim Agha
fuente
55
Windows a menudo no se entregó a tiempo (Longhorn, también conocido como Windows Vista, originalmente se suponía que se enviaría en 2003). No sé acerca de Office, pero la mayoría de los otros proyectos de software que mencionó explícitamente no tienen líneas de tiempo, o su calendario de lanzamiento es tan frecuente que incluyen todas las características que están listas en el lanzamiento, y eliminan todo lo demás hasta que esté listo .
Ken Bloom
2
Este es un mejor ejemplo de software de alta calidad: 420,000 líneas y sin errores: el software que impulsó el transbordador espacial . Eso sí, hubo enormes costos asociados con la obtención de este tipo de calidad.
dodgy_coder
@dodgy_coder, construir un avión seguro tampoco es barato ;-)
Karim Agha
1
@PaulNathancente es muy subjetivo;)
James Khoury
3
@KarimA .: Construir un avión seguro no es barato, pero una gran parte de lo que hace que un avión sea seguro es el software ... ¡Así que una parte importante del diseño del avión es en realidad el diseño del software!
asombro
10

Los bloques de construcción digitales pueden ser 1 o 0. No hay intermedios.

Un diseño mecánico tiene un nivel de tolerancia. Puedo poner un remache menos que perfecto en un puente y lo más probable es que no se caiga, sin embargo, en el código, incluso una sola instancia de poner un 0 donde debería estar un 1 puede fallar en todo el programa.

Debido a la naturaleza lógica e interactiva de la informática, cualquier cambio, incluso muy pequeño, puede conducir a una falla drástica.

Ashpool
fuente
21
Una vez escuché a alguien decir: "La construcción sería como la programación si, al colocar el pomo de la puerta hacia atrás, toda la casa explotara".
Morgan Herlocker
9

A menudo me he preguntado lo mismo. Ciertamente se siente (ocasionalmente) que somos un grupo de aficionados que no tienen idea de lo que estamos haciendo. No me gustan las explicaciones que culpan a los gerentes u otros factores externos: los desarrolladores deberíamos ser responsables de lo que creamos.

Creo que estamos en un negocio donde los errores son baratos . El parcheo de software es barato, en comparación con la reconstrucción de un rascacielos o la recuperación de cada teléfono celular vendido.

Esto ha creado una cultura donde los errores son parte de la vida cotidiana . Son aceptados con un encogimiento de hombros. Si bien algunos errores son probablemente inevitables, ¿deberían dominar nuestro trabajo diario ? Entiendo completamente a los gerentes que no sienten que el control de calidad valga la pena, precisamente porque esperan errores de todos modos. No entiendo a los programadores que no hacen todo lo posible para producir código libre de errores, porque corregir errores es aburrido.

En esencia, creo que es un problema cultural, y espero que cambie.

Waxwing
fuente
55
¿Entiendes a los programadores que no hacen todo lo posible para producir un código libre de errores, porque eso tomaría el doble de tiempo y la administración está agotando sus cuellos para implementar estas nuevas características ayer?
Beta
44
¿No debería ser cierto también en otras industrias? No niego que no existan factores externos, pero creo que un cambio debe venir desde adentro. Si los ingenieros de software adoptaran su papel de expertos en su campo, sus recomendaciones y estimaciones serían respetadas y no cuestionadas por la gerencia. ¿O estoy siendo ingenuo?
Waxwing
2
A menudo me sorprende cuando ocasionalmente visito a un cliente y lo veo usar el producto que estoy programando. Hay errores y funcionalidades que hacen que su forma de trabajar sea muy difícil, y como programador, veo lo fácil que podría ser mucho mejor para el usuario, pero el usuario nunca se ha quejado, porque cree que no vale la pena molestarse. para denunciarlo
asombro
7

Las normas y prácticas de ingeniería son muy diferentes en TI (como industria independiente) que en aeroespacial . Quizás esto se entienda más fácilmente considerando cómo reaccionan los profesionales de TI cuando se encuentran con documentos estándar para TI en el sector aeroespacial . Por ejemplo, los estándares Joint Strike Fighter C ++ que se han abierto camino en Internet en los últimos tiempos.

Muchos expresan desconcierto o resignación melancólica (ojalá pudiéramos hacerlo de esa manera); y muchos responden con ridículo, alegando que no hay una forma práctica de entregar productos de consumo de esta manera. Esto incluso puede ser correcto, dadas las expectativas, no de los consumidores, sino de la administración. Hay una gran desconfianza para los codificadores que solo codifican y codifican durante algunas semanas, sin demoar nada. Dios ayude al programador que simplemente diseña algo por dos semanas. No es así con los aviones.

En software, la gente realmente espera tener algo en este momento. Claro, dice el razonamiento, tomará un poco de tiempo tenerlo realmente sólido; pero ¿no podemos describir algo complejo en términos simples en una semana? También se aprende que las cosas complejas descritas en términos honestos y complejos rara vez excitan la imaginación; y, por lo tanto, muchos ingenieros terminan siendo cómplices en un mundo imaginario de cosas realmente simples que se juntan de manera creativa (a diferencia de un mundo de cosas difíciles que se hacen realmente bien).

sólidos
fuente
5

Algunas cosas de mi parte:

1- Estándares y piezas: son fabricantes de aviones , no desarrolladores. No estoy completamente seguro, pero supongo que muchas partes se subcontratan. No construyen sus propios instrumentos electrónicos, obtienen asientos de alguna compañía, los motores probablemente se desarrollan en otros lugares, etc.

Los proyectos de software, por otro lado, casi siempre comienzan desde cero con solo algunos pequeños marcos / ayudantes en su lugar.

2- Tiempo para llegar al mercado: el tiempo no es un problema crítico para los aviones. Apuesto a que el diseño del Airbus se finalizó años antes de que se terminara, y decidieron descuidar cualquier avance importante que pudiera ocurrir en ese momento. (Lo mismo para los fabricantes de automóviles, por ejemplo, la tecnología de punta que desarrollan en este momento llegará a las calles en 5 a 10 años).

Para el software, debe ser muy ágil, si empiezo un gran proyecto ahora y me tomo tres años para desarrollarlo sin ningún cambio, las posibilidades son bastante altas de que cuente con tecnología que ya no está disponible o que mi producto está completamente desactualizado. Esto a su vez ofrece muchos problemas.

3- Ciclo de lanzamiento y versiones. - Un avión debe estar completamente terminado cuando se "libera". No hay versiones beta estables, compilaciones nocturnas o similares. Además, una vez hecho, solo se puede modificar de forma pequeña. No puede agregar un nivel adicional con 100 asientos a un boeing existente, simplemente no es posible.

El software, por otro lado, tiene cambios incrementales que a menudo son solo "compilaciones que funcionan", pero no necesariamente productos terminados. Además, en TI no es inusual decir "oye, agreguemos otro compartimiento de equipaje a nuestro avión que contiene 50 toneladas adicionales".

mapache
fuente
5

Creo que la respuesta es bastante simple:

1) La construcción física y la implementación han existido durante tanto tiempo como la gente: hemos tenido miles de años para desarrollar nuestros métodos y técnicas para implementar proyectos físicos. La 'construcción' del software, que requiere un conjunto de habilidades completamente nuevo y diferente, no tiene más de 50 años; todavía no hemos tenido suficiente tiempo para resolverlo.

2) La construcción virtual es más difícil: tienes que "ver" cosas en tu mente que no tienen realidad física alguna. Requiere que analices y resumas mucha información antes de siquiera saber cómo se supone que se verá tu producto y los pasos que tomará para crearlo. No es así cuando se construye un puente o un edificio.

3) A menudo es mucho más difícil encontrar la fuente de una falla o error de software que cuando se hace ingeniería física. Si una viga se dobla, ve dónde se dobla y ve los soportes que la sostienen y fallan, etc. Encontrar un defecto de software puede implicar examinar una gran cantidad de código y procesos de interacción: difícil, lento y no vinculado al leyes de física y matemáticas en la forma en que son las estructuras físicas.

Vector
fuente
4

Intentaré responder usando una copia literal de un artículo de la musa incrustada de Jack Ganssle. Si bien esto dice firmware en todas partes, solo reemplácelo mentalmente por software.

¿Comparado con que?

El firmware es lo más caro del universo. En su maravilloso libro "Las leyes de Agustín", Norman Augustine, ex CEO de Lockheed Martin, cuenta una historia reveladora sobre un problema encontrado por la comunidad de defensa. Un avión de combate de alto rendimiento es un delicado equilibrio de necesidades en conflicto: rango de combustible vs. rendimiento. Velocidad vs. peso. Parece que a finales de los años 70 los luchadores eran casi tan pesados ​​como siempre. Los contratistas, que siempre buscaban mayores ganancias, buscaron en vano algo que pudieran agregar que costara mucho, pero que no pesaba nada.

La respuesta: firmware. Costo infinito, masa cero. La aviónica ahora representa más de la mitad del costo de un luchador. Eso es una gran parte de cambio cuando consideras que el último luchador estadounidense, el F-22, cuesta un tercio de mil millones por pop. Agustín prácticamente se ríe alegremente cuando relata esta historia.

Pero, ¿por qué el software es tan caro? Tom DeMarco respondió una vez a esta pregunta con estas tres palabras: ¿en comparación con qué? Continuó discutiendo casos de negocios relativamente aburridos, pero esa respuesta ha resonado en mi mente durante años. ¿Comparado con que? Con el software, creamos rutinariamente comportamientos de productos de complejidad sin precedentes. Claro, el código es caro. Pero nunca en la historia de la civilización alguien ha construido algo tan intrincado.

Considere el siguiente tipo de burbuja, levantado descaradamente de Wikipedia y sin verificar su precisión:

void bubblesort(int * A, int n){

    for(int i(0); i < n; ++i)

        for(int j(0); j < n - i - 1; ++j)

            if(A[j] > A[j + 1])

                std::swap(A[j], A[j + 1]);

}

Son solo 110 personajes no espaciales, quizás lanzados en una o dos horas. Supongamos que no tenemos software y tenemos que implementar un tipo utilizando alguna otra estrategia. ¿Cuánto costaría?

Un ingeniero mecánico podría jactarse de que su profesión construyó clasificadores mucho antes que las computadoras. Considere el clasificador de tarjetas modelo 82 de la era de 1949 de IBM ( http://www.columbia.edu/acis/history/sorter.html ) con un rendimiento de 650 tarjetas por minuto, bastante menos de lo que nuestro fragmento de código podría administrar incluso en un 4 MHz Z80. El modelo 82, por supuesto, solo clasificó una columna de una tarjeta a la vez; ordenar completamente un mazo podría tomar docenas de pases.

¿Cuánto tiempo llevó diseñar y construir esta bestia? Años, sin duda. Y su funcionalidad palidece en comparación con nuestro código, que es mucho más rápido y que puede manejar conjuntos de datos gigantes. Pero eso fue en 1949. ¿Cuánto tiempo tomaría construir una especie de burbuja a partir de componentes electrónicos, sin FPGA y VHDL, o una CPU?

En una hora logré un diagrama de bloques aproximado, uno por encima del nivel del chip (los bloques tienen nombres como "sumador", "bloqueo de 16 bits" y similares). Pero la lógica de secuenciación es claramente bastante complicada, así que acabo de incluir un PLD, asumiendo que en algún momento no sería demasiado difícil escribir las ecuaciones apropiadas. Y, sí, tal vez eso rompa la regla de la lógica no programable, pero diseñar y depurar toda esa lógica usando puertas en un período de tiempo razonable es tan improbable como el gas de un galón.

Suponiendo palabras y direcciones de 16 bits, el circuito necesitará alrededor de una docena de pestillos de 16 bits, sumadores y similares. Más memoria. Y no tengo idea de cómo llegan los datos sin clasificar a la RAM o cómo se exportan los resultados. Esos son requisitos de diseño no especificados. La solución solo de software resuelve naturalmente estos requisitos simplemente con el acto de escribir el prototipo de la función.

Traducir el diagrama de bloques aproximado a un esquema puede llevar un día. Luego está el momento de diseñar y producir una PCB, ordenar y cargar piezas (y cambiar el diseño para hacer frente a los problemas inesperados pero inevitables de final de la vida útil), y luego, por supuesto, hacer que el circuito funcione. Podríamos estar hablando de semanas de esfuerzo y mucho dinero para el tablero, las piezas y el equipo de prueba apropiado.

Todo esto para reemplazar 7 pequeñas líneas de código. Pocos programas integrados reales son menos de 10,000; muchos superan el millón. ¿Cuánto hardware y cuánta ingeniería se necesitaría para reemplazar un programa de computadora real y de gran tamaño?

Considere un programa real como una hoja de cálculo. ¿Cuántos circuitos se necesitarían para hacer uno sin un procesador? Podría ser del tamaño de una ciudad.

El firmware es la cosa más cara del universo, pero solo debido a la complejidad inimaginable de los problemas que resuelve. Pero es mucho más barato que cualquier otra alternativa. Entonces, cuando su jefe le pregunta irritadamente por qué el software lleva tanto tiempo, usted sabe qué decir. ¿Comparado con que?

¡Por lo tanto, allí! El software / firmware tiene una complejidad sin igual.

Vaibhav Garg
fuente
3

La ingeniería y gestión de software es fundamentalmente diferente a muchas otras áreas de ingeniería. Los entregables no son físicos, y el proceso de producción es el proceso de diseño y desarrollo. Crear otra copia de una pieza de software tiene esencialmente un costo marginal cero; Todo el costo se encuentra en el desarrollo de la primera copia.

Debido a la relativa juventud de la ingeniería y la gestión de software como disciplina, existe cierta información errónea y falsedades que todavía se toman como un hecho ( ver esta referencia ) que dificulta el desarrollo de software y la ingeniería en general.

joshin4colours
fuente
3
+1 sobre la inmadurez del desarrollo de software. La Ingeniería Civil ha tenido un par de miles de años para desarrollar sus prácticas. El sector aeroespacial ha tenido un centenar y se basa en otras disciplinas de ingeniería. El software aún es joven. También normalmente se entiende mal. Las personas pueden construir puentes sobre las corrientes o hacer aviones de papel cuando son niños: lo mismo no es realmente cierto para el software.
Andy Burns
3

No todos los desarrolladores se crean por igual. Algunos son buenos, otros, bueno, no.

Intenta leer el código de otras personas todo el tiempo para tener una idea de lo que estoy diciendo. Demasiadas declaraciones lógicas adicionales pueden agregar riesgo. Estos riesgos pueden conducir a mal comportamiento o errores. No hay suficientes declaraciones lógicas y ahora tiene referencias nulas. El buen programador entiende esto y sabe cuándo hacer qué y dónde. Pero nadie es perfecto. Las cosas son complejas. Agregue el trabajo mal pensado de los demás y es fácil ver cómo se ejecutan los proyectos.

El duque
fuente
3

Las catedrales solían tardar hasta 100 años en construirse.

Algunos aviones Airbus necesitan 1 millón de líneas de código para funcionar.

Cuanto más tiempo haya estado mejorando algo, más mejoras obtendrá, así que dele a la industria del software un par de siglos de prueba-error para mejorar, y veremos cuánto se necesita para desarrollar un gran proyecto sólido sin errores. o defectos.

NotGaeL
fuente
La catedral de Colonia se inició en 1248 y terminó en 1880. 632 años.
gnasher729
3

Los grandes proyectos a menudo ocurren en grandes organizaciones. Si nunca ha trabajado en una organización grande, hay una cosa que garantiza que mata el rendimiento y la productividad: la burocracia.

Sorprendentemente, muchas personas no saben qué es la burocracia (a menudo se confunde con la política), o incluso si tienen un problema de burocracia.

Recientemente concluimos un proyecto para implementar la autenticación con tarjeta inteligente. Originalmente se estimó en tres meses. Tomó 15 meses. No hubo ningún costo, presupuesto, alcance o razones técnicas para la demora. El alcance era en realidad bastante limitado, solo para cuentas con privilegios elevados (cuentas de administrador), alrededor de 1.200 cuentas en total.

Otro factor importante son sus socios comerciales. Esto incluiría vendedores. Si sus socios tienen un problema que introduce un retraso en su proyecto, no hay muchas opciones que realmente solucionen el problema del retraso. No funcionan directamente para usted, y es posible que no pueda despedir a esa persona a una pareja que puede ser la causa. El socio puede ser despedido o puede estar sujeto a sanciones financieras o desincentivos, pero eso no cambia el hecho de que el proyecto haya sufrido un retraso. Esto es precisamente lo que ocurrió con Boeing cuando emprendieron una estrategia de abastecimiento gigantesco con el Boeing 787 Dreamliner .

Greg Askew
fuente
3

Tengo una versión más corta para ti:

Sea lo que sea fácil de hacer o simplificado, escribimos un programa para hacerlo en lugar de nosotros.

Y luego luchar con el metaproceso en su lugar.

No es tan cierto, per se, pero todos los días se crean miles de blogs, en lugar de escribir motores de blog. Cada día laboral, se escriben miles de macros de Excel, en lugar de escribir aplicaciones de bases de datos especialmente diseñadas para estos.

Hay muchos otros factores, algunos de ellos mencionados aquí, pero quería agregar este punto a la discusión.

Aadaam
fuente
Estoy de acuerdo. Los programas grandes se pueden entregar sin problemas y a tiempo, ya que se han realizado cientos de veces durante 3 décadas. Por ejemplo, un editor de texto.
Droogans
No solo eso, sino la forma en que entregamos programas grandes sin problemas que se han hecho antes, es simplemente descargar el viejo programa de su sitio web y hacer una copia. Pero por alguna razón eso no cuenta como un gran proyecto de software exitoso.
bdsl
3

Falta de responsabilidad ... Las personas son demandadas cuando un avión se estrella. La industria del software declina cualquier responsabilidad en cualquier defecto de software, creando así una falta de incentivos para crear un producto robusto y seguro.

GreyGeek
fuente
1
Lo he estado diciendo por mucho tiempo. Si fue demandado cuando su aplicación se bloqueó, el código sería mucho más robusto ... Y hay muchas compañías a las que me gustaría demandar, por ejemplo, MS: cuántas horas se pierden debido a todas sus actualizaciones y parches y errores y revisiones que rompen otras cosas. Demandelos por esas horas perdidas y la calidad aumentará RÁPIDAMENTE.
Vector
Si ese fuera el caso, el costo aumentaría y las características disminuirían.
Jim G.
1
@JimG. La pregunta era sobre la fiabilidad, no la función ni el precio. Por supuesto, tener que hacer un producto más confiable introducirá más restricciones en su espacio de diseño y otros aspectos (características y costos) podrían verse afectados.
GreyGeek
44
Y el costo de un Boeing 737 es de $ 50-80 millones. Paga cada vez que se sube a uno: ¿paga cada vez que abre Office? Si me pagaran cada vez que alguien usara mi software directamente, estaría dedicado a la confiabilidad.
FlavorScape
1
@Jim G: Preferiría tener 1 versión estable de un producto en lugar de tener 5 cutres.
Giorgio
2

La mayoría de los proyectos grandes tienen un alto grado de separabilidad de los subproyectos, donde puede definir una pequeña cantidad de restricciones de diseño; todo el proyecto funcionará cuando se completen esos subproyectos. Si algo sale mal en un subproyecto, no se cuestiona todo el esfuerzo; solo busca formas alternativas de completar el subproyecto (por ejemplo, use un motor diferente).

Esto es posible pero difícil, tanto en la práctica como en la naturaleza humana, en proyectos de software.

En parte, otras industrias han aprendido por las malas que este tipo de separabilidad es algo bueno. Por ejemplo, si va a usar motores de avión Rolls Royce, no necesita usar pernos especiales Rolls Royce y puntos de fijación que solo funcionan con alas con un diseño particular, y luego si intenta cambiar a Pratt y Whitney, tiene que rediseñar todo su ala desde cero (lo que, a su vez, requiere un rediseño completo del fuselaje, lo que a su vez requiere que compre diferentes asientos, lo que a su vez requiere que compre un sistema de entretenimiento en vuelo diferente, cual...). Puede haber algunos vínculos, no puede simplemente cambiar los motores sin un cuidado, pero los grandes proyectos generalmente funcionan mejor cuando se minimizan esas cosas.

Supongo que los grandes proyectos de software diseñados como un grupo de pequeños proyectos de software con interfaces limpias entre sí no fallarán particularmente a menudo, siempre que el gran proyecto sea resuelto por el grupo de pequeños proyectos. (Es posible cometer un error a este respecto).

Rex Kerr
fuente
2

Construir sistemas de software es muy diferente de construir estructuras físicas. Es decir, la implementación es muy diferente. Si bien, por ejemplo, construye un enorme camión cisterna, realiza muchas tareas relativamente simples (¡aunque no fáciles!), Como soldar piezas con un robot o con la mano, apretar todas las tuercas y tornillos, pintar, hacer la decoración llevando todo los equipos y muebles y tal. Todo esto es algo muy simple de hacer, de verdad.

Sin embargo, cuando se trata de software, se vuelve mucho más complejo . Por ejemplo, ¿cómo implementa exactamente el inicio de sesión seguro y la credencial de usuario que almacena parte del producto? ¿Qué bibliotecas y herramientas puedes usar? ¿Con qué bibliotecas y herramientas está familiarizado? ¿Cómo hace exactamente para escribir la función hash + salado y cómo se asegura de que sea segura? Puede hacer esto de tantas maneras que es imposible establecer patrones de diseño prácticos reales para este tipo de cosas. Sí, dichos patrones de diseño no existen en menor escala como "mejores prácticas", pero cada único sistema de software es muy diferente de los demás, y los avances sobre el terreno y los cambios en el ritmo tan rápido que es esencialmente imposible para mantenerse al día.

Al construir una casa, realmente no te encuentras con problemas en los que te das cuenta de que las paredes de soporte principales parecen ser inadecuadas y necesitan ser reemplazadas, lo que requiere demoler el progreso hasta ahora y comenzar desde la base rehaciendo las paredes de soporte . Enfrenta tales problemas en la fase de diseño , porque es relativamente simple predecir qué tipo de muros de soporte necesita su edificio.

Sin embargo, ese no es el caso con el software. Realmente no se puede diseñar todo el producto como una sola entidad y luego implementarlo. El proceso de diseño de software suele ser iterativo y los objetivos y requisitos cambian a medida que el producto se implementa y se prueba. El desarrollo de software en su conjunto es un proceso iterativo en el que las cosas generalmente cambian cuando menos se espera, y muchas veces dichos cambios imponen desafíos que requieren más trabajo, más complejidad y, desafortunadamente y, en última instancia, más dinero, tiempo y trabajo duro para hacerlo bien.

Entonces, en esencia, la razón por la cual es difícil entregar grandes proyectos y estimar cronogramas y hojas de ruta de proyectos es que el desarrollo de software y especialmente el diseño de trabajo son campos muy complejos . La complejidad es la raíz del problema.

zxcdw
fuente
+1, y para llevar la idea más allá, es un fracaso apreciar la complejidad de las personas fuera de la industria que conduce a expectativas poco realistas, políticas irracionales y diseños extravagantes. El sector público en el Reino Unido es un ejemplo perfecto. Para un edificio público, digamos, la gerencia trata de obtener el diseño perfecto con la opinión de expertos, consultas extensas y planificación de proyectos a prueba de agua antes de cortar el césped. Pero ponga a las mismas personas frente a un nuevo sistema de TI y verá cambios de último minuto en los requisitos, el esquema de base de datos, la interfaz de usuario ... "¿qué tan difícil puede ser? Es solo un poco de escritura"
Julia Hayward,
1

La definición de "gran proyecto" es sesgada.

Un gran proyecto, técnicamente, puede entregarse a tiempo, y sin problemas, siempre y cuando sea algo que se ha construido muchas, muchas veces a lo largo de los años.

  • Un clon de Pac-Man.
  • Una calculadora
  • Un editor de texto

Estoy seguro de que estás pensando ... "¡pero esos son proyectos pequeños ! Un editor de texto es simple ". No estaría de acuerdo contigo. Las computadoras son escandalosamente complicadas. Solo instalar y configurar usuarios en un sistema operativo puede ser difícil a veces, y ni siquiera escribiste el sistema operativo, ni construiste el hardware.

Los proyectos de los que habla son proyectos enormes , similares a la exploración espacial. ¿Cómo sabes cuánto tiempo lleva desarrollar un viaje intergaláctico? ¿En qué modelo lo basamos? Usted tiene los conocimientos conocidos, las incógnitas conocidas, los conocimientos desconocidos y, finalmente, las incógnitas desconocidas, que surgen mucho en el desarrollo de software.

Creo que el problema es de expectativa. El hecho de que la tecnología esté allí no significa que su uso sea exitoso (o prudente) por un tiempo. Si otras industrias se comportaran como lo hicieron las industrias de software, para fines de la década tendríamos a la venta aspiradoras alimentadas con agujeros negros. O algún "visionario" tendría los recursos para construir una base lunar y decidiría que un Starbucks realmente "completaría" la experiencia para los visitantes. No creo que el problema sea la industria del software, pero las expectativas puestas en él.

Droogans
fuente
¿Aspiradoras con agujeros negros? ¿Qué pasa con la seguridad funcional?
Peter Mortensen
¿Falta de seguridad funcional? Es una característica! Recomendamos el uso de estructuras inmutables cuando intente limpiar algo con la aspiradora de agujeros negros.
Droogans
1

Aunque no es lo único que se puede mencionar, creo que vale la pena señalar una cosa básica. La mayoría de los productos están diseñados para adaptarse al comportamiento existente. Incluso un producto que es un avance radical (por ejemplo, el automóvil) generalmente está diseñado para adaptarse al comportamiento existente, y simplemente lo hace un poco más simple / más fácil / más barato / lo que sea que haga eso. Sí, a menudo también hay algún efecto secundario en el comportamiento existente (por ejemplo, obtener combustible para el automóvil en lugar de comida para los caballos), pero la mayoría de estos últimos tiende a ser un efecto secundario bastante menor.

Por el contrario, casi cualquier software que no cambia el comportamiento de los usuarios (por ejemplo, les permite hacer su trabajo considerablemente más fácilmente) está garantizado básicamente como un fracaso completo desde el día 1. Peor, los grandes proyectos de software no solo implican el comportamiento de los usuarios a nivel individual, pero el comportamiento de grupos grandes, a menudo la totalidad de la organización.

En resumen, el diseño del software en sí es a menudo la parte más fácil del trabajo. La parte difícil es rediseñar los trabajos de las personas para ellos. Eso es difícil de comenzar; hacerlo de una manera que no solo funcione, sino que también sea aceptado, es mucho más difícil aún.

Jerry Coffin
fuente
1

Airbus A380 no fue un proyecto exitoso como usted ha mencionado. Trabajo en una empresa CAD / CAM, y me dijeron que (teníamos el proyecto Airbus también) se retrasó unos años, porque estaban usando diferentes versiones de software en diferentes empresas. Es decir, se diseñaron diferentes partes en diferentes partes del mundo. Y mientras integraban, llegaron a saber que todo el diseño no podía integrarse, por lo que deben rediseñarlo en una versión. Mirándolo, no creo que haya sido exitoso. Si hubiera llegado 2-3 años antes, habría sido un cambio de juego para Airbus.

También con respecto al software robusto, si observa cualquier avión, automóvil (ABS, EPS, control de clima, etc.) o transbordador espacial, tienen más del 50% de software que los está ejecutando y creo que son muy robustos. Es solo que estamos más cerca del software, y hay muchos más programas de software, por lo que vemos más errores en ellos.

Visite: http://www.globalprojectstrategy.com/lessons/case.php?id=23 y vea cuánto éxito tuvo Airbus A380.

Peter Mortensen
fuente
1

Ingeniero de software aquí, con experiencia en ingeniería, y una esposa que trabaja en la construcción. Hemos tenido largas discusiones (y argumentos) sobre las diferencias de nuestros trabajos.

La ingeniería de software se trata de diseñar cosas nuevas . Casi todo lo básico se ha hecho en una biblioteca de código abierto en alguna parte. En casi cualquier trabajo donde se contrata a un ingeniero de software, tiene que diseñar algo que no existe.

En algo como la construcción y la mayoría de las formas de ingeniería, las cosas que de otro modo estarían en una 'biblioteca' de software ya están completamente diseñadas. ¿Quieres construir una torre? Simplemente copie y pegue los planos de una estructura existente, con algunas modificaciones.

De hecho, una de las principales razones por las que decidí no convertirme en ingeniero es que pasas la mayor parte de tu tiempo diseñando una mejora del 10% para una invención existente, cuando ese mismo tiempo podría usarse para programar algo más visible, como una red social .

No hay muchos diseños nuevos en ingeniería; Un ingeniero extremadamente experto es alguien que puede manipular un diseño existente en algo nuevo o mejorarlo. Pero se espera que casi todos los programadores modifiquen diseños, los piratee o creen algo nuevo.

Mire hacia atrás hasta qué punto los estándares han cambiado por completo, desde el ensamblaje a C a C ++ a Java, JavaScript, C #, PHP, etc. No hay mucho código que pueda reciclarse de hace 10 o 20 años. Esto es muy diferente de decir ... la industria automotriz o aeronáutica cuando puedes seguir mejorando diseños desde hace décadas.

La gestión de proyectos es notoriamente difícil en software . Las personas que realizan el trabajo realizan mejor las estimaciones de tiempo , pero cuando están ocupadas haciendo estimaciones, no escriben código . Esto tienta a las personas a evitar cualquier gestión de proyectos.

A menudo, una gran cantidad de código depende de personas específicas, y si estas personas llegan tarde o no pueden realizarlo, el código no avanza. Por el contrario, si desea construir un automóvil, simplemente puede contratar a diferentes personas para ensamblar los neumáticos, el chasis, la batería, el motor, etc. Los marcos existentes y orientados a objetos lo hacen posible, pero puede no ser práctico cuando se diseña todo desde cero.

Se pueden permitir fallas en el software . Las pruebas pueden ser costosas. En el software, es muy tentador omitir todas esas pruebas, cuando puede solucionar un bloqueo. En la mayoría de las formas de ingeniería, un "choque" puede ser fatal.

Tiene métodos de programación que utilizan pruebas exhaustivas, como la programación extrema (que en realidad se utilizó en megaproyectos de software). Pero con plazos ajustados (que se pueden hacer más estrictos a propósito), es tentador omitir toda esa programación y lanzar errores. El estilo de Joel Spolsky de "siempre arreglando todos los errores" ahorrará más tiempo a largo plazo, pero los indisciplinados se saltearán esto y fracasarán.

Los proyectos pequeños son mejores . Mi esposa una vez me pidió que consiguiera un trabajo en una gran empresa. Terminó en un argumento de que las grandes compañías son malas compañías ... para ella, una gran compañía tenía muchos recursos, experiencia, gestión funcional de proyectos y los procedimientos correctos. Para mí, una gran empresa es un dinosaurio, donde dedica la mayor parte de su tiempo a arreglar el código, probarlo y documentarlo.

He visto proyectos de TI de millones de dólares trabajados por menos de 10 personas. Más personas habrían frenado el proyecto y agregado burocracia innecesaria. WhatsApp es un ejemplo de un proyecto 'pequeño' que vale miles de millones de dólares. No es que los grandes proyectos no sean posibles, pero simplemente no necesita miles de personas para producir miles de millones de dólares en software.

Muz
fuente
0

Una razón que no se ha cubierto realmente en las otras preguntas es que el campo del software innova a una velocidad que ocurre muy raramente en el mundo basado en materiales.

Una razón para esto es que la evolución del software es un ciclo de retroalimentación positiva porque el software (lenguajes de programación, herramientas de construcción, IDE) se utiliza para construir software. Es el ejemplo más obvio de la ley de Ray Kurzweil de rendimientos acelerados, lo que resulta en un progreso a una velocidad de crecimiento exponencial. Una vez que haya dominado un marco, un lenguaje de programación y un protocolo de comunicación, es hora de pasar al siguiente.

Si los aviones se construyeran como un software, estaríamos cambiando el material con cualquier otro modelo, duplicando su capacidad y velocidad cada 18 meses, reemplazando la tecnología del motor para cada nuevo modelo con algo recién inventado, mientras agregamos la capacidad de nadar y buscar extraterrestres vida.

Ah, e idealmente, escucha los comandos de voz y funciona como una sala de cine completamente inmersiva, un estadio de paintball y un club nocturno con cuarto oscuro una vez que termina su viaje de trabajo. ¡La misma cosa! (La compañía que construyó aviones que lo llevó de manera confiable de A a B se vino abajo un año después de que apareciera la de cine, paintball y club nocturno).

Peter A. Schneider
fuente
No entiendo tu punto. Primero, muchos idiomas son bastante antiguos. Java tiene más de veinte años. Python tiene casi treinta años. Sí, hay nuevos idiomas, pero no es como si todos abandonáramos un idioma para pasar a uno nuevo cada dos años. Si bien la adopción de un nuevo marco, IDE o lenguaje puede ser un factor de lentitud para un equipo, tampoco encuentro los que usan herramientas familiares particularmente rápido. ¿Y la industria aeronáutica? Los aviones como Boeing 787 tienen muchas cosas nuevas que fueron difíciles de implementar.
Arseni Mourzenko
@ArseniMourzenko Bueno, Java estaba de moda para la programación de clientes web después de que salió y para la construcción de GUI cuando salió el swing, pero ambas modas duraron solo unos pocos años. Diablos, no hubo WWW antes de la década de 1990. La programación web es donde estaban los aviones en 1910 más o menos. Pero este ritmo está en curso.
Peter A. Schneider
-1

Para mí, el principal problema que enfrentan los ingenieros de software son los casos de uso, el usuario y las plataformas cruzadas.

Casos de uso

¿Cuántos casos de uso tiene un avión? La mayor parte es solo para volar de un lugar a otro. Tal vez hay más como radar, control de tráfico, etc., pero el caso de uso es claro y no mucho. En ingeniería de software, nos enfrentamos con requisitos poco claros y usuarios que no saben lo que quieren. Diferentes usuarios necesitan diferentes configuraciones / flujos, ¿se puede personalizar un avión como lo desee el usuario (quiero tener televisión y refrigerador)?

Usuario

¿Quién opera un avión? Un piloto, un copiloto, algunos mayordomos (si se cuentan) y operadores de torres. Todos son profesionales y tienen claras las descripciones de sus trabajos. Los novatos y los tontos utilizan el software, sin mencionar los piratas informáticos y los piratas informáticos malvados, aunque aún deben integrarse con otros módulos (como OpenID o Google AdSense ). Si un avión puede ser operado por tontos mientras aún sobrevive de misiles o ladrones ninja, entonces puede decir que el avión tiene la misma calidad con el software.

Plataformas cruzadas

Un avión vuela solo en el cielo de la tierra. No estoy seguro de cómo manejan el clima brumoso o ventoso o cálido, frío y húmedo, pero un avión no está diseñado para volar a diferentes niveles de gravitación (me sorprenderá si puede volar a Marte ). A veces, una aplicación debe sobrevivir a diferentes plataformas, como Internet Explorer, Google Chrome , Firefox y Safari para el navegador (lo siento, Opera ), o Windows XP / 7/8, o Linux para el nivel del sistema operativo. Sin mencionar los dispositivos móviles y diferentes resoluciones y orientaciones.

Fendy
fuente
-1

Si cree que otras industrias completan proyectos sin incidentes, debería leer la historia sobre el edificio del Citigroup Center construido en 1977. Incluso después de casi 7 años de planificación y construcción, el edificio se completó con un grave defecto de diseño que habría causado un colapso de un tormenta se espera cada 16 años.

En otras palabras, por cada año que el Citicorp Center estaba de pie, había una probabilidad de 1 en 16 de colapsar.

Los diseñadores originales no estaban al tanto de los problemas, pero afortunadamente fue atrapado por un estudiante que estudiaba el edificio.

todo parecía estar bien, hasta que, como LeMessurier lo cuenta, recibió una llamada telefónica. Según LeMessurier, en 1978 un estudiante universitario de arquitectura lo contactó con una afirmación audaz sobre el edificio de LeMessurier: que el Centro Citicorp podría volar por el viento.

Las reparaciones se hicieron literalmente al principio de la noche, involucrando a la menor cantidad de personas para mantener el secreto de la falla de diseño.

Se preparó un plan de evacuación de emergencia para el radio de 10 bloques que rodea el edificio.

Soldaron durante toda la noche y renunciaron al amanecer, justo cuando los ocupantes del edificio volvían a trabajar.

La historia permaneció en secreto hasta que el escritor Joe Morgenstern escuchó que se contaba en una fiesta y entrevistó a LeMessurier. Morgenstern reveló la historia en The New Yorker en 1995.

Lo que plantea la pregunta; cuántos otros defectos de diseño fatales en proyectos fueron reparados o ignorados en secreto sin reconocimiento público.

cmcginty
fuente