Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Se tiene que programar por parejas si se sigue un proceso ágil.
Esto es completamente falso. 'Ágil' es un término muy amplio definido sólo en términos de valores y principios, el más notablemente en el Manifiesto para el Desarrollo de Software Ágil. El manifiesto no menciona el programar por parejas y la mayoría de los métodos ágiles no lo incluyen en su aproximación.
Ya que programar por parejas es una práctica de XP, ha tenido mucha influencia en la comunidad ágil. Por consiguiente a menudo es mencionado como una práctica ágil – tomando como práctica algo que es comúnmente usado por la gente en proyectos ágiles. Pero esto es una observación, no una prescripción..

Escrito por Martin Fowler
Traducido por Rafael Vacas

Uno de los más largos debates en los círculos orientados a objetos es el debate entre HerenciaAbierta y HerenciaDiseñada. Josh Block ha sido probablemente quien mejor ha resumido el principio de la herencia diseñada: “Diseña y documenta para herencia o si no prohíbela”. Con este planteamiento te preocupas de decidir qué métodos pueden ser heredados y proteges los otros para evitar que sean sobrescritos.

El argumento más común para la herencia diseñada es que dado que la herencia supone una relación muy estrecha (y rompe la encapsulación) es fácil que las subclases efectivamente rompan las superclases por ejemplo, omitiendo comportamientos necesarios cuando sus métodos son invocados.

Muchos programadores, particularmente aquellos con una ActitudPermisiva, no están muy convencidos por este estilo de argumento. Otro argumento que encuentro más apetecible es el de Elliote Rusty Harold al discutir los principios de diseño de XOM. La cuestión aquí es que “las API son escritas por expertos para no expertos”. El creador de librerías debería estar debidamente versado en la tecnología con la que trabaja la librería. Deberían trabajar para simplificar esta tecnología a los usuarios de la librería. La encapsulación consiste en esconder secretos, por tanto una buena librería debería esconder toda clase de complicaciones y puntos peligrosos a los usuarios de la librería, ya usen la librería mediante invocaciones o herencia. Por tanto, con XOM puedo sobrescribir de forma segura las clases de la librería para hacer lo que quiera ya que la librería garantiza que aún así producirá XML bien formado, sin que tenga que preocupar a mi fea cabecita con todas las cosas que de otra forma podrían ir mal.

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

Para este artículo voy a describir dos estilos de cómo se hace el diseño en el desarrollo de software. Quizás el más común es el diseño evolutivo. Esencialmente, el diseño evolutivo quiere decir que el diseño del sistema crece mientras se implemente el sistema. El diseño es parte de los procesos de programación y según el programa se desarrolla el diseño cambia.

En su uso habitual, el diseño evolutivo es un desastre. El diseño termina siendo la agregación de un manojo de decisiones tácticas tomadas en el momento, cada una de las cuales hace el código más difícil de cambiar. Se podría argumentar de muchas formas que esto no es diseño, de hecho esto por lo general conduce a un diseño pobre. Como Kent dijo, el diseño está ahí para permitir cambiar el software fácilmente a largo plazo. Como el diseño se deteriora, entonces se necesita la capacidad de hacer cambios con eficacia. Se tiene el estado de entropía de software, con el tiempo el diseño se pone de mal en peor.

No sólo hace esto el software más difícil de cambiar, esto también hace los errores más fácil de reproducirse y a la vez más difícil encontrar y seguramente para resolver. Esto es la pesadilla “codificar y arreglar”, donde los errores se hacen exponencialmente más caros de arreglar según el proyecto avanza.

Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

Aún no he terminado de leerlo, pero por lo que he visto hasta ahora el artículo de 90 páginas Scrum and XP from the trenches es definitivamente uno de los mejores que se han escrito sobre el tema. Cuenta las experiencias de la aplicación de diferentes prácticas de SCRUM y XP durante un año en una empresa con los típicos problemas de desarrolo de software (incumplimiento de fechas, efecto "siempre estamos apagando fuegos", mala calidad, etc).

En el artículo se describen desde un punto de vista completamente práctico la forma en la que han están haciendo las cosas ahora después de una añ aprendiendo (gracias a las retrospectivas periódicas). Pero también es muy importante lo claro que deja que esta no es la forma definitiva y que seguirán evolucionando (de nuevo apoyándose en retrospectivas periódicas). Hay que recordar con respecto a esto que no sólo cada proyecto es diferente sino que cada día el mismo proyecto es un poco distinto al día anterior.

En definitiva un artículo muy recomendable para coger ideas y contrastar las prácticas que estamos usando con lo que le ha funcionado a otra gente.