Las leyes de Lehman sobre la evolución del software: por qué el código se pudre en silencio (y cómo evitarlo)

El software no se rompe como se rompen los puentes. Un puente que nunca se toca puede seguir en pie cincuenta años o más, y algunos resisten mucho más. Un código que nunca se toca hace lo contrario: se pudre en silencio. El mundo a su alrededor cambia (los sistemas operativos se actualizan, las APIs quedan obsoletas, las regulaciones cambian, los usuarios esperan más) y el programa intacto, congelado en el sitio, se vuelve un poco menos útil cada día hasta que una mañana, sin más, deja de funcionar.

Esto no es una opinión. Está más cerca de la física. Hace más de cincuenta años, un investigador de IBM observó que los grandes sistemas de software se comportan según patrones sorprendentemente consistentes a medida que envejecen, y dedicó dos décadas a convertir esas observaciones en un conjunto de leyes empíricas que hoy conocemos como las leyes de Lehman sobre la evolución del software. Siguen describiendo tu tablero de sprint de hoy, hayas oído hablar de ellas o no.

Vamos a conocer las leyes, de dónde vienen, dónde se sostienen, dónde se rompen y, lo más importante, cómo usarlas en proyectos reales este trimestre.

Un estudio que fundó una disciplina por accidente

Meir "Manny" Lehman. Foto: Hilehman, CC BY-SA 4.0, via Wikimedia Commons.

A finales de los años sesenta, IBM estaba construyendo OS/360, uno de los proyectos de software más ambiciosos de su época. Meir “Manny” Lehman, junto con su colega László Bélády, empezó a estudiar el historial de versiones de aquel sistema, midiendo cómo evolucionaban su tamaño, su número de defectos y el esfuerzo necesario para modificarlo de una versión a otra. (Bélády y Lehman publicaron un modelo temprano de esto en el IBM Systems Journal en 1976.)

Lo que empezó como tres observaciones en 1974 llegó a cinco en 1978 y, en 1996, a un conjunto de ocho leyes de la evolución del software. Hoy Lehman es ampliamente considerado el padre de todo el campo de investigación de la evolución del software: cuando murió en 2010, la comunidad académica lo recordó precisamente así.

Hay un matiz importante antes de seguir, porque es justo donde la mayoría de los resúmenes superficiales se descuidan. Lehman no afirmó que estas leyes se apliquen a todo el software. Clasificó los programas en tres tipos, la clasificación SPE:

• Los programas de tipo S están definidos por completo por una eSpecificación fija. Una función que calcula un resultado matemático es correcta o incorrecta frente a esa especificación, sin más. No necesita cambiar nunca.
• Los programas de tipo P resuelven un Problema del mundo real con una solución aproximada (piensa en un motor de ajedrez), donde el problema es estable pero nuestra solución siempre puede mejorar.
• Los programas de tipo E están Embebidos en el mundo real. Mecanizan una actividad humana o de negocio y pasan a formar parte del mundo que modelan. Una plataforma bancaria, un checkout de e-commerce, un sistema de historiales hospitalarios. En el momento en que se ponen en producción, cambian el entorno, lo que cambia los requisitos, lo que obliga al software a cambiar de nuevo.

Las ocho leyes describen los sistemas de tipo E, y casi todo lo que entregas para ganarte la vida es de tipo E. Por eso estas leyes se sienten tan personales.

Las ocho leyes de la evolución del software de un vistazo

Las leyes tampoco son ocho hechos inconexos. Se refuerzan entre sí formando una única dinámica que empuja al sistema hacia la decadencia, y una única fuerza contraria que la frena:

Cómo se acumulan las leyes: las aristas rojas empujan hacia la decadencia; el camino verde es el esfuerzo deliberado que la frena.

Ley 1: Cambio continuo

“Un sistema de tipo E debe adaptarse continuamente o se vuelve progresivamente menos satisfactorio.”

