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

Marcha de la muerte de Ed Yourdon toca un número de estas preguntas tipo meta.

En general, la industria del software carece de muchos de los siguientes, que se interponen en el desarrollo de grandes proyectos.

• Normalización y desglose de elementos de trabajo.

  • Esto ciertamente ha mejorado, pero las construcciones de diseño aún no están disponibles para romper un gran sistema. De alguna manera, el software ni siquiera puede ponerse de acuerdo sobre lo que necesita para un proyecto dado, y mucho menos poder descomponer las cosas en componentes.
  • El sector aeroespacial, la construcción de edificios, el automóvil, etc., todos tienen arquitecturas muy controladas por componentes con interfaces razonablemente ajustadas para permitir un desarrollo completamente paralelo. El software aún permite demasiado sangrado en las áreas correspondientes.

• Un gran cuerpo de proyectos exitosos y similares. El A380 no fue el primer gran avión que Airbus . Hay una gran cantidad de aplicaciones de software grandes por ahí, pero muchas de ellas han sufrido dramáticamente en algún aspecto u otro y no se acercarían a ser llamadas "exitosas".

• Un gran cuerpo de diseñadores y constructores que han trabajado en varios proyectos similares y exitosos. Relacionado con el problema del proyecto exitoso, no tener el talento humano que ha estado allí, hecho que hace las cosas 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. Mira la disparidad en los sistemas de archivos. Y, para el caso, ¿cuántos sistemas operativos verdaderamente únicos existen? Los grandes se convierten en clones de un elemento base en algún momento. AIX , Solaris , HP-UX , ... anuncia de nuevo a AT&T System V . Windows ha tenido una cantidad increíble de arrastre hacia adelante en cada iteración. En general, las variantes de Linux vuelven al mismo núcleo que Linus comenzó. Lo menciono, porque las variantes tienden a propagarse más rápido que los sistemas operativos verdaderamente únicos y propietarios.

• Muy mala estimación de proyecto. Dado que el factor de repetibilidad es tan bajo, es difícil proyectar qué tan grande será y cuánto tardará en construirse. Dado que los gerentes de proyecto y la Administración no pueden poner sus manos en el código y ver realmente 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 holgura permite las consecuencias no deseadas y los errores que se arrastran.

• Cualificaciones 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 un sustituto del calibre o la calidad de la habilidad. Como se ha mencionado muchas veces antes, entrevistar y encontrar un buen talento para la programación es difícil. Parte del problema es que la definición de "bueno" sigue siendo muy subjetiva.

No quiero ser totalmente negativo, y creo que la industria del software ha logrado avances significativos 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 avanzado mucho en un período de tiempo razonablemente corto.

La respuesta es sorprendentemente simple: las "otras industrias" tienen tienen una alta tasa de fracaso. Solo estamos comparando las cosas equivocadas. El software de escritura a menudo se llama 'compilación', 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 el software o interpretándolo directamente sobre la marcha.

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

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

En el software, no hay ninguna línea de fabricación de la nota. 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 compilación.

Para señalar algunas figuras:

1. Cambio de requisitos una vez iniciada 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, los pondría allí; pero en un gran proyecto de software, incluso después de que los programadores comenzaron a desarrollar, 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 tantas heurísticas y buenas prácticas; b) No hay muchos 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 usan para probar que una pieza de software funciona como se requiere; en su lugar se utiliza la prueba. Esto es cierto en otros campos de la ingeniería que dependen más de las matemáticas; la razón de esto es como complejidad;
6. Rush : muchos gerentes tienen fechas límite inalcanzables. por lo que 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 los demás tienen expectativas muy altas (especialmente en el tiempo de entrega) de los programadores y no entiendo 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 se entregaron años tarde.

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

No hubo ningún problema 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 los problemas más tradicionales de los nuevos aviones, 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 la aeronave inicial tuvo problemas estructurales.

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

