Programación fácil

¿Es fácil la programación de aplicaciones?


Programación fácil

Hoy el director de informática del cliente en el que trabajo estos meses, me ha pedido que programara un sistema de gestión de proyectos para finales de semana. Hoy es miércoles. Eran las tres de la tarde.

Los requisitos son: debe integrarse con la aplicación que tenemos de gestión de préstamos bancarios y almacenar los tiempos que cada desarrollador emplea en gestionar sus tareas e incidencias en los diferentes módulos de los proyectos de desarrollo. La frase final era para enmarcarla, de hecho no es la primera vez que la escucho: "Al fin y al cabo son sólo cuatro tablas",

Aparte del hecho de mezclar peras con manzanas ( ¿una aplicación de gestión de proyectos dentro de otra de gestión de créditos ?), de la definición de requisitos pésima, de la falta de visión de futuro y de la prepotencia con la que se ordenan ciertas cosas en las empresas, todo gira realmente alrededor de una idea: escribir una aplicación es enormemente fácil. De hecho, si en dieciséis horas no has conseguido hacer una aplicación así no sé que has hecho en todos tus años de carrera.

Me pregunto si se habrá parado a pensar porqué Microsoft ha tardado veinte años en desarrollar Project o ha invertido casi cinco en Team Foundation Server o porqué existen aplicaciones como Primavera, dotScrumm, BaseCamp o similares a unos precios astronómicos si son sólo cuatro tablas. Pandilla de vagos.

Me recuerda la ocasión en que un director de proyecto me dijo "le he prometido al cliente que tendríamos la gestión de los informes mañana a las nueve de la mañana, así que te quedan quince horas para hacerlo". Eran las seis de la tarde. Mi respuesta fue: "en realidad me queda media hora, si tiene que estar mañana a las nueve ahí tienes mi ordenador". Es a lo que te arriesgas cuando tienes tan poca consideración al trabajo de los demás.

En los mentideros del Software a una situación así se la denomina un Death March,: un proyecto que se sabe desde el principio que ni va a cumplir los plazos, ni los requisitos, ni se va a poder utilizar. Y desgraciadamente nos los encontramos a menudo.

Y todo se basa en una premisa totalmente falsa: la programación de aplicaciones es fácil.

Lo peor es que nos lo hemos buscado nosotros: hemos hecho de los ordenadores algo sencillo para los usuarios ocultando capas y capas de complejidad bajo una interface de usuario con dibujitos y palabras subrayadas que hasta los niños pueden utilizar. Tengo que contenerme cada vez que un padre orgulloso me dice "sabe mucha informática, tenías que verle utilizando Facebook" que debe ser equivalente a "sabe mucho de arquitectura, tendrías que ver cómo abre las puertas".

Pero no nos vayamos por las ramas, volvamos a las cuatro tablas. Cuatro tablas significan cuatro definiciones de tablas en base de datos, dieciséis consultas o procedimientos almacenados como mínimo (SELECT, INSERT, UPDATE y DELETE), al menos cuatro formularios.

Si queremos hacer las cosas mínimamente bien y dividir la aplicación en capas, implica tres capas con tres clases por tabla: doce clases.

Pero vayamos más allá, alguien tendrá que pensar en esta empresa. Lo que se pretende realmente es que los desarrolladores informen del tiempo empleado en cada tarea, por tanto, dado que vamos a insertarlo en nuestra aplicación de gestión de créditos (aagh), debemos identificar a los usuarios de desarrollo y darles de alguna forma derechos de acceso e impedir el acceso al resto. Además no debemos olvidar los derechos para creación de proyectos, módulos, tareas, ni la asignación de las tareas a usuarios.

No está en los requisitos, en realidad no hay nada en los requisitos, pero también debemos tener en cuenta lar relaciones entre tareas (cuales se deben hacer antes que otras), las fechas previstas y reales, los estados de finalización (no sólo los famosos "hecho" y "hecho hecho" si no también las anulaciones por cambios de requisito) y las tipologías.

Y por supuesto, dado que el motivo principal de la aplicación es obtener un control de tiempos, deberíamos pensar en los listados que queremos: tareas retrasadas, usuarios sobrecargados o infrautilizados, estimaciones de tiempo, caminos críticos...

¿Realmente sólo son cuatro tablas ?

Páginas relacionadas