Velocidad de iteración vs Calidad de iteración

Estoy leyendo Simple Architectures for Complex Enterprises de Roger Sessions. No me queda mucho así que en breve espero que tengáis una reseña sobre el libro aquí, pero hoy voy ha hablaros de una cuestión que el libro trata de manera muy amena: la velocidad de iteración vs la calidad de iteración.

Cuenta Roger Sessions en su libro una curiosa historia para ilustrar la diferencia que existe en el desarrollo de software entre iterar buscando la mayor velocidad de iteración o iterar buscando la mayor calidad de iteración. Este es un tema que ya he tratado con anterioridad en este blog: No persigas tu cola…, pero la historia que cuenta Roger Sessions es realmente ilustrativa.

El Coronel Jhon Boyd, uno de los grandes pilotos de la época de los primeros reactores de combate y estratega reconocido, estudio una anomalía en la luchas aéreas entre los dos grandes cazas de la década de los 50. Cito aquí la historia tal y como Roger Sessions la cita en su libro, traducida al español lo mejor que he sido capaz, además añado un video sobre el tema (en inglés), que no solo de informática vive el hombre:

"El Coronel John Boyd estaba interesado no solo en cualquier lucha aérea, sino específicamente en los combates entre el MiG-15s y el F-86s. Como ex-piloto y consumado diseñador de aeronaves, Boyd conocía estos dos aviones perfectamente. Él sabía que el MiG-15 era mejor técnicamente que el F-86. El MiG-15 podría subir más rápido que el F-86. El MiG-15 puede girar más rápidamente que el F-86. El MiG-15 tenía una mejor distancia de visibilidad. El F-86 tenía dos puntos a su favor. En primer lugar, tenía una mejor visibilidad lateral. Mientras que el piloto de MiG-15 podía ver más lejos, el piloto de F-86 podría ver un poco más por los laterales. En segundo lugar, el F-86 tenía un control de vuelo hidráulico. El MiG-15 tenía control de vuelo manual.

La hipótesis más común por parte de los diseñadores aéreos era que la maniobrabilidad era el componente clave a la hora de ganar duelos aéreos. Evidentemente, el MiG-15, con su giro más rápido y su capacidad para escalar más rápido, podía mejorar la capacidad de maniobra del F-86.

Pero hubo un pequeño problema con todo esto. A pesar de que el MiG-15 era considerado un avión superior por los diseñadores de aviones, el F-86 era preferido por los pilotos. La razón por la que era preferido por los pilotos fue simple: en los duelos uno-a-uno entre MiG-15 y F-86, el F-86 ganó nueve de cada diez veces."

¿Cómo un avión inferior puede ganar de manera consistente a un avión superior? Era la pregunta que surge rápidamente. Boyd, tenía una teoría:

"Boyd concluyo que la cuestión determinante a la hora de ganar un duelo aéreo no era observar, orientarse, planear o actuar mejor. La cuestión determinante para ganar un duelo aéreo era observar, orientarse planear y actuar más rápido. En otras palabras, como de rápido uno podía iterar. La velocidad de iteración, sugirió Boyd, bate a la calidad de iteración.

La siguiente pregunta que se realizo Boyd es esta: ¿por qué el F-86 iteraría más rápido?. La razón, concluyo, era algo que nadie había pensado que fuese particularmente importante, el hecho de que el F-86 contase con un mando de vuelo hidráulico mientras que el MiG-15 tenía un mando de vuelo manual. Sin ayuda hidráulica, costaba un poco más mover el mando de vuelo del MiG-15 que el del F-86. Aunque el MiG-15 girase más rápido (o pudiese llegar más alto) cada vez que el mando era movido, la cantidad de energía necesaria para mover el mando era mayor para el piloto del MiG-15. Con cada iteración, el piloto del MiG-15 sufría un poco más de fatiga que el piloto del F-86. Según se iba fatigando un poco más, tardaba un poco más en completar su ciclo de observar, orientarse, planear y actuar. El piloto del MiG-15 no perdía por que pilotase peor. Perdía por que completar el ciclo de lucha cada le costaba más tiempo."

