Cómo hacer las cosas

Amnesia... es la única excusa razonable que se me ocurre por haber dejado olvidado tanto tiempo a este blog. Amnesia unida, cómo no, a la falta de tiempo típica en cualquier proyecto de software cuando las deadlines se acercan, cuando hay días (si hay suerte) o semanas (por desgracia, lo más tipico en este mundillo) en que hay que aumentar los recursos dedicados a un proyecto porque hay que responder ante un cliente.

Precisamente a este tema voy a dedicar el post: ¿qué tiene de especial el desarrollo de software, que hace que sus planificaciones se salgan de fechas tan fácilmente?

Intentaré no alargarme mucho. Para empezar, comentaré una "pequeña" anécdota que nos ha ocurrido durante estos meses de ausencia blogueril. Se trata de un fallo de programación (llamado bug en jerga) que ha consumido mucho tiempo al proyecto... en realidad, demasiado.

Uno se pregunta cómo hemos llegado a ese punto. Qué se debería haber hecho para evitar el bug. Cuál es la metodología correcta para no encontrarse de nuevo con un problema similar en el futuro. En definitiva, tener la garantía de que se puede cumplir lo planificado con una cantidad mínima de problemas.

Hace unas semanas lei precisamente un interesante artículo, They Write the Right Stuff, que trataba un poco el tema,y que responde a la pregunta planteada más arriba. La respuesta es: Nada.
No hay nada de especial en el desarrollo de aplicaciones informáticas. Si se sigue una metodología determinada, es posible predecir el desarrollo de un producto con la misma precisión que puede planificarse la construcción de una casa (ni mucha ni poca, pero razonable).

La pregunta obvia es: ¿por qué no seguimos entonces esa metodología milagrosa? Hay varios factores básicos:

1) Cuesta muchos recursos (horas, dinero, tiempo) comparado con los costes de la metodología habitualmente usada.
En proyectos militares, espaciales, de aviación o medicina, etc. puede compensar de sobra, pues hay vidas y mucho dinero en juego.
Pero en el 99.99% de los casos (como el caso de NTS y el resto de empresas del sector), desde luego no compensa, en absoluto.



2) Es necesario que el software y hardware en el que nos basamos haya sido desarrollado con el mismo afán de perfección que nuestro producto.
Cuando uno se encuentra con que una API estándar, como es MIDP, no es seguida al pie de la letra, pueden aparecer problemas inesperados (y no miro a Nokia! ;-).

3) Conocimiento previo del software y hardware en el que desarrollamos.
NTS podría jactarse de conocer los entresijos de muchos dispositivos móviles, pero lo cierto es que, cada vez que aparece uno nuevo en el mercado (muy a menudo), siempre traen algun sorpresita oculta, para amenizar la vida a los confiados programadores y atrasar el desarrollo un par de días más.


Moraleja: sinceramente, ni idea :P. Por desgracia, con las herramientas disponibles hoy en día, parece que la única posibilidad es aceptar que los planes rara vez se cumplen a la perfección, y seguir poniendo todo nuestro empeño para minimizar esos riesgos usando otras metodologías (tal vez imperfectas, pero bastante eficaces).