Lo que sucede cuando un software se convierte en un agujero negro

Un agujero negro se empieza a formar cuando una estrella de masa al menos 2,5 veces la del Sol se convierte en una supernova e implosiona hasta formar una singularidad de la cual nada puede escapar.

De forma análoga, una aplicación de software lo suficientemente grande puede sufrir un proceso de colapso y convertirse en un agujero negro siguiendo la secuencia que viene a continuación.

Fué a Bjarne Stroustrup a quién le leí que “un sistema grande y complejo que no ha evolucionado a partir de otro más simple que funcionaba bien, no funciona y, además, es imposible arreglarlo para que funcione” (creo que esto es del libro The Design and Evolution of C++ publicado en 1994). Tal hipótesis se comprobó empíricamente muchas veces en el siglo XX y es por eso que se cambió el foco a proyectos ágiles.

De modo que es mejor empezar con un mínimo producto viable (MVP). El desafío es que aunque el producto sea inicialmente pequeño su arquitectura debe estar pensada para crecer. Ello supone un equilibrio muy difícil entre la simplicidad y la escalabilidad.

El MVP es, por lo general, una chapuza, aunque si los adoptadores tempranos están lo bastante necesitados, la empresa llega a la versión 2.0 que es la que suele tener verdadero éxito comercial. En la versión 2.0 ya se ha adquirido un buen conocimiento del problema a base de depurar la versión 1.0 pero el producto todavía lo mantiene poca gente y no ha crecido hasta un tamaño desmesurado. La versión 2.0 es una bonita estrella de tamaño mediano como nuestro Sol.

En la industria del software, con una buena versión estás en el negocio y con una mala estás fuera. Tras la versión 2.0 hay dos formas rápidas de morir: por el efecto del segundo sistema o por agujero negro.

El segundo sistema es, básicamente, rediseñarlo todo desde cero en contra del consejo de Stroustrup. Siguiendo la analogía se trata de crear una supergigante azul que pesa demasiado y genera demasiada gravedad y calor.

La dinámica del agujero negro en software

Siguiendo la secuencia principal la estrella 2.0 se convierte en una gigante roja que funcionalmente sirve para todo y no hace bien absolutamente nada. En este momento algunas cosas empiezan a pasar:

– Un grupo de desarrolladores radicales mantiene algunos puntos de vista inflexibles acerca de cómo debe ser la arquitectura del sistema.

– Al MVP se le van añadiendo funcionalidades sprint tras sprint.

– Individualmente, las funcionalidades parece que tienen sentido, pero están dictadas por las necesidades impuestas por diferentes clientes y todas juntas generan un producto complejo e inconsistente.

– Como los sprints son cortos, las prioridades cambian con frecuencia y muchas funcionalidades quedan inacabadas.

– El backlog del producto crece de forma continuada.

– Simultáneamente, cada vez se emplea una cantidad de tiempo creciente corrigiendo bugs.

– Los tests unitarios no son de gran ayuda pues aunque los módulos funcionen bien la arquitectura sigue fallando.

– Debido a la acumulación de deuda técnica, los jefes de equipo empiezan a quejarse sistemáticamente sobre la falta de recursos humanos para el desarrollo.

– Sin embargo, a pesar de agregar más recursos se incrementan los retrasos en las fechas previstas.

– Superado un determinado umbral de complejidad, se inicia un colapso cuyo desenlace fatídico es inevitable. Con cada nueva versión el software es más lento y más inestable hasta que llega un momento en el que no se dispone de ninguna versión reciente que alcance el nivel de calidad requerido para entrar en producción.

Síntomas de que la aplicación se está colapsando

– En cada versión se introducen más bugs que funcionalidades.

– Nadie confía realmente en que la última versión sea estable.

– En el dpto. de calidad ya no saben muy bién qué testear ni cómo.

– Cada vez se tarda más en sacar una versión.

– El rendimiento de la siguiente versión es sistemáticamente peor que el de la anterior.

– Empiezan a aparecer aplicaciones satélite que hacen lo mismo que debería hacer la aplicación original pero “mejor”.

– Se convocan reuniones recurrentes a diario para seguir el progreso de determinados temas.

– Los jefes de equipo críticos con la dinámica de trabajo empiezan a desaparecer de la plantilla por razones poco claras.

– El sprint board se ha convertido en lo que gobierna la estrategia de la empresa, dictando lo que se puede hacer (o no) y cuándo.

Razones del colapso

a) La arquitectura del software es tal que contiene la semilla de su propia destrucción.