De esta observación se deriva la Ley de la Iteración de Boyd: la velocidad de iteración bate a la calidad de iteración.

Hoy en día todas las metodologías de desarrollo son iterativas. No hay otra manera de desarrollar software que en iteraciones en las que se repite la secuencia de combate del desarrollo de software: conocer el problema, analizarlo, implementar la solución, construir, probar (con diferentes variantes). La diferencia es que unas metodologías ponen el peso en la calidad de iteración (CMMI, RUP) mientras que otras ponen el peso en la velocidad de iteración (XP, Scrum). ¿Alguien duda de quien está ganando más combates?. La idea es clara, si te vas a equivocar, equivócate pronto, rectifica rápido en lugar de tratar de no equivocarte por todos los medios y quedarte sin tiempo para rectificar. A veces se describe esto como dinero por flexibilidad en lugar de dinero por información. Las metodologías guiadas por un plan, consumen muchos recursos trantando de asegurar las maniobras adecuadas, las metodologías ágiles tratan de realizar las maniobras de manera rápida y razonablemente adecuada. Si hay problemas siempre se puede rectificar… si el coste de rectificar es razonable y si tienes la ágilidad necesaria para no morir en el intento.

La esencia del software es iterativa, como la esencia del combate aéreo y no deja de ser curioso como ese énfasis en la iteración rápida aparece en todas las buenas practicas de la ingeniería del software, igual que en combate aéreo. Perseguimos encontrar rápido los errores, intentamos incorporar temprano el feedback de los usuarios, intentamos construir el software de manera frecuente y minimizando el coste de construirlo, etc…

¿Qué opinión os merece esta reflexión? ¿Mejor primar la velocidad de iteración o la calidad de iteración?

