archivo

Archivo de la etiqueta: Andy Hunt

Me parece muy interesante la siguiente reflexión de Dave Thomas: “Queremos que la gente vea el software como algo más orgánico, como algo más maleable y algo con el que tengas que estar preparado para interactuar con él y mejorarlo todo el tiempo”.

Esta reflexión está relacionada con una cita de Andy Hunt y Dave Thomas de su libro “The Pragmatic Programmer”: “En lugar de a la construcción el software se parece más a la jardinería” y en la justificación de dicha afirmación por parte del propio Dave Thomas (traducción libre): “En los jardines existe la suposición de que va a tener un mantenimiento constante. Todo el mundo dice que quiere un jardín que no requiera mucho mantenimiento pero al final es un jardín es algo con lo que siempre estás interactuando bien sea para mejorarlo o mantenerlo”.

Yo también veo el desarrollo de software así. La realidad demuestra que los procesos que se informatizan están en continua evolución, cambian normativas, se quiere buscar una mejora continua, se quiere ser competitivo. Por otro lado el software por sus características es un elemento que puede ser mantenido y mejorado sin necesidad de interrumpir el funcionamiento normal del sistema, incluso cuando se realizan modificaciones radicales sobre el mismo (salvo en aquellos casos donde el cambio en el proceso sea tan abrupto que haga el sistema inútil de la noche a la mañana, cosa que si bien puede pasar, no es lo más frecuente).

El software va a requerir mantenimiento (o mejor dicho, evolución), por ese motivo hay que pensar en tiempo de desarrollo la estrategia más adecuada para reducir la necesidad y los costes de mantenimiento. Desarrollar dejando eso en segundo plano después cuesta mucho dinero y problemas.

Cuando los procesos por sí solos sean capaces de desarrollar software tal vez piense que su importancia es mayor que la de las personas pero mientras sean los seres humanos los que con su esfuerzo sacan adelante los proyectos para mi la prioridad la tienen ellos.

La creencia en que el proceso lo soluciona todo ha llevado a la definición de algunos que prácticamente no dejan margen de maniobra a los desarrolladores que se ven atados de pies y manos (en el caso de que además su cumplimiento sea obligatorio) a la hora de tomar decisiones, actitudes o estrategias que pueden ser más positivas para el proyecto en el que se está trabajando. En el desarrollo de software no hay llaves maestras, no hay verdades absolutas y mucho menos procesos que sirvan para todo y que sean una garantía infalible de éxito.

Las personas que participan en el proyecto requieren margen de maniobra para poder adoptar dentro de unas restricciones la solución más adecuada para su contexto actual.

Sobre este tema me gusta mucho la siguiente reflexión de Andy Hunt y Dave Thomas, “Cualquier proceso que intente reducir el desarrollo de software a algo que no requiera utilizar el cerebro normalmente da lugar a solo eso: un producto desarrollado por gente sin cerebro”.

Hace poco tuve la oportunidad de leer una entrevista que se realizó a Andy Hunt y Dave Thomas en el año 2003 que giraba alrededor de conceptos tratados en su libro: “The Pragmatic Programmer” y que me permitió darme cuenta de que el término DRY (Don’t repeat yourself) y que hacían uso en su libro iba más allá de la duplicación de código.

Por ejemplo, en el artículo que escribí denominado: “Desarrollo de software. Martin Fowler. Un buen diseño pasa por reducir o eliminar el código duplicado“, el concepto lo aplicaba en relación al código duplicado, algo que no es erróneo porque forma parte del DRY pero que no representa toda su semántica.

¿A que se refieren con el DRY? Pues a evitar la duplicidad de cualquier componente software o no de un proyecto de desarrollo de software, como dicen estos autores (traducción libre): “Toda pieza de conocimiento (entidad) en un proceso de desarrollo debería tener una única representación” de manera que esto va más allá del código duplicado, extendiéndose a objetos de bases de datos, elementos documentales, funcionalidades, etc…

Todos conocemos las consecuencias de las duplicidades:

– Trabajo de más innecesario que se podría haber utilizado en tareas que requerían un mayor esfuerzo o en otras que hubieran sido de interés como por ejemplo refactorizar, automatizar testing, desarrollo de funcionalidades que no pudieron ser abordadas, etc…

– Mayor esfuerzo para mantener coherentes las duplicidades.

Realmente un producto o un sistema de información son susceptibles de ser evolucionados mientras no hayan llegado al final de su ciclo de vida.

En este artículo cuando se hace referencia a versión final del producto me estoy refiriendo a la versión final de un producto en el contexto de un proyecto concreto.

Un enfoque evolutivo o iterativo incremental realmente es efectivo si se realiza con intención ya que la probabilidad de que el avance sea continuo en cada iteración requiere que se “tire a dar” en cada ciclo. Hay que entender también que en ocasiones la evolución vendrá como consecuencia del descubrimiento de un camino incorrecto o de un error en las especificaciones, el feedback hace crecer a la solución tanto si los reportes son positivos como negativos, es decir, a veces parecerá que no termina de progresar el desarrollo pero una vez encontrado de nuevo el rumbo el ritmo de avance puede ser incluso sensiblemente mayor una vez que se tiene más claro el problema y se reduce la incertidumbre conforme nos vamos aproximando a la versión de entrega del producto.