Chico rascacielos aquí. No estoy seguro de poder responder a tu pregunta, pero seguramente puedo aclarar algunos elementos del hilo. De hecho, los edificios ocurren muy rápido. Una restricción importante es la configuración regional (regulaciones). Pero en general toma de 3 a 10 años para un edificio alto 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 kernel o sistema operativo. En este sentido, el desarrollo de software es mucho más rápido. Nunca compilamos desde cero, ya que esta será una tarea de alto riesgo en la que el cliente nunca se registrará. La mayoría del diseño y desarrollo en edificios se deriva de proyectos probados y completados.

Por experiencia personal, solo uno de cada diez proyectos se construye. El proceso es impulsado por el desarrollo en lugar de por el diseño, por lo que en el momento en que el precio del acero sube, todo el proyecto está fuera de la ventana o está diseñado, ya que el diseño es el componente económico del proceso.

El diseño toma un mes para el concepto a esquemático, de dos a seis meses para el desarrollo de diseño, otros seis meses para detalles y documentos de construcción por un equipo de arquitectos, consultores de planificación, ingenieros estructurales, ingenieros eólicos, ingenieros de servicios, consultores de cantidad y costo. , topógrafos, ingenieros de accesibilidad y la lista continúa ...

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

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

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

En general, mi estimación (potencialmente errónea) según la pregunta de OP es que la programación es más un arte que una ingeniería. ¿Por qué las personas se complacen e incluso lo hacen gratis, encuentran expresión y elegancia en ello? La informática también es (como en la lata) más una ciencia que una ingeniería. ¿Por qué trataría de probar algoritmos en lugar de solo parchar partes existentes y trabajar para que las cosas funcionen? No estoy seguro si esto tiene algún sentido; No soy un tipo 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 solucionar esto, y algunos se salen con la suya al deshacerse de la complejidad interna. Si nada más esto puede tener algo que ver con eso?

Entonces, ¿cuánto tiempo tomó el diseño de aquellos? ¿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.

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 en sí mismo. Y el proceso de diseño es totalmente diferente del proceso de producción. Requiere personas con experiencia y es imposible 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 las 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 partes 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 que los proyectos de software se terminan con grandes retrasos y costos inflados es porque los gerentes aún piensan que pueden estimar, predecir y planificar un proceso de diseño de este tipo. Esto fracasa más a menudo de lo que realmente es válido. Todavía piensan que al vincular a las personas con un proceso de construcción rígido, de alguna manera pueden aumentar la calidad a pesar de que el resultado final es, en su mayoría, opuesto al aumento de los costos y la falta de plazos.

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

O imagínese, en el medio de un proyecto de construcción de un puente, alguien dice: "Eh, acabamos de hacer un trato con una compañía naviera. Necesitan que el puente sea 40 pies más alto, porque sus barcos son mucho más altos. Gracias. "

Estas son solo algunas de las razones por las cuales los proyectos de software, grandes y pequeños, terminan en fallas a una velocidad alarmante.

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

Como otros en este hilo, a menudo también he atribuido los fallos a la inmadurez de la TI, la falta de estándares detallados (sí, en serio, ¿alguna vez ha revisado la hoja estándar de un perno simple?) y el falta de componentes y módulos estandarizados.

Otras industrias, como la construcción de edificios o la construcción de barcos, también tienen muchos más "caminos trillados": el conocimiento y la experiencia de un prototipo de solución particular, que, en forma personalizada, se reutiliza una y otra vez. ¿Alguna vez te has preguntado por qué los edificios, barcos o aviones de diferente tamaño y propósito se ven tan parecidos? (hay excepciones a la regla, por supuesto ...)

Esto se debe a que esos prototipos están bien investigados, bien entendidos, se utilizan en general y tienen un historial probado. No porque no se pudiera hacer de otra manera. En la TI, la estandarización rara vez es el caso: (los grandes) los proyectos tienden a reinventar componentes, haciendo investigación y entrega 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 en condiciones inciertas. Y debido a esto, por supuesto, estos productos son mucho más rápidamente obsoletos, se escriben y se reemplazan a costos igualmente grandes con solo unos ligeramente mejores. Lo que TI necesita es el equivalente a 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, sin embargo. A diferencia de las otras industrias mencionadas, la TI es verdaderamente ubicua: se utiliza en cada aspecto de nuestra vida moderna. Así que es un pequeño milagro. La TI logró tanto progreso y es capaz de entregar los resultados que obtiene.

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

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

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

