Esta es la primera entrega de una serie que pretende reunir algunos de los principios y buenas prácticas más populares en el desarrollo de software que nos ayudan a seguir la filosofía Kaizen en esta profesión.
Kaizen es una palabra japonesa que significa ‘cambio a mejor’, y es un concepto que abraza el proceso de mejora continua, basado en acciones concretas y sencillas. Es una mentalidad que potencia el cambio y el abandono de las posiciones estáticas, y constituye un proceso que no acaba nunca.
Lo que me resulta enriquecedor de tener este pensamiento instalado en la mente, es que me ayuda a buscar siempre mejorar cada día o en cada proyecto, aunque sea una simple y pequeña inversión de unos minutos en mejorar respecto al día anterior.
Para esta serie de artículos, me voy a centrar en esta acepción sencilla, sin profundizar en los planes de acción y ceremonias que se aplican en el mundo de la producción industrial cuando hablamos de Kaizen.
La regla del Boy Scout:
Deja siempre el campamento más limpio de como lo encontraste
Uncle Bob lo llama aplicar la “regla del boy scout”, Martin Fowler lo llama refactor oportunista, pero en esencia vienen a decir lo mismo.
Este principio es bastante simple, y lo que viene a decir es que deberíamos comportarnos como hacen los Boy Scout cuando salen al campo, que dejan la zona en la que están un poco mejor que se la encontraron al llegar.
Aplicado al desarrollo de software, lo que quiere decir es que cada vez que modificamos algo de código (un método, una clase, etc), deberíamos dejarlo un poco mejor que lo hemos encontrado.
Para esta regla hay que aplicar cierta empatía y sentido de trabajo en equipo, ya que no hay que limitarse a recoger nuestra propia “basura”, sino que debemos recoger y limpiar un poquito de la “basura” que nos encontramos.
Otra característica que hace de esta regla algo bastante simple y productivo, es que no hace falta (ni es recomendable) reconstruir todo el código que veamos, sino simplemente hacer pequeñas acciones cada vez que nos lleven pocos minutos, como poner un nombre más expresivo, extraer a un método o a una clase, o formatear el código. No se trata de refactorizar toda la aplicación hasta que se ajuste totalmente al ideal de perfección. Basta con intentar dejar cada archivo que abras mejor de como lo encontraste. Todo pequeño gesto contribuye a que el software que mantenemos no se degrade, y que incluso mejore con el tiempo.
Conclusión
Independientemente del estado en el que se encuentre nuestro desarrollo, si de manera constante terminamos nuestra jornada y está un poco mejor que cuando la empezamos, a largo plazo veremos como mejora nuestro flujo de entrega de valor, y además evitaremos que nuestro producto caiga en la espiral negativa de la Teoría de las ventanas rotas, que veremos en próximas entregas.
Nota: Este texto fue publicado originalmente en el blog de Kirei Studio.