La intención no quiere decir que se deba buscar la perfección en cada entrega, sino de llevar el proyecto en la dirección adecuada en el contexto actual, conforme vayamos evolucionando el producto tendremos la oportunidad de ir afinando cada vez más el producto (es un objetivo implícito dentro de un enfoque de naturaleza evolutiva) tanto a través del feedback como a través de la aplicación de buenas prácticas de programación.

Ya lo dice Andy Hunt: “No es tan importante hacerlo todo bien a la primera. Es absolutamente importante hacerlo bien al final”.

A veces localizar determinados errores e incidencias en el código y/o localizar puntos donde el sistema no tiene un buen rendimiento o donde funcionalmente tiene “comportamientos extraños” resulta complejo porque se obvian segmentos del código que se entiende que tienen un funcionamiento correcto.

¿Por qué se puede llegar a la conclusión de que funcionan si lo mismo ni siquiera lo has programado tu y ni te has preocupado por analizar el código? Pues porque generalmente hasta ahora no ha provocado problemas.

Bien, pero, ¿en qué contexto no ha dado problemas?, ¿estás seguro que en este el comportamiento era el adecuado?. En la mayoría de los casos no se somete al código a todas las casuísticas posibles, a veces porque la propia dinámica del proyecto te obliga a seleccionar bien el testing a realizar y a reutilizar componentes desarrollados en este o en otros proyectos y otras veces porque confiamos demasiado en le software que desarrollamos y en nuestra infalibilidad antes los errores (he conocido a mucha gente que se creía infalible pero a ninguno que lo fuera realmente).

Andy Hunt tiene una cita que resume todo esto de la siguiente manera: “No pases por alto una rutina o una sección de código implicado en el error porque creas que funciona. Demuéstralo. Demuéstralo en este contexto, con estos datos y con estas restricciones”.

Comenta Andy Hunt que (traducción libre): “La capacidad de adaptarse al cambio rápidamente es algo que los equipos pequeños tienen por defecto que los equipos grandes nunca van a tener. Aquí es donde los grandes envidian a los pequeños. Lo que puede tardar semanas en cambiar en una organización grande puede que solo lleve un día en una organización pequeña. Esa ventaja no tiene precio”.

La capacidad de adaptación al cambio es la base de las teorías evolucionistas de Darwin y uno de los fundamentos de los enfoques ágiles de los proyectos de desarrollo de software. O cambias rápido y bien o tal vez sea demasiado tarde.

La lógica es aplastamente: algo grande y complejo requiere más tiempo para adaptarse a una nueva circunstancia ya que resulta complejo vencer a la inercia y requiere mucho esfuerzo realinear los objetivos y la acción en la dirección adecuada.

Esto lo podemos ver, por ejemplo, cuando estamos tratando con sistemas de información complejos y otros más simples. A veces por las características del proceso o procesos que se informatizan o por la estrategia de sistemas de información a emplear (sistemas integrados) nos encontramos con sistemas complejos y/o de gran tamaño, en estos casos lo importante es analizar si todo lo desarrollado tiene utilidad real o no(el ejemplo que pongo siempre del mando a distancia: de los cuarenta botones que tiene el mando, ¿cuáles son los que realmente utilizo?) con el objeto de buscar la solución más simple dentro de ese contexto (en el camino hacia la simplicidad casi siempre hay margen de mejora independientemente de la situación de partida).

En el mundo empresarial los gigantes caminan poderosos cuando se encuentran en un contexto en el que se han adaptado perfectamente y ahí pueden lucir y aprovechar su musculatura en la lucha contra otras organizaciones más pequeñas, sin embargo si estos gigantes no han consolidado engranajes que mejoren la eficiencia en el tiempo de adaptación al cambio y/o no han sabido adelantarse a él sufren mucho y se desmoronan como un castillo de arena. Ahí son fuertes las organizaciones pequeñas y de cómo utilicen esa ventaja inicial condicionará mucho sus resultados en ese nuevo contexto económico o de negocio.

No siempre todo sucede como queremos, hay circunstancias que están por encima de nosotros y que impiden conseguir los objetivos, que no trabajemos como nos gusta o que simplemente nos hagan sentirnos incómodos.

No se trata de bajar los brazos o de quedarte sentado, la paciencia no es eso o al menos yo no la veo así, sino de saber esperar sin perder de vista nuestro trabajo y sin renunciar a nuestro deseo de cambiar las cosas.

Quien sabe esperar suele tener su premio, el contexto cambia, a veces a peor pero otras muchas a mejor. En un contexto favorable generalmente todo está cuesta abajo y se consigue de manera más sencilla lo que en contextos desfavorables requiere un esfuerzo muy grande.

¿Cuántas veces el que más resiste gana? Conozco muchos casos en los que es así.

Todo tiene un límite, la paciencia también. Al fin y al cabo la paciencia es una apuesta y se gana o se pierde, por eso hay que saber cuándo abandonar y escrutar otras opciones. Bajo esta perspectiva la paciencia es la capacidad de esperar el tiempo suficiente a que surja la oportunidad o cambie la situación y la habilidad de saber cuándo se ha esperado demasiado.

La paciencia no se debe asociar a grandes períodos de tiempo. En algunos casos esperar unas horas o unos días puede considerarse paciencia, en otros casos pueden ser meses o años.

Andy Hunt considera que “Paciencia y amabilidad es poder”, creo que no se equivoca.