Después de leer este post sobre la podredumbre del software, no he podido evitar pensar en el que, para mi, es uno de los mayores problemas a la hora de desarrollar software, especialmente si se trata de productos estándar.

Cuando un cliente o uno de nuestros comerciales quiere añadir algo a una aplicación, generalmente se acerca a mi con preguntas como ¿se puede hacer que…? ¿costaría mucho si…? ¿cuánto se tardaría en…?

Mal. Antes de añadir una funcionalidad, la primera pregunta que hay que responder es ¿debería la aplicación hacer…? El problema de las preguntas anteriores es que asumen que la respuesta a ésta última es afirmativa, pero eso no siempre es así.

Lo malo es que el software lo aguanta (casi) todo. En comparación con el Mundo Real™, donde existen unas leyes muy rígidas que marcan lo que se puede hacer y lo que no, en el mundo del desarrollo de software esas leyes son mucho más flexibles, especialmente para la gente que no comprende realmente lo que es desarrollar software.

El desarrollo de software es un proceso que tiene como objetivo producir algo. Un producto. Es importante tener claro el producto que queremos conseguir con un desarrollo de software, pero muchas veces la supuesta flexibilidad del desarrollo como proceso hace que el objetivo inicial se diluya, se transforme y, finalmente, se pierda.

No estoy hablando de esculpir unas especificaciones en piedra y ceñirse a ellas. A estas alturas el que más y el que menos conoce las metodologías ágiles y, la mayoría de nosotros, las apoyamos. Nos preparamos para el cambio, lo abrazamos, y todo eso…

Sin embargo, una cosa es estar preparado para el cambio y otra muy distinta es correr como pollos sin cabeza, cambiando continuamente de rumbo sin un objetivo fijo.

Hay productos que parece que evolucionan así:

Cronología de un proyecto

Versión 1.0: Hemos preparado un producto llamado Paella que va a romper el mercado.

Un cliente dice que la competencia le ofrece Macarrones con Chorizo, ¿cómo es posible que nuestra paella no lleve chorizo?

Versión 2.0: Paella con chorizo.

El product manager ha decidido que el futuro son los iPhone y la movilidad. Quiere una paella que se pueda comer en cualquier parte.

Versión 3.0: Paella Mobile con Chorizo.

Seguro que muchos de vosotros habéis estado involucrados en proyectos así. Proyectos en los que cualquier cosa que se le ocurriese a un cliente potencial acababa automáticamente en el backlog del producto (y con prioridad alta), sin tener en cuenta si era una buena idea, o al menos si era compatible y consecuente con lo que intentaba conseguir.

Muchas veces los proyectos acaban dirigidos por gente que está demasiado cerca del cliente y con una presión muy elevada por parte de éste, lo que provoca que no sea fácil mantener la cabeza fría y la visión a medio/largo plazo.

En esos casos, cada nuevo cliente se convierte en una nueva funcionalidad apilada sin ningún criterio sobre la aplicación, provocando contradicciones, disminuyendo la usabilidad y dañando el producto en su conjunto.

Llegas a la situación en que el cliente dirige tu desarrollo y acabas por diseñar algo al más puro estilo Homer Simpson:

No siempre está en nuestras manos decidir lo que va a pasar con lo que estamos desarrollando. Debemos trabajar para que el software sea mantenible, robusto, usable, etc., pero también podemos aportar nuestra experiencia e intentar que el producto en el que estamos trabajando siga teniendo sentido.