¿Cuándo está terminado un proyecto software?
Un artículo de Rafa G. Blanes
No hace mucho, publiqué "The Coder Habits: Los #39# Hábitos del Programador Profesional", libro que he hecho con mucha ilusión y siguiendo más o menos mi propio flujo de trabajo para escribirlo.
Este flujo de trabajo propio, consiste básicamente en:
- Microtareas añadidas a Wunderlist.
- Selección de temas.
- Creación de los contenidos.
- Revisión de éstos.
- Buscar y leer documentación.
- Comprobar qué opinan otros profesionales.
- etc.
Y, cómo no, varias pasadas de revisión y corrección, todo ello durante varios meses en los quizá tenía libre media horilla una tarde para el nuevo libro, dos horas un sábado, etc.
Lo curioso es que en cada una de esas pasadas de revisión, siempre encontraba algún detalle que mejorar, un párrafo demasiado denso que mejoro aligerándolo con expresiones más ágiles y sencillas, algún error de puntuación que me lleva a usar la RAE más de lo que me gustaría, una nueva matización o la corrección de la repetición de un mismo concepto en una sección.
No hace mucho, precisamente comentaba con un compañero que es difícil determinar cuándo consideras que el libro está "listo" y cuándo puedes dar por terminado el trabajo para su publicación, porque con cada revisión, siempre encuentras algo que te gustaría mejorar, o algo que antes te sonaba muy bien pero que ya no.
Por cierto, recomiendo hacer una lectura en voz alta como parte del proceso de revisión, así se encuentran expresiones con una sonoridad extraña.
Por tanto, llegamos a la conclusión de que un libro "nunca está terminado del todo", esto es, puede que alcance un punto de madurez en el que crees que ya está listo para darlo a conocer con profesionalidad y calidad, pero da que pensar que si lo revisas diez veces más, quince o veinte veces más, el libro va a cambiar necesariamente en muchos aspectos. No en vano, es común que los autores revisen sus propias obras muchos años más tarde después de publicación (más aún si han tenido cierto éxito).
Difícil dar por acabado un libro. Y exactamente lo mismo ocurre en un proyecto software.
Cada vez que reviso alguno de los proyectos en los que he intervenido, siempre encuentro algún pequeño detalle que quiero mejorar, quizá una mejora en el diseño, o encuentras en algún sitio recóndito la posibilidad de aplicar un pequeño refactoring, o se te ocurre externalizar esas clases de ayudar como librería independiente, o quieres aprovechar una nueva característica de la última actualización del framework que utilizas.
Dejando al margen que al proyecto se le puedan pedir nuevos requisitos y funcionalidades, yo no sería capaz de afirmar categóricamente que un proyecto software ya está terminado "completamente"; funciona, sus tests pasan, cumple las necesidades del cliente a la perfección, pues maravilloso, está listo para ponerlo en producción, pero siempre vamos a encontrar qué mejorar, no me cabe la menor duda, tanto en la calidad de su código, su diseño y la calidad también de sus tests.
Por tanto, es difícil afirmar que exista un software "perfecto", podrá ser perfecto desde el punto de vista de su funcionamiento, pero siempre va a haber algo que mejorar en un proyecto con miles o cientos de miles de líneas de código.
Ahora bien, mejorar y cambiar porque sí, tampoco tiene sentido. Yo siempre me pregunto qué aporta este nuevo cambio que veo necesario: si simplifica, hace el código más elegante, legible, fácil de mantener y reutilizable, entonces es un cambio necesario, pero si no hace nada de eso sino todo lo contrario, mejor dejarlo todo como estaba. Recuerdo que hace muchos años, cambiaba cosas sin preguntarme si hacía más complejo el diseño o si ofuscaba un poco la solución; ahora siempre cambio algo pensando en simplificar. Punto.
Cambiar por cambiar, además, puede resultar peligroso si el proyecto no está suficientemente respaldado por pruebas; si no lo está, mejor dedicarnos a tener un conjunto de tests de calidad y después ya nos podremos dedicar a mejorar lo que queramos.
Antes de comenzar un nuevo ciclo de desarrollo, siempre intento dedicar algo de tiempo a mejorar aspectos del ciclo anterior que, quizá, no quedaron demasiado bien o a resolver aquella deuda técnica pendiente; esto es también un modo de preparar el terreno para la nueva funcionalidad que se va a incorporar.
Siendo así las cosas, no entiendo que un desarrollador se pueda aburrir en algún momento, porque aunque todo funcione perfectamnete, siempre hay algo que optimizar y mejorar.
Yo creo en la mejora continua e iterativa, creo más en construir algo de calidad poco a poco, y no a impulsos (mucho hoy y nada en la próxima semana). Prueba a hacer cinco micromejoras que te consumen diez minutos de tu tiempo en lo que sea durante un mes seguido. ¿Qué pasará cuando hayas acumulado cientos de micromejoras en tu proyecto?
No en vano, uno de los proyectos más longevos de los que soy reponsable ahora mismo (una plataforma de telegestión de contadores digitales), incluso después de siete años y de varias versiones y de haberse desplegado para muchos clientes, de vez en cuando nos encontramos con un pequeño bug.