archivo

Archivos diarios: septiembre 23, 2012

Avanzar no es no parar.

Ron Jeffries realizó la siguiente reflexión (traducción libre): “Cuanto de manera más frecuente nos tomemos un momento para reflexionar sobre cómo van las cosas, probablemente nos daremos cuenta más pronto en aquellas situaciones en las que nos estemos saliendo de la ruta más óptima”.

Huir hacia adelante no es la solución, ejecutar trabajo no tiene por qué acercarnos a la meta.

¿Cómo estamos?, ¿qué ha pasado?, ¿qué hemos hecho mal?, ¿en qué hemos acertado?, ¿en qué podemos mejorar?, ¿cómo podemos hacerlo?, de las medidas que tomamos anteriormente ¿qué ha funcionado?, ¿cuál ha sido su impacto real en el proyecto?.

De nada vale todo eso si no tienes la voluntad de asumir errores. Realmente ahí es donde radica la dificultad de todo, en asumir errores.

En el desarrollo de software los extremos no son buenos. A veces se le da al programador un diseño tan detallado que básicamente lo que hace es traducirlo a código fuente en el contexto del framework con el que trabaja. Otras veces no existe diseño o bien las especificaciones no son completas y son los programadores solos o en colaboración con analistas los que rellenan los huecos.

Desde mi punto de vista es importante que el programador sepa lo que tiene que hacer, es decir, que las especificaciones las conozca y que también conozca los objetivos no funcionales pero sobre esa base es necesario darle libertad para que dentro de esas restricciones pueda realizar la solución que resulta más conveniente.

Es necesario tener en cuenta que si se realiza un desarrollo en base a un análisis y/o diseño que se realizó hace tiempo es muy posible que quien lo hiciera no tuviera en cuenta determinados factores que sí son conocidos en el presente y no resulta lógico no echar cuenta a una solución mejor por tener en cuenta un trabajo que se efectuó sin conocer determinados tipos de detalles.

También es importante precisar que ese margen de maniobra permite que el programador dentro de esas restricciones pueda expresar su creatividad (algo que todos llevamos dentro) y realice su trabajo más motivado, algo que todos sabemos termina produciendo resultados de mayor calidad.

Como siempre es importante evaluar el contexto. No hay verdades absolutas. Es posible que en determinadas situaciones tener un nivel de detalle importante resulta fundamental, por ejemplo, cuando se externaliza a otro equipo de trabajo las tareas propias de programación de un desarrollo (o parte de él), aunque incluso en estos casos hay que tener en cuenta que la comunicación seguirá siendo necesaria (y se debe considerar un problema si no la hay) porque siempre quedará algún detalle que no se ha especificado al 100%.