Si llevás más de un par de años escribiendo código, probablemente ya te chocaste con patrones que se repiten sin importar el lenguaje, la empresa o la década. Proyectos que se atrasan aunque sumes gente. APIs cuyo comportamiento "no documentado" termina siendo depended-on por alguien. Abstracciones que parecían limpias y terminaron filtrando detalles del sistema subyacente. Todo eso no es mala suerte: es física organizacional. Las leyes de ingeniería de software son el intento de la industria, durante los últimos 60 años, de poner nombre a esos patrones recurrentes para que la próxima generación no tenga que aprenderlos a los golpes.
El proyecto Laws of Software Engineering recopila 56 de estas leyes, principios y heurísticas en una sola colección navegable. No son teoremas matemáticos en el sentido estricto — la mayoría son observaciones empíricas con décadas de evidencia anecdótica y, en algunos casos, estudios formales. Pero tienen algo más poderoso: describen cómo se comportan los sistemas y los equipos en el mundo real, no en el mundo de los whiteboards. En este artículo hacemos un recorrido por las leyes más útiles agrupadas por dominio: arquitectura, equipos, planificación, calidad, diseño y toma de decisiones.
¿Qué son las leyes de ingeniería de software?
Una "ley" en este contexto no es una regla que alguien te obliga a seguir. Es un patrón suficientemente observado como para que tenga sentido ponerle nombre y referenciarlo. Cuando un tech lead dice "esto es un clásico Conway" en una retrospectiva, está apelando a una abreviatura: si tu org tiene tres equipos desconectados, tu software va a terminar siendo tres servicios desconectados, guste o no. Las leyes de ingeniería de software funcionan como vocabulario compartido que permite diagnosticar problemas sin volver a inventar la descripción cada vez.
💭 Clave: Las leyes no son prescriptivas ("hacé esto"), son descriptivas ("esto va a pasar"). Su valor está en ayudarte a anticipar consecuencias, no en darte un manual de instrucciones.
Algunas vienen de la ingeniería clásica (Murphy, Parkinson), otras del software específicamente (Brooks, Hyrum, Postel), y otras son heurísticas cognitivas que se volvieron inseparables del oficio (Occam, Dunning-Kruger, Hanlon). Juntas forman una especie de folklore técnico que separa al ingeniero que aprendió de los que vinieron antes del que está condenado a repetir sus errores.
Leyes sobre arquitectura
La arquitectura de un sistema refleja más decisiones humanas que técnicas.
Ley de Conway
Formulada por Melvin Conway en 1967: "las organizaciones diseñan sistemas que reflejan su estructura de comunicación". Si tu empresa tiene cuatro equipos que no se hablan, vas a tener cuatro servicios mal integrados. La consecuencia práctica es la Inverse Conway Maneuver: estructurá los equipos como querés que sea la arquitectura, no al revés. Empresas como Amazon con sus "two-pizza teams" fueron pioneras en usar Conway a favor.
Ley de Hyrum
Hyrum Wright (Google) la cristalizó: "con suficientes usuarios de tu API, todos los comportamientos observables de tu sistema terminarán siendo depended-on por alguien, sin importar el contrato". Cambiás el orden de las keys en un JSON — que nunca prometiste mantener — y se rompe un cliente en producción. Aplica a librerías, APIs públicas, servicios internos, sistemas operativos. Es la razón por la que Linux no rompe nunca el userspace y por la que Windows carga hacks para cada juego viejo.
Teorema CAP
En un sistema distribuido sólo podés garantizar dos de tres: Consistencia, Availability, tolerancia a Particiones de red. Como las particiones siempre existen en sistemas reales, en la práctica elegís entre consistencia y disponibilidad. Bases de datos como Postgres priorizan consistencia; DynamoDB o Cassandra priorizan disponibilidad. CAP no es un artefacto académico: define por qué tu arquitectura tiene que asumir fallos en vez de rezar para que no ocurran.
Ley de Gall
"Un sistema complejo que funciona siempre evolucionó desde un sistema simple que funcionaba". Intentar diseñar un sistema complejo desde cero casi nunca termina bien. Si querés llegar a una plataforma de 500 microservicios, el camino realista empieza con un monolito que funciona y se va descomponiendo. Startups que intentan el big-bang microservicios antes de tener product-market fit son el meme por excelencia de esta ley.
Ley de Tesler
También conocida como conservación de la complejidad: cada aplicación tiene una cantidad de complejidad inherente que no se puede eliminar, sólo mover. Si simplificás la UI, la complejidad se va al backend. Si simplificás el backend, se va a los clientes. Tu trabajo como arquitecto no es eliminarla — es ubicarla donde cause menos daño.
Leyes sobre equipos humanos
Ley de Brooks
Del clásico The Mythical Man-Month (1975): "agregar programadores a un proyecto atrasado lo atrasa más". El motivo es el overhead de comunicación y onboarding: meter cinco personas nuevas significa que los que ya estaban ahora pasan semanas explicando en lugar de produciendo. Brooks es la razón por la que responderle al CEO "contratá más gente" cuando un proyecto va mal casi nunca es la respuesta correcta.
Número de Dunbar
El antropólogo Robin Dunbar estimó que una persona puede mantener unas 150 relaciones estables. En ingeniería se traduce en que, cuando una org de desarrollo pasa de ~150 personas, la comunicación informal se rompe y empiezan a hacer falta estructuras formales (guilds, chapters, RFCs, platform teams). Es por eso que muchas empresas dividen en unidades de negocio cuando superan ese tamaño.
Ley de Price
La raíz cuadrada del número de participantes hace el 50% del trabajo. En un equipo de 16, típicamente 4 personas producen la mitad del output. No es necesariamente injusto: suele ser la combinación de contexto acumulado, seniority y conocimiento de dominio. Saber que esto pasa ayuda a planificar bus factor y sucesión, en vez de descubrirlo cuando alguien clave se va.
Principio de Peter
"En una jerarquía, cada empleado tiende a ascender hasta su nivel de incompetencia". El mejor IC se asciende a tech lead. El mejor tech lead, a engineering manager. El mejor manager, a director. En algún punto la persona llega a un rol en el que ya no brilla — y se queda ahí. Por eso muchas empresas modernas crean dual ladders (IC / management) para que los grandes ingenieros no estén obligados a abandonar el código para subir de sueldo.
Bus Factor
La cantidad mínima de personas de tu equipo que tendrían que "ser atropelladas por un bus" para que el proyecto colapse. Bus factor = 1 es el estado más frágil posible: una sola persona entiende el sistema de pagos, la pipeline de deploy, el Terraform de producción. Medir y subir el bus factor (pair programming, documentación, rotaciones) es higiene operacional básica.
Leyes de planificación y productividad
Ley de Parkinson
"El trabajo se expande hasta llenar el tiempo asignado". Si tenés tres semanas para una feature de una semana, la feature va a tomar tres semanas. Por eso los deadlines cortos y las timeboxes funcionan — no porque la gente trabaje más rápido bajo presión, sino porque deja de agregar "mejoras" que nadie pidió.
Regla del 90-90
El primer 90% del código toma el primer 90% del tiempo. El 10% restante toma el otro 90%. Si alguna vez estimaste "mañana lo termino" y terminaste invirtiendo dos semanas más en edge cases, estabilización y bugs raros, ya experimentaste la regla. Explica por qué las estimaciones de software son sistemáticamente optimistas.
Ley de Hofstadter
"Siempre tarda más de lo que esperás, incluso cuando tomás en cuenta la ley de Hofstadter". Es autoreferencial y medio broma, pero describe una realidad dolorosa: los seres humanos somos malos estimando tareas complejas, y agregar un buffer "de seguridad" rara vez alcanza. La mejor defensa es trabajar en iteraciones cortas donde los atrasos se detectan temprano, no al final.
Ley de Goodhart
"Cuando una métrica se convierte en objetivo, deja de ser una buena métrica". Si medís la productividad en líneas de código, alguien va a escribir código inflado. Si medís en tickets cerrados, alguien va a partir tickets. Si medís en test coverage, alguien va a agregar tests vacíos. Toda métrica de ingeniería que usás para evaluación personal termina corrompida.
⚠️ Ojo: Goodhart aplica duro a métricas de AI y DevEx. Si tu plataforma interna mide "% de PRs auto-mergeados" como KPI, vas a terminar con un equipo que optimiza para auto-merge en vez de para calidad.
Leyes de calidad y código
Ley de Murphy
"Lo que pueda salir mal, saldrá mal". En software se traduce en defensive programming real: si una condición puede ocurrir, en producción va a ocurrir. Red de 1 en 10 millones de requests se convierte en un incidente diario si servís mil millones de requests al día. Netflix construyó Chaos Monkey explícitamente para provocar las fallas que Murphy garantiza, en vez de esperarlas.
Ley de Postel
"Sé conservador en lo que enviás, liberal en lo que aceptás". Originalmente aplicada a TCP, se extendió a APIs y parsers. Es un arma de doble filo: aceptar input laxo mejora la interoperabilidad inicial pero, a la larga, genera dialectos (HTML pre-HTML5 es el ejemplo canónico). Una revisión moderna sugiere ser estricto en lo que aceptás para evitar que los clientes construyan sobre comportamientos accidentales (y caer en Hyrum).
Ley de Linus
"Dados suficientes ojos, todos los bugs son superficiales". La frase que justificó el modelo open source. La versión matizada: muchos ojos ayudan sólo si están calificados y revisan activamente. OpenSSL tuvo ojos durante años y Heartbleed (2014) estuvo ahí sin que nadie lo viera. El principio sigue siendo cierto pero no es automático: requiere cultura de code review real, no rubber stamps.
Broken Windows
Tomado de la criminología urbana: si dejás ventanas rotas sin reparar, el edificio se degrada rápido. En un codebase, si permitís TODOs sin dueño, comentarios muertos, tests skipeados y archivos inmortales, la calidad colapsa en cascada. La contraparte es la Boy Scout Rule de Uncle Bob: dejá el código mejor de como lo encontraste.
Ley de Kernighan
"Debuggear es el doble de difícil que escribir el código". Por lo tanto, si escribís código lo más inteligente que podés, por definición no vas a ser capaz de debuggearlo. Corolario práctico: escribí código más simple de lo que podrías, para tener margen mental cuando algo falle a las 3 AM.
Debuggear es más difícil que escribir: diseñá pensando en el incidente futuro.
Leyes de diseño
DRY, KISS, YAGNI
- DRY (Don't Repeat Yourself) — cada pieza de conocimiento tiene una única representación. Ojo con el anti-patrón: aplicar DRY prematuramente une cosas que parecen iguales pero van a divergir.
- KISS (Keep It Simple, Stupid) — elegí la solución más simple que resuelva el problema. El beneficio no es estético: es que la gente que mantiene el código dentro de dos años la va a poder entender.
- YAGNI (You Aren't Gonna Need It) — no agregues funcionalidad "por si acaso". Cada opción de configuración, cada endpoint "por las dudas", cada abstracción especulativa es deuda desde el día uno.
SOLID
Los cinco principios de Robert C. Martin para diseño orientado a objetos: Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion. Son más útiles leídos como heurísticas ("¿esta clase tiene una sola razón para cambiar?") que como reglas absolutas. En contextos funcionales o distribuidos pierden peso — pero la intuición que dan sobre acoplamiento sigue siendo vigente.
Ley de Demeter
"Hablá sólo con tus amigos inmediatos". En código: evitá a.b().c().d(). Cada chainazo de accesos crea dependencia en la estructura interna del colaborador — si esa estructura cambia, te rompés. Se viola muchísimo y se paga en refactors.
// Violación de Demeter
double total = order.getCustomer().getAddress().getCity().getTaxRate() * subtotal;
// Respetando Demeter
double taxRate = order.calculateTaxRate();
double total = taxRate * subtotal;
Principio de menor asombro
El software debería comportarse como la gente espera que se comporte. Si tu función sort() modifica el array original en vez de devolver uno nuevo — y el resto de la librería devuelve copias — estás violando este principio. El costo no es técnico: es cognitivo. Cada violación es un bug latente esperando a un desarrollador con prisa.
Leyes de decisiones y sesgos
Acá entran las heurísticas cognitivas que más plata cuestan en tech cuando se ignoran. No son leyes de software en sentido estricto, pero se manifiestan en cada decisión técnica.
Dunning-Kruger
Cuanto menos sabés de un tema, más confianza tenés en tu opinión. Se ve claro en arquitectura: el ingeniero junior que acaba de leer sobre microservicios va a querer microservicios para todo. El senior que vio migraciones reales a microservicios es mucho más cauto. Aplicá el principio a vos mismo: si estás muy seguro de una decisión técnica fuera de tu área, asumí que te falta información.
Navaja de Hanlon
"Nunca atribuyas a la malicia lo que se explica por la estupidez o la negligencia". En incident response es oro: antes de buscar al saboteador interno, asumí que alguien se equivocó al escribir un YAML. El 99% de las veces es eso.
Navaja de Occam
La explicación más simple suele ser la correcta. Si la API devuelve 500, la explicación más probable es que tu request esté mal, no que el proveedor haya sido hackeado. Empezá por las hipótesis simples antes de ir a las exóticas.
Falacia del costo hundido
"Ya invertimos seis meses en esto, no podemos parar ahora". Sí podés. Los seis meses están hundidos — no los recuperás si seguís. La decisión correcta es evaluar el costo y beneficio desde hoy hacia adelante, ignorando lo ya gastado. La mitad de los proyectos zombies en empresas grandes existen porque nadie quiere admitir la falacia del costo hundido.
Cómo se relacionan entre sí
Las leyes no viven en silos. La interacción entre Conway, Brooks y Dunbar, por ejemplo, explica por qué las reorganizaciones masivas fracasan. Este diagrama muestra las dependencias más comunes:
graph LR
A["Estructura del equipo (Conway)"] --> B["Arquitectura resultante"]
A --> C["Overhead de comunicación (Brooks)"]
C --> D["Atrasos en entregas"]
B --> E["APIs públicas"]
E --> F["Usuarios dependen de todo (Hyrum)"]
F --> G["Imposible cambiar sin romper"]
D --> H["Scope creep (Parkinson)"]
H --> I["Complejidad crece (Gall)"]
I --> J["Código impredecible (Murphy)"]
Cómo aplicar las leyes de ingeniería de software en el día a día
Conocerlas es la parte fácil. Integrarlas en tu práctica diaria requiere algunos hábitos:
- En cada code review: buscá violaciones de Demeter, YAGNI y KISS. Si no podés explicar por qué una abstracción existe, probablemente no debería existir todavía.
- En diseño de sistemas: dibujá primero la estructura del equipo, después la arquitectura (Conway). Asumí que todo output observable va a ser dependency de alguien (Hyrum). Elegí explícitamente entre C y A (CAP).
- En planificación: multiplicá tu estimación por 1.5 (Hofstadter). Nunca midas productividad con una sola métrica (Goodhart). Aceptá que el 10% final es caro (90-90).
- En producción: cualquier fallo posible eventualmente ocurre (Murphy). Revisá bus factor cada trimestre. Tratá las ventanas rotas antes de que se multipliquen.
- En decisiones de carrera: acordate del Principio de Peter cuando te ofrezcan un ascenso. Pensá dos veces si aceptar te saca de lo que sabés hacer bien.
💡 Tip: Una buena forma de aprender las leyes es hacer un glosario compartido con tu equipo. Cuando aparece un problema, nómbralo con la ley correspondiente. Ese vocabulario convierte retrospectivas de una hora en conversaciones de diez minutos.
Las leyes también son una herramienta de comunicación con stakeholders no técnicos. Explicarle a un product manager que "Brooks" es la razón por la que contratar tres devs más no va a acelerar el MVP de la semana que viene es más efectivo que debatir números. Las mejores carreras en ingeniería de software se construyen no sólo sobre habilidades técnicas, sino sobre la capacidad de ver patrones que ya ocurrieron miles de veces y evitarlos — o al menos, cuando inevitablemente ocurren, tener el lenguaje para discutirlos con claridad.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Las leyes de ingeniería de software son reglas obligatorias?
No. Son observaciones empíricas sobre cómo se comportan los sistemas, los equipos y los desarrolladores. Funcionan como heurísticas: te ayudan a anticipar consecuencias, pero no hay una policía que te obligue a seguirlas. Ignorarlas tiene costo, pero aplicarlas ciegamente sin contexto también.
¿Cuál es la ley más importante para un desarrollador junior?
Probablemente KISS y YAGNI. La mayoría de los errores en los primeros años vienen de over-engineering: abstracciones prematuras, configuraciones que nadie pidió, "flexibilidad" para casos hipotéticos. Escribir código simple que resuelve el problema actual es una habilidad subestimada y la base para aplicar bien el resto.
¿La Ley de Conway se puede romper?
En la práctica, no. Sí se puede usar a favor con la Inverse Conway Maneuver: diseñá la estructura organizacional que querés que produzca tu arquitectura objetivo. Si querés una arquitectura de plataforma, necesitás un platform team. Si querés microservicios independientes, necesitás equipos autónomos. Intentar lograr una arquitectura que no coincide con tu org gráfica siempre falla.
¿La Ley de Brooks sigue siendo válida con IA y herramientas modernas?
Sí, aunque con matices. El overhead de onboarding y coordinación baja cuando las herramientas son mejores (documentación autogenerada, ambientes de desarrollo reproducibles, IAs como asistentes), pero no desaparece. Sumar cinco personas a un proyecto atrasado sigue costando productividad neta en el corto plazo. La ley se aplica incluso cuando los "nuevos" son agentes de IA: alguien tiene que reviewar su output.
¿Qué diferencia hay entre la Ley de Hyrum y la Ley de Postel?
Postel es un consejo de diseño: aceptá input laxo, produce output estricto. Hyrum es una observación de realidad: cualquier comportamiento observable va a ser depended-on. En la práctica moderna muchas veces entran en tensión — ser "liberal en lo que aceptás" genera comportamientos accidentales que, por Hyrum, se vuelven contrato de facto. Por eso hay una tendencia reciente a ser más estricto en los inputs de las APIs nuevas.
¿Dónde puedo aprender más sobre estas leyes?
El sitio lawsofsoftwareengineering.com las cataloga todas con explicaciones y ejemplos. Libros clásicos que vale la pena leer: The Mythical Man-Month (Brooks), The Pragmatic Programmer (Hunt & Thomas), Designing Data-Intensive Applications (Kleppmann) y Accelerate (Forsgren, Humble, Kim).
Referencias
- Laws of Software Engineering — Catálogo navegable de 56 leyes y principios con explicaciones y ejemplos.
- Conway's Law (Wikipedia) — Texto original de Melvin Conway (1967) y aplicaciones modernas de la Inverse Conway Maneuver.
- The Mythical Man-Month (Wikipedia) — Resumen del libro de Fred Brooks donde se formula la ley que lleva su nombre.
- Hyrum's Law — Sitio oficial que explica la ley de Hyrum Wright sobre comportamiento observable en APIs.
- CAP Theorem (Wikipedia) — Formulación original del teorema CAP de Eric Brewer y sus interpretaciones posteriores.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)