En PSP (Personal Software Process) o como pasarse de rosca midiendo se comenta el caso en el que un desarrollador "pierde" algún tiempo codificando (por supuesto que con algún errorcito) una función que valida fechas al estilo IsDate de Visual Basic... en realidad, idéntica al IsDate de Visual Basic.
¡Qué barbaridad! ¡Qué pérdida de tiempo! ¡Qué desconocimiento del lenguaje!
Ésta es una breve historia sobre cuatro programadores.
Programador A
Luego de un par de meses el Programador A que ha codificado la función ValidaFecha idéntica a IsDate ve ese código, se sonríe un poco y piensa "qué inútil". Borra el cuerpo de la función y lo reemplaza por la llamada a IsDate.
Programador B
Programador B no ha creado la función "inútil" para validar fechas. Luego de resolver el tema en una pantalla en particular copia y pega las 130 líneas de código en cada una de las 50 pantallas del sistema.
Pero después de un par de meses ve ese código en una pantalla, se sonríe un poco y piensa "qué inútil". Lo reemplaza por IsDate. Se queda pensando... revisa todas las pantallas y encuentra las mismas líneas junto a otras que hacen algo parecido. Está molesto, porque sabe que tiene que corregirlo y se le hace trabajoso. Le molesta pensar que tiene que probar nuevamente todas las pantallas del sistema. Finalmente, crea una clase dedicada a validaciones donde, entre otras, encapsula la función IsDate.
Programador C
Programador C ha comenzado igual que Programador B (copiando todo en todos lados), también busca en todo el sistema y las reemplaza por la llamada a IsDate en cada una de las pantallas.
Programador D
No sabemos qué solución adoptó el Programador D, pero en todo caso podemos estar seguros de lo siguiente: cuando lo vuelva a ver no reflexionará ni un segundo sobre cómo ha llegado allí, ni sobre si está bien o mal, salvo cuando se presente algún error (que puede ser en todo el sistema o en una pantalla en particular). En este caso corregirá el tema puntual y seguirá con su vida.
Ahora, con un poco de perspectiva, juzguemos a cada uno.
Obviamente Programador A es un junior, o apenas ha comenzado a programar en VB. Hizo lo mejor que pudo con las herramientas y el conocimiento que tenía. Trabajó prolijamente y en una forma tal que luego no tuvo problemas en mejorar el código a la par de su propio conocimiento.
Casi lo mismo podemos decir de Programador B. Pero en mi opinión tiene más mérito. ¿Por qué? Corrigió el error en todo el sistema y buscó la forma de que no le vuelva a suceder. Empezó un escalón más abajo que Programador A, y llegó más arriba. En realidad no importa si su solución es óptima o incluso correcta. El Programador B intenta solucionar los problemas "de aquí en más". Cuanto más se equivoque más aprenderá.
Lo único que ha aprendido Programador C es que existe una función llamada IsDate que valida fechas, que no es poco pero tampoco tanto. Es el tipo de persona que dice "muchos árboles" en vez de "bosque".
La vida del Programador D evidentemente pasa por otro lado. Supongo que poco le importará nuestra opinión de él o de su código, en tanto conserve su trabajo.
En definitiva, desde nuestro punto de vista, grandes desarrolladores que hemos nacido sabiéndolo todo y que nunca hemos reinventado la rueda, todo es una gran pérdida de tiempo. Sabemos perfectamente cuándo hay que usar IsDate y cómo se comporta por lo que nunca tendremos problemas con ella, y tal vez hasta vemos un poco inútil el encapsularla en una clase de validaciones.
Al resto de los mortales sugiero juzgarlos no por la corrección de sus soluciones en un momento dado, sino midiendo cómo capitalizan su experiencia a través del tiempo.
No hay comentarios.:
Publicar un comentario