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

Si te importa lo que haces, te interesas en hacerlo cada vez mejor. Esto implica reflejar como haces las cosas y probar nuevas técnicas para ver si te hacen mejorar. Aunque otros recomienden nuevas técnicas, la única forma de saber si funcionan para ti es probándolas tú mismo y comprobar si mejoran tu rendimiento.

El problema es que la mejora, particularmente con nuevas técnicas no es lineal. A menudo hay una brecha que se abre cando intentas una nueva estrategia. La mejor ilustración que recuerdo de esto es del excelente libro de Gerald Weinberg Convertirse en un Líder Técnico. Viene de su hábito de jugar al pinball.

A medida que iba mejorando lentamente en mi nivel, empecé a sospechar que se me estaba pasando algo. Aunque mi puntuación subía rápidamente cuando tenía tres bolas en juego, de repente, al intentar mantener las tres bolas en juego, perdía las tres de golpe. Sólo pasaba una de cada cuatro veces, pero eso significaba que había perdido uno de tres preciosos turnos.

Me preguntaba que pasaría si dejaba de intentar mantener las 3 bolas en juego y me concentraba en su lugar en asegurar que una de las tres bolas se mantuviera en el campo de juego. Cuando probé esta nueva estrategia, mi puntuación cayó, inmediatamente, en el abismo. De hecho, estaba jugando contra un chiquillo al mismo tiempo, y empezó ganándome. Incapaz de afrontar la derrota, volví a mi antigua estrategia y lo puse en su lugar.

Más tarde, sin embargo, sin público observando, probé la nueva estrategia de nuevo. Y de nuevo mi puntuación bajó, pero me di cuenta de que no estaba perdiendo turno con tanta frecuencia, quizá sólo una de cada cinco veces que jugaba con tres bolas al mismo tiempo. Perseverando, con la práctica, mejoré mi habilidad para ignorar las otras dos bolas y mantener al menos una en el campo. No puntuaba mucho cuando las tres bolas estaban en juego, pero mi puntuación total aumentó. También conseguí jugar más tiempo en mi turno, lo cual es uno de los principales objetivos del juego.

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.