archivo

Archivo de la etiqueta: Dave Thomas.

El desarrollo de software es un continuo adelante y detrás no solo fruto del feedback o del cambios en las especificaciones sino también como parte del proceso de construcción. ¿Quién no tiene que corregir errores?, ¿quién no mejora una sección del código que no termina de convencerle?, ¿quién no tiene que realizar ajustes como consecuencia de evolución solicitada por el área usuaria?.

Este tema lo traté en artículo: “¿Qué es el mantenimiento?” y lo vuelvo a hacer ahora porque realmente el hecho de que en el desarrollo de software la frontera entre la construcción y el mantenimiento sea tan débil (por no decir inexistente) me parece muy interesante ya que refleja un aspecto inherente al desarrollo de software como es su naturaleza evolutiva, es decir, el sistema se desarrolla poco a poco y con el paso del tiempo va adquiriendo forma, en todo ese proceso hay evolución y no solo por los aspectos funcionales (o no funcionales) que se van añadiendo, modificando o eliminando sino porque en ese proceso el software también cambia y no necesariamente para cambiar una funcionalidad (refactorización, corrección de incidencias, etc…).

Esta naturaleza evolutiva junto a otra característica inherente al proceso de desarrollo como es la incertidumbre ponen de manifiesto que el software estará sometido a cambios a lo largo del proyecto (por muy diversas causas) y que será necesario habilitar los mecanismos necesarios para que la adaptación a los mismos se realice lo antes posible.

Me gusta el enfoque que Dave Thomas da sobre este tema (traducción libre): “Si nos fijamos en el tiempo que pasamos programando, escribimos un poco y luego volvemos atrás y hacemos un cambio. O volvemos atrás y corregimos una incidencia. O lo tiras todo o lo reemplazas por otra cosa”.

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.

Los desarrolladores tenemos la tendencia a creernos mejores de lo que realmente somos. Afortunadamente el día a día nos pone de nuevo los pies en el suelo cuando los resultados que obtenemos distan de las posibilidades que teníamos.

Alejarnos del día a día ya sea porque vamos escalando en la organización o porque se realizan tareas que no están relacionadas con proyectos supone alejarnos de lo que nos pone los pies en el suelo y esa arrogancia crece y no parece tener freno.

La arrogancia también llega cuando no asumimos los errores (siempre es culpa de otro o simplemente los ignoro) o cuando se tiene una buena racha de resultados (probablemente hayas tenido que ver en ello pero no serás el único responsable).

La arrogancia crea distancia con los demás tanto si pertenecen a tu equipo como si se trata de la otra parte en una relación cliente/proveedor. Si eres bueno no hace falta ser arrogante para que te respeten.

La arrogancia te hace bajar las defensas, es lo que tiene creerte invulnerable. Cuando bajas la tensión y cuando disminuyes la atención es cuando mas posibilidades hay de cometer errores. Es una demostración más de que la arrogancia no te engrandece sino que te empequeñece.

Un ejemplo de esto último lo tenemos en la siguiente cita de Dave Thomas: “Si asumes que puedes producir un software libre de errores, tu actitud cambia cuando lo escribes. Tiendes a ser arrogante o por lo menos complaciente con el código que escribes”.

El desarrollador de software, por regla general, es creativo. Esa creatividad lleva en muchas ocasiones a incrementar la complejidad del producto bien sea añadiendo funcionalidades innecesarias o por querer hacer filigranas sobre funcionalidades que son importantes o sobre aspectos más internos del desarrollo como la arquitectura o la programación.

La complejidad adicional puede ser bienvenida si realmente aporta un valor proporcional al esfuerzo necesario para llevarla a cabo. El problema realmente se produce porque la complejidad añadida no suele tener aparejado ese beneficio y se convierte al final en un lastre con el que tenemos que cargar y que no siempre resulta sencillo quitárnoslo de encima.

Sobre aspectos técnicos (salvo en proyectos con usuarios con el perfil adecuado) el usuario no va a entrar a valorar tus decisiones por lo que en estos casos se requiere una cierta disciplina personal para ser práctico, diseñando un software de calidad pero sin entrar en excesos que pueden poner precisamente en peligro ese nivel de calidad o incluso la posibilidad de alcanzar las expectativas por incurrir en un coste excesivo en este tipo de tareas.

Sobre aspectos funcionales sí que debe ser el usuario el que tenga la última palabra (no entro a valorar las situaciones en las que hay que discutir aspectos presupuestarios que condicionarán hasta dónde se puede llegar con el presupuesto existente en base al esfuerzo invertido en las tareas realizadas hasta ahora).

Claro que podemos expresar nuestra opinión y debatir con el usuario (toda propuesta es mejorable), incluso mostrarnos con una cierta vehemencia en lo que creemos que es lo más correcto, pero al final la decisión debe ser siempre del usuario (aunque se equivoque y le hayas advertido) porque de lo contrario te estás echando a la espalda una responsabilidad que no te corresponde y que después te saldrá cara y por otro lado porque si desarrollas funcionalidades que no ha pedido el usuario pocas veces te lo agradecerán, lo más probable es que tengan menos utilidad de lo que crees y seguirás teniendo que hacer los desarrollos que estaban pactados.

La siguiente reflexión de Dave Thomas resume toda esta situación (traducción libre): “Si trabajas con el usuario con una mayor proximidad. Si trabajas interactivamente con el usuario ya sea diaria o semanalmente, el usuario tendrá la capacidad de indicarte cuando es tiempo de parar. No le permitas a los programadores añadir funcionalidades solo porque piensen que podrían ser una buena idea. Añadir funcionalidades debería ser una decisión del usuario y no una decisión del programador”.

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”.