b) Alguna pieza del producto causa problemas constantemente.

c) El rendimiento está sistemáticamente por debajo de lo aceptable.

d) La configuración y mantenimiento de la aplicación es extraordinariamente costosa.

Reemplazar una pieza defectuosa parece un problema fácil a primer vista, pero puede no serlo porque exista miedo de que el recambio será aún peor, o el programador que la desarrolló ya no está o existen acuerdos con terceros que obligan a usarla.

El rendimiento típicamente es malo por una o varias de la siguientes razones:

– Las peticiones de red son demasiadas.
– Los accesos a la base de datos son excesivos y/o ineficientes.
– La aplicación tiene una estructura en múltiples capas como una cebolla.
– Algunos algoritmos son demasiado costosos.

Las mayores ganancias se obtienen optimizando los recursos más lentos, por orden: red, disco, memoria y CPU.

Es frecuente que las herramientas para la gestión de la configuración sean paupérrimas. Se invierte mucho tiempo en lo que ve el cliente en detrimento de lo que necesitan los implantadores y operadores y despreciando el principio de cibernética que establece que la complejidad de cualquier sistema de control es siempre proporcional a la complejidad del sistema controlado.

Cómo eludir el agujero negro

Lo peligroso de la dinámica del agujero negro es que no es fácil percatarse de que la estrella está punto de colapsarse súbitamente. Con un producto en fase de “gigante roja” es necesario tomar medidas perentoriamente:

1. Reconocer que el producto requiere una re-ingeniería profunda.

2. Detener por completo el flujo entrante de nuevas funcionalidades.

3. Nombrar un nuevo arquitecto jefe.

4. Organizar sesiones de diseño donde todos los que tienen experiencia en el desarrollo y uso del software puedan participar en igualdad de condiciones.

5. En general, mejor evitar los comités para la toma de decisiones, pues tienden a adoptar soluciones “de compromiso” que no satisfacen por completo a nadie y carecen del coraje y la audacia necesarios para escapar del pozo gravitacional.

5. Quitar de en medio a los que obstaculizan el cambio, mandarlos un mes a la playa, o lo que sea…

6. Definir la batería de tests de aceptación de los cambios.

7. Especificar las dependencias entre los módulos y cómo se verá afectada cada parte con el cambio. Si esto no es posible, mejor pensar en abandonar el producto existente y volverlo a hacer.

8. Diseñar el plan de migración. Nunca sacar una versión que sea incompatiblle con la anterior. Por muchos problemas que resuelva, si es incompatible hacia atrás, se obligará al departamento comercial a vender el producto de nuevo abriendo una puerta de par en par a la competencia.

9. Quemar las naves. No hay vuelta atrás, o el producto se rediseña o muere, pero no se seguirá manteniendo la versión anterior pues ello implicaría igualmente la muerte.

10. Acordar el roadmap de desarrollo. No introducir nuevas funcionalidades a la espera de las cuales se encuentren los clientes. Se pueden introducir nuevas funcionalidades pero nunca condicionadas a un plazo de entrega distinto del de las necesidades intrínsecas de la re-ingeniería.

11. Inducir stress creativo. En ausencia de un plazo de entrega los programadores se relajan y empiezan a producir código muy bonito pero difícilmente rentable. Aunque no se esté a merced de las exigencias del cliente, el equipo aún tiene que sentir la presión para entregar algo que funcione bien en un período razonable de tiempo.

12. Vigilar de cerca las estadísticas de bugs y benchmarks.

13. Formar a todos los incumbentes en la nueva arquitectura. Ganarse a los campeones en cada departamento. Mentalizar a la gente de que cualquier proceso de cambio es inexorablemente traumático en alguna medida. Repartir relajantes musculares, evitar que cunda el pánico.

14. Hacer un piloto de actualización.

15. Actualizar al resto de clientes. Celebrarlo. Irse a casa.

Posts relacionados:
1-2-3 de por qué fallan los proyectos informáticos. (Versión Cerø)
Windows Vista y el Efecto del Segundo Sistema.
Cómo diseñar una aplicación escalable.

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Bookmarks
Esta entrada fue publicada en Organizando la Comunidad. Modelos de Desarrollo. Guarda el enlace permanente.

2 respuestas a Lo que sucede cuando un software se convierte en un agujero negro

  1. Pingback: Muerte por agilismo | La Pastilla Roja

  2. Pingback: Cómo sobrevivir a las estimaciones de software | La Pastilla Roja

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *