Bertrand Meyer. La complejidad es enemiga de la calidad del software

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.

Octava ley de Lehman. Realimentación del sistema

Su enunciado es el siguiente: «El proceso de evolución del sistema es consecuencia de un proceso de realimentación (feedback) a diferentes niveles, de manera iterativa y por diferentes actores, y debe ser considerado como tal para conseguir mejoras significativas sobre cualquier base razonable».

El carácter evolutivo del desarrollo de software lo caracteriza durante todo su ciclo de vida. Es continuo, aunque se materializa mediante incrementos o iteraciones, que pueden ser mediante ciclos más o menos regulares o de forma más discontinua.

En cada evolución se tiene la posibilidad de recabar feedback a diferentes niveles, por ejemplo, calidad estática del código (utilizando algún analizador tipo Sonar), número de defectos que presente al producto, grado de satisfacción del usuario, mejoras o nuevas funcionalidades que quieran incorporar una vez que se han analizado las de la versión que se ha entregado, etc…

Con la información obtenida se pueden plantear diferentes acciones que debidamente priorizadas pueden mejorar la calidad del sistema y que darán lugar a nuevas actuaciones (nuevas evoluciones) sobre el mismo.

Séptima ley de Lehman. Reducción de la calidad

Su enunciado es el siguiente: «La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)».

En esta ley, Lehman trata el problema de la disminución de la calidad desde diferentes puntos de vista:

– El usuario tiende a ser más exigente conforme mayor sea la inversión dedicada a la evolución del producto y conforme se den cuenta (independientemente de que sepan interpretar su complejidad o no) de la maleabilidad del software.

– La calidad del software se ve afectada por en incremento de la complejidad del sistema conforme se va evolucionando y eso afecta a diferentes escalas: codificación/arquitectura (deuda técnica), usabilidad, etc…

– Por otro la propia convivencia del sistema con su entorno tecnológico (software y hardware), el cual evoluciona de la misma forma que los sistemas y en muchos casos con características muy similares. En esa evolución se tratan de corregir fallos de seguridad, se trata de dar una mayor estabilidad, a la par de incluir nuevas funcionalidades que puedan resultar de utilidad (y distinguirla de otras opciones del mercado).

Si un sistema no se adapta a esos cambios y las características de los nuevos entornos operacionales que se estén montando no son compatibles, estamos acotando el sistema a seguir subsistiendo con versiones en muchos casos sin soporte de los mismos y que además, se irá quedando marginada porque el esfuerzo central del Departamento de Sistemas se centrará en los entornos en los que se encuentre el grueso de los sistemas de información de la organización, además de aquellos que sean considerados críticos.

El alcance de esta séptima ley se puede extender al propio framework de desarrollo del producto y al conjunto de librerías dependientes que utilice, de manera que surgen nuevas versiones de las mismas que mejoran las anteriores a la vez que corrigen defectos en las mismas.

También puede ser extensible a una menor calidad como consecuencia de no aplicar medidas conforme se incrementa la complejidad del producto (en este caso se asimilaría a la segunda ley de Lehman).

Sexta ley de Lehman. Crecimiento continuo

Su enunciado es el siguiente: «Las funcionalidades del sistema tienen que crecer constantemente para mantener la satisfacción del usuario a lo largo de su ciclo de vida».

Se trata de una particularización de la primera ley de Lehman, solo que en este caso no se habla de adaptación y sí de crecimiento (que como ya hemos visto son conceptos que pueden ser complementarios pero que son diferentes).

Los dos principales fundamentos de esta ley se encuentran:

– En que en el proceso de desarrollo de la aplicación, con el objeto de adecuar el alcance a las posibilidades del proyecto (tiempo, presupuesto, etc…), hay funcionalidades que se descartaron o se postergaron, bien por no considerarse esenciales en ese momento o por no poderse acometer su versión.

– Cuando un sistema presenta problemas a la hora de ponerse en marcha en el conjunto de usuarios, en lugar de ponernos a analizar los motivos por los cuales no cumplen las expectativas, se tiende a pensar que la solución se encuentra en la incorporación de nuevas funcionalidades (que tiendan a tapar o a restar protagonismo a las deficiencias que presente la aplicación).

