Sherlock Holmes

"Una vez descartado lo imposible, lo que queda, por improbable que parezca, debe ser la verdad"

Esta frase fue escrita por Arthur Conan Doyle para su personaje Sherlock Holmes y resume el mecanismo de las investigaciones en la mayoría de las novelas policiales: ir descartando posibles explicaciones hasta llegar a la única posible.
Lo difícil, tanto en los casos de Sherlock como en la vida real, es poder descartar N-1 explicaciones, porque N es grande y porque descartar cada explicación no es fácil (creo que no lo podría haber dicho de una manera más nerd o geek, como se dice ahora).

Pero nosotros no necesitamos resolver cosas en la vida real. Sólo necesitamos que nuestros programas anden y existen factores que hacen viable comportarnos como si fuéramos Sherlock Holmes (o el Dr. House, para un ejemplo más moderno).

En primer lugar, las computadoras son determinísticas. Esto significa que si una computadora recibe dos veces exactamente el mismo input el resultado que va a producir va a ser exactamente el mismo. Esta idea no se condice con nuestra experiencia de todos los días (sobre todo si somos usuarios de ciertos sistemas operativos), pero no deja de ser una verdad absoluta, por lo menos para computadoras de nuestra época que no planeen tomar el mundo.

¿Cual es la consecuencia para nuestro método Sherlockiano? Que podemos descartar todas las hipótesis que sean del estilo "no cambié nada y dejo de andar". Si dejó de andar, es por un motivo; quizás nunca podamos descubrirlo; quizás lo haya hecho otra persona, pero existió un motivo (siempre quise poner un punto y coma escribiendo en castellano, es raro porque odio hacerlo cuando programo).

Este es un punto muy importante, porque nos permite liberar nuestro cerebro de mucho trabajo inútil. Si algo deja de funcionar, solo necesitamos ver que cosas cambiaron desde la última vez que anduvo y podemos estar seguros que alguno de esos cambios va a ser el culpable. Teniendo pocos sospechosos, siempre es más fácil descubrir al criminal.

Es aquí donde, además de las características inherentes de nuestro medio, entran en juego hábitos que permiten mantener la lista de sospechosos corta. En el párrafo anterior hay una frase tramposa: solo necesitamos ver que cosas cambiaron desde la última vez que anduvo. Parece sencillo, pero para saber esto se necesita poder determinar primero cual fue la última vez que nuestro programa anduvo y segundo que cosas cambiaron desde entonces.

¿Cómo podemos ser capaces de saber cuándo fue la última vez que nuestro programa funcionó? Si se trata de un problema que aparece en nuestro ambiente de desarrollo, las técnicas que mencionamos aquí son muy eficientes. Si dejamos pasar poco tiempo entre pruebas, es facil saber cuando fue que nos equivocamos. Los tests de unidad en estilo TDD son particularmente eficaces: si corremos los tests cada 10 minutos, un test fallado debe tener un sospechoso bastante obvio.

Si se trata de un problema que apareció en producción o en testing la cosa es más complicada. Hay que recrear los ambientes anteriores para poder verificar en que momento apareció el bug, lo cual a veces es difícil y consume mucho tiempo. Pero nada de esto es nuevo, siempre supimos que dejar llegar bugs a producción es muy caro.

La otra mitad del problema es determinar que cambió para que nuestro programa dejara de andar y aquí entra en acción un hábito muy querido por los autores de este blog: los commits frecuentes. Digamos que logramos determinar que el programa dejó de andar la noche del 24 de julio a las 3AM y que podemos considerar todos los cambios ocurridos cerca de ese momento como sospechosos. Si un programador estuvo modificando código sin commitear durante un mes e hizo commit a las 2AM, todos esos cientos de cambios son igualmente sospechosos. En cambio, si trabajamos de manera de poder commitear todos los días, el conjunto de sospechosos (la cantidad del codigo commiteado) es mucho más corto.

La misma solución se puede aplicar para los problemas en Producción, si no para evitarlos por lo menos para minimizarlos, aplicando las práctica de Integración Contínua y Entregas Frecuentes. La idea es la misma: No esperar a tener mil cambios en la aplicación para pasarla a productivo porque eso implica que cualquier error tiene miles de "sospechosos". Mientras que si uno hace mini-implementaciones y entrega frecuentemente, cada bug tendrá unos pocos "posibles" sospechosos.

Por supuesto, hay variaciones de estos problemas en equipos de trabajos grandes, con gente que modifica a la vez las mismas partes del programa, pero la regla general se mantiene: si algo dejo de andar fue por algún cambio y cuando más fácilmente puedas determinar ese cambio tu vida va a ser más fácil.

Elemental Watson!, Diria Sherlock Holmes (Claro que esa frase no la dice en ninguno de los cuentos o novelas que escribió Arthur Conan Doyle, "Urban Legend" que le dicen).

Flexibilidad ante el cambio

Inmaginense la siguiente situación: Comienzo de un proyecto, el Gran-Gerente de proyecto, Gran-Jefe-Saco-Agua-De-Las-Piedras reune a todo el equipo y anuncia "El equipo de funcionales va a comenzar con la (Gran)Etapa de relevamiento, durará unos 10 meses. Queremos lograr entender completamente lo que quiere el usuario asi no vamos a tener ningún cambio y vamos a saber todo para cuando entremos en la etapa de desarrollo, que durará unos 3 meses.". Esta es una situacion real, números de meses incluidos. Me sucedió a mi.

Una y otra vez todos hemos estado en proyectos adonde pasa mas o menos lo mismo: Una Gran Etapa De Relevamiento al principio del mismo para "evitar" tener que realizar Cambios y para aprender TODO lo que hay que aprender. Una y otra vez hemos llegado a la mitad o al final del proyecto, con varios meses de retraso respecto de la fecha original, cuando, al mostrarsele el sistema a los usuarios comienzan a aparecer estos "cambios-que-se-suponian-que-no-tenian-que-existir".