9 comentarios en “Velocidad de iteración vs Calidad de iteración”

  1. Me gusta la comparación que has hecho, pero es peligrosa. La idea de calidad de iteración, debe afectar no a la calidad de los construido, si no a su profundidad, a su alcance.
    Ciclos de menos “calidad” de OODA no significaría que la acción que haces es peor, si no que la has decidido con menos datos de observación. Aplicado al software no significaría que degradas el concepto de “producto terminada” en cada iteración, si no que has recapacitado menos tiempo en el análisis de lo que pide el cliente, por que esperas reaccionar enseguida si hay cambios.
    Hay un libro de las estrategias de John Boyd aplicados a estrategias empresariales, que me gustó bastante: Certain to Win (http://www.amazon.com/Certain-Win-Chet-Richards/dp/1413453767)

    Un saludo! De todas maneras me ha encantado la comparación! 🙂

  2. @Joserra: Sin duda nadie debe entender la idea que se cuenta en esta historía como que no se debe atender la calidad. La historia no es sobre calidad de software como bien apuntas.

    Tu lo has descrito perfectamente, incluso creo que sería mejor algo del estilo de velocidad de interación frente a profundidad de iteración tal y como tu propones. Excelente aportación.

    Yo por mi parte ya he comentado en alguna ocasión que la calidad del software no es opcional (http://geeks.ms/blogs/rcorral/archive/2006/09/02/En-el-software_2C00_-la-calidad_2C00_-no-es-opcional.aspx), no es algo con lo que se pueda especular…

    Gracias por el comentario y por la sugerencia del libro. Lo compraré.

  3. Nuevamente mi enhorabuena Rodrigo, una vez más logras hacernos llegar información de primera. Además eres un excelente comunicador.

    Saludos

  4. Sin duda Iteración rápida.
    A mi modo de ver, en cada iteración se van completando una serie de requerimientos, casos de uso, historias. Si la iteración es rápida no hay lugar para sobrecargar el diseño, o irse por las ramas.
    Tras cada iteración, realizamos pruebas de aceptación, a veces automáticas a veces con el mismo cliente, recibimos feedback, corregimos si es necesario y continuamos. Esto hace que las desviaciones sean mínimas, dándonos la flexibilidad (maniobrabilidad) suficiente para corregir las cosas a tiempo; No me estoy refiriendo solo al análisis, sino también a la planificación del proyecto. Iteraciones rápidas = más iteraciones = más puntos de control = menos probabilidad de desviaciones.
    Al hilo de lo que ha comentado Joserra, focalizamos el análisis, y como sabemos que nunca será la última iteración, que hay otras por venir, tenemos en cuenta que lo que estamos haciendo debe ser lo suficientemente flexible para poder cambiarse, extenderse y acoplarse con el resto de cosas, tener esto en mente desde el comienzo, no tiene precio.
    Extrapolando, lo que llamamos muchas veces prueba de concepto, maqueta, incluso beta, viene a ser un poco esto mismo, búscanos feedback y lo queremos cuanto antes.
    Carlos.

  5. @Julio: ¡Gracias! pero en esta ocasión el mérito no es mio… al menos no del todo…

    @Carlos: comparto lo que dices punto por punto.

    ¡Gracias por los comentarios!

  6. Rodrigo comparto tu vision y toma nota de las ideas que trasmites. Por lo pronto ya estoy consiguiendo desde la Oficina Tecnica de O… que se considere el tema de la metodologias agiles. Lo cual aunque pueda parecer algo sencillo creeme que me esta costando lo mio.

    Ya se ve la necesidad de iterar rapidamente. En fin pasito a pasito.

    Un saludo

  7. genial !! y saco otra conclusión sobre lo que ahs escrito (es lo que hacemos la gente poco creativa):

    “(el F-86) tenía una mejor visibilidad lateral. Mientras que el piloto de MiG-15 podía ver más lejos, el piloto de F-86 podría ver un poco más por los laterales”

    Esto también supongo que influyó y mucho, ya que la capacidad de observar para comprender, analizar y tomar decisiones es muy importante. Es decir, podemos “ir muy rápido” pero si el proceso de mejorar, a partir de nuestra performance es un proceso costoso; a la larga lo terminamos pagando evitando el aprender de nuestro desempeño (y esto es realmente una pena).

    Saludos

  8. @Miguel: Me alegro de que en O… lo estéis valorando. De verdad creo que las metodologías ágiles os podrían ayudar mucho. Se que a veces es dificil en organizaciones grandes el cambiar ciertas inercias o ciertas ideas preconcebidas sobre las metodologías ágiles, pero los casos de exito son muchos y sobre todo los costes de implatación son mucho menores. Los riesgos asociados a la posible perdida por fallo de implantación son muy muy asumibles.

    @Bruno: Cierto. Ver más y sobre todo tomar decisiones sobre aquello sobre lo que tenemos visibilidad real es clave. Planificar no es tomar decisione sobre el futuro sin tener visibilidad, sino tomar deciones sobre lo que vemos, que no hipotequen el futuro. Comparto lo que dices de aprender antes de tomar decisiones.

    ¡Un saludo, gracias por vuestro comentarios!

  9. Segú leí en la época (soy ya añoso) otra de las razones porque los Sabres derribaban mas Mig 15 que viceversa eran dos: 1) los pilotos norcoreanos no estaban tan bien entrenados como los estadounidenses y 2) el Sabre era mas pesado que el MIg y el error d elos pilotos nordcoreanos era “ganarle” en una picada al Sabre cuando el peso del mismo le daba mayor velocidad por la masa y por lo tanto sobrepasaba el avión ruso. El Mig 15 cuando fue estudiado porque un norcoreano entregó un MIg a los Norteamericanos. Se viói que era basicamente la copia de un motor inglés: el Roll Royce con un fuselaje rudimentario y pocos sistemas donde no importaba la seguridad del piloto y el Sabre era mas sofisticado y por ello mas pesado con triples sistemas (electricos, hidraúlicos, etc.) por si
    8 fallaba uno el MIg solo uno.
    Eso se decía en el mismo momento en que se desarrollaba la guerra.

Deja un comentario

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