Con respecto a este segundo fundamento, hoy en día se tratan de racionalizar mucho más los desarrollos, de manera que se trata de buscar la solución más simple que trate de satisfacer las expectativas de los usuarios, lo que hace que solo se tenga en cuenta el desarrollo de nuevas funcionalidades si resulta estrictamente necesario.

Quinta ley de Lehman. Conservación de la familiaridad

Su enunciado es el siguiente: «Cuando un sistema evoluciona, todos aquellos que están asociados a él: desarrolladores, personal de ventas, usuarios, deben mantener un conocimiento de su contenido y comportamiento para tratar de conseguir que la evolución sea satisfactoria. Un crecimiento excesivo disminuye ese conocimiento. De ahí que el crecimiento incremental promedio permanezca invariante».

O lo que es lo mismo, la única manera de que las personas vinculadas al sistema no pierdan el control sobre los cambios que se realizan es que su crecimiento se realice de forma sostenida, de manera que la combinación entre el número, complejidad e impacto de las funcionalidades que se añadan o modifican en cada evolución del sistema se mantenga constante.

También es importante tener en cuenta que cuando un conjunto de personas se acostumbran a una determinada dinámica de funcionamiento del sistema, les resulta más complicado encajar cambios sensibles sobre el mismo. La costumbre se termina imponiendo a nuevas ideas o por lo menos a aquellas que puedan interpretarse como disruptivas.

Cuarta ley de Lehman. Conservación de la estabilidad organizacional

Su enunciado es el siguiente: «La velocidad (y efectividad) de desarrollo de un sistema en evolución permanece invariante durante su ciclo de vida».

En cierto modo está relacionada con la anterior ley, porque no deja de ser un atributo más que se autorregula por el propio contexto en que se desarrolla el sistema y por sus propias características.

Según esta ley (con la que se podrá estar más o menos de acuerdo), es complicado que se den todas las condiciones adecuadas para que la velocidad de desarrollo de un determinado sistema aumente, porque cuando se tenga un buen equipo de trabajo lo mismo son los responsables funcionales o el personal directivo los que se muestran indecisos, toman decisiones erróneas, tienen que reducir o cambiar el equipo por motivos económicos u optan por ralentizar la evolución o cuando estas circunstancias sean favorables, lo mismo es el equipo el que no responde.

A lo anterior hay que sumar otros factores como son el incremento de la complejidad que compensaría (en negativo) un mejor funcionamiento de la organización o el hecho de que haya algunos atributos que según la tercera ley de Lehman se mantienen constantes como, por ejemplo, la tasa de errores (que también afectan a la velocidad de desarrollo).

Haciendo medias de esas situaciones se entenderá que la efectividad de la evolución se mantiene más o menos constante durante su desarrollo.

Tercera ley de Lehman. Autorregulación

Su enunciado es el siguiente: «El proceso de evolución de un sistema es autorregulado con una distribución de las medidas del producto y del proceso cercana a la normal».

¿Qué quiere decir eso? Que el propio contexto en el que se evoluciona el sistema (junto al propio sistema) generan unas condiciones que provocan que haya una serie de características del producto que sigan una tendencia o se mantengan invariantes, de manera que por ejemplo, atributos tales como el tiempo entre entregas, el número de defectos detectados o el tamaño, sigan una determinada línea.

Esas condiciones surgen por las propias características del sistema o por las propias características de la organización, ya que no hay que olvidar que los desarrolladores hacen su trabajo bien para un cliente o bien dentro de una organización más grande que tendrá implantados otros sistemas y que tiene unas prioridades que van variando en función de las propias necesidades de la organización.

La propia complejidad del software interviene como un elemento más de este proceso autorregulador, de esta forma podemos asociar esta ley con la segunda de la siguiente manera:

– Podemos hacer actuaciones para reducir la complejidad o realizar mejoras en nuestras prácticas de trabajo, que siempre se encontrarán limitadas por las propias características del sistema y su contexto, es decir, se puede mejorar, pero siempre habrá una «carga extra» que tendremos que soportar.

