it-swarm-es.com

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

Después de ver National Geographic's serie MegaStructures , 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 en sí de grandes proyectos lleva solo unos pocos años o, a veces, algunos meses .

Por ejemplo, Airbus A38"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 de 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 proyecto y aumentará el riesgo de no terminarlo en absoluto).

Los que aún se entregan a menudo contienen 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 a fin de ofrecer productos a gran escala y casi sin fallas muy rápido?

515
Arseni Mourzenko

Ed Yourdon's Death March toca varias de estas preguntas de metatipo.

En general, la industria del software carece de lo siguiente, 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 aún 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 avión grande que Airbus construyó. Existen muchas aplicaciones de software grandes, pero muchas de ellas han sufrido drásticamente en algún aspecto u otro y no estarían cerca de 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 , ... anuncia de nuevo a AT&T Sistema 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 me refiero a ser todo negativo, y creo que la industria del software ha avanzado mucho 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.

338
user53019

La respuesta es sorprendentemente simple: esas 'otras industrias' do tienen una alta tasa de fallas. 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é estamos haciendo 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.

457
Danny Woods

Para señalar algunas cifras:

  1. Cambio de requisitos después de comenzar 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 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. Rush - 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 gran software.

182
m3th0dman

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 usando versiones diferentes y ligeramente incompatibles de CATIA software de diseño. 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 aeronaves 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.

142
Jim In Texas

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 tratar de 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 bien mantenerlos separados, pero no es posible diseñarlos 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?

114
The builder

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í misma es fácil.

Basado en este artículo , se está entendiendo lentamente, que el desarrollo de software es principalmente un proceso de diseño donde el documento de diseño es el código fuente mismo. 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 para metodologías ágiles que se enfocan en mejorar la calidad del código como el 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 dicho proceso de diseño. 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.

45
Euphoric

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 gastan convirtiendo 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 tenga otros 40 pies de altura, 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.

41
Kennah

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 de alguna manera se parecen tanto? (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 unos ligeramente 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, sin embargo, 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 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.

21
pub ny

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 aviones como lo es en la industria del software, seguramente verá muchos proyectos de aviones fallidos.

Mira los carros; Hay fabricantes de alta calidad que fabrican automóviles muy duraderos y muy 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 implica 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 ;-)

16
Karim Agha

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.

11
Ashpool

A menudo me he preguntado lo mismo. Ciertamente se siente (ocasionalmente) como si fuéramos 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.

9
waxwing

Los estándares y prácticas de ingeniería son muy diferentes en TI (como industria independiente) que en aeroespacial . Quizás esto sea más fácil de entender si se considera cómo reaccionan los profesionales de TI al encontrar documentos estándar para TI en el sector aeroespacial . Por ejemplo, los Estándares Joint Strike Fighter C++ que han recorrido 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 tener algo complejo descrito 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).

7
solidsnack

Algunas cosas de mi parte:

1- Estándares y partes: son planos fabricantes, no desarrolladores. No estoy del todo 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 marcos/ayudantes pequeños 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-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 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 "hey, agreguemos otro compartimiento de equipaje a nuestro avión que contiene 50 toneladas adicionales".

5
racoonie

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 la física y las matemáticas en la forma en que son las estructuras físicas.

5
Vector

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 qué?

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 verificación de 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 que nuestro fragmento de código podría manejar incluso en un Z80 de 4 MHz. 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 desordenada, 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 al 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 por el acto de escribir El prototipo de la función.

La traducción del 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 qué?

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

4
Vaibhav Garg

Los grandes proyectos a menudo ocurren en grandes organizaciones. Si nunca ha trabajado en una organización grande, hay una cosa que está garantizada para matar 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 Boeing 787 Dreamliner .

3
Greg Askew

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.

3
Aadaam

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 del software como disciplina, existe cierta información errónea y falsedades que todavía se toman como hechos ( ver esta referencia ) que dificulta el desarrollo del software y la ingeniería en su conjunto.

3
joshin4colours

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.

3
The Duke

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.

3
GreyGeek

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.

3
NotGaeL

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, cuales...). Puede haber algunos vínculos, no puede simplemente cambiar los motores sin un cuidado, pero los grandes proyectos generalmente funcionan mejor cuando tales cosas se minimizan.

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

2
Rex Kerr

Construir sistemas de software es muy diferente de construir estructuras físicas. Es decir, el 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 muy simple cosas que hacer, de verdad.

Sin embargo, cuando se trata de software, obtiene 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 hashing + salado y ¿cómo se asegura de que sea segura? Puede hacerlo de tantas maneras que es imposible establecer una práctica real patrones de diseño para este tipo de cosas. Sí, dichos patrones de diseño existen en menor escala como "mejores prácticas", pero cada sistema de software es muy diferente de los demás, y el El campo avanza y cambia a un ritmo tan rápido que es esencialmente imposible 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 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 del proyecto es que el desarrollo de software y especialmente el diseño de trabajo son muy complejos campos. La complejidad es el problema raíz.

2
zxcdw

Airbus A38 no fue un proyecto exitoso como has 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=2 y vea cuánto éxito tuvo Airbus A380.

1
techExplorer

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 consiste en 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' en 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 razones principales 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, de 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 los diseños desde hace décadas.

La gestión de proyectos es notoriamente difícil en el software . Las estimaciones de tiempo se hacen mejor ¡por personas que hacen el trabajo, pero cuando están ocupadas haciendo estimaciones, ¡no están escribiendo 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 orientados a objetos y existentes 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 programación extrema (que en realidad se utilizó en megaproyectos de software). Pero con plazos ajustados (que pueden hacerse más estrictos a propósito), es tentador omitir toda esa programación y lanzar errores. El estilo Joel Spolsky de "siempre arreglando todos los errores" ahorrará más tiempo a largo plazo, pero los indisciplinados se saltearán esto y fallará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 empresas son malas compañías ... para ella, una gran empresa 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.

1
Muz

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, o construiste el hardware.

Los proyectos de los que está hablando 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? Tienes 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 las 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 lo colocaron en .

1
Droogans

Aunque no es lo único que podría ser mencionado, 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 algunos efectos secundarios 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.

1
Jerry Coffin

Una razón que realmente no se ha cubierto en las otras preguntas es que el campo del software innova a una velocidad que ocurre 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 usa para construir software. Es el ejemplo más obvio de la ley de los retornos acelerados de Ray Kurzweil, que resulta en un progreso a una velocidad de crecimiento exponencial. Una vez que haya dominado un marco, lenguaje de programación, protocolo de comunicación, es hora de avanzar 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. ¡Lo mismo! (La compañía que construyó los aviones que lo llevaron de manera confiable de A a B se arruinó un año después de la del cine , salió la función de paintball y club nocturno).