CLEM: A Behavior-Centric Software Quality Measurement Framework for Structural Change Monitoring

Imagina que estás observando el crecimiento de una ciudad. Podrías contar cuántos ladrillos se colocan cada día, o podrías comprobar si el ayuntamiento siguió las reglas. Pero hay una tercera forma, más interesante, de mirar una ciudad: observar cómo cambian los edificios. ¿La gente derriba paredes viejas para añadir una habitación nueva? ¿Construyen un nuevo ala que se une al costado sin tocar la casa principal? ¿Simplemente accionan un interruptor para cambiar la iluminación? ¿O simplemente reorganizan los muebles? En el mundo del software, esta es exactamente la pregunta que los investigadores se están haciendo. El software no es solo código; es un sistema vivo que tiene que cambiar constantemente para seguir siendo útil. Si un sistema solo cambia derribando sus propias paredes, eventualmente se convierte en un desastre inestable y peligroso. Pero si cambia añadiendo nuevas alas o accionando interruptores, se mantiene fuerte y flexible. Esta es la esencia de la "calidad del software": no solo si el código funciona hoy, sino si puede seguir creciendo sin desmoronarse mañana.

Este artículo presenta una nueva herramienta llamada CLEM (Change Localization and Externalization Measurement) para responder a esa pregunta. En lugar de limitarse a contar cuánto código se cambió, CLEM actúa como un detective que observa cómo los desarrolladores arreglan o actualizan un sistema. Clasifica cada cambio en uno de cuatro "personajes":

1. Modificación (M): El enfoque de "Derribar la pared". Cambiar el código central directamente. Es rápido pero arriesgado, como hacer un agujero en una pared para añadir una puerta.
   2.Extensión (E): El enfoque de "Añadir algo". Construir nuevas funcionalidades que se conectan al sistema sin tocar el núcleo, como añadir una habitación nueva a una casa.
2. Low-code (L): El enfoque de "Diagrama de flujo". Usar herramientas visuales o reglas para cambiar el comportamiento, como un gerente de negocios que reorganiza un flujo de trabajo sin escribir código.
3. Configuración (C): El enfoque del "Interruptor". Simplemente cambiar ajustes o parámetros, como girar un dial para cambiar el volumen.

Los investigadores probaron esta idea en tres proyectos de software diferentes: dos públicos de un gran ecosistema tecnológico y una aplicación privada de salud. Descubrieron que CLEM puede distinguir claramente entre un sistema que es "saludable" (que usa principalmente complementos y switches) y uno que está "enfermo" (que constantemente hackea su propio núcleo). Sin embargo, también descubrieron algo sorprendente: saber cómo cambia un sistema no predice automáticamente si tendrá más errores el próximo mes. Es una gran herramienta para entender la estructura de un sistema, pero no es una bola de cristal para predecir errores futuros.

El nuevo cuaderno del detective: Cómo funciona CLEM

Piensa en el desarrollo de software como una cocina con mucho movimiento. Durante años, los chefs (desarrolladores) han sido medidos por cuántos platos cocinan (volumen de actividad) o qué tan limpia está la cocina al final de la noche (revisiones de código estático). Pero, ¿y si la cocina se está cayendo a pedazos porque cada vez que necesitan una especia nueva, tienen que romper una pared para llegar a la despensa? Ese es el problema que CLEM resuelve. No solo cuenta los platos; observa el método que los chefs usan para obtener los ingredientes.

El artículo propone que cada vez que se actualiza un sistema de software, el cambio ocurre de una de cuatro formas, y la mezcla de estas formas nos dice todo sobre la salud del sistema.

• La Modificación (M) es el método de "Fuerza Bruta". Es como un chef agarrando un mazo para romper una pared porque necesita un estante nuevo. Cumple el objetivo rápido, pero si lo haces demasiado, todo el edificio se vuelve inestable.
• La Extensión (E) es el método "Modular". Es como construir un carrito nuevo y desmontable que rueda hacia la cocina. El chef no toca las paredes; simplemente añade una nueva herramienta. Esto es más seguro y mantiene intacta la estructura central.
• El Low-code (L) es el método del "Plano". Imagina a un gerente dibujando un nuevo flujo en una pizarra que le dice a los robots qué hacer, sin que los robots necesiten ser reprogramados. Es una forma de nivel superior para cambiar las cosas.
• La Configuración (C) es el método del "Dial". Es solo girar una perilla para que el horno esté más caliente o las luces brillen más. No se necesita construcción alguna.

Los autores argumentan que un sistema de software sano y duradero debería apoyarse más en la Extensión, el Low-code y la Configuración, y menos en la Modificación. Si un sistema está "Modificando" constantemente su núcleo, es probable que esté acumulando "deuda técnica", una forma elegante de decir que está pidiendo prestada estabilidad al futuro y tendrá que pagarla con intereses más tarde.

El experimento: Observando tres cocinas

Para ver si esta idea funciona, los investigadores hicieron una excursión a tres "cocinas" (repositorios de software). No solo miraron los platos finales; observaron las manos de los chefs durante meses.