Este es el cimiento. El valor de un programa de tipo E no es fijo; se define en relación con un entorno en movimiento. Mantén el software quieto y la brecha entre lo que hace y lo que el mundo necesita se ensancha por sí sola.

Escenario práctico. Tu aplicación de e-commerce se integra con una pasarela de pago. Escribiste esa integración hace dos años y ha funcionado de forma impecable: nadie la ha tocado. Entonces la pasarela anuncia que va a dejar de dar soporte a TLS 1.1 y a cambiar el formato de firma de sus webhooks en 90 días. No escribiste ni un solo error, y sin embargo tu funcionalidad “terminada” es ahora una cuenta atrás hacia una caída en producción. El Cambio continuo significa que ningún módulo está realmente terminado; solo está terminado por ahora. La respuesta de ingeniería es presupuestar un mantenimiento que aún no puedes nombrar, y diseñar los puntos de integración (adaptadores, interfaces versionadas) para que “el mundo se movió” te cueste un cambio pequeño en lugar de una reescritura.

Ley 2: Complejidad creciente

“A medida que un sistema de tipo E evoluciona, su complejidad aumenta a menos que se realice un trabajo explícito para mantenerla o reducirla.”

Fíjate en la formulación: la complejidad sube por defecto. Es la entropía natural de un sistema bajo cambio continuo. Cada funcionalidad añadida contra una fecha límite, cada caso especial atornillado a un flujo existente, cada “ya lo limpiaremos más tarde” eleva el desorden estructural. Reducir la complejidad es lo único que exige un esfuerzo deliberado, y ese esfuerzo rara vez está en la hoja de ruta.

Escenario práctico. El checkout de una startup empieza como una función limpia. Marketing quiere un camino para códigos promocionales, así que se añade un if. Luego un camino de facturación B2B. Luego uno de tarjetas regalo. Luego excepciones fiscales regionales. Dieciocho meses después, esa función tiene 600 líneas con 40 flags que interactúan, y cada cambio arriesga romper un camino que nadie recuerda. La Ley 2 te dice que esto no fue una falta de disciplina de un mal desarrollador: es la trayectoria esperada. La contramedida es tratar la refactorización como una partida recurrente, no como una hazaña puntual: un “presupuesto de complejidad” permanente (digamos, un 15-20% de cada sprint) dedicado a extraer módulos, eliminar ramas muertas y mantener a raya la complejidad ciclomática. Las fronteras de microservicios y las costuras de la arquitectura limpia son tácticas, pero el punto estratégico es más simple: si no inviertes energía en combatir la complejidad, la complejidad gana. (Esto es exactamente lo que el pensamiento Lean llama eliminar el desperdicio: la complejidad que ya no se gana su sitio es muda, y podarla es trabajo de verdad, no un sobrecoste.)

Ley 3: Autorregulación

“Los procesos de evolución de los sistemas de tipo E se autorregulan, con la distribución de las medidas de producto y de proceso cercana a la normal.”

Esta es la ley que más se tergiversa en los resúmenes (no trata de “la evolución de los programas grandes”). Lehman observó que la evolución de un sistema se comporta como un organismo regulado. Medidas como el tamaño de cada versión y la tasa de crecimiento fluctúan alrededor de una tendencia estable, con los picos y los valles cancelándose más o menos entre sí. Aprieta fuerte en una versión y el sistema tiende a compensar: un mecanismo de retroalimentación lo devuelve hacia su ritmo de largo plazo.

Escenario práctico. Un product manager, frustrado con el progreso constante, ordena una versión espectacular: triplicar el alcance normal en un trimestre. El equipo obedece. El resultado es predecible para quien conozca esta ley: el número de defectos se dispara, la versión siguiente se encoge drásticamente mientras el equipo absorbe las consecuencias, y la media de las dos versiones cae casi exactamente sobre la línea de tendencia histórica. La conclusión accionable es un regalo para quien planifica: el propio historial de versiones es una herramienta de previsión. Si tus últimas diez versiones promediaron unos 30 puntos de historia de funcionalidad nueva neta con un patrón de aparición de defectos aproximadamente normal, un plan que asume 90 está luchando contra la gravedad. Usa la tendencia para fijar expectativas creíbles, y trata una versión que la supere desmesuradamente como una señal de riesgo, no como un triunfo.

