La Pastilla Roja

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.

Estos últimos días he estado rememorando todos los proyectos en los que he participado, que desde el 95 a esta parte son unos cuantos. Recopilando esa experiencia voy llegando a la conclusión de que casi todas las metodologías comunmente empleadas se equivocan en el objetivo fundamental. A renglón seguido voy a proponer mi conjetura sobre el error de base, que se aplica no sólo a los proyectos informáticos sino también a cualquier proyecto vital.

Veamos, históricamente teníamos waterfall. Waterfall, en resumen, viene a decir que el cliente te da una serie de requisitos, digamos: el logro profesional, la casa, el coche, los niños, las vacaciones en la Costa del Sol, etc. Y tú diseñas como implementarlo: el empleo, la hipoteca, el leasing, la clínica de fertilización in vitro, la multipropiedad costera… El problema de waterfall es que resultaba muy difícil cambiar la salida del sistema una vez que se habían introducido las entradas, ya que no te puedes cambiar fácilmente de empleo, ni puedes divorciarte del banco, y a los hijos bien les quieres a morir bien preferirías haber tenido un perro según te hayas levantado de la cama ese día con el pie izquierdo o con el derecho.

Entonces alguien propuso Agile, que grosso modo es una herencia de metodologías japonesas para incrementar la productividad. El manifiesto agilista afirmó que lo importante ya no era saber exactamente desde el principio qué es lo que se quería hacer, sino maximizar la productividad y facilitar la incorporación de cambios de la mejor forma posible. Creo que fué entonces cuando aparecieron los yuppies 100% enfocados en ganar más dinero por día del que pueden razonablemente gastar.

Incrementar la productividad sin incorporar controles contínuos de calidad era suicida y es por eso que todos los equipos ágiles hacen también Test Driven Development (en la vida real el TDD es como acostarse con una persona antes de casarse con ella).

Hasta aquí teóricamente muy bien. Tenemos una idea aproximada de lo que queremos, tenemos una buena metodología de gestión de cambios y somos productivos. Excepto que por el camino se nos ha perdido el factor humano, concretamente, se nos ha olvidado cuánto miedo y cuánta frustración experimentan las personas durante el proceso de alcanzar los objetivos.

Y aquí vienen mis diez postulados sobre la gestión de proyectos basada en expectativas:

1. El cliente no sabe lo que quiere. Sabe cuales son sus objetivos de negocio. Pero no sabe cómo traducir estos objetivos en una lista de tareas técnicas. El gerente de cuenta tampoco lo sabe (porque tampoco es técnico). El único que sabe exactamente lo que hay que hacer es el programador. Pero al programador se le ocultan normalmente los objetivos de negocio. Por consiguiente, el programador va a ciegas respecto de los objetivos reales del proyecto.

2. El éxito se mide sólo en función de las expectativas. La productividad no importa. Con las herramientas modernas la productividad es tan grande que normalmente sobrepasa cualquier requisito de la demanda. El éxito de un proyecto no es lo que se alcanzó en términos absolutos, sino la diferencia entre lo que el cliente esperaba obtener y lo que obtuvo realmente. He aquí el gran malentendido de los story point. En Agile, el story point es una métrica abstracta del valor que obtiene el cliente. Se supone que cuantos más story points por sprint obtenga el cliente más satisfecho estará. Pero esto, en general, es falso. Lo que el cliente quiere realmente (aunque a veces pida otra cosa) es saber a priori cuántos story points obtendrá de forma segura por unidad de tiempo en el futuro próximo. En la vida cotidiana así es como mucha gente termina con el superpuesto directivo, la mansión, los niños, el perro, el smartphone, el superdeportivo y profundamente amargada y decepcionada.

3. La mayoría de la gente no aguanta trabajar bajo presión. La predictibilidad y la tranquilidad son mucho más importantes que la productividad. Esto es debido a que la mayoría de la gente es incapaz de gestionar la incertidumbre, pues la duda sobre lo que va a suceder les causa una ansiedad insoportable incluso cuando el resultado más probable de la incertidumbre sea un éxito rotundo. Es decir, la sensación de «éxito» en un proyecto no se percibe tanto por la velocidad a la que avanza sino por la cantidad de incertidumbre que reduce.

