archivo

Archivo de la etiqueta: Bertrand Meyer

Comenta Bertrand Meyer que: “El único gran enemigo de fiabilidad (y tal vez de la calidad del software en general) es la complejidad”, y tiene gran parte de razón.

La complejidad en sus dos vertientes: incluir funcionalidades no necesarias (o hacer más complejas funcionalidades que sí son necesarias) y descuidar la arquitectura y construcción del software haciendo el software mucho más complicado de evolucionar (mayor esfuerzo y mayor probabilidad de errores).

Tenemos que aprender a ser pragmáticos, a dejar de construir la casa por el tejado, a querer rizar el rizo sin ni siquiera tener el producto funcionando y todo ello sin olvidar que si no se construye software de calidad estamos poniendo resistencia y frenos a la capacidad de adaptación y evolución del sistema.

Una solución más compleja no tiene por qué ser mejor, una solución con más funcionalidades no tiene por qué ser mejor y una solución que esté a lo último en tecnología no tiene por qué ser mejor. Lo de menos es más, no es tampoco ciencia exacta, pero la verdad es que funciona más veces de lo que creemos.

Si desarrollas una solución demasiado compleja, al final pasa como con los mandos a distancia, muchos botones, muchas funciones, pero al final no utilizas ni el 10% de ellas.

Por otro lado, añadir complejidad de manera sistemática sin tener el producto en producción supone prácticamente comprar toda la taquilla para un más que probable fracaso y con poco margen de maniobra posterior, ya que tendremos un software mucho más voluminoso que mantener (y con una mayor deuda técnica ) y habrá menos recursos económicos para hacerlo.

La siguiente cita de Bertrand Meyer puede crear algo de controversia (traducción libre): “Que esté correcto es claramente la primera calidad. Si un sistema no hace lo que se supone que debe hacer, entonces todo lo demás importa poco”.

¿Por qué digo que es controvertida? Si se entiende a partir de ella que el fin último es satisfacer las necesidades de los usuarios a través de un producto que se aproxime a lo que estaban esperando y que para eso todo vale, puede considerarse como polémica porque la calidad del software va más allá de eso, es más, probablemente sin esos otros ingredientes resulta mucho más complicado conseguir ese objetivo.

De hecho, si en el software se va acumulando tanta deuda técnica que hace prácticamente inmanejables las tareas de evolución del producto, tenemos un problema importante porque si bien se ha podido conseguir un producto del que estén satisfecho los usuarios, es posible que esa satisfacción sea efímera porque lo más probable es que el producto tenga que modificarse en un futuro, sea a corto, medio o largo plazo y si como consecuencia de las dificultades para adaptar el sistema al cambio no es posible en forma y/o en tiempo (y/o en la cantidad de dinero que es posible invertir), el éxito inicial se habrá convertido en un espejismo.

Como es lógico, Bertrand Meyer pone sobre la mesa algo muy importante y que los desarrolladores a veces perdemos de vista y es que, por regla general, desarrollamos un software para que lo utilice un tercero y no para:

– Seguir procesos por el simple hecho de seguirlos, sin tener en cuenta la realidad y contexto del proyecto y producto en el que estamos trabajando.

– Seguir determinadas técnicas que pudiendo ser beneficiosas no resultan prácticas para este proyecto concreto.

– Ponernos a hacer experimentos que si no tienen como fin obtener un aprendizaje que permita dar un mayor valor al producto directa o indirectamente, se deberían evitar.

Para Bertrand Meyer: “El único gran enemigo de fiabilidad (y tal vez la calidad del software en general) es la complejidad”.

En mi opinión hay muchas más variables pero sí que es cierto que la complejidad condiciona, sin lugar a dudas, el resultado final de un producto, su usabilidad y la capacidad de realizar mantenimientos sobre él o, lo que es lo mismo, la capacidad de evolucionarlo.

