El objetivo no es terminar

Nos lanzamos a programar con el objetivo incorrecto: terminar. El software nunca se termina, así que partir con el objetivo de terminar es partir con el barco hacia el arrecife. Lo vas a hundir. El software evoluciona o degenera, pero nunca se termina.

El verdadero objetivo es hacerlo lo mejor posible con los recursos que se tienen. Esto lo estoy experimentando de primera mano desde hace tiempo con mis propios proyectos. Es una visión basada en la experiencia.

Cuando hemos pensado que teniamos que terminar un hito, pocas veces hemos conseguido implementar lo que teníamos en mente en el tiempo y forma imaginados. Sin embargo, el 100% de las veces que hemos perseguido terminar, hemos introducido bugs y problemas de regresión.

Por otra parte, cuando hemos trabajado en proyectos colaterales con el fin de construir una buena herramienta en lugar de "terminar algo", hemos alcanzado una calidad que sobrepasa lo que podíamos imaginar. Calidad significa, conseguir un producto que nos aporta valor en corto plazo de tiempo y que nos permite seguirlo evolucionando con poco esfuerzo para seguir ampliando su valía. Los dos frameworks open source que he desarrollado en mi vida confirman esta idea. La clave ha sido abordar pequeñas funcionalidades de necesidad prioritaria, pensando siempre en cómo se utilizarían y no en cuándo estaría terminado.

Cuando nos sentamos a programar no se debe tener la mente puesta en sacar la próxima release. La mente debe estar concentrada en resolver lo mejor posible el próximo criterio de aceptación o el próximo test. El único momento en que se puede hacer énfasis en "terminar" es cuando un test unitario está rojo y hay que conseguir el verde.

No se puede desarrollar con prisa porque se consigue justo lo contrario de lo que se quiere. Cuando cambiamos prisa por concentración se alcanza un beneficio espectacular. Como dicen en el libro Rework, la palabra ASAP (As soon as possible) es un veneno.

En muchos proyectos seguiremos viéndonos obligados a dar estimaciones muy abstractas a medio y largo plazo pero todo el mundo sabe que las estimaciones de este tiempo son casi como tirar los dados. Si te ves obligado a estimar lo inestimable, al menos no te creas tu mismo que el objetivo es cumplir con esa estimación. El objetivo es entregar la herramienta más útil al cliente y para ello hay que priorizar adecuadamente, meter la tijera y trabajar sin el objetivo de llegar a esa supuesta estimación.

Enjoyed reading this post?
Subscribe to the RSS feed and have all new posts delivered straight to you.
  • http://cnatra.blogspot.com CNatra

    Totalmente de acuerdo.
    Cada día me reafirmo más en que si quisiéramos poner todo lo que nos gustaría en cada producto, no terminaríamos nunca, por lo que terminar significa, como bien dices, en conseguir sacar adelante y con calidad lo que más valor aporta al negocio del cliente.

  • http://twitter.com/#!/jbeerdev Jose B. Cortés

    Muy cierto, Carlos…. a veces nos obsesionamos tanto con las fechas previstas para sacar las releases y dejamos un poco de lado el “hacer bien la tarea”. Muy buen post. 🙂

  • http://developing.frogtek.org Pedro

    Hola Carlos. Yo a veces también tengo esa sensación que planteas. Pero a veces me da la impresión que también introducimos bugs por no conocer 100% el problema en cuestión, a parte de por terminar dicho problema. Priorizamos terminar algo en vez de priorizar entender el problema , cuando he desarrollado cosas para mi me ha dado la impresión de hacerla con menos bugs. Aprovecho para nombrar el libro de rework de nuevo donde también dicen que sus herramientas son buenas dado que ellos mismos fueron su propio cliente.

  • http://moidev.com Moises Gallego

    Tienes toda la razón del mundo.
    Yo en mis proyectos personales, donde soy yo el que toma las decisiones, no pongo nunca tiempos, si hitos que alcanzar, pero nunca cuando alcanzarlos.
    Por ejemplo ahora llevo sin avanzar una semana aun trabajando todo el tiempo en el proyecto, por que estoy o bien refactorizando o mejorando el entorno de integración. Que mas da si para la siguiente versión tardo una semana mas o un mes, no tengo prisa, lo que quiero es que el resultado sea el mejor posible.
    Otra cosa es cuando tienes unos tiempos que cumplir 🙁 pero es lo que hay.

    Muy bueno el articulo.

  • Antonio Manuel Rubio Cuenca

    Me ha gustado mucho el artículo.

    Sobre la frase: “Nos lanzamos a programar con el objetivo incorrecto: terminar. El software nunca se termina, así que partir con el objetivo de terminar es partir con el barco hacia el arrecife. Lo vas a hundir. El software evoluciona o degenera, pero nunca se termina.”

    Lo he estado hablando con unos amigos y hemos llegado a la conclusión que el proyecto termina; lo hace cuando el cliente deja de pagar.