Mira los coches; Hay fabricantes de alta calidad que fabrican automóviles muy duraderos y muy avanzados (piense en Land Rover, Mercedes) y hay otros que fabrican 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, donde comienzas a tener jugadores más débiles.

El software no es diferente. Por otro lado, tienes muchos productos con errores, 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 extrañan es la cantidad de mantenimiento que implica el mantenimiento de un automóvil, un camión cisterna o un avión que tomamos como un hecho de la vida real. Cada avión tiene que someterse a un control técnico antes de cada despegue. Tienes que revisar tu auto cada varias millas y hacer cosas regulares como cambiar el aceite, cambiar los neumáticos.

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

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

Un diseño mecánico tiene un nivel de tollerance. 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 vez de poner un 0 donde debería haber un 1 puede fallar todo el programa.

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

Muchas veces me he preguntado lo mismo. Sin duda, se siente (ocasionalmente) como si fuéramos un grupo de amateurs que no tienen idea de lo que estamos haciendo. No me gustan las explicaciones que culpan a los gerentes u otros factores externos: nosotros los desarrolladores debemos ser responsables de lo que creamos.

Creo que estamos en un negocio donde los errores son baratos . El software de parches es barato, en comparación con la reconstrucción de un rascacielos o la recuperación de todos los teléfonos celulares vendidos.

Esto ha creado una cultura donde los errores forman parte de la vida cotidiana . Se aceptan encogiéndose de hombros. Mientras que algunos errores son probablemente inevitables, deberían dominar nuestro trabajo diario ? Entiendo completamente a los gerentes que no creen 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 por generar código sin errores, porque corregir errores es aburrido.

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

Los estándares 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 de estándares para TI en el sector aeroespacial . Por ejemplo, los Joint Strike Fighter C ++ Standards que se han abierto camino en Internet en los últimos tiempos.

Muchos expresan desconcierto o resignación (deseo que podamos 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 puede incluso ser correcto, dadas las expectativas, no de los consumidores, sino de la administración. Existe una gran desconfianza para los programadores que simplemente codifican y codifican durante unas pocas semanas, sin demostrar nada. Dios ayuda al programador que simplemente diseña algo durante dos semanas. No es así con los aviones.

En software, la gente realmente espera tener algo en este momento. Claro, el razonamiento continúa, tomará un 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 estimulan la imaginación; y, por lo tanto, muchos ingenieros terminan siendo cómplices en un mundo imaginado de cosas realmente simples que se unen de manera creativa (a diferencia de un mundo de cosas difíciles que se hacen muy bien).

Algunas cosas de mi parte:

1- Normas y piezas: son fabricantes planos, no desarrolladores. No estoy del todo seguro, pero supongo que muchas partes están subcontratadas. 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 de cero con solo algunos marcos / ayudantes pequeños en su lugar.

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

Para el software, debe ser muy ágil, si comienzo un gran proyecto ahora y me tomo tres años para desarrollarlo sin ningún cambio, es muy probable que confíe en una tecnología que ya no está disponible o que mi producto esté completamente anticuado. 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 esto, solo se puede modificar de una manera pequeña. No se puede agregar un nivel adicional con 100 asientos a un boeing existente, simplemente no es posible.

Por otra parte, el software

tiene cambios incrementales que a menudo son simplemente "compilaciones que funcionan", pero no necesariamente productos terminados. Además, en TI no es raro decir "hey, 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 lo han hecho las personas: hemos tenido miles de años para desarrollar nuestros métodos y técnicas para implementar proyectos físicos. La "construcción" de software, que requiere un conjunto de habilidades completamente nuevo y diferente, no tiene más de 50 años, aún 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 analice y abstraiga mucha información antes de que sepa cómo se ve su producto y los pasos necesarios para crearlo. No es así cuando se construye un puente o un edificio.

3) A menudo es mucho más difícil encontrar el origen de un error o error de software que cuando se hace ingeniería física. Si una viga se dobla, ve dónde se está doblando 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 interactivos: es difícil, requiere mucho tiempo y no está relacionado con el Las leyes de la física y las 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, simplemente sustitúyalo mentalmente por software.

  

