Las tres simples verdades (que te harán la vida de desarrollador más cómoda)

Cualquier proyecto software comienza cargado de problemas e incertidumbres, se desarrolla con problemas e incertidumbres y se entrega con... pues eso.

Cuando programamos estamos resolviendo problemas, al menos algunos de los que conocemos y nos agobiamos precisamente por aquellos que desconocemos.

Todo sería un poquito más fácil si asumiéramos que cualquier proyecto software tiene en su naturaleza tres verdades que al conocerlas bien nos pueden hacer nuestro trabajo más asumible y cómodo. Son las siguientes.

No hay ningún proyecto software que recoja completamente los requisitos al principio.

Nos han enseñando que como primera parte de un proyecto se debe afrontar una toma de requisitos. Esto en sí mismo ya es un tema de estudio profundo y empresarialmente un tema que casi siempre comienza mal: en ocasiones quienes recogen esos requisitos no poseen las competencias necesarias para trasladarlos al papel para que sean entendibles por el equipo que implementa el proyecto; en otras quien se encarga de esta tarea no está comprometido con el proyecto, por lo que le da igual especificar bien, cuando no pocas veces entender lo que el cliente quiere es más un tema de psicología que de tecnología.

En cualquier caso, por una razón u otra la realidad es que recibir requisitos completos es una utopía y cuanto antes aprehendamos esto nuestro trabajo podrá ser enfocado con un mayor grado de flexibilidad. No entramos aquí en técnicas ágiles que afrontan esta laguna inicial con reconsideraciones continuas del catálogo de requisitos, lo cual es la manera correcta de enfocar el problema, pero en muchos casos el contexto laboral te impide poner en práctica una metodología ágil.

Por muchos requisitos que se haya conseguido obtener al principio, éstos cambiarán con total seguridad.

No podemos basar completamente las decisiones de diseño que se toman e implementan en requerimientos iniciales: cualquier proyecto software va a ver modificado lo que se espera de él con el tiempo. En cuantas ocasiones he vivido eso por parte de un cliente igual que los "pues ya que...", sin entender las consecuencias desastrosas que puede tener para la solución software el esperar que un vehículo de cuatro ruedas ahora tenga que volar...

Sólo si aceptamos que en cierta medida nuestro software se debe adaptar a cambios entonces programaremos con un enfoque más abierto: modularizaremos mejor, desacoplaremos bien las partes funcionales del producto, nos esforzaremos mejor por hacer clean code, permitiremos un alto grado de configuración y particularización, etc.; sólo podremos hacer esto si nos inculcamos el hábito de programar para el cambio.

Cualquier software que no permita evolucionar ni ser modificado se tirará a la basura más pronto que tarde.

Siempre habrá muchas más cosas que hacer de las que nos permite el tiempo y el dinero.

A medida que avanzamos en la ejecución del proyecto las posibilidades de desarrollo, mejora e ideas se irán abriendo y ampliando en forma de árbol: exponencialmente.

Tenemos que asumir que siempre vamos a tener más cosas de las que realmente podemos afrontar y hacer. Si aceptamos que esto es así entonces podremos priorizar mejor y determinar qué es lo importante para el proyecto y qué lo accesorio, nos evitará divagar entre tareas sin terminar sin cerrar niguna al 100% y nos evitará ir dejando una technical debt que nos pase factura meses más tarde.

Simple pero efectivo: tres verdades sencillas de entender pero que tantas veces he visto totalmente incomprendidas en muchos de los proyectos que he participado.

Fuente (aparte del sentido común), el valiosísimo libro de Jonathan Rasmusson The Agile Samurai: How Agile Masters Deliver Great Software.