Lanzamientos de Software: ¿Cuándo es Suficientemente Bueno, Suficientemente Bueno?

by Rosario Disomma
Lanzamientos de Software: ¿Cuándo es Suficientemente Bueno, Suficientemente Bueno? thumbnail

En julio, EuroPython 2013 tuvo lugar en Florencia, Italia por tercer año consecutivo. Un poco sobre mi: Soy italiano y soy programador de Python, por eso estoy emocionado de compartir más sobre mi experiencia en EuroPython. Python tiene una comunidad increíble, llena de algunas de las personas más inteligentes e inspiradoras de la industria de la TI. Después de ser parte de esta comunidad durante siete años, puedo decir honestamente que las conferencias de Python son todo sobre las personas. Las personas hacen que esta comunidad sea grandiosa.

Una de esas personas inspiradoras es Alex Martelli, ingeniero senior en Google y miembro de la Fundación del Software Python. Presentó una conferencia principal en EuroPython este año titulada ¡”Suficientemente Bueno” es Suficientemente Bueno! o, como él dijo, citando a Richard Gabriel: el enfoque de Nueva Jersey, también conocido como “Peor es Mejor” versus el “enfoque de MIT/Stanford, también conocido como “Lo Correcto”. No estaba seguro de sobre qué hablaría, pero el título era intrigante. Y una cosa que he aprendido de las conferencias de Martelli durante los últimos siete años es que cuando habla, lo mejor que puedes hacer es escuchar, aprender y tomar notas. Así que, eso fue exactamente lo que hice.

La conferencia principal examinó dos enfoques diferentes para el lanzamiento de software. El primero, “Lo Correcto”, recomienda esforzarse por la perfección (conformarse con un lanzamiento de software que esté por debajo de “perfecto” es un compromiso lamentable). El segundo, “Peor es Mejor”, dice mantenerlo simple, simplemente suficiente, lanzar pronto, lanzar a menudo, obtener mucho feedback (este es el “enfoque de Nueva Jersey” porque Unix es un buen ejemplo y fue escrito en Nueva Jersey).

Martelli explicó cómo Richard Gabriel identificó cuatro valores fundamentales que estas dos aproximaciones tienen en común: simplicidad, corrección, consistencia y completitud. Luego continuó explicando que lo que realmente importa es la prioridad que se les da a estos valores. Las conclusiones de Gabriel pueden resumirse en estas dos citas:

La filosofía de hacer lo correcto se basa en dejar que los expertos hagan su trabajo de expertos

la cosa hasta el final antes de que los usuarios la reciban. 

Peor-es-mejor aprovecha las ventajas naturales de lo incremental

desarrollo. La mejora incremental satisface algunas necesidades humanas…

Fue aún más lejos, señalando cómo la interpretación de Gabriel se acerca a lo que Eric Raymond describió en su libro, “La Catedral y el Bazar”, en el cual describió dos modelos divergentes de desarrollo de software: la catedral, donde los expertos están a cargo y el núcleo se trata de expertos haciendo cosas de expertos, versus el Bazar, que es fuente de multitudes y caótico, donde la multitud está a cargo e incluye personas que están directamente involucradas, pero inevitablemente incluso las personas que solo están ayudando están allí, porque necesitan el producto del bazar para realizar trabajos no relacionados.

Obviamente, el enfoque de Raymond estaba en los errores y creía que un millón de ojos harían el proceso de descubrimiento de errores más rápido, y ese es exactamente el punto. Para tener a un millón de personas mirándolo, tienes que liberar el código. Tienes que sacarlo al mundo real y dejar que la gente lo use. Como dijo Martelli, si quieres liberar solo la “Perfección”, si quieres que el experto haga lo de experto, entonces necesitas un “Gran Diseño de Antemano”, una identificación perfecta de los requisitos, una arquitectura perfecta, un diseño perfecto, implementaciones perfectas, etc. ¡Y tomará una eternidad! Pero aún más importante, la vida real no tiende a cooperar.

Para citar nuevamente a Martelli, “La vida real no tiende a cooperar.” Los requisitos cambian, al igual que la arquitectura, el diseño y la implementación. El desarrollo iterativo es el camino a seguir. Despliega algo, corrige errores, mejora, utiliza control de versiones, revisiones de código, estilo de código, pruebas (si no estás probando, estás buscando problemas) y por último, pero no menos importante, documenta claramente lo que has hecho.

Esto no significa que debamos bajar nuestras expectativas. Como señaló Martelli, “nuestro sueño debe seguir siendo grande, pero la mejor manera de lograr esos sueños sigue siendo lanzar temprano y frecuentemente.” Continuó mostrando ejemplos sobre arquitecturas perfectas que nunca fueron implementadas, lanzadas, o que perdieron la batalla contra sus rivales no tan perfectos, incluyendo, Xanadu vs WWW, TCP/IP vs ISO/OSI, MIT ITS vs UNIX.

El video de la conferencia principal tiene una duración de aproximadamente una hora, pero realmente sugiero que todos los que desarrollan software deberían verlo. Incluso si no estás de acuerdo con las conclusiones, es una gran fuente de información. Grabación de la conferencia principal: http://www.youtube.com/watch?v=gHG9FRSlPxw

Mi gran pregunta después de la conferencia fue, ‘¿Cuándo es “suficientemente bueno” suficientemente bueno?’ ¿Cuándo llega ese momento, cuando estás en medio de un proceso de desarrollo, en el que puedes decir, “¡Hey, es hora!” Afortunadamente, la respuesta a mi pregunta ya estaba en la conferencia de Martelli, solo esperando ser notada.

Sugerencia: aquí tienes un extracto del artículo de Eric Ries, autor de “The Lean Startup”, Good enough never is (or is it?). Esta es su definición de “minimum viable product”.

“El producto mínimo viable es esa versión de un nuevo producto que permite

un equipo para recopilar la máxima cantidad de aprendizaje validado con el menor esfuerzo.

¡Ahí está! Esa es la respuesta que buscaba. Implementa algo que mejore la vida de alguien, algo que resuelva algún problema real del mundo. Hazlo tan pronto como esté en un estado que permita que tú y tu equipo aprendan de las interacciones de usuarios reales, recolecten datos reales y obtengan retroalimentación real. Aprende a lidiar con el hecho de que los usuarios viven en el mundo real – y ese mundo es imperfecto. Pero la alternativa es peor; si solo esperas a que tu software crezca a la perfección dentro de una catedral, nunca lo lanzarás.

La perfección es un proceso, no un estado. Parafraseando a Eduardo Hughes Galeano,  la utopía es como intentar llegar al horizonte que nunca alcanzarás, pero nos impulsa a avanzar.