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

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?

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.

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.

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.

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.

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?

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.

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.

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.

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 ;-)

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.

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.

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).

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".

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.

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.

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.

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.

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.

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 .

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.

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.

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).

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.

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.

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.

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.

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.

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).

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.

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.

• La falla de diseño que casi aniquiló un rascacielos de Nueva York (slate.com)
• Citigroup Center (wikipedia.com)