4. Los detalles sobre lo que está sucediendo no son para corazones sensibles. La mayoría de las personas se desmayan o entran en pánico cuando ven sangre. Es por esto, en parte, que al paciente lo sedan y a los médicos no les gusta tener público observando cómo trabajan, pues cuanta más gente haya mirando cómo está el pulso del paciente mayor es la probabilidad de que cunda el pánico si tiene un latido más rápido o lento que otro. El veto informativo no sólo se aplica al cliente o a los familiares del paciente, sino también a los propios gestores de cuenta. Por dicha razón, el Doctor House va por libre y no le comenta a nadie lo que está haciendo. Aunque si no se tratase de una ficción televisiva en la vida real a House lo habrían despedido tres veces en cada temporada por saltarse los protocolos.

5. Los planes son papel mojado, pero la planificación es imprescindible. Es imposible especificar a priori de forma completa y rigurosa todo lo que se requiere en un proyecto. Pero, por otra parte, si no se hace tal esfuerzo, a posteriori en el mismo instante en que algo salga mal (y siempre hay algo que sale mal) los incumbentes empezarán a culparse unos a otros sobre quién no se había enterado de qué. El desarrollo iterativo basado en adaptarse a las necesidades cambiantes del cliente es un plan suicida debido a que termina inexorablemente en una discusión acalorada sobre quién cambió qué y cuándo, en la cual el proveedor (aunque sea inocente) lleva siempre las de perder.

6. La metodología debe cambiar con la fase del proyecto. No era posible descubrir América calculando exactamente dónde estaba, ni agua para cuántos días se requeriría en el camino. Por otra parte, no es posible mantener un asentamiento colonial viable sin saber cuánta agua se necesita a diario. Es decir, con una metodología de colono nunca descubrirás América y con una metodología de descubridor nunca sobrevirás en América.

7. Obsesionarse con hacerlo todo bien conduce a resultados indeseados. El objetivo de un proyecto es lograr un resultado excelente y para ello hay que hacerlo todo siempre lo mejor posible. Nunca hay que despreciar las buenas prácticas pues se crearon por muy buenas razones, pero no se debe confundir el fin con los medios. Algunas personas se obsesionan tanto con las metodologías y los protocolos que estos acaban siendo un fin en si mismos. Y el día en que la metodología empieza a gobernar tu vida es que has perdido el norte, lo mismo seas un fanático del gantt o del sprint board o un fanático religioso. Las personas se aferran a rajatabla las metodologías y a los rituales porque les proporcionan una falsa sensación de seguridad.

8. Sólo un profesional puede juzgar el desempeño de otro profesional. Todos los programadores que he conocido son geniales. Y todos los médicos que he conocido son los mejores en su especialidad. Pero yo carezco de criterio para determinar si mi médico de cabecera es un milagrero o un matasanos.

9. Nunca hay que hacer caso de lo que dice la persona presuntamente a cargo. Esto es debido a que por el Principio de Peter las personas ascienden en la jerarquía hasta que no son capaces ni de formular sus propios objetivos. Hay que tener en cuenta que la explicación que da el responsable de algo consiste en un conjunto de justificaciones para demostrar porqué no es su responsabilidad. Los mayores desastres son siempre causados por los «mejores» gestores debido a la confianza ciega que la gente deposita en ellos.

10. Cualquier metodología que ignore el factor humano está condenada al fracaso. No se puede poner en práctica un proceso sin tener en cuenta cómo se sentirán las personas implicadas en ese proceso. Esto los militares lo saben muy bien y es por eso que se pone a los soldados a cantar en grupo, además de muchísimos otros rituales castrenses. Como por alguna absurda razón nos parece ridículo que los programadores se junten para cantar, lo que hemos hecho es tratar de eliminar el factor humano de la metodología, automatizarlo todo con sistemas de integración contínua y reducir al empleado a un robot que produce story points bajo una estricta supervisión. Lo cual sería una idea fantástica de no ser porque el empleado no es un robot dotado de inteligencia.

Como conclusión, todo tiene que ver con el difícil equilibrio entre nuestras grandes esperanzas y la conciencia sobre lo que podemos alcanzar realmente. Si no fracasas y te equivocas lo bastante entonces es que tus objetivos no eran lo suficientemente ambiciosos. Por otra parte, los humanos reaccionan de forma muy desagradable ante el fracaso, e incluso sólo ante la idea imaginaría de fracasar. La solución a este dilema es ser capaz de encapsular los riesgos en una caja de seguridad, de modo que si todo explota los daños estén controlados. Es como correr Fórmula 1. No se trata de ir despacito por la pista para no salirte de ella. Sino de correr a la mayor velocidad posible en la confianza de que si te sales del trazado y das tres vueltas de campana destrozarás el bólido pero tú aún conseguirás salir de él en una sola pieza.

Post relacionado: Las zonas grises de Agile.