Ley 4: Conservación de la estabilidad organizativa

“El ritmo medio de actividad global efectiva en un sistema de tipo E en evolución es invariante a lo largo de la vida del producto.”

El ritmo efectivo al que se entrega cambio útil tiende a mantenerse más o menos constante a lo largo de la vida de un proyecto y, sorprendentemente, es en gran medida independiente de los recursos que le eches. Esta es la ley que se solapa con la famosa observación de Fred Brooks en The Mythical Man-Month: “añadir mano de obra a un proyecto de software atrasado lo atrasa más”.

Escenario práctico. Un proyecto va tres meses retrasado. El instinto de la dirección es añadir cinco ingenieros. Pero los recién llegados tienen que aprender el dominio, el equipo existente debe dejar de construir para incorporarlos, y el número de canales de comunicación del equipo crece de forma cuadrática (un equipo de 5 personas tiene 10 enlaces por pares; uno de 10 personas tiene 45). Durante los dos meses siguientes, la producción efectiva baja. La Conservación de la estabilidad organizativa dice que el rendimiento está gobernado menos por el número de personas que por la complejidad acumulada del sistema y la estructura de comunicación de la organización. La palanca no es más gente, sino eliminar fricción: reducir los tiempos de build y despliegue, pagar la complejidad de la Ley 2, clarificar la propiedad del código y acortar la latencia de la retroalimentación para que el ritmo efectivo de cada ingeniero suba.

Ley 5: Conservación de la familiaridad

“A medida que un sistema de tipo E evoluciona, todos los relacionados con él (desarrolladores, personal de ventas, usuarios) deben mantener el dominio de su contenido y comportamiento para lograr una evolución satisfactoria. Un crecimiento excesivo merma ese dominio. De ahí que el crecimiento incremental medio se mantenga invariante a medida que el sistema evoluciona.”

Todos los conectados al sistema (desarrolladores, operadores, personal de soporte y usuarios) solo pueden absorber una cierta cantidad de cambio por versión antes de perder la noción de cómo funciona. Las versiones que meten demasiada novedad superan ese presupuesto de absorción, y la calidad y la adopción lo pagan.

Escenario práctico. Un equipo intenta una reescritura “big bang”: un año de trabajo y luego una única versión que reemplaza el 70% del producto de golpe. En el lanzamiento, los tickets de soporte se desbordan, el equipo no puede razonar sobre cuál de los mil cambios causó cada regresión, y los usuarios avanzados se rebelan contra una interfaz que ya no reconocen. La Ley 5 explica los rediseños de UI fallidos que todos recordamos, esos en los que los usuarios firmaban peticiones para que volviera la versión antigua. La disciplina que prescribe es limitar la novedad de cada versión, no solo su tamaño. Entrega de forma continua en incrementos digeribles, ejecuta los caminos nuevos y los antiguos en paralelo detrás de flags, y da tiempo a la gente para construir familiaridad. El cambio que tu equipo y tus clientes pueden entender es la verdadera restricción, no el cambio que puedes programar.

Ley 6: Crecimiento continuo

“El contenido funcional de un sistema de tipo E debe aumentar continuamente para mantener la satisfacción del usuario a lo largo de su vida.”

Aquí está el trío que más se confunde de todo el conjunto, así que separémoslo con limpieza. La Ley 1 (Cambio) trata de adaptar la funcionalidad existente a un mundo que cambia. La Ley 2 (Complejidad) trata del desorden interno que se acumula. La Ley 6 (Crecimiento) trata de la superficie externa de funcionalidades, que necesita expandirse porque las expectativas de los usuarios suben sin parar y nunca se reinician. El extra que ayer encantaba es hoy lo que se da por sentado.