Si nos dejamos seguir por las modas, si se imponen restricciones técnicas o de arquitectura que no condicionan sobre manera el proyecto, si miramos la solución como un juguete o un banco de pruebas, probablemente se le esté añadiendo la resultado final una complejidad innecesaria y que después va a resultar muy costosa de eliminar.

Si el producto se empieza a “engordar” con funcionalidades que no son necesarias, con módulos que no tienen nada que ver con su objeto final (porque resulta más barato incluirlos en la plataforma que crear un sistema desde cero para ellas), etc…, también se estará añadiendo complejidad que hay podido ser evitable.

A más complejidad más probabilidad de que existan errores y que no sean detectados. A más complejidad más deuda técnica.

El producto resultante de un proyecto de desarrollo de software requiere de un período de maduración que comienza con el inicio del mismo a través de los ajustes que se realizan en las diferentes iteraciones y a través del conocimiento adquirido dentro y al final de las mismas (no solo se trata de aprender del feedback, se puede aprender también mientras se analiza una historia de usuario y nos apoyamos en estrategias tales como prototipado, pantallazos, etc…).

La solución no se tiene clara desde el principio, nadie la tiene ni usuarios ni desarrolladores (cada uno dentro de su ámbito de actuación) y lo más probable es que la visión que ambas partes tengan del producto en ese momento difieran sensiblemente.

El conocimiento inicial es limitado y esto eleva la probabilidad de que cometamos errores.

Es cierto que por algo tendremos que empezar y eso ya supone una apuesta pero eso es diferente a jugar todas tus cartas a una solución y tirar con ella hasta el final que es lo que sucede en los ciclos de vida clásicos. En estos casos también se madura la solución pero más a nivel técnico que funcional lo que da lugar a los problemas habituales en la aceptación del producto o tras su puesta en producción y es el desajuste entre lo que el usuario recibe y las expectativas que tenía puestas en el mismo.

En el proceso de maduración tendremos probablemente que desechar decisiones que tomamos en etapas anteriores precisamente por el hecho de no haber acertado o por existir otras soluciones más efectivas y válidas. Tirar y volver a hacer tiene un coste pero más caro resulta ir hasta el final con una solución no satisfactoria.

Lo importante es hacer un producto cada vez mejor aunque no consigamos un avance lineal en el proyecto.

Bertrand Meyer realizó la siguiente cita: “Las malas ideas y las más complicadas (que a menudo son las mismas) a menudo aparecen las primeras, se necesita tiempo para que aparezcan las simples y elegantes”.

Cuando se documenta es necesario tener presente el período de caducidad del documento. Si hay documentos que se pretenden que sean la referencia del producto desde diferentes puntos de vista: funcional, operativo, arquitectura, diseño, etc… es importante tener en cuenta hasta dónde llega nuestra capacidad de ir manteniéndolos conforme el producto evoluciona.

Ser demasiado ambicioso implicará muy probablemente que buena parte de esa documentación deje de actualizarse y por tanto esté caducada a efectos prácticos (incluso se puede dar el caso de que la misma perjudique más que ayude). Sin embargo resulta difícil encontrarnos con casos en donde un documento se tache como caducado siendo la única referencia la fecha real de elaboración o aprobación del mismo (si es que efectivamente aparecen por alguna parte).

La documentación debe ser la realmente necesaria (que no es lo mismo que la teóricamente necesaria) y acorde a lo que podamos soportar. Sobre esa premisa cada cual dentro del enfoque que considere más adecuado para el proyecto que decida qué es lo que realmente necesita (salvo que existan procesos donde más allá que de un mínimo te impongan una serie de hitos documentales).

Creo que la siguiente reflexión de Bertrand Meyer (profesor universitario y autor francés, experto en programación orientada a objetos y creador del lenguaje Eiffel) resume el contenido de este artículo: “Hay una situación peor que no tener documentación y es tener documentación incorrecta”.