Extreme Programming Explained, por Kent Beck (Addison-Wesley 2000). ¡Adoro este libro! Sí, sé que tengo tendencia a tomar posturas radicales, pero siempre había intuido que podía haber un proceso de desarrollo de programas muy diferente, y mucho mejor, y pienso que XP se acerca bastante a ello. El único libro que me impactó de forma similar fue Peopleware (descrito a continuación), que trata de los entornos y la interacción con la cultura de las empresas. Extreme Programming Explained habla de programación, y echa abajo la mayoría de las cosas, incluso los recientes «hallazgos». Llega al punto de decir que los dibujos están bien siempre que no se les dedique demasiado tiempo y se esté dispuesto a tirarlos a la basura. (Observe que este libro no lleva el «sello de certificación UML» en su portada.) Comprendería que alguien decidiese si quiere trabajar o no para una compañía basándose sólo en si usa XP. Es un libro pequeño, con capítulos cortos, fácil de leer, y que da mucho que pensar. Uno empieza a imaginarse trabajando en esa atmósfera y vienen a la mente visiones de un mundo nuevo.

UML Distilled, por Martin Fowler (2ª edición, Addison-Wesley, 2000). Cuando se descubre UML por primera vez, resulta intimidante porque hay tantos diagramas y detalles. Según Fowler, la mayoría de esa parafernalia es innecesaria, así que se queda sólo con lo esencial. Para la mayoría de los proyectos, sólo se necesitan unos pocos instrumentos gráficos, y el objetivo de Fowler es llegar a un buen diseño en lugar de preocuparse por todos los artefactos que permiten alcanzarlo. Es un libro corto, muy legible; el primer libro que debería conseguir si necesita entender UML.

The Unified Software Development Process, por Ivar Jacobson, Grady Booch y James Rumbaugh (Addison-Wesley 1999). Estaba predispuesto a que no me gustase este libro. Parecía tener todos los ingredientes de un aburrido texto universitario. Me quedé gratamente sorprendido: sólo unos pocos pasajes del libro contienen explicaciones que dan la impresión de que los conceptos no han quedado claros para los propios autores. La mayor parte del libro no sólo es clara, sino también amena. Y lo mejor de todo es que el proceso tiene realmente sentido. No es Extreme Programming (ni tiene su claridad respecto a las pruebas), pero también forma parte del mastodonte UML: aunque usted no consiga que se adopte XP, la mayoría de la gente se ha subido al carro de «UML es bueno» (independientemente de su nivel de experiencia real con él), así que probablemente pueda conseguir que lo adopten. Pienso que este libro debería ser el buque insignia de UML, y es el que se debe leer después de UML Distilled de Fowler cuando se desee tener más nivel de detalle.

Antes de elegir método alguno, es útil enriquecer su perspectiva a través de los que no están intentando vender ninguno. Es fácil adoptar un método sin entender realmente lo que se desea conseguir con él o lo que puede hacer por uno. Otras personas lo están usando, lo cual parece una buena razón. Sin embargo, los humanos tienen un extraño perfil psicológico: si quieren creer que algo va a solucionar sus problemas, lo van a probar. (Eso se llama experimentación, y es bueno.) Pero si eso no les resuelve nada, redoblarán sus esfuerzos y empezarán a anunciar por todo lo alto su fabuloso descubrimiento. (Eso es negación de la realidad, y no es bueno.) La idea parece consistir en que si usted consigue meter a más gente en el mismo barco, no se sentirá solo, incluso si no va a ninguna parte (o se hunde). No estoy insinuando que todas las metodologías sean un callejón sin salida, sino que hay que estar armado hasta los dientes con herramientas mentales que ayuden a seguir en el modo de experimentación («Esto no funciona, vamos a probar otra cosa») y no en el de negación («No, eso no es un problema. Todo va maravillosamente, no necesitamos cambiar»). Creo que los libros siguientes, leídos antes de elegir un método, le proporcionarán esas herramientas.

Software Creativity, por Robert Glass (Prentice-Hall, 1995). Es el mejor libro que he leído que describa una visión de conjunto sobre el debate de las metodologías. Consta de una serie de ensayos cortos y artículos que Glass ha escrito o recopilado (P. J. Plauger es uno de los que contribuyen al libro), que reflejan sus numerosos años dedicados a pensar y estudiar el tema. Son amenos y de la longitud justa para decir lo necesario; no divaga ni aburre al lector. Pero tampoco vende humo; hay centenares de referencias a otros artículos y estudios. Todos los programadores y jefes de proyecto deberían leer este libro antes de caer en el espejismo de las metodologías.

Software Runaways: Monumental Software Disasters, por Robert Glass (Prentice-Hall 1997). Lo realmente bueno de este libro es que saca a la luz lo que nunca contamos: la cantidad de proyectos que no sólo fracasan, sino que lo hacen espectacularmente. Veo que la mayoría de nosotros aún piensa «Eso no me va a pasar a mí» (o «Eso no volverá a pasarme») y creo que eso nos pone en desventaja. Si se tiene siempre presente que las cosas pueden salir mal, se está en mejor posición para que salgan bien.

Object Lessons, por Tom Love (SIGS Books, 1993). Otro buen libro para tener «perspectiva».

Peopleware, por Tom DeMarco y Timothy Lister (Dorset House, 2ª edición 1999). Aunque los autores proceden del desarrollo de software, este libro trata de proyectos y equipos de trabajo en general. Pero el énfasis está puesto en las personas y sus necesidades, y no en las tecnologías. Se habla de crear un entorno en el que la gente sea feliz y productiva, en lugar de decidir las reglas que deben seguir para convertirse en perfectos engranajes de una máquina. Esta última actitud, pienso yo, es lo que más contribuye a que los programadores sonrían y digan sí con la cabeza cuando se adopta un método y sigan tranquilamente haciendo lo mismo que siempre.

Complexity, por M. Mitchell Waldrop (Simon & Schuster, 1992). Relata el encuentro entre un grupo de científicos de diferentes disciplinas en Santa Fe, Nuevo Méjico, para discutir sobre problemas reales que como especialistas no podían resolver aisladamente (el mercado bursátil en economía, la formación inicial de la vida en biología, por qué la gente se comporta de cierta manera en sociología, etc.). Al reunir la física, la economía, la química, las matemáticas, la informática, la sociología y otras ciencias, se está desarrollando un enfoque multidisciplinar de esos problemas. Pero, más importante aún, está apareciendo una nueva forma de pensar en esos problemas extremadamente complejos: alejándose del determinismo matemático y de la ilusión de poder escribir una fórmula que prediga todos los comportamientos, hacia la necesidad de observar primero y buscar un patrón para después intentar emularlo por todos los medios posibles. (El libro cuenta, por ejemplo, la aparición de los algoritmos genéticos.) Ese tipo de pensamiento, creo yo, es útil a medida que investigamos formas de gestionar proyectos de software cada vez más complejos.