archivo

Archivos diarios: agosto 20, 2012

Se produce cuando se tergiversa, se saca fuera de contexto o se da una interpretación interesada como argumento para desacreditar una aseveración o una opinión.

Algunos ejemplos (la verdad es que podría haber tantos como alcance vuestra imaginación o tantos como casos de la vida real hayáis o estéis viviendo):

Persona A: Tener la deuda técnica bajo control es un aspecto importante en el desarrollo de proyectos de calidad.
Persona B (Argumento Straw man): Si nos centramos es aspectos y términos que el usuario ni conoce ni valora estamos centrando nuestro enfoque fuera de lo realmente importante que es satisfacer las expectativas del usuario.

Comentario: La Persona A dice que es un aspecto importante, pero no dice ni que sea el único ni que sea el menos importante, es decir, no lo hace excluyente, sin embargo la Persona B tergiversa la posición de A cuando lo califica como elemento central para evaluar la calidad del software y como si condicionase al resto de actividades, algo que no se puede interpretar explícitamente de lo comentado por A.

Persona A: El proceso tiene excesiva carga documental.
Persona B (Argumento Straw man): Entonces, ¿cuál es la opción?, ¿no documentar?, ¿no realizar una reflexión o análisis previo de cada etapa del desarrollo o de cada elemento que sea necesario construir?.

Comentario: La Persona A no dice que no se documente sino que en su opinión la relación de entregables del proceso es excesiva, sin embargo la persona B lo tergiversa dando por entendido que la persona A no quiere realizar ningún tipo de documentación.

Persona A: Necesito una mayor implicación en el proyecto por parte de vuestro Departamento.
Persona B (Argumento Straw man): ¿Crees que no tenemos carga de trabajo?, mira nuestra herramienta de gestión que sé que tienes acceso a ella y observa la gran cantidad de tareas que tenemos.

Comentario: La Persona A solo pide una mayor implicación de otro Departamento. No pone en tela de juicio de si en el otro Departamento se trabaja o no, argumento que pone encima de la mesa la Persona B para desviar la atención.

Lo fácil es echar la culpa a todos los demás menos a nosotros. El proyecto va mal, la decisión ha sido incorrecta, no importa, yo todo lo que hice estaba bien y si no ha salido como debía es porque: los usuarios no han respondido, el cliente no tiene ni idea, el proveedor solo piensa en el dinero, etc….

El resultado de un proyecto para bien o para mal es la suma del trabajo, esfuerzo y decisiones de muchas personas. El éxito no es de una persona o de un equipo y el fracaso tampoco, lo que pasa es que el éxito tiene muchos padres y el fracaso es huérfano.

Ahora bien, como es lógico, todos no tienen la misma parte de culpa en el éxito y en el fracaso.

Es muy importante, lo he dicho muchas veces, tener una actitud crítica con el trabajo que depende de nosotros (el del equipo y el que realizamos) porque no siempre acertamos. Sin esa visión crítica, algo que por cierto falta a muchísimas personas de nuestra profesión, estamos limitando nuestro desarrollo profesional porque si no se reconoce el error, si no se reconoce el punto de mejora vamos a volver a repetirlo.

Muchas veces vemos el enemigo por todos lados cuando lo mismo está más cerca de lo que creemos.

La siguiente cita de Alistair Cockburn lo resume a la perfección: “Hemos conocido al enemigo y somos nosotros mismos”.

La visión de la refactorización no debe ser la de: “trato de cerrar cuanto antes las tareas que tengo asignadas que ya tendré oportunidad después de dedicar tiempo a poner el código un poco mejor”, principalmente por dos razones:

1) La mayoría de las veces, salvo que esté muy interiorizado por el equipo de trabajo y por el programador la necesidad de refactorizar y los beneficios que trae consigo, no se termina dedicando tiempo a realizar estas tareas porque continuamente van a surgir otras que se considerarán más prioritarias y sobre las que recaerá la atención. En este contexto tomar ese tipo de actitudes no es más que querer engañarnos a nosotros mismos: “finalmente no pude poner el código mejor o reducir el acoplamiento entre esas clases porque estoy hasta arriba de trabajo y no tengo tiempo”.

2) Se descuida la programación dejando para más adelante detalles que perfectamente podrían ser resueltos conforme se está trabajando. Todo es susceptible de mejorar de ahí lo útil que resulta refactorizar pero es importante que los esfuerzos dedicados a esa tarea sean los necesarios (y no más).

Es cierto que a veces las restricciones temporales imponen unas condicionen que ni permiten refactorizar y ni siquiera permite cuidar lo que se quisiera la codificación y la arquitectura. En estos casos el contexto del proyecto manda y probablemente para conseguir el resultado final en el tiempo y presupuesto establecidos habrá que sacrificar parte de su mantenibilidad y robustez.

¿Qué se puede hacer en estos casos? Lo que se pueda (realmente la situación de partida del proyecto es la culpable de todo lo demás) pero siempre con la intención de hacerlo de la mejor forma posible.