¿Comparado con qué?

     

El firmware es lo más caro del universo. En su maravilloso   libro "Augustine's Laws", Norman Augustine, ex CEO de Lockheed Martin,   cuenta una historia reveladora sobre un problema encontrado por la defensa   comunidad. Un avión de combate de alto rendimiento es un equilibrio delicado.   de necesidades conflictivas: rango de combustible vs. rendimiento. Velocidad vs. peso. Eso   Parece que a finales de los 70 los luchadores estaban tan pesados como lo habían hecho   jamás. Los contratistas, siempre persiguiendo mayores ganancias, miraron en vano   por algo que podrían agregar que costaba mucho, pero que pesaba   nada.

     

La respuesta: firmware. Costo infinito, masa cero. Aviónica ahora cuentas   por más de la mitad del costo de un luchador. Eso es un pedazo de cambio cuando   considera el último caza estadounidense, el F-22, cuesta un tercer lugar   de un billón de pop. Agustín prácticamente se ríe con alegría cuando él   Relata esta historia.

     

¿Pero por qué es tan caro el software? Tom DeMarco una vez respondió esto   Pregunta con estas tres palabras: ¿comparado con qué? Pasó a   discutir casos de negocios relativamente aburridos, pero esa respuesta tiene   resonó en mi mente durante años. ¿Comparado con que? Con software nosotros   rutinariamente crea comportamientos de productos de complejidad sin precedentes. Por supuesto,   el código es caro Pero nunca en la historia de la civilización ha   alguien construyó algo tan intrincado.

     

Considere la siguiente clasificación de burbuja, levantada sin vergüenza de Wikipedia   y no se verifica su exactitud:

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

}

     

Es un mero 110 caracteres no espaciales, quizás arrojados en una hora o   dos. Supongamos que no teníamos software y tuvimos que implementar una ordenación usando   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 IBM de la era 1949 de 1949.   ( enlace ) con un rendimiento   de 650 tarjetas por minuto, algo menos que nuestro fragmento de código podría   Administrar incluso en un Z80 de 4 MHz. El modelo 82, por supuesto, solo ordenó uno.   columna de una carta a la vez; para ordenar completamente una cubierta 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 gigantescos. Pero eso fue en 1949.   ¿Cuánto tiempo tomaría construir una burbuja de componentes electrónicos?   sin FPGAs y VHDL, o una CPU?

     

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

     

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

     

La conversión del diagrama de bloques en bruto a un esquema puede tardar un día.   Luego está el tiempo para diseñar y producir una PCB, ordenar y cargar   partes (y cambiar el diseño para hacer frente a lo inesperado pero   problemas inevitables del final de la vida), y luego, por supuesto, hacer que el circuito   trabajo. Podríamos estar hablando de semanas de esfuerzo y mucho dinero para el   Tablero, partes y equipo de prueba apropiado.

     

Todo esto para reemplazar 7 pequeñas líneas de código. Pocos programas incrustados reales   son menos de 10,000; muchos superan el millón. ¿Cuánto hardware y cómo?   se necesitaría mucha ingeniería para reemplazar una verdadera, de gran tamaño   programa informatico?

     

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

     

El firmware es lo más caro del universo, pero solo porque   De la complejidad inimaginable de los problemas que resuelve. Pero es   Mucho más barato que cualquier otra alternativa. Entonces cuando tu jefe pregunta irritado   Por qué el software tarda tanto tiempo, sabes qué decir.    ¿Comparado con qué?