Escenario práctico. Un producto SaaS de analítica se lanza con cinco integraciones y a los clientes les encanta. Dos años después, los prospectos se marchan en las llamadas de ventas porque le falta el conector de Snowflake que un competidor añadió el mes pasado. El producto no ha empeorado; su contenido funcional simplemente dejó de crecer mientras las expectativas seguían subiendo, y la brecha se lee como un declive. La Ley 6 es el motor detrás de toda hoja de ruta de producto y de toda lista de funcionalidades “imprescindibles”. El detalle estratégico es que el Crecimiento (Ley 6) y la Complejidad (Ley 2) tiran en sentidos opuestos: cada funcionalidad que añades para satisfacer a los usuarios también aumenta la entropía. Los equipos maduros tratan esto como un compromiso explícito, podando las funcionalidades de bajo valor con tanta agresividad como añaden las de alto valor, para que el crecimiento no hipoteque el código en silencio.

Ley 7: Calidad en declive

“La calidad de un sistema de tipo E parecerá declinar a menos que se mantenga con rigor y se adapte a los cambios del entorno operativo.”

Fíjate en la palabra precisa: la calidad parecerá declinar. El código en disco no ha cambiado, pero sí los estándares con los que se le juzga. El entorno se movió (nuevos navegadores, nuevos dispositivos, diez veces el tráfico, nuevas expectativas de seguridad) y un programa que era excelente frente al listón de 2019 se ve pobre frente al de 2026.

Escenario práctico. Un monolito ha funcionado de forma fiable durante años. Nadie ha introducido un error. Y sin embargo los usuarios ahora se quejan de que es “lento y torpe”. Lo que de verdad pasó: el tráfico móvil pasó del 20% al 70% y la aplicación nunca se diseñó para él; el conjunto de datos creció 50 veces y las consultas que eran instantáneas ahora se arrastran; los competidores fijaron una nueva base de responsividad. La Calidad en declive dice que el antídoto es activo, no reactivo: debes adaptarte continuamente al entorno operativo, no solo corregir los defectos reportados. En la práctica, eso significa observabilidad que mida el rendimiento real frente a las expectativas de hoy, recalibración periódica de carga y seguridad, y pruebas automatizadas más pipelines de CI/CD que hagan la adaptación continua lo bastante barata como para hacerla de verdad. La calidad no es un estado al que llegas; es un ritmo que sostienes.

Ley 8: Sistema de retroalimentación

“Los procesos de evolución de tipo E constituyen sistemas de retroalimentación multinivel, multibucle y multiagente.”

Esta es la piedra angular, y reformula todas las demás. Hacer evolucionar un sistema grande no es un pipeline lineal del requisito al código. Es una red de bucles de retroalimentación: los usuarios reaccionan a las versiones, los datos de soporte fluyen hacia producto, las decisiones de producto restringen la ingeniería, la realidad de la ingeniería remodela la hoja de ruta, la estructura organizativa moldea la arquitectura (la Ley de Conway al acecho). Como los bucles interactúan, los cambios locales producen efectos no locales, a menudo contraintuitivos.

El bucle externo de entrega más los bucles internos correctores discontinuos: los gobiernas todos a la vez, nunca uno de forma aislada.

Escenario práctico. Un VP, con la esperanza de elevar la calidad, impone una nueva regla: cada pull request necesita tres aprobaciones. El bucle pretendido dice “más revisión → menos errores”. El sistema real dice otra cosa: las colas de revisión se atascan, los ingenieros agrupan PRs más grandes para amortizar el sobrecoste, los PRs grandes se aprueban a ojo porque nadie puede revisar 2.000 líneas con cuidado, y las tasas de defectos suben. La Ley 8 advierte de que no puedes gobernar de forma fiable un sistema de retroalimentación ajustando una sola variable y dando por hecho que el resto se queda quieto. La disciplina que exige es humildad más medición: cambia una cosa, instrumenta los bucles, vigila los efectos de segundo orden y ajusta; exactamente la postura empírica y guiada por hipótesis que codifican las buenas culturas de DevOps y de mejora continua.

