¿Qué es lo más complejo del desarrollo de software, según su experiencia?

Algunos programas se encuentran en la intersección de los mundos físico y virtual. En el mundo físico, la mayoría de las cosas con las que tratamos son analógicas: cualquier cosa puede suceder en cualquier momento, y la mayoría de las cosas pueden tomar valores arbitrarios de posición, velocidad, color, etc. Se necesita algún tipo de sensor (un sensor de imagen para cámara, calor, humedad, gps u otros sensores para sus respectivos atributos) que deben ser leídos por software y manipulados en el modelo de mundo virtual. La velocidad a la que se leen los sensores y la precisión de los sensores imponen límites al modelo virtual. Por ejemplo, un sensor de imagen capaz de una resolución de 640 × 480 y 10 cuadros por segundo es mucho menos costoso y exigente que una cámara 4K (3840 × 2160) a 240 cuadros por segundo, pero proporciona un conjunto de imágenes mucho más granuloso e inconexo. La confiabilidad del sistema puede requerir redundancia para lidiar con fallas externas o de componentes, por lo que se requieren cámaras adicionales junto con la lógica para determinar qué usar cuándo. Y el costo importa.

Si está desarrollando un software para un sistema de conducción autónomo, los requisitos macro pueden establecerse de manera muy simple: “Mantenga un espacio seguro entre el vehículo, otros vehículos, peatones y otros peligros en todo momento”. A partir de un requisito como este, los equipos de hardware y software necesitan crear especificaciones para una miríada de detalles, y no importa cuán estrictamente especificados haya casos de esquina en el mundo real que creen sorpresas. ¿Qué sucede cuando la lluvia ligera está interactuando intermitentemente con los sensores y un ciclista vira frente al automóvil al anochecer?

Como ingenieros, debemos anticipar una amplia gama de cosas que pueden suceder, y diseñar y probar casos de esquina muy extraños. No podemos culpar a los “requisitos” porque los especificadores no siempre entienden las restricciones del sistema que crean problemas potenciales. Desarrollamos especificaciones del sistema, manuales, notas de la versión y otros documentos a los que nadie presta atención hasta que ocurre una catástrofe, momento en el que debemos luchar para armar una solución.

Existen problemas informáticos “difíciles” relacionados con el mundo físico: leer correctamente todos los sensores a la velocidad correcta en todas las condiciones, procesar los datos del sensor dentro del tiempo requerido y tomar decisiones basadas en los datos procesados. Todos estos son algoritmos que deben ser concebidos, desarrollados, probados y refinados. Como es costoso chocar autos y medir impactos, todo debe simularse.

El arte del ingeniero es la capacidad de tomar un conjunto muy complejo de componentes, dispositivos y subsistemas interactivos y convertirlos en un simple gesto en un teléfono inteligente que funciona el 99.99% del tiempo. Por $ 0.99.

Varias cosas: no puedo elegir una.

• En primer lugar, presentar el diseño adecuado para requisitos incluso relativamente simples: debe tener la combinación correcta de extensibilidad y no sobre ingeniería.
• Realice ingeniería inversa del código fuente mal documentado de su propia empresa.
• Problemas de depuración que surgen en el campo: hay bloqueos, síntomas inesperados, no hay suficiente información de depuración, no hay retroceso, nada. Estás obligado a revisar el código (tu propio escrito) y descubrir cómo y por qué.
• Repasando su propio gran proyecto un par de años más tarde e intente comprender qué está haciendo y por qué está haciendo lo que está haciendo.
• Proporcionar un nivel adecuado de cobertura de prueba a su código.
• Refactorizando el código heredado, y en realidad * justificando * a las partes interesadas por qué el código necesita ser refactorizado en primer lugar.
• En los niveles superiores, comprender qué proyectos son importantes y se traducirán en ganar más dinero para su empresa; si tuviera que elegir uno, esto es probablemente lo más complejo del desarrollo de software.

¿Qué es lo más complejo del desarrollo de software?

Hasta ahora, hay cuatro excelentes respuestas a esta pregunta, que discuten el papel confuso de las personas, los problemas de requisitos, las interacciones con el mundo físico, etc. Todos estos factores hacen que el desarrollo de software sea más complejo, pero el factor de complejidad final son las pruebas de software.

¿Por qué probar? En la literatura, las pruebas generalmente no se tratan como una parte glamorosa del desarrollo, pero cuando estamos probando, nos enfrentamos a la Segunda Ley de la Termodinámica, que nos advierte que la perfección es en última instancia inalcanzable.

Entonces, incluso si supiéramos absolutamente todos los requisitos (que no podemos, por supuesto), mantuvimos todos los factores humanos bajo control (también imposible) y supiéramos exactamente todas las propiedades físicas del mundo real (una vez más, imposible) , todavía nunca podríamos realizar el número infinito de pruebas para cubrir todas las situaciones posibles.

En otras palabras, el software aún podría sorprendernos en cualquier momento. Eso es lo que yo llamo complejidad.

Por supuesto, aún podemos trabajar duro para resolver estos otros problemas. Sobre los requisitos, por ejemplo, vea nuestros libros de Exploración de requisitos.

