Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
Durante el fin de semana oí la triste noticia de que John Vlissides murió después de una larga batalla contra el cáncer. John es conocido como uno de "la Banda de los Cuatro" que produjo probablemente el mejor libro escrito sobre el diseño de software.

John era una de las personas que yo más deseaba encontrarme cuando asistía a conferencias, siempre disfrutaba de su compañía y me encontraba muy cómodo con él. Me invitó a visitar el Centro de Investigación de IBM durante un día, y fué un excelente anfitrión mientras paseábamos por las oficinas donde él trabajó. Fué un escritor dedicado y experto, sólo puedo sentir pena por no haber sido capaz de pasar más tiempo trabajando con él. Es muy triste pensar que no me lo volveré a encontrar.

Como contribuidor principal al mundo de los patrones, es muy apropiado que esta comunidad le haga un memorial en su página wiki donde la gente puede honrar su memoria "compatiendo las historias de como él le ha ayudado, apoyado o inspirado ".
Artículo Original

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer

Uno de los elementos comunes de los métodos ágiles es que otorgan a la programación un papel central en el desarrollo de software – mucho más de lo que la ingeniería del software suele hacer. Para esto es necesario considerar el código como la principal documentación de un sistema software.

Casi de inmediato siento la necesidad de refutar un malentendido muy común. Tal principio no quiere decir que el código sea la única documentación. Aunque a menudo se dice esto de la ProgramacionExtrema, nunca lo he oído decir a los líderes de éste movimiento. Generalmente, se necesita documentación adicional como complemento al código.

La razón por la que el código es la fuente principal de documentación se debe a que es la única lo suficientemente detallada y precisa como para ocupar este rol - un punto explicado elocuentemente por Jack W. Reeves en su famoso ensayo "¿Qué es Diseño?".

Escrito por Martin Fowler
Traducido por Carmen Vidal
Revisado por Jorge Ferrer
Una base de datos en memoria (también denominada base de datos embebida) es una base de datos que corre completamente en la memoria principal, sin utilizar el disco duro. Por lo general, es creada cuando un proceso comienza, se ejecuta embebida dentro del proceso, y es destruida cuando el proceso termina.

A primera vista una idea tan bestia parece ridícula. Los dos objetivos principales de la mayor parte de bases de datos son persistir la información entre invocaciones del proceso y manejar el acceso concurrente a datos entre procesos. Las bases de datos en memoria no cumplen ninguno de estos objetivos – ¿ Cuál es su utilidad?

El caso más común en el que las he usado recientemente es para pruebas. Cuando se desarrolla una aplicación empresarial, las pruebas que atacan a la base de datos pueden consumir mucho tiempo cuando se ejecutan las baterías de pruebas. En estos casos, emplear una base de datos en memoria puede tener un efecto de un orden de magnitud que reduce tiempos de construcción radicalmente. Ya que a la mayor parte de los ThoughtWorkers se les da un aviso si no han tenido una barra verde recientemente, esta arquitectura es un hecho diferenciador.

Siguiendo con la imparable proliferación de los blogs de audio o podcasts se ha lanzado el Agile Toolkit Podcast. En esta web se pueden escuchar entrevistas y conversaciones de primera mano de personajes como Scott Ambler (Agile Modelling, Mary Poppendick (Lean Development), Ward Cunningham (Inventor del Wiki, tarjetas CRC, FIT, y más) entre otros.

Los ficheros de audio se publican con licencia Creative Commons y permiten su redistribución para uso no comercial.

Traducido por Jorge Ferrer
Revisado por Miguel Figueroa-Calix

Una de las frustraciones en el campo del desarrollo de software es la dificultad para elegir entre diferentes técnicas y herramientas. Es habitual que cuando alguien propone alguna técnica o herramienta se le pidan 'datos objetivos' de que su propuesta es mejor que las alternativas. Esta es una petición que puede entenderse, pero que al final está abocada a no tener respuesta. Para empezar porque no podemos medir la productividad (ver CannotMeasureProductivity).

Así que ante la carencia de 'datos objetivos' habitualmente empleamos evidencias anecdóticas. De hecho mi carrera tiene como objetivo difundir ideas basadas en el análisis de evidencias anecdóticas. A pesar de su inferioridad con respecto a los fenómenos medidos objetivamente no es muy sabio ignorarlas. Después de todo, ¿de qué otra manera podemos aprender? Es cierto que aprendemos mucho de nuestras propias experiencias, pero cuando otros nos cuentan las suyas también nos proporcionan mucha información.

Esta es la razón por la que me entusiasma ver que la gente informa de sus experiencias, incluso si son particulares y no están basadas en medidas exactas. En estos casos, los lectores entienden estas limitaciones y se quedarán con aquellas lecciones que puedan aplicar en sus propias circunstancias.