Dónde se doblan las leyes, y por qué esa es la parte más útil

Una teoría de 50 años construida sobre un mainframe de los años sesenta merece escrutinio, y lo ha recibido de sobra. El desafío más importante vino del código abierto.

En 2000, Michael Godfrey y Qiang Tu estudiaron el kernel de Linux a lo largo de 96 versiones entre 1994 y 2000 y encontraron algo que las leyes no predecían: el kernel creció a un ritmo superlineal. Eso contradecía directamente el modelo de crecimiento de raíz cuadrada inversa que Lehman y Turski habían derivado de sistemas comerciales, donde se esperaba que el crecimiento se frenara a medida que el tamaño y la complejidad hicieran más difícil cada cambio. Un modelo de desarrollo masivamente paralelo, distribuido globalmente y voluntario reescribió, al parecer, la curva de crecimiento. Estudios posteriores sobre proyectos open source de larga vida encontraron que las leyes se cumplen de forma desigual: el Cambio continuo resulta notablemente robusto, pero otras, como la Conservación de la familiaridad y la propia dinámica de crecimiento predicha, a menudo no se cumplen en cuanto cambia el contexto de un proyecto (por ejemplo, cuando entra en fase de mantenimiento o crece mediante contribución masiva en paralelo).

¿Por qué se doblan las leyes justo aquí? La desviación no es aleatoria: se reduce a muchos factores, y el primero de ellos es que las fuerzas que impulsan el crecimiento de funcionalidades no son las mismas. Lehman derivó sus leyes de sistemas comerciales, donde lo que se construye está gobernado en última instancia por el mercado: las funcionalidades se añaden para ganar contratos, retener clientes y proteger los ingresos, y esa presión económica moldea la cadencia de versiones, el alcance y el constante tira y afloja entre nueva funcionalidad y estabilidad. Un kernel de código abierto responde a un conjunto de incentivos completamente distinto. Una funcionalidad llega a Linux porque un colaborador la necesita para su propio hardware, porque un fabricante aporta un driver río arriba, porque los mantenedores la consideran técnicamente sólida y digna de la carga de mantenimiento a largo plazo, no porque mueva una cifra de ingresos o aparezca en una hoja de ruta comercial. No hay ningún trimestre que cumplir, ninguna métrica de churn, ningún nivel de precios que proteger. Y con miles de colaboradores independientes resolviendo cada uno su propia necesidad en paralelo, el crecimiento no está limitado por la capacidad de una sola organización (Ley 4) ni por aquello con lo que un único equipo puede mantenerse familiarizado (Ley 5), así que puede correr de forma superlineal de un modo que los conjuntos de datos comerciales de Lehman nunca mostraron. Los criterios que deciden si una funcionalidad existe siquiera son sencillamente distintos de los comerciales con los que se calibraron las leyes.

Eso reformula todo el resultado. Varias de las leyes de Lehman son, en el fondo, afirmaciones sobre la organización que produce el software (su economía, su capacidad, sus incentivos) tanto como sobre el código en sí. Cambia el motor que impulsa el trabajo y el comportamiento medible cambia con él. El kernel de Linux no rompió las leyes; funcionaba con un motor distinto del que observó Lehman.

Esto no es razón para descartar las leyes. Es la razón para respetarlas. Las leyes de Lehman son generalizaciones empíricas sobre un régimen concreto: sistemas cerrados, desarrollados comercialmente y acotados a una organización. Cuando cambias el régimen de forma fundamental (la economía, el paralelismo, el modelo de colaboradores), algunas leyes se doblan y otras se quiebran. Saber cuáles leyes son robustas (el cambio es inevitable, la complejidad sube sin esfuerzo, la retroalimentación domina) y cuáles son condicionales (la curva de crecimiento exacta, la cadencia autorregulada) es justo el tipo de criterio que separa a los ingenieros que citan principios de los ingenieros que los usan.

La única idea que conviene guardar

Quita la formalidad y las ocho leyes se reducen a una sola verdad incómoda:

