http://herraiz.org

Como últimamente he pasado bastantes horas en trenes y autobuses, me instalé una jueguecillo de sudokus en la Nokia 770, e intenté jugar un rato. El juego en realidad no es más que un sistema de ecuaciones sometido a algunas restricciones. En cada recuadro de nueve casillas, la suma de todas las variables es igual a la suma de los enteros de 1 a 9, y todas las variables son diferentes. Las restricciones adicionales son que las variables de cada fila y columna son todas diferentes entre sí. Con lo que nos quedan 9 ecuaciones con 9 restricciones, y 18 restricciones adicionales. El problema se puede simplificar, porque dentro de las 18 restricciones adicionales están incluidas algunas de las 9 restricciones de cada recuadro.

Lo que quiero decir es que se puede resolver de manera sistemática, siempre y cuando el sistema tenga solución, y por tanto no hay en realidad juego, porque o tiene solución o no la tiene, y aplicando el método se encuentra. Por ejemplo, mediante aritmética de matrices.

Cuando voy en el metro o en el cercanías, observo a la gente que resuelve los sudokus, y no parecen emplear un método sistemático, o al menos no uno exacto. De manera más intuitiva suelen ir al recuadro con menos variables (que tiene más números ya descubiertos), y a partir de ahí intentan resolver el sistema mediante prueba y error. De hecho, todos lo hacen con lápiz y goma, y emplean la goma varias veces.

¿Y qué tiene esto que ver con el desarrollo de software?

En el libro The Success of Open Source, que leí hace poco, en su edición de 2004, en la página 76, leí la siguiente frase

There are only two ways we know to make extremely complicated things. One is by engineering, and the other is evolution

que el autor del libro atribuye a un tal Hillis, y que dice que se la dijo en una conversación de café.

La gente que resuelve los sudokus, al concebirlos como sistemas complejos, intenta resolverlos por evolución (esto es, prueba y error), en vez de aplicar el método sistemático (por ejemplo, aritmética de matrices). Y lo hacen así porque para hallar la solución a un problema específico, es menos costoso el enfoque evolutivo. Cuando haya que resolver muchos sudokus, será más ventajoso el enfoque sistemático.

En el software pasa algo parecido. La complejidad del sistema es grande, y no es inmediato deducir un método sistemático para resolver el problema. Además, la escala del problema (en el sentido de la cantidad de veces que tendrá que desarrollarse el mismo sistema) no es grande. Por lo que el enfoque menos costoso es el evolutivo. Es más, una vez que se ha desarrollado un sistema, el proceso de aprendizaje asociado al sistema implica que la próxima vez que se vaya a desarrollar uno similar, los recursos que habrá que emplear (por ejemplo, el número de horas que habrá que dedicar) serán menores.

La ingeniería del software tradicional intenta luchar contra este modo de desarrollar el software, mediante la formalización. Por ejemplo, se hace que se escriban desde el principio los requerimientos, se sistematizan los flujos de información, se asignan zonas del desarrollo a diferentes personas, y se establecen permisos para evitar intereferencias, etc.

En cambio en muchos proyectos de software libre no se hace así. Bien es cierto que algunos aplican las prácticas que menciono en el párrafo anterior; pero no lo hacen a priori, sino que lo hacen tras un tiempo en el que sistema ha ido desarrollándose, y los desarrolladores incrementando su conocimiento acerca del sistema. Es decir, han ido surgiendo casi de manera natural. Es decir, surgen por evolución.

En resumen, en sistemas muy complejos, que no se conocen, y que no se van a resolver muchas veces de manera repetitiva, es mejor resolver el problema por evolución que por ingeniería (esto es, de manera sistemática).