¡Así que ahí! El software / firmware tiene una complejidad sin precedentes.

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 un costo marginal esencialmente cero; Todo el costo se encuentra en el desarrollo de la primera copia.

Debido a la relativa juventud de la ingeniería de software y la gestión como disciplina, existe cierta desinformación y falsedades que aún se toman como un hecho ( vea esta referencia ) lo que dificulta el desarrollo de software y la ingeniería en su conjunto.

No todos los desarrolladores son creados igualmente. Algunos son buenos, otros son, 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 sentencias lógicas y ahora tienes 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 escapan 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 mejora obtendrá, así que déle a la industria del software un par de siglos de errores de prueba para mejorar, y veremos cuánto se necesita para desarrollar un enorme sólido. Proyecto sin errores o fallas.

Los proyectos grandes a menudo ocurren en organizaciones grandes. Si nunca ha trabajado en una organización grande, hay una cosa que garantiza 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), ni siquiera si tienen un problema de burocracia.

Recientemente concluimos un proyecto para implementar la autenticación con tarjeta inteligente. Originalmente se estimó en tres meses. Le 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), aproximadamente 1,200 cuentas en total.

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

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

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

Y luego lucha con el meta-proceso en su lugar.

No es muy cierto, per se, pero cada día se configuran miles de blogs, en lugar de escribir motores de blogs. Cada día laboral, se escriben miles de macros de Excel, en lugar de escribir aplicaciones de base 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, por lo que crea una falta de incentivo 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 un pequeño número 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; simplemente busca formas alternativas para completar el subproyecto (por ejemplo, usar 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 de la manera difícil que este tipo de separabilidad es algo bueno. Por ejemplo, si va a utilizar motores de aviación Rolls Royce, no necesita usar pernos y puntos de fijación especiales de Rolls Royce que solo funcionan con alas con un diseño particular, y luego, si intenta cambiar a Pratt y Whitney, tiene que rediseñar su ala completa desde cero (lo que, a su vez, requiere un rediseño completo del fuselaje, 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...). Es posible que existan algunos vínculos (no puedes simplemente intercambiar motores sin preocuparte), pero los grandes proyectos generalmente funcionan mejor cuando se minimizan tales cosas.

Postulo 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 realmente 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. Mientras que, por ejemplo, construye un enorme camión cisterna, realiza muchas tareas relativamente sencillas (¡aunque no fáciles!), Como soldar partes con un robot o con la mano, apretar todas las tuercas y tornillos, pintar, hacer la decoración cargando todo El equipamiento y mobiliario y demás. Todo esto es muy simple cosas que hacer, realmente.

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ás familiarizado? ¿Qué hace exactamente para escribir la función hashing + salting y cómo se asegura de que sea segura? Puede hacer esto de tantas maneras que es imposible establecer ningún patrón de diseño práctico real para este tipo de cosas. Sí, dichos patrones de diseño do existen en una escala más pequeña como "mejores prácticas", pero cada sistema de software es muy diferente de los otros, y el campo avanza y cambia a un ritmo tan rápido que es esencialmente imposible de mantener.

Cuando construyes una casa, realmente no te topas con problemas en los que te das cuenta de que los muros de apoyo principales parecen ser inadecuados y necesitan ser reemplazados, lo que requiere que destruyas el progreso hasta el momento y comiences desde la base rehaciéndote. Los muros de apoyo. Aborda estos problemas en la fase de diseño , porque es relativamente sencillo predecir qué tipo de paredes 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 del software suele ser iterativo, y los objetivos y requisitos cambian a medida que se implementa y prueba el producto. El desarrollo de software en su conjunto es un proceso iterativo en el que las cosas cambian cuando menos se espera, y muchas veces tales cambios imponen desafíos que requieren más trabajo, más complejidad y, por desgracia, 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 líneas de tiempo y planes de trabajo del proyecto es que el desarrollo de software y especialmente el diseño de trabajo son campos muy complejos . La complejidad es el problema raíz.

La definición de "proyecto grande" está sesgada.

Un gran proyecto, técnicamente, se puede entregar a tiempo, y sin problemas, es algo que se ha construido 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. La instalación y configuración de usuarios en un sistema operativo puede ser difícil a veces, y ni siquiera escribió el sistema operativo, ni construyó el hardware.

Los proyectos de los que estás hablando son enormes , similares a la exploración espacial. ¿Cómo sabes cuánto tiempo lleva desarrollar los viajes intergalácticos? ¿En qué modelo nos basamos? Tienes los conocidos conocidos, los desconocidos conocidos, los desconocidos conocidos y, por último, los desconocidos desconocidos, que surgen mucho en el desarrollo de software.

Creo que el problema es de expectativa. El hecho de que la tecnología esté ahí no significa que su uso sea exitoso (o sabio de usar) por un tiempo. Si otras industrias se comportaran como lo hicieron las industrias de software, tendríamos aspiradoras eléctricas de agujero negro para la venta a finales de la década. O algún "visionario" tendría los recursos para construir una base lunar y decidir 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 .

Aunque no es la única cosa que podría mencionarse, 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 se fabrica para ajustarse al comportamiento existente, y simplemente lo hace un poco más simple / fácil / barato / lo que sea para hacer 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 suele ser un efecto secundario bastante menor.

En contraste, casi cualquier software que no cambie el comportamiento de los usuarios (por ejemplo, dejar que hagan su trabajo de manera mucho más fácil) está básicamente garantizado como un fracaso completo desde el día 1. Peor aún, los grandes proyectos de software no no solo implica el comportamiento de los usuarios a nivel individual, sino el comportamiento de grupos grandes, a menudo la totalidad de la organización.

En resumen, el diseño del software en sí mismo suele ser la parte más fácil del trabajo. La parte difícil es rediseñar los trabajos de la gente para ellos. Es difícil empezar con eso; 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 ha mencionado. Resulta que trabajé en una empresa de CAD / CAM, y me dijeron que (también teníamos el proyecto Airbus) se retrasó unos años, porque estaban usando diferentes versiones de software en diferentes compañías. Es decir, se estaban diseñando diferentes partes en diferentes partes del mundo. Y al integrarse, llegaron a saber que todo el diseño no podía integrarse, por lo que tenían que rediseñarlo en una versión. Así que mirándolo no creo que haya tenido éxito. Si hubiera llegado 2-3 años antes, habría sido un cambio de juego para Airbus.

También con respecto al software robusto, observa que cualquier avión, automóvil (ABS, EPS, control de clima, etc.) o transbordador espacial tiene más del 50% de software que los está ejecutando y me parece 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: enlace y ver cuánto éxito tuvo el 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 consiste en diseñar cosas nuevas . Casi todo lo básico se ha hecho en una biblioteca de código abierto en algún lugar. En casi cualquier trabajo donde se contrata a un ingeniero de software, ella 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 otra manera estarían en una 'biblioteca' en software ya están completamente diseñadas. ¿Quieres construir una torre? Simplemente copie y pegue los planes desde 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 del tiempo diseñando una mejora del 10% en un invento 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 capacitado es alguien que puede manipular un diseño existente en algo nuevo o mejorarlo. Pero se espera que casi todos los programadores modifiquen los diseños, los pirateen o creen algo nuevo.

Mire hacia atrás hasta qué punto han cambiado completamente los estándares, desde ensamblado a C a C ++ a Java, JavaScript, C # , PHP, y así sucesivamente. No hay mucho código que se pueda reciclar de hace 10 o 20 años. Es muy diferente decirlo ... la industria automotriz o aeronáutica cuando puede seguir mejorando los diseños de décadas atrás.

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

A menudo, una gran cantidad de código depende de personas específicas, y si estas personas llegan tarde o no pueden actuar, el código no avanza. Por el contrario, si desea construir un automóvil, simplemente puede contratar 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 que no sea práctico cuando diseñas todo desde cero.

Pueden permitirse errores en el software . Las pruebas pueden ser costosas. En el software, es muy tentador omitir todas esas pruebas, cuando puedes simplemente arreglar un fallo. 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 usó 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 con errores. El estilo Joel Spolsky de "corregir todos los errores" ahorrará más tiempo a largo plazo, pero el indisciplinado se saltará este y fallar.

Los proyectos pequeños son mejores . Mi esposa una vez me pidió que consiguiera un trabajo en una gran empresa. Terminó con el argumento de que las grandes empresas son malas empresas ... 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 pasa la mayor parte de su tiempo corrigiendo el código, probándolo y documentando.

He visto proyectos de TI de millones de dólares trabajados por menos de 10 personas. Más personas habrían retrasado 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 que miles de personas produzcan miles de millones de dólares en software.

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

Una de las razones de esto es que la evolución del software es un ciclo de retroalimentación positiva porque el software (lenguajes de programación, herramientas de compilación, IDE) se usa para construir software. Es el ejemplo más obvio de la ley de Ray Kurzweil de los rendimientos acelerados, dando como resultado un progreso a una velocidad de crecimiento exponencial. Una vez que haya dominado un marco, el lenguaje de programación y el protocolo de comunicación, es hora de seguir adelante con a la siguiente.

Si los aviones se construyeran como un software, cambiaríamos el material con todos los demás modelos, duplicaremos su capacidad y velocidad cada 18 meses, reemplazar la tecnología del motor para cada nuevo modelo con algo que se acaba de inventar, y agregar la capacidad de nadar y búsqueda de vida extraterrestre.

Ah, e idealmente escucha los comandos de voz y se duplica como una sala de cine, un estadio de paintball y un club nocturno completamente inmersivos una vez que finaliza tu viaje de trabajo. ¡Lo mismo! (La compañía que construyó aviones que lo consiguieron de A a B de manera confiable se derrumbó un año después de que saliera el que tenía el cine, el paintball y el club nocturno).

Para mí, el principal problema que enfrenta la ingeniería 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 volar de un lugar a otro. Quizás haya más, como el radar, el control de tráfico, etc., pero el caso de uso es claro y no mucho. En ingeniería de software, nos enfrentamos a requisitos y usuarios poco claros que no saben lo que quieren. Los diferentes usuarios necesitan diferentes configuraciones / flujos, ¿se puede personalizar un avión como el usuario quiere (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 ellos son profesionales y sus descripciones de trabajo son claras. El software es utilizado por noobs y dummies, por no mencionar a los hackers y crackers malvados, mientras que todavía deben integrarse con otros módulos (como OpenID o Google AdSense ). Si un avión puede ser operado por maniquíes mientras aún sobreviven 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 caliente, frío y húmedo, pero un avión no está diseñado para volar a un nivel de gravitación diferente (me sorprendería si puede volar a Mars ). 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 de SO. Sin mencionar los dispositivos móviles y las diferentes resoluciones y orientaciones.

Si cree que otras industrias completan proyectos sin incidentes, debe leer la historia sobre el edificio del Centro Citigroup 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 evento de tormenta esperado cada 16 años.

  

En otras palabras, por cada año que estuvo en pie el Centro Citicorp, había una posibilidad de 1 en 16 de que colapsara.

Los diseñadores originales desconocían los problemas, pero afortunadamente fue capturado por un estudiante que estudia el edificio.

  

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

Las reparaciones se hicieron literalmente en la portada de la noche en la que participó la menor cantidad de personas para mantener en secreto el defecto de diseño.

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

  

Se soldaron durante toda la noche y se retiraron al amanecer, justo cuando los ocupantes del edificio regresaban al trabajo.

     

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

Lo que plantea la pregunta; cuántas otras fallas de diseño fatales en los proyectos se repararon o ignoraron en secreto sin el reconocimiento público.

• El defecto de diseño que casi se borró de una Ciudad de Nueva York Skyscraper (slate) / a>
• Centro de Citigroup (wikipedia.com)