Si lo dejas solo, se desfasa del mundo (Ley 1), acumula desorden interno (Ley 2), se ve peor frente a estándares en alza (Ley 7) y priva a sus usuarios del crecimiento que ahora esperan (Ley 6), mientras bucles de retroalimentación que no controlas del todo (Ley 8) se resisten a tus intentos de gestionarlo, y no puedes salir del atolladero a fuerza de contratar gente (Ley 4).

Los equipos que prosperan no son los que escapan de estas fuerzas (nadie lo hace). Son los que planifican para ellas: los que presupuestan el mantenimiento antes de que sea urgente, los que invierten un esfuerzo continuo en combatir la complejidad, los que dimensionan cada versión a lo que la gente puede absorber, los que tratan la calidad como un ritmo sostenido y no como una línea de meta, y los que gobiernan su proceso midiendo sus bucles en lugar de lanzar decretos sobre ellos.

Hay un nombre para esa postura. Si las leyes de Lehman describen la enfermedad (entropía que se acumula, complejidad que crece sola, calidad que resbala mientras el mundo no para de moverse), entonces el pensamiento Lean es lo más parecido a un tratamiento que tenemos: eliminar el desperdicio (muda) sin descanso, mantener los lotes pequeños para que la gente nunca pierda la noción del sistema (que es precisamente la Conservación de la familiaridad de Lehman), incorporar la calidad desde el principio en lugar de inspeccionarla después, y dejar que los bucles de retroalimentación, no los edictos, gobiernen el trabajo (la octava ley de Lehman, reformulada como práctica de gestión). No es una analogía forzada: los dos marcos describen el mismo sistema desde extremos opuestos; uno nombra las fuerzas, el otro la disciplina que les responde.

El complemento de este artículo

Lean Thinking for Busy Software Developers

Las leyes de Lehman nombran las fuerzas que arrastran a todo código hacia la decadencia. Este libro es el manual de campo para plantarles cara. Lleva los principios Lean de Toyota al código: recorta el desperdicio invisible de tu proceso, mantén los lotes pequeños (la Conservación de la familiaridad en la práctica), incorpora la calidad en lugar de inspeccionarla después y gobierna con bucles de retroalimentación en lugar de edictos, con ejemplos concretos, métricas DORA y un capítulo completo sobre cómo trabajar con agentes de IA.

Consíguelo en Leanpub → Más información

Actualmente disponible en italiano; hay una edición en inglés en preparación; suscríbete en Leanpub para recibir el aviso.

Lehman vio cómo un sistema operativo de mainframe le enseñaba estas lecciones en los años setenta. Tu código distribuido, cloud-native y asistido por IA te las está enseñando de nuevo ahora mismo. La única pregunta es si estás leyendo el temario, o si te están evaluando en un examen que no sabías que estabas haciendo.

Ideas clave

• La decadencia es lo predeterminado. Un sistema del mundo real (de tipo E) dejado intacto no se queda quieto: se desfasa de su entorno (Ley 1) y parece perder calidad (Ley 7).
• La complejidad crece a menos que la combatas. La Complejidad creciente (Ley 2) es entropía; solo la refactorización deliberada la revierte. Presupuéstala, no esperes que ocurra sola.
• No puedes resolverlo a fuerza de contratar gente. La Conservación de la estabilidad organizativa (Ley 4), y la Ley de Brooks, implican que el rendimiento está gobernado por la complejidad y la comunicación, no por el mero número de personas.
• Entrega un cambio que la gente pueda absorber. La Conservación de la familiaridad (Ley 5) limita cuánta novedad pueden asimilar un equipo y sus usuarios por versión. Los lotes pequeños le ganan a las reescrituras big bang.
• Sigue creciendo, pero poda. El Crecimiento continuo (Ley 6) es obligatorio para la satisfacción, pero cada funcionalidad eleva la complejidad; trátalo como un compromiso explícito.
• Gobierna los bucles, no las variables. La evolución es un sistema de retroalimentación (Ley 8); cambia una cosa, mide los efectos de segundo orden y ajusta.
• Las leyes se doblan, así que usa el criterio. Se cumplen de forma desigual en proyectos modernos y de código abierto; sabe cuáles son robustas y cuáles condicionales.

