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.