Explicación de la entropía del software: causas, efectos y remedios
Publicado: 2022-03-11Este artículo está dirigido al desarrollador de software o gerente de proyecto que siente curiosidad por saber qué es la entropía del software, los efectos prácticos en su trabajo y los factores subyacentes que contribuyen a su crecimiento.
El objetivo principal es crear conciencia sobre la entropía del software porque es un factor en todas las formas de desarrollo de software. Además, exploramos un medio por el cual se puede asignar un valor concreto a la entropía del software. Solo cuantificando la entropía del software y observando su crecimiento en versiones sucesivas podemos comprender realmente el riesgo que representa para nuestros objetivos actuales y planes futuros.
¿Qué es la entropía del software?
La entropía del software recibe su nombre de la principal característica de la entropía en el mundo real: es una medida del caos que permanece igual o aumenta con el tiempo . Dicho de otra manera, es una medida de la inestabilidad inherente construida en un sistema de software con respecto a alterarlo.
Desafortunadamente, rara vez se le da a la entropía del software la importancia que merece.
No se tiene en cuenta cuando se saca a alguien de un equipo de desarrollo, se inicia prematuramente un ciclo de desarrollo o se implementan "soluciones rápidas", momentos en los que, de hecho, es más probable que crezca.
El desarrollo de software es un arte y un oficio cuyos componentes básicos están mal definidos. Mientras que los constructores trabajan con cemento y clavos, el desarrollador de software trabaja con afirmaciones lógicas y un conjunto de suposiciones. Estos no se pueden sostener en la mano y examinar, ni se pueden ordenar por un octavo de pulgada. Aunque el observador casual puede verse tentado a comparar el desarrollo de software con la construcción, más allá de algunas similitudes superficiales, es contraproducente hacerlo.
A pesar de estas dificultades, podemos establecer las pautas que nos permitirán comprender las fuentes de entropía del software, medir el alcance del riesgo que representa para nuestros objetivos y (si es necesario) qué pasos se pueden tomar para limitar su crecimiento.
La definición propuesta de entropía de software es la siguiente:
donde
El concepto de una iteración de desarrollo es parte integral de nuestra comprensión de la entropía del software. Estos son ciclos de actividad que conducen de un comportamiento del sistema a otro. Los objetivos que nos fijamos durante la iteración del software se denominan alcance . En el desarrollo de software, dichos ciclos implican modificar o expandir el código subyacente del software.
Todas las modificaciones al código ocurren en una iteración de desarrollo, incluso si quienes las llevan a cabo no las consideran de esa manera. Es decir, las organizaciones más pequeñas que se enorgullecen de construir sus sistemas utilizando una metodología "rápida y sucia", con poca o ninguna recopilación de requisitos o análisis, aún usan iteraciones de desarrollo para lograr sus objetivos. Simplemente no los planean. De manera similar, incluso si el comportamiento de un sistema modificado difiere de alguna manera de nuestras intenciones, aún se logró mediante una iteración de desarrollo.
De hecho, el riesgo de que esto suceda es exactamente lo que pretende explicar nuestra conciencia de la entropía del software y limitar nuestro deseo de medirla. Entonces, en términos prácticos, podemos definir la entropía del software de la siguiente manera.
Cualquier sistema dado tiene un conjunto finito de temas abiertos conocidos I 0 . Al final de la próxima iteración de desarrollo, habrá un conjunto finito de problemas abiertos conocidos I 1 . La entropía inherente del sistema especifica cuánto es probable que difiera nuestra expectativa de I 1 de su valor real y cuánto es probable que crezca la diferencia en iteraciones posteriores.
Efectos de la entropía del software
Nuestra experiencia práctica de los efectos de la entropía del software depende de cómo interactuamos con el sistema en cuestión.
Los usuarios tienen una vista estática del software; les preocupa cómo se comporta ahora y no les importan las partes internas de un sistema. Al realizar una acción predefinida, los usuarios asumen que el software responderá con un comportamiento predefinido correspondiente. Sin embargo, los usuarios son los menos preparados para deducir el nivel de entropía del software que están utilizando.
La entropía del software está ligada a la noción de cambio y no tiene significado en un sistema estático. Si no hay intención de alterar el sistema, no podemos hablar de su entropía. Asimismo, un sistema que aún no existe (es decir, la siguiente iteración es en realidad la primera de su existencia) no tiene entropía.
El software puede percibirse como "defectuoso" desde el punto de vista de un usuario, pero si durante las iteraciones posteriores los desarrolladores y administradores de software cumplen sus objetivos según lo planeado, ¡debemos concluir que la entropía en el sistema es realmente bastante baja! La experiencia de los usuarios, por lo tanto, nos dice muy poco, si es que algo, sobre la entropía del software:
Los desarrolladores de software tienen una visión fluida del software. Se preocupan por cómo funciona actualmente un sistema solo en la medida en que debe cambiarse, y se preocupan por los detalles de cómo funciona para diseñar una estrategia adecuada.
Los gerentes tienen quizás la visión más complicada del software, tanto estático como fluido. Deben equilibrar las exigencias del corto plazo con las exigencias de un plan de negocios que se extienda más hacia el futuro.
Las personas en ambos roles tienen expectativas. La entropía del software se manifiesta cada vez que se echan a perder esas expectativas. Es decir, los desarrolladores y gerentes de software hacen todo lo posible para evaluar los riesgos y planificarlos, pero, excluyendo las interrupciones externas, si sus expectativas se ven frustradas, solo entonces podemos hablar de entropía de software. Es la mano invisible que rompe las interacciones de los componentes que no estaban en el alcance, hace que los servidores de producción se bloqueen inexplicablemente y retiene una revisión oportuna y rentable.
Muchos sistemas con altos niveles de entropía dependen de individuos específicos, particularmente si hay miembros jóvenes en el equipo de desarrollo. Esta persona posee un conocimiento tal que los demás no pueden realizar sus tareas sin su “valiosa” aportación. No se puede capturar en diagramas UML estándar o especificaciones técnicas porque consiste en una amalgama de excepciones, corazonadas y sugerencias. Este conocimiento no depende de un marco lógicamente consistente y, por lo tanto, es difícil, si no imposible, transferirlo a cualquier otra persona.
Supongamos que con gran determinación y esfuerzo, tal organización es capaz de dar la vuelta y estabilizar su departamento de TI. La situación parece haber mejorado porque, cuando el desarrollo de software se ha detenido, cualquier progreso es alentador. Sin embargo, en realidad, las expectativas que se cumplen son bajas y los logros poco interesantes en comparación con las elevadas metas que estaban al alcance mientras la entropía aún era baja.
Cuando la entropía del software abruma un proyecto, el proyecto se congela.
No puede haber más iteraciones de desarrollo. Afortunadamente, esta situación no surge instantáneamente. La marcha lenta pero precipitada hacia el borde de un precipicio es algo por lo que pasan todos los sistemas. No importa qué tan bien organizada y eficiente sea la primera versión, en sucesivas iteraciones de desarrollo, su entropía (y, por lo tanto, el riesgo de que las cosas salgan mal inesperadamente) aumentará a menos que se tomen medidas específicas para evitarlo.
La entropía del software no se puede reducir. Al igual que la entropía en el mundo real, solo crece o permanece igual. Al principio, sus efectos son insignificantes. Cuando comienzan a manifestarse, los síntomas son leves y pueden enmascararse o ignorarse. Pero si una organización solo intenta combatir la entropía del software una vez que se ha convertido en el riesgo dominante en un proyecto, lamentablemente descubrirá que sus esfuerzos son en vano. Por lo tanto, el conocimiento de la entropía del software es más útil cuando su alcance es bajo y los efectos adversos mínimos.
No se sigue que cada organización deba dedicar recursos a limitar el crecimiento de la entropía en sus productos. Gran parte del software que se desarrolla en la actualidad, en particular el software orientado al consumidor, tiene una vida útil esperada relativamente corta, tal vez de unos pocos años. En este caso, sus partes interesadas no necesitan considerar los efectos de la entropía del software, ya que rara vez se convertirá en un obstáculo serio antes de que se descarte todo el sistema. Sin embargo, existen razones menos obvias para considerar los efectos de la entropía del software.
Considere el software que ejecuta la infraestructura de enrutamiento de Internet o transfiere dinero de una cuenta bancaria a otra. En un momento dado, hay una o más versiones de este software en producción, y sus comportamientos colectivos pueden documentarse con una precisión razonablemente alta.
La tolerancia al riesgo de un sistema es una medida de cuánto y qué tipo de comportamiento inesperado podemos permitir cómodamente de una iteración de desarrollo a la siguiente. Para los tipos de sistemas que acabamos de mencionar, la tolerancia al riesgo es mucho menor que, digamos, el software que enruta las llamadas telefónicas. Este software, a su vez, tiene una menor tolerancia al riesgo que el software que maneja el carrito de compras de muchos sitios web comerciales.
La tolerancia al riesgo y la entropía del software están relacionadas en el sentido de que la entropía del software debe ser mínima para estar seguros de que nos mantendremos dentro de la tolerancia al riesgo de un sistema durante la siguiente iteración de desarrollo.
Fuentes de entropía de software
La entropía del software surge de la falta de conocimiento . Resulta de la divergencia entre nuestras suposiciones comunitarias y el comportamiento real de un sistema existente. Este hecho explica por qué la entropía del software solo tiene significado en el contexto de modificar un sistema existente; es la única vez que nuestra falta de comprensión tendrá algún efecto práctico. La entropía del software encuentra un terreno más fértil en un sistema cuyos detalles no pueden ser entendidos por una sola persona, sino que se distribuyen entre un equipo de desarrollo. El tiempo también es un poderoso borrador del conocimiento.
El código es la expresión de una serie de afirmaciones lógicas. Cuando el comportamiento del software (y por tanto su código) no se corresponde con la lógica que pretende expresar, podemos hablar de su entropía inherente. Esta situación puede presentarse de tres maneras: la lógica es bien conocida y diverge de su expresión, existen múltiples interpretaciones de la lógica que el código intenta expresar o la lógica no es bien conocida.
La primera situación —la lógica es bien conocida y diverge de su expresión actual— es la más fácil de abordar pero también la menos común. Solo los sistemas muy pequeños mantenidos por quizás dos participantes, un desarrollador y alguien responsable del plan de negocios, entrarán en esta categoría.
La segunda situación —la lógica no es bien conocida— es rara. Para todos los efectos, la iteración de desarrollo ni siquiera puede comenzar. Si en algún momento todas las partes interesadas pueden ponerse de acuerdo, es probable que se enfrenten a la primera situación.
La mente humana interpreta sus experiencias, filtrándolas y modificándolas de manera efectiva en un intento de encajarlas en un marco personal. En ausencia de hábitos de desarrollo efectivos, basados en un libre intercambio de ideas, respeto mutuo y expectativas claras, puede haber tantas interpretaciones de cómo funciona un sistema actualmente como miembros del equipo. Los objetivos del equipo para la iteración de desarrollo actual pueden estar en disputa.
Muchos desarrolladores se protegen de esta situación reforzando su propia comprensión única de lo que se requiere de ellos y cómo “debería” organizarse el sistema. Los gerentes y otras partes interesadas, por otro lado, podrían intentar sin saberlo cambiar las suposiciones de otros miembros del equipo en un intento equivocado de hacer sus propias vidas más fáciles.
Ahora hemos llegado a la fuente más común de entropía del software: existen múltiples interpretaciones incompletas de la lógica que el sistema pretende expresar. Dado que solo hay una única manifestación de esta lógica, la situación es, por definición, problemática.
¿Cómo surge este desconocimiento? La incompetencia es una forma. Y como ya hemos visto, la falta de acuerdo sobre los objetivos de la próxima iteración de desarrollo es otra. Pero hay otros factores a considerar. Una organización puede pretender emplear una metodología de desarrollo pero luego abandonar al azar algunos o todos sus aspectos en el suelo. Luego, los desarrolladores de software tienen la tarea de completar tareas vagas, a menudo abiertas a interpretación. Las organizaciones que implementan cambios en su metodología de desarrollo son particularmente vulnerables a este fenómeno, aunque no son las únicas. Los conflictos personales de los que la gerencia no es consciente o no puede resolverlos también pueden conducir a una peligrosa divergencia entre las expectativas y los resultados.
Hay una segunda forma, más importante, en la que perdemos conocimientos técnicos sobre un producto: en la transferencia. Capturar el conocimiento técnico en papel es un desafío incluso para los escritores más competentes. La razón es que qué transcribir es tan importante como cómo . Sin la disciplina adecuada, un redactor técnico puede registrar demasiada información. Alternativamente, pueden hacer suposiciones que les hagan omitir puntos esenciales. Una vez producida, la documentación técnica debe mantenerse meticulosamente actualizada, una propuesta difícil para muchas organizaciones que pierden el rastro de los documentos casi tan pronto como se escriben. Debido a estas dificultades, el conocimiento técnico rara vez se transfiere solo en documentos, sino también en parejas u otras formas de interacción cercana de persona a persona.
La entropía del software da pasos agigantados cada vez que un participante activo deja un equipo de desarrollo. Se están llevando una valiosa porción de conocimientos técnicos con ellos. Reproducir ese saber hacer es imposible y aproximarlo requiere un esfuerzo considerable. Sin embargo, con suficiente atención y recursos, se puede preservar suficiente conocimiento para minimizar el crecimiento de la entropía del sistema.
Hay otras fuentes de entropía, pero estas son relativamente menores. Por ejemplo, la podredumbre del software es el proceso por el cual un sistema se ve afectado inesperadamente por cambios en su entorno. Podemos pensar en el software de terceros en el que se basa (como las bibliotecas), pero existen otras causas más insidiosas de la pudrición del software, generalmente como resultado de cambios en los supuestos en los que se basó el sistema. Por ejemplo, si un sistema se diseñó con ciertas suposiciones sobre la disponibilidad de memoria, puede comenzar a funcionar mal en momentos inesperados si se reduce la memoria disponible.
Cómo calcular la entropía: asignar valores a C, S e I
I es el número de problemas de comportamiento no resueltos en un sistema de software, incluida la ausencia de funciones prometidas. Esta es una cantidad conocida que a menudo se rastrea en un sistema como JIRA. El valor de I se deriva directamente de él.
C es la probabilidad percibida de que, cuando se hayan implementado las unidades de trabajo en el alcance, el número de problemas abiertos reales I1 en la próxima iteración sea mayor que su estimación actual. Este valor vive en el dominio 0 <= C <= 1.
Se podría argumentar que la probabilidad C es precisamente lo que la entropía del software pretende medir. Sin embargo, existen diferencias fundamentales entre este valor y nuestra medida de la entropía del software. La probabilidad percibida de que algo salga mal es exactamente eso: no es un valor real. Sin embargo, es útil porque los sentimientos de las personas que participan en un proyecto son una valiosa fuente de información sobre cuán estable es.
El alcance S tiene en cuenta la magnitud de los cambios propuestos y debe expresarse en las mismas unidades que I. Un valor mayor de S disminuye la entropía porque estamos aumentando el alcance de los cambios propuestos. Aunque esto puede parecer contradictorio, debemos tener en cuenta que la entropía es una medida de cómo el desarrollo del sistema puede no cumplir con nuestras expectativas. No es suficiente decir que la entropía es una medida de la probabilidad de que se presenten problemas. Naturalmente, intentamos anticiparnos a los riesgos y los tenemos en cuenta en nuestra planificación (y, por lo tanto, en nuestra estimación de I1, que bien puede aumentar por encima de 0 ). Claramente, cuanto más seguros estemos de asumir un gran alcance de cambio, menos entropía se puede decir que hay en el sistema, a menos que quienes planifican los cambios y/o los llevan a cabo sean incompetentes. Esta posibilidad, sin embargo, probablemente se refleja en el valor actual de
Tenga en cuenta que no necesitamos intentar especificar la magnitud de la diferencia entre el valor real de I 1 y su valor esperado. Si asumimos que nuestros planes son correctos cuando los hacemos, tampoco es razonable suponer que podemos predecir el grado en que el resultado no cumplirá con nuestras expectativas; solo podemos especificar una posibilidad percibida C de que no lo haga. Sin embargo, el grado en que el valor real I 1 difiere de su valor esperado es una entrada importante en el cálculo de la entropía en la siguiente iteración en forma de valor derivado
Teóricamente, es posible que I tenga un valor negativo. En la práctica, sin embargo, esta situación nunca ocurrirá; no solemos resolver los problemas por casualidad. Los valores negativos para
C es un valor subjetivo. Existe en la mente de los participantes de una iteración de desarrollo y se puede deducir sondeándolos y promediando los resultados. La pregunta debe hacerse de manera positiva. Por ejemplo: "En una escala de 0 a 10, siendo 10 lo más probable, ¿cómo estimaría las posibilidades del equipo de lograr todos sus objetivos en esta iteración de desarrollo?"
Tenga en cuenta que la pregunta se plantea sobre los objetivos del equipo como un todo, no como un subconjunto. Una respuesta de 10 indicaría un valor de 0 para C, mientras que una respuesta de 7 indicaría un valor de 0,3. En equipos más grandes, cada respuesta puede ponderarse en función de factores relevantes, como cuánto tiempo ha estado involucrada una persona en el proyecto y cuánto de su tiempo realmente dedica a él. Sin embargo, la competencia no debe ser un factor en la ponderación de las respuestas. En poco tiempo, incluso un miembro menor del equipo tendrá una idea de cuán efectivo es para lograr sus objetivos. Es posible que equipos lo suficientemente grandes deseen descartar los valores informados más altos y más bajos antes de promediar el resto.
Preguntar a los profesionales qué tan probable es que su equipo fracase es una propuesta delicada y provocativa. Sin embargo, esta es exactamente la pregunta que debe hacerse cualquier organización que desee cuantificar la entropía. Para garantizar respuestas honestas, los participantes deben dar su estimación de C de forma anónima y sin temor a las repercusiones, incluso si informan un valor abismalmente alto.
A S se le debe asignar un valor en las mismas "unidades de trabajo" que a
Tenga en cuenta que no consideramos las revisiones u otros lanzamientos no programados para la producción como que definen el alcance de una iteración de desarrollo, ni debemos sustraer ninguna historia asociada de
La dificultad con este enfoque es que debe ocurrir un período de descubrimiento y análisis antes de que los errores puedan dividirse posteriormente en historias. Por lo tanto, el verdadero valor de I solo puede definirse después de un retraso. Además, el sondeo de C se produce naturalmente al comienzo de cada sprint. Por lo tanto, los resultados obtenidos deben promediarse una vez más a lo largo de todo el lanzamiento. A pesar de estas dificultades, es probable que cualquier equipo que emplee aspectos de una metodología Agile descubra que las historias son la unidad más precisa para cuantificar S (y, por lo tanto
Hay otras metodologías de desarrollo en uso hoy en día. Cualquiera que sea la metodología empleada, los principios para medir la entropía del software siguen siendo los mismos: la entropía del software debe medirse entre lanzamientos a producción, S e I deben medirse en las mismas "unidades de trabajo" y las estimaciones de C deben tomarse de los participantes directos en una manera no amenazante y preferiblemente anónima.
Reducir el crecimiento de E
Una vez que se pierde el conocimiento sobre un sistema, nunca se puede recuperar. Por esta razón, la entropía del software no se puede reducir. Todo lo que podemos esperar hacer es frenar su crecimiento.
El crecimiento de la entropía se puede limitar adoptando las medidas adecuadas durante el desarrollo del software. El aspecto de programación en pares del desarrollo Agile es particularmente útil en este sentido. Debido a que más de un desarrollador está involucrado en el momento en que se escribe el código, se distribuye el conocimiento de los detalles esenciales y se mitigan los efectos de la partida de los miembros del equipo.
Otra práctica útil es la producción de documentación bien estructurada y de fácil consumo, especialmente dentro de organizaciones que emplean una metodología en cascada. Dicha documentación debe estar respaldada por principios estrictos y bien definidos entendidos por todos. Las organizaciones que se basan en la documentación como medio principal de comunicación y salvaguardar el conocimiento técnico son muy adecuadas para este enfoque. Solo cuando no hay pautas o capacitación sobre cómo escribir y consumir documentos escritos internamente, como suele ser el caso en organizaciones más jóvenes que emplean RAD o metodologías ágiles, su valor se vuelve sospechoso.
Hay dos formas de reducir el crecimiento de la entropía en un sistema: Ejecutar cambios destinados a reducir
El primero implica la refactorización. Las acciones destinadas a reducir I tienden a ser de naturaleza técnica y probablemente ya sean familiares para el lector. Debe ocurrir una iteración de desarrollo. La parte de esta iteración que pretende reducir el crecimiento de la entropía no brindará ningún beneficio empresarial tangible, aunque consumirá tiempo y recursos. Este hecho a menudo hace que la reducción del crecimiento de la entropía sea difícil de vender dentro de cualquier organización.
Reducir el valor de C es una estrategia más poderosa porque el efecto es a más largo plazo. Además, C actúa como un control importante del crecimiento de la proporción de I a S. Las acciones para reducir C tienden a centrarse en el comportamiento y el pensamiento humanos. Si bien es posible que estas acciones no requieran una iteración de desarrollo per se, ralentizarán las iteraciones posteriores a medida que los participantes acepten y se ajusten a los nuevos procedimientos. El acto aparentemente simple de ponerse de acuerdo sobre las mejoras que se deben realizar es un camino lleno de peligros propios, ya que los objetivos dispares de los participantes del proyecto y las partes interesadas de repente salen a la luz.
Terminando
La entropía del software es el riesgo de que cambiar el software existente resulte en problemas inesperados, objetivos incumplidos o ambos.
Aunque es insignificante cuando se crea el software por primera vez, la entropía del software crece con cada iteración de desarrollo. Si se permite que continúe sin control, la entropía del software finalmente detendrá el desarrollo.
Sin embargo, no todos los proyectos deben tener en cuenta los efectos de la entropía del software. Muchos sistemas dejarán de producirse antes de que la entropía pueda ejercer efectos perceptibles y nocivos. Para aquellos cuya vida es lo suficientemente larga como para que la entropía represente un riesgo creíble, crear conciencia sobre ella y medir su alcance, aunque todavía es bajo, proporciona un medio para garantizar que el desarrollo no se interrumpa prematuramente.
Una vez que un sistema ha sido completamente abrumado por los efectos de la entropía del software, no se pueden realizar más cambios y el desarrollo esencialmente ha llegado a su fin.