Pero no importa cuánto lo intentes, aún te enfrentarás al problema de la prueba. Para comprender este problema y lo que puede hacer para reducirlo (pero no eliminarlo), eche un vistazo a Perfect Software y otras ilusiones sobre las pruebas.

Gestión de expectativas. Un desarrollador tiene múltiples fuerzas (a menudo opuestas) que afectan su vida laboral. Primero, tiene el cliente que paga el software. Este cliente a menudo no puede expresar sus necesidades de manera formal, por lo que puede ser difícil o imposible obtener una especificación formal por adelantado. (Y si lo hace, a menudo es muy inexacto e incompleto).

Luego tiene la administración, que desea que el software se produzca de la manera más rápida y económica posible, sin errores y, por lo tanto, sin costos de soporte. Y, naturalmente, las pruebas serán limitadas o inexistentes, ya que las pruebas cuestan tiempo y dinero.

Los clientes esperan un software económico y a prueba de errores que resuelva mágicamente todos sus problemas, y esperan que los desarrolladores sean lectores de la mente.

Los gerentes esperan que los desarrolladores produzcan ese software en un abrir y cerrar de ojos, con poco tiempo perdido, sin pruebas y sin costos de soporte.

En realidad, escribir el software es la menor parte de este problema.

Solo para agregar más para pensar.

Una vez que haya superado el trato con clientes y gerentes despistados, todavía tiene esas áreas del sobre que podrían ser empujadas.

Es bastante difícil tratar con los clientes para recrear procesos comerciales competitivos con el desarrollo de software tal como lo conocemos. Es más difícil crear software ya que aún no lo sabemos.

A veces, el cliente desea una solución que requiera un gran avance. Ahora, algunos de estos están fuera de alcance, pero en algún momento hay suficiente trabajo preliminar para ir más allá.

La complejidad asociada con empujar el sobre puede ser emocionante. Si su gerente, ya sea por amabilidad o locura, le permite correr con una colección de conceptos, puede trabajar duro para eliminar la nube de lo desconocido. Siempre está tratando de dominar el siguiente concepto para establecer un nuevo proceso.

La desventaja es que el mismo gerente que te deja fuera de la caja no puede comenzar a comprender lo que le estás diciendo, incluso si el software está en sus manos trabajando y lo está usando. Ahora, el gerente se esfuerza (o no se esfuerza lo suficiente) para traducir su descripción de este software en algo que una persona menos imaginativa pueda entender, como un inversionista. Fracasa en los puntos más sutiles y tergiversa repetidamente el diseño del programa para todos los que conoce. Intenta diluir lo que usted dice, omitiendo los puntos más significativos, al mismo tiempo que falla la historia de la investigación y el desarrollo y el descubrimiento de su definición comercial que podría conducir a un ROI.

Esto es como presentarse ante una multitud de personas y mostrarles un platillo volador que puede atravesar un agujero de gusano. Todos dan un paseo, ven y tocan el otro lado del universo. Luego, después de regresar, todos están de acuerdo en que la demostración no fue más que una buena discusión, y vuelven a cavar hoyos con palas, una vez más, hablan de la posibilidad de viajes extraordinarios mientras mueven cada grupo de tierra con sus espadas.

El ingeniero solo puede pensar que los mismos hombres podrían tomar palos de bambú en lugar de palas si se los presentaran. Los mismos tipos de inversores podrían abandonar sus casas y vivir en cuevas. Pero entonces, su gerente más comunicativo puede haber pensado cuidadosamente en sus cabezas que actúan de esta manera.

Y así, el ingeniero, obligado a descartar su pasión por falta de pago, se va a un rincón tranquilo del mundo y aprende a cocinar hamburguesas.

Sobre la base de la excelente respuesta de Hakon hapnes strand, diría que lo más complejo es que la gente piensa que el software es fácil de cambiar (y pensando en ello, el movimiento ágil no nos ha hecho ningún bien a este respecto).

Si usted es ingeniero civil y alguien le pide que construya una pasarela peatonal sobre un arroyo, saben instintivamente que no pueden regresar a la mitad del proyecto y cambiarlo a una carretera de 6 carriles sobre un estuario. En el software, la gente pide el equivalente de este cambio todo el tiempo. Después de todo, son solo palabras y símbolos, ¿no?

Si hablamos de desarrollo de software, entonces es complejo gestionar las expectativas en nombre de los proveedores. Tienen una presión continua de los clientes para cumplir con los requisitos de su proyecto en plazos establecidos, así como para proporcionarles software libre de errores, probado y en condiciones de funcionamiento.

La presión sobre el equipo de Software Development Company es bastante alta, ya que tienen que asegurarse de que el software que entregan a un cliente debe tener todos los requisitos que el cliente ha solicitado. Por lo tanto, si está confundido acerca de los softwares complejos y no sabe de dónde obtener el mejor rendimiento, puede contactarnos.

Como dijo Håkon: descubrir lo que el usuario final realmente quiere. La mayoría de las personas no tienen idea de qué puede hacer el software, qué no puede hacer y qué quieren que haga. Una vez que pasa ese punto y sabe lo que tiene que hacer, desarrollarlo es simple. Tal vez mucho trabajo, pero también está cavando un hoyo de 10 pies en arcilla cocida, y no lo llamarías “complejo”, simplemente agotador.