Preguntas frecuentes

¿Qué son las leyes de Lehman sobre la evolución del software?

Son ocho observaciones empíricas, formuladas por Meir M. Lehman entre 1974 y 1996, que describen cómo los sistemas de software de tipo E (los que están embebidos en el mundo real) inevitablemente cambian, crecen y se degradan con el tiempo a menos que se invierta un esfuerzo deliberado. El conjunto abarca el Cambio continuo, la Complejidad creciente, la Autorregulación, la Conservación de la estabilidad organizativa, la Conservación de la familiaridad, el Crecimiento continuo, la Calidad en declive y el Sistema de retroalimentación.

¿Qué es un sistema de tipo E?

En la clasificación SPE de Lehman, un programa de tipo E es aquel embebido en el mundo real que mecaniza una actividad humana o de negocio, como una plataforma bancaria o un checkout de e-commerce. A diferencia de los programas de tipo S (definidos por una especificación fija) y de tipo P (una solución aproximada a un problema estable), un sistema de tipo E modifica el propio entorno que modela, lo que lo obliga a seguir evolucionando. Las ocho leyes describen los sistemas de tipo E.

¿Siguen siendo válidas las leyes de Lehman para el software moderno y de código abierto?

En parte. Los estudios de replicación encontraron que las leyes se cumplen de forma desigual. El Cambio continuo es notablemente robusto, pero otras se doblan en cuanto cambia el régimen de desarrollo. El estudio del kernel de Linux que Godfrey y Tu realizaron en 2000 encontró un crecimiento superlineal que contradecía el modelo de crecimiento de raíz cuadrada inversa que Lehman había derivado de sistemas comerciales, y estudios FLOSS posteriores hallaron que leyes como la Conservación de la familiaridad a menudo no se cumplen.

¿Por qué parece que la calidad del software decae aunque nadie cambie el código?

Por la séptima ley de Lehman, la Calidad en declive: la calidad de un sistema de tipo E se juzga frente a un entorno en movimiento. A medida que avanzan los navegadores, los dispositivos, los volúmenes de tráfico y las expectativas de los usuarios, el software que nadie toca se ve progresivamente peor aunque su código no haya cambiado. El antídoto es la adaptación continua al entorno operativo, no solo la corrección reactiva de errores.

¿Por qué el kernel de Linux no sigue la ley de crecimiento de Lehman?

Porque el kernel funciona con incentivos distintos a los de los sistemas comerciales que estudió Lehman. Su modelo de crecimiento asumía que el crecimiento de funcionalidades está gobernado por la presión del mercado y de los ingresos dentro de una única organización de capacidad limitada. En el código abierto, las funcionalidades se añaden porque los colaboradores las necesitan para su propio hardware, porque los fabricantes aportan drivers río arriba o porque los mantenedores las consideran técnicamente sólidas, no para alcanzar un objetivo de ingresos o una hoja de ruta comercial. Con miles de colaboradores independientes trabajando en paralelo, el crecimiento no está limitado por la capacidad de una sola organización, así que Godfrey y Tu (2000) midieron un crecimiento superlineal en lugar de la desaceleración predicha. La ley no falló; el kernel funciona con un motor diferente, porque los criterios que deciden si una funcionalidad existe son distintos de los comerciales con los que se calibraron las leyes.

Fuentes y lecturas adicionales: Bélády y Lehman, “A Model of Large Program Development”, IBM Systems Journal (1976); Lehman, “Laws of Software Evolution Revisited” (1996); Godfrey y Tu, “Evolution in Open Source Software: A Case Study” (2000); Canfora et al., “In memory of Manny Lehman, ‘Father of Software Evolution’” (2011); y González-Barahona et al., “Studying the laws of software evolution in a long-lived FLOSS project” (2014).