Introducción a la Programación – Felipe Ramirez – 2da Edición

En términos computacionales, supongo que pertenezco a lo que sería la tierra media. Una época en la cual si querías ver un cuadro dibujado en la pantalla, había que programarlo; una buena máquina tenía 20 MB en disco duro y un monitor que soportara 16 colores era un lujo que muy pocos privilegiados podían tener.

En esos días, como programador debías tener lógica de programación o te morías de hambre, dado que sin lógica era imposible desarrollar nada. Ahora las cosas han cambiado. Pasó el tiempo y las máquinas mejoraron, mejoraron las herramientas y los lenguajes también; ahora colocar un cuadro es tan fácil como arrastrar y colocar una figura en la pantalla, y el desarrollador no sabe qué sucede atrás, tan bambalinas. ¿Tengo algo en contra de la mejora continua de equipos, lenguajes y herramientas? Para nada. Vivo de ello.

Mi preocupación va en otro sentido. Pasan los años y como consultor ya me sé a la perfección los síntomas de una empresa con problemas de desarrollo de aplicaciones. Año con año sigo escuchando las mismas quejas: desfases en tiempo, desfases en presupuesto, y requerimientos mal entendidos pero bien desarrollados.

El común denominador es siempre un cliente descontento, antes como ahora. Si las máquinas, los lenguajes y las herramientas de desarrollo han evolucionado tan radicalmente, y sin embargo seguimos teniendo los mismos problemas, entonces hemos estado buscando la solución a los problemas de desarrollo en el lugar equivocado.

Para identificar la solución a un problema basta con encontrar una situación libre de problemas, digámoslo así, un caso de éxito. Después analizamos nuestro caso de fracaso, y fácilmente detectamos las diferencias con el caso exitoso; corregimos el rumbo en nuestros casos de fracaso y corregimos la situación. Es una simple aplicación de mejores prácticas.