– En el caso de que evolucionemos el sistema (aún sin la realización de medidas específicas para mantener o reducir la complejidad, sin que eso quiera decir que no se apliquen buenas prácticas), habrá una serie de atributos que permanecerán constantes, como podría ser la tasa de errores, o que crecerán proporcionalmente (siguen una tendencia) como el tamaño del sistema.

Segunda ley de Lehman. Complejidad incremental

Su enunciado es el siguiente: «Cuando un sistema evoluciona se incrementa su complejidad a menos que se trabaje para mantenerla o reducirla».

La complejidad crece no solo a nivel de deuda técnica (algo que es razonable por el incremento del tamaño del sistema), sino también a nivel de administración, usabilidad y recursos software y hardware necesarios para su funcionamiento.

Si se tiene cuidado y se aplican buenas prácticas, este incremento de la complejidad puede hacerse más moderado e incluso puede reducirse si se aplican medidas específicamente destinadas a este fin (que se complican cuando a la vez se están incorporando nuevas funcionalidades al sistema).

Lo que viene a decirnos (de la mano de la Primera Ley) es que con el paso del tiempo va a ser necesario evolucionar las aplicaciones y que ese coste será progresivamente mayor conforme se realicen nuevas actividades de mantenimiento en el sistema.

Primera ley de Lehman. Cambio continuo

Su enunciado es el siguiente: «Los sistemas deben ser continuamente adaptados o se convierten progresivamente en menos satisfactorios».

No todos los sistemas requieren el mismo nivel de evolución pero sí que es cierto que el contexto cambia y que tarde o temprano (en algunos casos más pronto que tarde) será necesaria una adaptación al cambio.

Es importante tener en cuenta que la adaptación no implica necesariamente un crecimiento del sistema (si bien en la mayoría de los casos pueden estar ligados), ya que un proceso de adaptación puede estar basado en una nueva forma de enfocar las funcionalidades ya implementadas en el sistema o en una reingeniería del proceso que se ha informatizado.

Es cierto que hay sistemas que no se han tocado en años pero, ¿es realmente porque no es necesario o por el coste que tendría asociado?. El motivo principal de que estas aplicaciones no se toquen es económico a lo que hay que sumar el factor de incertidumbre (o miedo) de retocar un sistema que está funcionando (con más o menos satisfacción para la organización y para los usuarios) y que por dentro se sospecha que está todo cogido con alfileres.

Lo que viene a decir esta ley es que no podemos pensar es que nuestra inversión no termina con la adquisición del producto software o con su desarrollo a medida, sino que tendremos que seguir realizando nuevas inversiones para adaptar el mismo a los cambios en las necesidades de la organización, del mercado, etc…

O lo que es lo mismo, el mantenimiento es inevitable.

Leyes de Lehman. Introducción II

Otro aporte de Lehman consistió en el hecho de que conforme se evoluciona un producto crece su complejidad y su tamaño, lo que hace que cada vez sean más costosas esas actividades.

Por tanto, el mantenimiento de un producto es inevitable y su coste (como consecuencia de una mayor complejidad) irá creciendo a lo largo del tiempo. De ahí que se considere que el software no se desgasta, pero sí que se deteriora.

Recordemos una conocida cita de Fred Brooks: «La complejidad del software es una propiedad esencial, no accidental».

¿Es posible poner medios? Claro que sí, tanto en las actividades ordinarias de desarrollo (aplicando buenas prácticas y considerando la refactorización como parte del propio proceso de desarrollo) como con actividades extraordinarias (planes de acción para simplificar la arquitectura del sistema, reducir la deuda técnica, etc…). No obstante, debemos tener en cuenta que con independencia de estas actividades sí que es cierto que la complejidad del sistema crece conforme el mismo evoluciona.

Más controvertidas resultan otras afirmaciones de Lehman, en las cuales considera que determinados atributos relacionados con el desarrollo de software (tamaño, número de defectos, tasa de crecimiento), etc…, se mantienen más o menos constantes o siguen una tendencia (una proporcionalidad) a lo largo del proceso de evolución del software.

Estas afirmaciones, personalmente me parecen más discutibles (no quiero decir que no esté de acuerdo en todas), si bien, pese a que me base en mi propia experiencia, no he analizado datos empíricos para verificar si efectivamente se cumplen o no.