Porqué pasa esto? Son los usuarios una fraternidad de sádicos a los que les gusta torturarnos? Son los funcionales, los desarrolladores personas altamente perturbadas y disfuncionales (eh... mejor no contestemos esto) que no pueden entender lo que el usuario les pide? Existe el destino y se empeña en ponernos piedras en el camino?

O será que el cambio es una parte normal de todo proyecto?

Hasta el surgimiento de las metodologías ágiles el cambio se trataba (se sigue tratando) como una anomalía, como un error del usuario o como un síntoma de que alguien se equivocó y no relevó lo suficiente. Cuando hablamos de cambio lo hacemos en todo sentido pero particularmente de los requerimientos y necesidades del usuario.

Por este motivo es que Waterfall indica que debe realizarse una Gran Etapa de Relevamiento al Principio (en inglés, BRUF, Big Requirements Up Front), seguido de escritura de casos de uso (indicado por el DR. RUP) y terminando con requerimientos firmados por usuarios temerosos (de meterse en camisas de once varas y de estar firmando los "10 mandamientos del sistema" tallados en Mármol!).

PMI lo trata con un proceso de "gestión de cambio" o "Control de Cambio" adonde en base a un pedido de cambio del relevamiento inicial se realiza un "cambio de alcance", lo cual implica reestimar costos, chequear asignación de recursos, reestimar tiempos, replanificar y obtener la autorización del sponsor / Gerentes del proyecto para proceder con el cambio. Cualquier parecido con la tortuga de Mafalda es pura coincidencia (La tortuga se llamaba Burocracia).

Justamente uno de los principios comúnes a todas las metodologías ágiles es: El cambio es parte de la realidad!

No es un hecho excepcional, no es causado por usuarios viles y sádicos que quieren hacer un infierno de nuestras vida. No es causado por analistas funcionales perezosos (bah, vagos) o que no saben como escribir un caso de uso (que los hay, los hay) ni por malos programadores que malinterpretan lo que esta escrito en la lista de requerimientos (de estos también hay). Sencillamente es que no importa cuanto tiempo le dediquemos al relevamiento, no importa cuantas Maquetas, prototipos o casos de uso hagamos para mostrarle al usuario, no importa cuanto esfuerzo le dediquemos a reuniones de validación, siempre siempre siempre va a haber cambios a partir del relevamiento inicial (por favor, vuelvan atras y lean de nuevo esta frase).

Porqué? bueno, los principales motivos son :

1. El usuario ve el sistema funcionando y ahí se da cuenta lo que realmente quería .
2. El usuario descubrió a lo largo de todo el tiempo de trabajo en conjunto con analistas y desarrolladores lo que necesita.
3. Funcionales y Programadores aprendieron del dominio del problema y son capaces finalmente de entender lo que el negocio necesita ahora que el usuario finalmente aprendió.
4. El negocio simple y sencillamente cambió.
5. La legislación cambió.
6. El/Los usuarios cambiaron (y usuarios distintos quieren soluciones distintas).

Es decir, simple y sencillamente porque es NORMAL que la realidad cambie (un cambio en alguna regulación, etc, el mercado cambia, aparece un nuevo producto, etc). Y es NORMAL que el conocimiento cambie a medida que uno va teniendo más información y aprendiendo. Esta información solo se puede obtener a través de la experiencia. Esto es así porque al ser un sistema un modelo abstracto de la realidad el usuario sólo se da cuenta de las consecuencias de lo que pidió cuando lo ve funcionando, cuando lo "toca".

Que mente perversa nos metió en la cabeza la idea de que podemos preveer de entrada la forma en que se va a comportar la realidad!? Que cambios se van a producir en el mercado? que leyes saldrán? que va a querer el nuevo usuario o de que se va a dar cuenta el usuario que tenemos cuando le mostremos el comportamiento de las reglas de negocio que relevamos en casos concretos? seria como predecir el clima, pero de aca a un año!.

Una simple muestra para ver el lugar que ocupa el cambio en las metodologías ágiles, en el primer libro de XP, llamado "XP Explained", de Kent Beck, tenia como subtitulo "Embrace Change", abracemos el cambio!

Escuchemos de nuevo finalmente a Kent Beck, en un fragmento de su libro "Implementations Patterns" :

"Nuestra industria parece adicta a la idea de que solo si diseñamos el software bien de entrada no tendremos que cambiar luego el sistema.

Recientemente lei una lista de razones por las que el software cambia. En la lista estaban los programadores que no hacen bien su trabajo al entender los requerimientos, sponsors y usuarios que cambian de parecer y otros motivos mas. El unico factor que faltaba en la lista era justamente el cambio legítimo. La lista asumía que el cambio es siempre un error.

¿Porque no sirve un pronostico del tiempo para todos los dias? Porque el tiempo cambia de manera impredecible. ¿Porque no podemos listar de una sola vez todas las formas en las que necesitaremos que el sistema sea flexible? Porque los requerimientos y la tecnología cambian de manera impredecible.

Esto no nos releva de nuestra responsabilidad de hacer lo mejor que podamos para desarrollar el sistema que el usuario necesita ahora pero sugiere que hay límites al valor de hacer sistemas a prueba-de-cambios-futuros, a través de la especulación.

Poniendo todos estos factores juntos, la necesidad para que el sistema sea flexible ante el cambio, el costo de esa flexibilidad, la impredecibilidad de adonde será necesaria, me lleva a creer que el momento para introducir esa flexibilidad es sólo cuando la misma es absolutamente necesaria".