1. La cocina "Fit" (fit-framework): Este era un proyecto público diseñado para ser un sistema de plugins. Esperaban que estuviera lleno de "Extensiones" (E).
2. La cocina "App" (app-platform): Este era otro proyecto público, pero fue construido para el diseño visual de bajo código (low-code). Esperaban que estuviera lleno de "Low-code" (L) y "Configuración" (C).
3. La cocina "Antisuger": Esta era una aplicación privada de salud para la gestión del azúcar en sangre. Fue construida por un equipo diferente con herramientas distintas. Esperaban que estuviera en una fase temprana y caótica, probablemente llena de "Modificaciones" (M).

Los investigadores analizaron 607 actualizaciones específicas (commits) en estos proyectos. Utilizaron un conjunto de reglas transparentes para observar los archivos que se estaban cambiando. Si un archivo estaba en una carpeta de "plugin", lo contaban como Extensión. Si era un archivo de "flujo", lo contaban como Low-code. Si era un archivo de código central, era Modificación.

Lo que encontraron: Los sistemas se veían diferentes

Los resultados fueron exactamente lo que la teoría de la "cocina saludable" predijo.

• La App-platform era, de hecho, muy "externalizada". Alrededor del 69.5% de sus cambios fueron Extensiones, con muy poca manipulación directa del núcleo. Su puntuación "CLEM-ES" (una medida de cuánto se alejó el cambio del núcleo) fue un sólido +0.685.
• El Fit-framework era una mezcla. Tenía muchas Extensiones (33.4%), pero también una parte significativa de Modificaciones (29.1%). Su puntuación fue de +0.418, mostrando que era más saludable que un desastre puro, pero no tan "externalizada" como la App platform.
• La aplicación de salud Antisuger era lo opuesto. Era casi totalmente dominante en "Modificación", con el 83.0% de sus cambios siendo ediciones directas al núcleo. Su puntuación fue de -0.659, indicando que todavía estaba en una fase frágil de "hackear las paredes".

Esto demostró que CLEM puede detectar con éxito la diferencia entre un sistema que crece añadiendo alas y uno que crece rompiendo paredes. Los investigadores incluso comprobaron si sus reglas eran justas haciendo que dos humanos revisaran 160 actualizaciones aleatorias. Coincidieron el 100% de las veces en la categoría principal, lo que sugiere que las reglas son sólidas y reproducibles.

El giro: La estructura no predice los errores (todavía)

Aquí es donde el artículo es muy cuidadoso. Podrías pensar: "Si un sistema está hackeando sus propias paredes (alta Modificación), debería romperse más a menudo, ¿verdad?". Los investigadores probaron esto. Observaron si las puntuaciones de CLEM podían predecir si el sistema tendría más "correcciones de errores" (bug fixes) el mes siguiente.

¿La respuesta? No hay un vínculo claro.
En sus datos, la puntuación de "Modificación" no predijo de manera fiable si el mes siguiente estaría lleno de correcciones de errores. La puntuación "CLEM-ES" (qué tan externalizados eran los cambios) tuvo casi cero correlación con las futuras correcciones de errores en esta muestra específica.

Este es un hallazgo crucial. Los autores declaran explícitamente que CLEM no es una bola de cristal mágica para predecir defectos. No reemplaza las formas antiguas de contar errores o la rotación de código (code churn). En su lugar, ofrece un tipo diferente de información. Te dice sobre la postura estructural del sistema. Un sistema con una alta puntuación de Modificación puede no tener más errores hoy, pero está construyendo una estructura que es más difícil de mantener y más propensa a volverse frágil con el tiempo. Es como un edificio que es estructuralmente inestable; puede que no colapse hoy, pero el plano es malo.

Por qué esto es importante

El artículo concluye que CLEM es una nueva y poderosa lente para los gestores de software. Mueve la conversación de "¿Cuánto código escribimos?" a "¿Cómo estamos cambiando nuestro sistema?".

• Si ves a un equipo haciendo constantemente Modificaciones, es una señal para detenerse y preguntar: "¿Por qué estamos rompiendo nuestras propias paredes? ¿Podemos construir un plugin en su lugar?".
• Si ves a un equipo haciendo principalmente Extensiones y Configuraciones, sugiere que el sistema está madurando y volviéndose más estable.

Los autores son honestos sobre los límites de su trabajo. Admiten que su muestra fue pequeña (solo unos pocos meses de datos de tres proyectos) y que la parte de "predicción de errores" no funcionó como esperaban. Sugieren que CLEM es mejor utilizarlo como una herramienta complementaria: una forma de vigilar la salud estructural de un sistema junto con las métricas tradicionales. No es un veredicto final sobre la calidad, sino una forma muy clara y auditable de ver si un sistema de software está aprendiendo a crecer o si está atrapado en el hábito de romper su propia base.

En resumen, CLEM nos da un vocabulario para hablar de la forma del cambio. Nos ayuda a ver si nuestro software está construyendo un rascacielos o simplemente apilando ladrillos sobre una pila inestable, y esa distinción puede ser lo más importante que podamos medir para la supervivencia a largo plazo de cualquier sistema digital.