• Es una ciencia (David Gries, 1981)
• Es un arte (Donald Knuth, 1998)
• Es un proceso (Watts Humphrey, 1989)
• Es como tener un coche, siempre tienes que arreglar cosas (P.J. Plauger, 1993)
• Es como conducir un coche, siempre tienes que ir haciendo pequeñas correcciones (Kent Beck, 2000)
• Es un juego (Alistair Cockburn, 2002)
• Es como un bazar (Eric Raymond, 2000)
• Es como la jardinería (Dave Thomas & Andy Hunt, 1999)
• Es como rodar Blancanieves y los siete enanitos (Paul Heckel, 1994)
• Es como cazar hombres lobo o ahogarse con dinosaurios en una hoyo de alquitrán (Fred Brooks, 1995)
• Es como construir un edificio (la mitad de la industria, 19xx)

Posiblemente muchos tengan parte de razón, aunque con la última comparación es con la que estoy totalmente en desacuerdo. Si tuviese que quedarme con una, escogería la de la jardinería. Queda muy cursi, pero es la realidad.

En definitiva, diría que el desarrollo de software es como crear/cuidar un jardín atestado de fauna (incluidos hombres lobo y dinosaurios) que evoluciona según las leyes darwinianas a un ritmo diez millones más rápido del normal (menos los dinosaurios, que están en huelga) y el cual es visitado por turistas españoles que les gusta crear hogueras y practicar sexo al aire libre, a la holandesa.

El libro se mueve en torno a una serie de consejos, ideas y observaciones para desarrolladores. Toca prácticamente todos los puntos en el trabajo diario de un programador, desde las herramientas a usar a cómo implementar incuso cómo actuar y pensar. A decir verdad, muchos capítulos podrían aplicarse a cualquier otra labor y son bastante genéricos.

Al final del libro viene una chuleta con todos los tips que se han ido mencionando, muy curiosa. La mayoría de ellos son bastante razonables, como "Always design for concurrency", otros son interesantes y sorprendentes, "English is just a programming language"; pero la mayoría son tópicos que cualquiera con un mínimo de experiencia conocerá, "DRY", "Think about your work", pero que no viene mal verlos en escrito una vez más.

En general es un libro realmente bueno, y que cualquiera que le guste leer libros técnicos, debería tener en su lista, pues además es muy corto (quitando anexos, poco más de 200pag., letra gorda y fácil lectura). No es un libro donde aprendas cosas concretas, lo definiría más bien como una forma de dialogar sobre el desarrollo y la programación, algo bastante divertido , aunque en este caso el diálogo es unidireccional de los autores hacia ti, suficiente.

Su principal problema es su extensión, se queda corto, muy corto. No entra en profundidad en ningún aspecto, simplemente estamos dialogando sobre temas. Y en aquellos donde dominas puede resultar incluso molesto (el capítulo sobre herramientas estuve a punto de saltarlo y eso que odio no leer los libros linealmente) puesto que no puedes participar en dicho diálogo. Además la mayoría de temas que trata suelen ser cosas que ya conocerás, pero nunca está de más saber el punto de vista de otro, ¿no crees?.

Lo mejor del libro es que a pesar de que la mayoría de las cosas ya las sabrás, en determinados puntos el autor te sorprende con algo que no esperabas que dijera (seguramente estas "sorpresas" son bastante subjetivas y dependientes del lector), solo por esto, ya lo recomiendo.

Es, en definitiva, un libro sobre filosofía que toca, disimuladamente, temas de ingeniería del software.

Abstractions live longer than details

Tip #53