Extreme Programming para Milennialls y Gen Z

Puedes leer este post en inglés aquí.

Crear software es difícil. Y cuanto más aprendo sobre la historia de nuestra industria, más me doy cuenta de que siempre ha sido así. En 1968, en la primera Conferencia de Ingeniería de Software de la OTAN, algunos asistentes empezaron a hablar del término Crisis del Software para referirse a lo difícil que era crear software útil y eficiente en un tiempo razonable. En 1972 Edsger Dijkstra también habló sobre ello en su discurso al ganar el Premio Turing.

¡La principal causa de la crisis del software es que las computadoras se han vuelto varios órdenes de magnitud más potentes! Para decirlo sin rodeos: mientras no había computadoras, la programación no suponía ningún problema; cuando ya tuvimos algunas computadoras básicas, la programación se convirtió en un problema leve, y ahora que tenemos computadoras muy potentes, la programación se ha convertido en un problema gigantesco. - Edsger Dijkstra

Edsger Dijkstra se maravilló de lo potentes que eran las computadoras en los 70. Seguro que le hubiese gustado haber tenido una bola de cristal para entender lo que estaba por venir. La gente dejó de hablar de la crisis del software a finales de los 80 porque psicológicamente es extremadamente difícil estar en modo de crisis durante más de dos décadas. Pero la crisis del software nunca terminó. No realmente.

Comparte este post en 🐦 twitter o suscríbete a mi newsletter With a grain of salt para recibir un email con novedades cada cierto tiempo.

Y de repente eran los 90. E Internet estaba en auge con productos digitales que requerían un time to market mucho más corto. Lo que implicaba ciclos de vida más cortos y requisitos que cambiaban constantemente.

Desastre

La mayoría de los proyectos de software (funcionalidad, producto) terminaban en desastre. Y eso todavía pasa hoy en día. Porque nada ha cambiado realmente. Estoy seguro de que te suenan o has vivido algunas situaciones desastrosas:

Pero, ¿por qué fracasan los proyectos de software? No, en serio. ¿Por qué? Sé que has estado en algunas de estas situaciones. Pero, ¿cómo podrías evitarlas? En los 90, Kent Beck se hizo la misma pregunta. Y después de años de experimentación publicó Extreme Programming explained.

La madre de Agile

Extreme Programming es la madre de lo que hoy en día algunas personas llaman “metodologías ágiles”. En realidad, eso no es del todo cierto porque otras iniciativas similares surgieron en los años 90: Rapid Application Development, Feature Driven Development, Pragmatic Programming o Adaptive Software Developmet. Pero estas no son metodologías. No realmente. ¿Sabes por qué cuando alguien habla de implementar metodologías ágiles, todo suena tan vacío y rancio? Porque las metodologías ágiles no se pueden implementar. No existen. No hay nada que implementar. Agile no se trata de metodologías. Se trata de cultura. Algunos personas se dieron cuenta de esto en los 90 porque su vida estaba llena de metodologías. Y las despreciaban. Extreme Programming nació como un cambio cultural. Una forma diferente de crear software reduciendo riesgos y evitando desperdicios.

Extreme Programming propone adoptar ciertos valores, algunos principios y algunas buenas prácticas para planificar, desarrollar, testear, comunicar y diseñar. Ninguno de estos valores, principios o prácticas está escrito en piedra. Aunque la mayoría de ellos han resistido la prueba del tiempo. Por ahora voy a saltarme las prácticas o reglas porque se han escrito libros completos sobre cada una de ellas. Échales un ojo aquí. Pero sí quiero detenerme en los valores y los principios.

Valores

Principios

No tan simple

Pero, ¿por qué fracasan los proyectos de software? No, en serio. ¿Por qué? Todavía no he contestado esa pregunta. ¿Qué resuelve realmente Extreme Progamming que las metodologías anticuadas no resuelven? Porque, a primera vista, parece sólo una metodología light. Otro conjunto de reglas.

