Extreme Programming Explained por Kent Beck (Addison-Wesley 2000).¡Adoro ese libro! Si,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 mientras que no se les dedique demasiado tiempo y se esté dispuesto a tirarlos a la basura. (observen que ese 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 el hecho que usan 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 Jacobsen, Grady Booch, y James Rumbaugh (Addison-Wesley 1999). Estaba mentalizado para que no me gustase ese libro. Parecía tener todos los ingredientes de un aburrido texto universitario. Me quedé gratamente sorprendido - solo unos islotes dentro del libro contienen explicaciones que dan la impresión que los conceptos no han quedado claros para los propios autores. La mayoría del libro es no solamente claro, sino agradable. Y lo mejor de todo, es que el proceso tiene realmente sentido. Esto no es Extreme Programming (y no tiene su claridad acerca de los tests) pero también forma parte del mastodonte UML - incluso si usted no consigue hacer adoptar 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 podría conseguir que lo adopten. Pienso que ese libro debería ser el buque insignia del UML, y es el que se debe de leer después del UML Distilled de Fowler en cuanto se desee tener más nivel de detalle.

Antes de elegir método alguno, es útil enriquecer su perspectiva 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, que es una cosa buena) 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, que 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 no llevan a ningún lado, pero 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, no es 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).Ese 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 comprado (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 simplemente aire; hay centenares de referencias a otros artículos y estudios. Todos los programadores y jefes de proyecto deberían leer ese 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 ese libro es que expone a la luz lo que nunca contamos: la cantidad de proyectos que no solo 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 desfavorece. Al tener siempre en mente que las cosas pueden salir mal, se está en mejor posición para hacerlas ir 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).A pesar de que tiene elementos de desarrollo de software, ese 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 esté feliz y productiva, en lugar de decidir las reglas que deben seguir para convertirse 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 un método es adoptado y sigan tranquilamente haciendo lo mismo que siempre.

Complexity, by 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 a esos problemas. Pero más importante aun, una nueva forma de pensar en esos problemas extremadamente complejos está apareciendo: 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.