[#ALM] El placer de hacer las cosas mal

Hola !

Como programadores, muchas veces somos demasiados perfeccionistas. Usualmente nos enfrentamos al difícil momento donde tenemos que terminar una tarea en un tiempo prefinido y nos toca decidir

– Seguir adelante con una solución poco elegante y que requiere poco tiempo

– Optar por una solución más robusta (o bonita) y que nos pone en la duda de si realmente lo terminaremos a tiempo

Esto es lo que se conoce como un momento incómodo. Y no me refiero a la deuda técnica o a dejar algo que luego se alguien detecte como code smell. Esto es más importante, tu salud es la que está en juego. Una porción de código bruto que escrites hoy, es un developer enfadado mañana. Un developer enfadado mañana, especialmente contigo, nunca suele ser una buena idea.

Por ejemplo, supongamos que tenemos que migrar una app que funciona con Kinect SDK V1.5 para que utilice Kinect SDK V2. Es casi seguro que, además de los cambios propios de código de la sintaxis del nuevo sensor (skeleton por body por ejemplo), por el camino me dedique a refactorizar a mejorar algunas otras cosas y que después de muchas lecciones aprendidas quiera tirar y hacer una parte importante de nuevo de esa app.

Todo esto está muy bien (y es lo que seguramente terminaré haciendo), sin embargo si aplicamos la máxima de solo hacer el trabajo definido en el Sprint, sólo deberíamos migrar el SDK. No deberíamos aplicar ningún otro tipo de cambio o mejora.

Pensemos en diferentes escenarios

– ¿Qué sucede si solo migro el SDK a la versión 2.0?. El trabajo está completado, el Sprint puede cerrarse con éxito.

– ¿Qué sucede si el proceso de refactorización es mucho más complejo de lo que inicialmente suponíamos y puede ocasionar que tenga que pedir ayuda a alguien del equipo?

Si pensamos en aportar valor a nuestros clientes, es muy probable que a nivel código la primera opción sea la más correcta. La funcionalidad final de la aplicacióno no cambiará por más que dentro esté todo hecho una oda a los espaghettis. La segunda opción nos llama también a la premisa de aportar valor con nuestro equipo de trabajo, finalmente a hacer un trabajo de calidad.

El tema tiene muchas aristas y no hay una solución simple que se pueda aplicar. Es por eso que Scrum no es para aficionados. Si alguien me pregunta a mi, yo seguramente optaría por la 2da opción. Eso sí, primero solo migrando el SDK, y luego aprovechando para crear un branch específico para aplicar las mejoras. Es muy probable que el 2do trabajo entre en un próximo Sprint, pero si no doy lo mejor de mi mismo para hacer las cosas bien, pues no podré dormir 😀

Saludos @ Madrid

/El Bruno

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.