Las personas, siempre queremos que algo nos lleve a otra cosa. Pero el plan casi nunca sale como se esperaba. Tendemos naturalmente al determinismo causal: cada evento que sucede es causado por algo que sucedió antes. Y esto es cierto, pero generalmente ignoramos la complejidad: ningún evento tiene una sola causa. Nuestras mentes tienen un sentido de causa y efecto sobredesarrollado. Es por eso que el determinismo causal nos permite diseñar, planificar y estimar cuánto tiempo nos llevará poner el código en producción. Pero gracias a que nuestras mentes lineales son tan malas para entender la complejidad, cuando la ignoramos, estamos condenados al desastre.

Los equipos de Ingeniería son sistemas sociales complejos que crean y mantienen sistemas de software complejos. Y, por alguna razón, nuestro primer impulso para evitar el caos es crear un sistema de reglas. Una metodología. Pero un sistema complejo solo puede ser controlado por un sistema más complejo. Entonces, las metodologías que creamos acaban siendo más complejas que el sistema en sí. Porque matemáticamente tiene sentido. La burocracia y el Dark Agile tienen sentido cuando se piensa en el control. No hay otra forma de controlar un conjunto de sistemas complejos.

Si te vuelves a fijar en los valores y principios de Extreme Programming, puedes ver que están ahí para ayudarte a navegar la complejidad en lugar de tratar de domarla. Esto no es algo que solo Kent Beck se haya dado cuenta. El titular de The Nature of Software Development de Ron Jeffries es Mantenlo simple, hazlo valioso, constrúyelo pieza por pieza. Mantenlo simple porque agregar más complejidad a un sistema que ya es complejo de por sí, siempre empeora la situación. Favorecer la simplicidad tiene sus ventajas y desventajas, pero a nivel de sistema socio-técnico, los beneficios siempre superan a las desventajas. Hacerlo valioso tiene mucho que ver con el feedback rápido. ¿De qué otra manera vas a saber si lo que estás creando realmente aporta valor? Y construirlo pieza por pieza es otra forma de hablar de cambios incrementales.

The Mythical Man Month

Pero esto no es algo que las personas se dieron cuenta en los 90. Frederick Brooks cuenta la historia de cómo IBM construyó OS/360 en su libro The Mythical Man Month. Habla de las lecciones aprendidas mientras construía un proyecto de software tan grande en los 60. Hace 50 años.

Añadir personas a un proyecto de software atrasado lo atrasa aún más. - Frederick Brooks

Brooks se dio cuenta de que la mayoría de las personas que se dedican a la Ingeniería de Software son optimistas. Por lo que sea, asumimos que todo saldrá bien. Una de las razones es que ignoramos la complejidad. No solo la del software sino también la de nuestro entorno social. Olvidamos que crear algo en equipo es complejo. Las interacciones entre personas no se pueden ignorar. El equipo no tiene que ser grande para que sea complejo. Los números grandes y la complejidad no tienen mucho que ver. Toma el problema de los tres cuerpos como ejemplo.

Es la gente, estúpido

Edsger Dijkstra pensó que los problemas eran las computadoras. Y en parte tenía razón. Pero las computadoras potentes solo nos permiten crear software más potente. Y el software potente se crea en equipos. La creación de software, especialmente dentro de un equipo, tiene más que ver con las personas que con el software en sí. La solución y los procesos deben tener en cuenta la complejidad de la estructura social. La mayoría de los problemas en Ingeniería de Software surgen porque las personas somos complejas e impredecibles.

Extreme Programming es un buen sitio para empezar. Si piensas que sus principios y valores son demasiado simples es porque lo son. No subestimes lo compleja que puede volverse una situación cuando añades solamente una nueva práctica. Y no intentes domesticar la complejidad. Controlarla es imposible. Intenta navegarla.

Comparte este post en 🐦 twitter o suscríbete a mi newsletter With a grain of salt para recibir un email con novedades cada cierto tiempo.