La siguiente reflexión de Dave Thomas representa una realidad (traducción libre): “El objetivo final de desarrollar software es producir código que genere un valor para el negocio. Y ese valor es producido por el código que se ha escrito. Solo cuando has escrito el código sabes si efectivamente es así”.

Ni Dave Thomas ni mi apoyo a su cita suponen menospreciar todo el trabajo realizado previamente (independiente de la metodología utilizada y de si es más ortodoxo o no en la ingeniería de requisitos), es más, sin él no tendríamos nada. Sin intención estaríamos iterando indefinidamente hasta agotar el presupuesto en un producto que probablemente se encuentre muy lejos de las expectativas del usuario (si es que se ha llegado a obtener algo que realmente funcione).

Intención, siempre con intención. Siempre intentando estar más cerca de la solución, nos equivocaremos muchas veces pero siempre intentaremos tirar a dar.

Pero la solución final la tendremos a través del feedback porque hasta entonces lo abstracto no se ha convertido en algo real.

Que el software se deteriora conforme se va evolucionando es un hecho a partir del momento en que el sistema tiene implementadas el conjunto de funcionalidades que el usuario realmente necesita (el problema de esto es que casi siempre resulta complicado saber cuándo se llega a este punto y que incluso llegando a él habrá funcionalidades adicionales a las estrictamente necesarias que también se habrán implementado).

Este deterioro es aplicable a nivel funcional (se implementarán nuevas funcionalidades muchas de las cuales serán innecesarias, lo que hará más complejo el uso del sistema, introducirá nuevos errores y provocará probablemente efectos colaterales) y técnico (antipatrones ancla de barco y lava seca, incremento de la complejidad, etc…).

Hablo en términos generales, ya que incluso en estos casos es posible mejorar el sistema en ambos aspectos.

Ahora bien, me parece muy interesante poneros la siguiente reflexión de Dave Thomas, ya que la deuda técnica es una resistencia que tiene el software pero de cara a su evolución y en ese sentido es importante tenerla en cuenta, no obstante la deuda técnica no actúa si el software está en reposo (eso de que no actúa también es relativo ya que un sistema con una deuda técnica alta es serio candidato a dar muchos problemas) si vemos dicho concepto desde el punto de vista de la mantenibilidad: “La métrica del coste del cambio empieza a correr cuando tomas una decisión. Si no tomas una decisión, entonces no hay nada que cambiar y la curva contínúa plana”.

Por tanto, la degradación no debería considerarse función del tiempo sino de la evolución. Sin embargo se asocia generalmente con el tiempo y tiene una cierta lógica ya que la evolución es consecuencia de actuaciones que se realizan en el sistema conforme avanza el tiempo.

Es cierto que hay muchas variables que influyen sobre tu motivación pero hay una que tiene una especial relevancia (no digo que sea capaz de revertir situaciones imposibles pero que sí es bastante efectiva incluso en contextos que te invitarían a una permanente bajada de brazos) y es sentir que aportamos valor con nuestro trabajo (que mediante nuestro esfuerzo intelectual y físico influimos positivamente en el producto) y que lo que hacemos permite mejorar ya sea un proceso, una herramienta, una organización, un conjunto de personas o el mundo.

Ese sentimiento debe nacer de uno mismo si bien es importante que los gestores ayuden a forjarlo y a consolidarlo algo que no es demasiado habitual ya que generalmente se destacan más los fallos que los aciertos y no se comunica los efectos que el desarrollo produce sobre sus destinatarios (es cierto que no siempre se puede saber con certeza pero también lo es que no se suele prestar demasiada atención a obtener esa información).

Ya que tenemos que ir a trabajar y que pasamos allí un buen número de horas cada día resulta mucho mejor sentirnos importantes y sentir que lo que hacemos vale para algo.

La siguiente cita de Dave Thomas creo que resume perfectamente el contenido de este artículo: “Para motivarte y mantenerte comprometido necesitas estar orgulloso de lo que estás haciendo. Si por el contrario te consideras un trabajador de una línea de ensamblaje cuyo único trabajo es coger una especificación y convertirla en bytes, no vas a tener suficiente interés en lo que estás haciendo como para hacerlo bien”.

Es cierto que hay personas que se sienten encantadas con ser meros ejecutores de tareas, lo respeto, pero mi visión sobre el papel que debe desempeñar cada persona en un proyecto de desarrollo de software va mucho más allá de eso y está en consonancia con el contenido de este artículo.

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.

Para Dave Thomas la calidad y el desarrollo no son elementos que se deban separar: “La calidad es algo que tu haces todo el tiempo mientras está desarrollando”.

Cuando en nuestra cabeza solo existe el deseo o necesidad de seguir ejecutando trabajo ya sea por presiones de nuestros superiores y/o del cliente y/o porque lo queremos es quitarnos cuanto antes las tareas que tenemos asignadas difícilmente conseguiremos un producto final de calidad (en todos los sentidos, tanto en aspectos técnicos como en funcionales).

La verdad es que es complicado salir de la espiral de las presiones y de los plazos pero si no tenemos una plena conciencia de que tenemos que desarrollar, dentro de nuestras posibilidades y del proyecto, un software con la mayor calidad posible siempre encontraremos una excusa, a veces más fundada y otras casi sin argumento, para limitarnos a ejecutar tareas lo más rápido posible sin centrarnos en que lo importante no es la rapidez sino la efectividad y la misma se obtiene a través de la calidad.