Introducción
Los laicos a menudo me preguntan por qué los humanos podemos emprender grandes proyectos de construcción o ingeniería con relativo éxito y, sin embargo, nos cuesta entregar proyectos de software sin errores y a tiempo.
En un intento de explicar por qué este es el caso, doy a continuación 7 razones por las que el desarrollo de software es muy difícil. Este no es un intento de tolerar las prácticas de desarrollo de software de mala calidad. Más bien, estoy tratando de mostrar que incluso con excelentes procesos de desarrollo, todavía es difícil hacer el desarrollo de software correctamente.
1. La industria del software es joven.
Los humanos han estado construyendo una casa, carreteras y puentes durante miles de años. No tenemos idea de cuántas casas o puentes se derrumbaron en los primeros días cuando los humanos aprendieron las técnicas correctas para construir estas estructuras.
Uno solo tiene que mirar el infame colapso del puente Tahoma Narrows en 1940 para darse cuenta de que, miles de años después de la construcción de los primeros puentes, todavía no habían perfeccionado la construcción del puente.
En comparación, la industria del software solo tiene unos 50 años. Todavía tenemos un largo camino por recorrer antes de tener el cuerpo de experiencia que nos avalan las industrias de construcción y fabricación.
Hoy en día, la industria de la construcción utiliza principalmente materiales y piezas prefabricadas. La mayoría de estos están hechos a máquina y han sido probados en muchos otros proyectos.
La industria del software, por otro lado, no tiene la gama de componentes prefabricados que tienen otras industrias. Los sistemas de software se crean fundamentalmente mediante un proceso de descubrimiento, invención y creación de nuevos componentes con el resultado de que cada nuevo sistema es un proyecto personalizado creado desde cero. Esto nos lleva a nuestro siguiente punto.
2. Cada línea de código es un punto potencial de falla
Debido a que todos los proyectos nuevos son personalizados, se deduce que cada línea de código no está probada y, por lo tanto, debe probarse. Sin embargo, en el mundo real, esto es totalmente poco práctico.
Cada línea de código tendrá decenas, incluso miles, de posibles entradas, salidas, estados o dependencias para tratar. Puede afectar o verse afectado por otras líneas de código o por factores externos. Incluso si fuera posible documentar cada caso de prueba para una línea de código, aún no podría estar seguro de que no hubiera algún factor desconocido que pudiera causar un error.
Y probar una sola línea de código es solo una parte del desafío. No existe una línea de código por sí sola. Es parte de todo el sistema y todo debe ser probado para garantizar que todas las partes de la aplicación funcionen correctamente.
La gran complejidad del software significa que es imposible probar cada camino, por lo que en el mundo real los mejores equipos de proyecto implementarán procesos diseñados para aumentar la probabilidad de que el software esté libre de defectos. Utilizarán técnicas como estándares de codificación, pruebas unitarias, pruebas de humo, pruebas de regresión automatizadas, revisiones de diseño y códigos, etc., todo lo cual debería mejorar la calidad del software.
Todas estas pruebas tienen un costo. La pregunta que debe responderse en cada proyecto es: ¿qué tan crítico es este software y cuántas pruebas debemos hacer para garantizar que el software sea correcto?
Con demasiada frecuencia, la fase de prueba se apresura y el software sale con un nivel inaceptable de defectos. Por otro lado, para la mayoría de los sistemas, hay rendimientos decrecientes para extender la prueba más allá de cierto punto. Llega un punto con todo el software en el que el valor de liberar el software es mayor que el valor obtenido al continuar buscando pruebas de defectos. Esta es la razón por la cual se lanza la mayoría del software comercial a pesar de que se sabe que contiene defectos.
3. Falta de entrada del usuario
Durante más de 10 años, la compañía de investigación, The Standish Group, ha encuestado a las compañías sobre sus proyectos de TI. El factor N ° 1 que provocó que los proyectos de software fueran cuestionados fue la “Falta de entrada del usuario”.
Las razones para esto pueden incluir:
* El sistema está siendo promovido por la gerencia y por lo tanto el
los usuarios comerciales no tienen buy-in
* Los usuarios están demasiado ocupados y tienen cosas “más importantes” que hacer
* Las relaciones entre la comunidad de usuarios y el equipo de TI son deficientes.
Sin la participación y el aporte de un representante del usuario, el proyecto está condenado al fracaso. Esta persona debe ser un experto en el dominio del tema con la autoridad para tomar decisiones y un compromiso con los plazos del proyecto.
Entonces, suponiendo que haya una buena entrada del usuario, comienza el desafío de traducir los requisitos en un diseño. Y esta no es una tarea fácil como lo muestra nuestro siguiente punto.
4. Los usuarios no saben lo que quieren hasta que lo ven
Incluso con una buena aportación de los usuarios, ninguna cantidad de análisis de los requisitos del usuario puede eliminar un hecho inmutable de que los usuarios solo piensan que saben lo que quieren. En verdad, no es hasta que comienzan a ver algo, y a usarlo, que comienzan a comprender realmente lo que necesitan. Esto es especialmente cierto cuando el software se está desarrollando para una nueva idea o proceso que no han usado antes.
Los estudios han demostrado que el proyecto promedio experimenta un cambio del 25% en los requisitos desde la etapa de “requisitos completos” hasta la primera versión. Este es el famoso problema de “alcance progresivo” que afecta a casi todos los proyectos. Por lo general, comienza una vez que comienzan a aparecer los primeros diseños, lo que hace que los usuarios piensen más profundamente sobre lo que realmente quieren.
El desafío es: a) ignorar los nuevos requisitos y continuar construyendo de acuerdo con los documentos de diseño y arriesgarse a entregar un sistema que no haga lo que los usuarios necesitan o b) asumir los cambios a medida que surgen con el resultado de que el proyecto se expande y suben los costos?
No hay una respuesta simple a este dilema a pesar del hecho de que varias técnicas, como el desarrollo ágil, han evolucionado para facilitar la adaptación a los requisitos cambiantes. Incluso los cambios aparentemente pequeños pueden tener un gran impacto en un proyecto. Cada requisito explícito puede conducir a muchos más requisitos implícitos (por un factor de hasta 50) que complican aún más el software.
Cambiar los requisitos durante la fase de desarrollo es uno de los grandes desafíos que enfrentan todos los desarrolladores de software. Se puede hacer, pero nunca pienses que es fácil. Y no piense que se pueden acomodar nuevos requisitos sin afectar la línea de tiempo o el presupuesto a menos que haya una eliminación correspondiente de los requisitos.
5. No hay barreras de entrada para convertirse en programador
Hay un argumento que establece que el desarrollo de software es muy difícil porque la programación es muy fácil. En otras palabras, es relativamente fácil aprender a escribir código, pero hay una gran brecha entre eso y la entrega de un excelente software.
Uno podría equipararlo a aprender un nuevo idioma. Sí, puede aprender la gramática y adquirir un vocabulario razonable, pero ese es un juego de pelota completamente diferente a tener una conversación fluida de dos vías con algunos hablantes nativos.
Varios estudios han demostrado que la relación de productividad entre diferentes grados del desarrollador puede ser tan alta como 28: 1. Con eso en mente, seguramente solo querrás contratar a los mejores desarrolladores. Desafortunadamente, esto no es fácil ya que los grandes desarrolladores son un producto muy raro.
No existe una barrera para ingresar al mundo de la programación y, por lo tanto, está inundado de muchos programadores pobres que afectan negativamente a los proyectos. Además, incluso los desarrolladores jóvenes potencialmente buenos seguirán cometiendo errores que un desarrollador más experimentado habrá aprendido a evitar.
Realmente vale la pena pagar más por un desarrollador experimentado de primera clase. Harán las cosas más rápido, mejor y con menos código. Su proyecto se entregará más rápido y tendrá menos defectos. Ahora le ahorrarán dinero y también le ahorrarán dinero durante la vida útil del sistema en costos de soporte y mantenimiento.
6. Todo el software se ve afectado por factores externos.
Las estructuras físicas obedecen las leyes físicas, por ejemplo, se ven afectadas por la gravedad, la masa, la atmósfera, etc. A través de miles de años de aprendizaje, se sabe mucho sobre el mundo físico y, por lo tanto, se puede modelar y predecir.
Un software es “mindware” y, por lo tanto, no obedece las leyes físicas, pero generalmente debe ajustarse a restricciones externas como el hardware, la integración con otro software, las regulaciones gubernamentales, los formatos de datos heredados, los criterios de rendimiento, la escalabilidad, etc.
Comprender y atender todos estos factores externos es una tarea casi imposible. Incluso un requisito aparentemente simple, como el soporte de múltiples navegadores, aumenta exponencialmente la dificultad de construir y probar software. Si luego agrega un requisito para admitir múltiples versiones de cada navegador, nuevamente aumentará exponencialmente la complejidad y la dificultad.
7. La estimación es un arte, no una ciencia.
Dada la premisa de que todos los proyectos nuevos se crean a medida, que no hay componentes prefabricados, que el proyecto sufrirá un aumento de alcance y que el nivel de habilidad en todo el equipo de desarrollo generalmente varía, entonces no es de extrañar que estimar la duración del proyecto nunca puede ser un ejercicio científico. Hay demasiadas incógnitas. Si nunca antes ha creado el mismo software con el mismo equipo, ¿cómo puede saber cuánto tiempo llevará?
Por supuesto, la experiencia lo guía en su estimación y cuanta más experiencia tenga, más probabilidades tendrá de anticipar las incógnitas. Se ejecutan demasiados proyectos porque las personas sin experiencia establecen estimaciones demasiado optimistas que esperan que todo fluya sin problemas y que no tienen en cuenta las incógnitas.
En los últimos 10 años, el método de desarrollo ágil ha surgido como un medio para abordar estos problemas de estimación. Si bien esta es generalmente una forma más confiable de controlar los plazos de los proyectos y, por lo tanto, el costo, no es adecuada para todos los proyectos o incluso en algunas partes de los proyectos.
Cuando los proyectos involucran interfaces externas complejas o se está utilizando nueva tecnología, las estimaciones se vuelven aún más difíciles de acertar. Estos son riesgos que a menudo son difíciles de cuantificar por adelantado y generalmente solo se descubren a medida que se realiza el trabajo.
Resumen
Una aplicación de software es como un iceberg: el 90% no está visible. La mayor complejidad en la aplicación se encuentra debajo de la línea de flotación y es invisible para el usuario. La próxima vez que se pregunte por qué los proyectos de software parecen ser tan difíciles de realizar, tal vez tenga tiempo para pensar en los desarrolladores. En general, están trabajando duro para cumplir a tiempo contra una ola de desafíos y complejidad.