Las leyes de la ingeniería de software
(lawsofsoftwareengineering.com)- Una colección que reúne en un solo lugar 56 principios y patrones que influyen en los sistemas de software, los equipos y la toma de decisiones, y que abarca ampliamente desde la operación de equipos hasta arquitectura, calidad, diseño y toma de decisiones
- Las leyes relacionadas con equipos, como la Ley de Conway, la Ley de Brooks y el número de Dunbar, muestran que la estructura organizacional influye directamente en el diseño del sistema y en la productividad
- En el área de arquitectura, se organizan restricciones y principios que deben considerarse al diseñar sistemas complejos, como la Ley de Hyrum, el teorema CAP y la Ley de Gall
- Las leyes relacionadas con calidad abordan las dificultades reales de mantener la calidad del código y de depurar, incluyendo deuda técnica, la pirámide de testing y la Ley de Kernighan
- En el área de toma de decisiones, abarca sesgos cognitivos y criterios de juicio en los que es fácil caer durante el desarrollo, como el efecto Dunning-Kruger, la falacia del costo hundido y el principio de Pareto
Equipos (Teams)
1. Ley de Conway (Conway's Law)
Las organizaciones diseñan sistemas que reflejan su propia estructura de comunicación
- La arquitectura de software tiende naturalmente a seguir la estructura de comunicación de la organización que la creó
- Si un equipo está dividido en 3 grupos, el sistema también tenderá a dividirse en 3 grandes módulos
- También existe la "estrategia de Conway inversa" (Inverse Conway Maneuver): un enfoque que primero reorganiza la estructura del equipo para ajustarla a la arquitectura deseada
- Al adoptar microservicios, es efectivo hacer coincidir los límites del equipo con los límites de los servicios
2. Ley de Brooks (Brooks's Law)
Agregar personal a un proyecto de software retrasado lo retrasa aún más
- Cuando se incorpora personal nuevo, los miembros existentes del equipo gastan tiempo en capacitación y coordinación, lo que reduce temporalmente la productividad total
- A medida que aumenta el número de integrantes, las rutas de comunicación crecen de forma exponencial (con n personas, n(n-1)/2)
- Frederick Brooks la formuló en su libro de 1975 The Mythical Man-Month, basado en su experiencia con el proyecto IBM OS/360
- Puede explicarse cuantitativamente con la Ley de Little (L = λ × W): al sumar personal, aumenta el WIP (trabajo en curso), pero el throughput se estanca, por lo que el lead time incluso aumenta
- La solución no es agregar personal, sino ajustar el alcance o cambiar el cronograma
3. Número de Dunbar (Dunbar's Number)
El límite cognitivo de relaciones que una persona puede mantener de forma estable es de unas 150 personas
- Robin Dunbar derivó esta cifra a partir de la correlación entre el tamaño del cerebro de los primates y el tamaño de sus grupos sociales
- La estructura jerárquica social de Dunbar: ~5 personas (relaciones íntimas), ~15 (colaboradores de confianza), ~50 (relaciones laborales cercanas), ~150 (conexiones sociales estables)
- Cuando una organización de ingeniería supera las 150 personas, la comunicación informal llega a su límite y se vuelven necesarias jerarquías y procesos formales
- El "Two-Pizza Team" de Amazon (5 a 10 personas) refleja que, incluso dentro de 150 personas, la colaboración real ocurre en unidades más pequeñas
4. Efecto Ringelmann (The Ringelmann Effect)
Cuanto más grande es el grupo, menor es la productividad individual
- A medida que aumenta el número de integrantes del grupo, disminuye la contribución de cada persona, en un fenómeno de "holgazanería social" (social loafing)
- En los equipos de software, cuando el tamaño del equipo crece, se diluye la responsabilidad individual y aumenta el costo de coordinación
- Explica por qué los equipos pequeños logran una mayor producción por persona
5. Ley de Price (Price's Law)
El número de personas equivalente a la raíz cuadrada del total de participantes realiza el 50% del trabajo total
- En una organización de 100 personas, unas 10 personas hacen la mitad del trabajo total
- Cuanto más crece la organización, mayor es la dependencia de un pequeño grupo de personas de alto rendimiento
- Explica por qué la productividad no aumenta de forma lineal al escalar un equipo
6. Ley de Putt (Putt's Law)
Quienes entienden la tecnología no gestionan, y quienes gestionan no entienden la tecnología
- Expresa de forma satírica la brecha entre el rol de gestión y la experiencia técnica en organizaciones tecnológicas
- Al diseñar la estructura de liderazgo técnico, es necesario reconocer esa brecha y establecer mecanismos para compensarla
7. Principio de Peter (Peter Principle)
Dentro de una organización, todo empleado tiende a ser promovido hasta su nivel de incompetencia
- Describe el patrón en el que una persona competente en un rol es promovida y se vuelve incompetente en el nuevo rol
- Refleja la realidad de que un gran desarrollador no necesariamente se convierte en un buen manager
- Muestra la necesidad de un sistema de doble escalera que separe la ruta de IC (Individual Contributor) de la ruta de management
8. Bus Factor
El número mínimo de salidas de miembros del equipo que puede poner a un proyecto en grave riesgo
- Si el Bus Factor es 1, existe un punto único de falla (Single Point of Failure)
- Es importante aumentar el Bus Factor mediante compartir conocimiento, pair programming y documentación
- El code review y el cross-training son formas prácticas de mejorar el Bus Factor
9. Principio Dilbert (Dilbert Principle)
Las empresas tienden a promover a los empleados incompetentes a puestos de gestión para limitar el daño
- Una observación satírica propuesta por Scott Adams, como variación del Principio de Peter
- Un fenómeno organizacional paradójico en el que los puestos de gestión se consideran el lugar donde se causa menos daño al trabajo práctico
Planificación (Planning)
10. Optimización prematura / principio de optimización de Knuth (Premature Optimization)
La optimización prematura es la raíz de todos los males
- Donald Knuth lo planteó en un artículo de 1974: "en aproximadamente el 97% de los casos, las pequeñas eficiencias deben ignorarse"
- Como alrededor del 20% del código consume el 80% del tiempo de ejecución, optimizar el 80% restante del código es un desperdicio
- El orden correcto es: primero hacer que funcione → luego que sea correcto → y, si hace falta, hacerlo rápido
- Como el código optimizado aumenta la complejidad, debe hacerse después de identificar los cuellos de botella reales mediante profiling
11. Ley de Parkinson (Parkinson's Law)
El trabajo se expande hasta llenar todo el tiempo disponible
- Si la fecha límite es de 2 semanas, el trabajo se alarga 2 semanas; si es de 4, se alarga 4 semanas
- Explica por qué es importante establecer hitos cortos y claros en proyectos de software
- El ágil basado en sprints es una forma práctica de responder a esta ley
12. Regla del 90-90 (The Ninety-Ninety Rule)
El primer 90% del código ocupa el 90% del tiempo de desarrollo, y el 10% restante ocupa otro 90% del tiempo
- Advierte que el 10% final de un proyecto de software (edge cases, pulido y corrección de bugs) toma mucho más tiempo de lo esperado
- La expresión "casi terminado" puede en realidad señalar el punto medio del cronograma completo
13. Ley de Hofstadter (Hofstadter's Law)
Siempre toma más tiempo del esperado, incluso si se tiene en cuenta la Ley de Hofstadter
- Una ley con estructura de autorreferencia recursiva que expresa la dificultad inherente de estimar plazos en software
- La realidad es que, incluso agregando buffer, el cronograma sigue excediéndose
- Douglas Hofstadter la presentó en su libro de 1979 Gödel, Escher, Bach
14. Ley de Goodhart (Goodhart's Law)
Cuando una métrica se convierte en objetivo, deja de ser una buena métrica
- Un caso representativo es cuando se fija la cobertura de código como KPI y eso termina produciendo tests sin sentido
- Si la productividad se mide por líneas de código (LOC), se termina generando código innecesariamente verboso
- Hay que enfocarse no en optimizar métricas, sino en lograr valor real
15. Ley de Gilb (Gilb's Law)
Si algo necesita cuantificarse, medirlo de cualquier manera es mejor que no medirlo
- Aunque una medición perfecta sea imposible, una medición aproximada siempre es más útil que no medir
- También aplica a elementos difíciles de cuantificar, como la calidad del software o la satisfacción del usuario
Arquitectura (Architecture)
16. Ley de Hyrum (Hyrum's Law)
Si hay suficientes usuarios de una API, alguien dependerá de todo comportamiento observable del sistema
- No solo la especificación oficial de la API, sino también comportamientos no oficiales como timing, formato de mensajes de error y orden de clasificación se vuelven dependencias
- El caso de Microsoft Windows, que mantuvo comportamientos de versiones anteriores para conservar la compatibilidad con apps de terceros que dependían de comportamientos y bugs no documentados
- Hyrum Wright de Google lo observó a partir de su experiencia con cambios en bibliotecas internas de Google alrededor de 2011-2012
- Su colega Titus Winters le dio el nombre de "Ley de Hyrum" (incluida en Software Engineering at Google)
- El contrato real no es la API oficial, sino el conjunto completo del comportamiento observable
17. Ley de Gall (Gall's Law)
Un sistema complejo que funciona necesariamente evolucionó a partir de un sistema simple que funcionaba
- Si se diseña un sistema complejo desde el inicio, hay demasiadas variables desconocidas sin validar, por lo que la probabilidad de fracaso es alta
- Base teórica del enfoque MVP (Minimum Viable Product)
- El caso de Facebook, que comenzó en 2004 como un sistema simple de perfiles para estudiantes de Harvard y se fue expandiendo gradualmente
- Incluso al migrar a microservicios, conviene empezar con un monolito e ir separándolo gradualmente
- Propuesta por John Gall en su libro Systemantics de 1975 (un clásico de culto publicado tras ser rechazado por 30 editoriales)
18. Ley de las abstracciones con fugas (The Law of Leaky Abstractions)
Toda abstracción no trivial tiene fugas en algún grado
- Un caso representativo es cuando un ORM oculta SQL, pero al aparecer problemas de rendimiento, al final hay que revisar las consultas que se generan
- La recolección de basura de Java/Python también es una abstracción, pero comportamientos internos como las pausas de GC afectan el rendimiento
- La lección no es que la abstracción sea mala, sino que hay que prepararse para cuando la abstracción se rompa
- Joel Spolsky la presentó en una entrada de blog de 2002 junto con ejemplos de TCP, memoria virtual y otros
- También se conecta en contexto con la frase de George Box: "todos los modelos están equivocados, pero algunos son útiles"
19. Ley de Tesler / Ley de conservación de la complejidad (Tesler's Law)
Toda aplicación tiene una complejidad inherente que no se puede eliminar; solo se puede mover, no hacer desaparecer
- Pregunta clave: ¿quién va a cargar con la complejidad? (usuario vs. sistema)
- Calendly absorbe en el sistema la complejidad de coordinar horarios, mientras que un hilo de email se la traslada al usuario
- Un buen diseño mueve la complejidad de la experiencia del usuario al interior del sistema
- Larry Tesler la formuló en los años 80 mientras trabajaba en Apple Lisa y las primeras GUI
20. Teorema CAP (CAP Theorem)
Un sistema distribuido solo puede garantizar dos de tres: consistencia (C), disponibilidad (A) y tolerancia a particiones (P)
- Las particiones de red son inevitables en la práctica, así que la elección real es consistencia vs. disponibilidad
- Sistemas CP (ej.: MongoDB): cuando ocurre una partición, bloquean escrituras para mantener sincronizadas todas las réplicas
- Sistemas AP (ej.: Cassandra, DNS): siguen respondiendo solicitudes durante una partición y permiten inconsistencias temporales entre réplicas
- Eric Brewer lo propuso en 2000 en el contexto de servicios web, y Gilbert & Lynch lo demostraron formalmente en 2002
21. Efecto del segundo sistema (Second-System Effect)
Después de un sistema pequeño y exitoso, suele venir un sistema sucesor sobrediseñado y excesivamente grande
- Patrón en el que, tras el éxito del primer sistema, se intenta meter todas las ideas en el segundo
- Las causas principales son el exceso de funciones (feature creep) y la sobregeneralización (over-generalization)
- Frederick Brooks lo identificó en The Mythical Man-Month
22. Falacias de la computación distribuida (Fallacies of Distributed Computing)
Ocho suposiciones erróneas que suelen tener quienes diseñan un sistema distribuido por primera vez
- Las 8 falacias: (1) la red es confiable, (2) la latencia es cero, (3) el ancho de banda es infinito, (4) la red es segura, (5) la topología no cambia, (6) hay un solo administrador, (7) el costo de transporte es cero, (8) la red es homogénea
- Si se diseña con base en estas suposiciones, en producción aparecen fallas inesperadas y problemas de rendimiento
23. Ley de las consecuencias no intencionadas (Law of Unintended Consequences)
Si cambias un sistema complejo, debes esperar resultados imprevistos
- Si se cambia un componente del sistema, pueden aparecer efectos secundarios en lugares que no se habían previsto
- Principio que respalda la necesidad de chaos engineering y pruebas integrales
24. Ley de Zawinski (Zawinski's Law)
Todo programa intenta expandirse hasta poder leer correo
- Satiriza el fenómeno de inflación de funciones (feature bloat), por el que el software exitoso intenta añadir cada vez más capacidades
- Observada por Jamie Zawinski (desarrollador de los primeros tiempos de Netscape)
- Advertencia sobre la tendencia de las herramientas simples a intentar convertirse con el tiempo en plataformas para todo
Calidad (Quality)
25. Regla del Boy Scout (The Boy Scout Rule)
Debes dejar el código en mejor estado del que lo encontraste
- La clave no es un gran refactor, sino la mejora continua e incremental
- Practicar pequeñas mejoras cada vez, como corregir nombres de funciones confusos, eliminar código duplicado o agregar pruebas faltantes
- Robert C. Martin (Uncle Bob) la aplicó al desarrollo de software en Clean Code (2008)
- Principio de los ingenieros de Google: "If you touch it, you own it" — si modificas el código, también asumes la responsabilidad por su calidad
- Aplicar esta regla ayuda a prevenir el efecto de ventanas rotas (Broken Windows) y evita la acumulación de deuda técnica
26. Ley de Murphy (Murphy's Law)
Todo lo que pueda salir mal, saldrá mal
- Base de la programación defensiva, el manejo de excepciones y el diseño preparado para fallas
- En software, hay que diseñar el manejo de errores y los fallbacks con la mentalidad de que "todo error que pueda ocurrir, ocurrirá"
27. Ley de Postel / principio de robustez (Postel's Law)
Sé conservador en lo que haces y liberal en lo que aceptas de los demás
- En diseño de APIs, el principio indica que la salida debe cumplir estrictamente la especificación, mientras que la entrada debe aceptar con flexibilidad diversos formatos
- Jon Postel estableció este principio de robustez (Robustness Principle) al diseñar los protocolos TCP/IP
- Guía práctica para mejorar la interoperabilidad entre sistemas
28. Teoría de las ventanas rotas (Broken Windows Theory)
No dejes sin atender el mal diseño, las malas decisiones ni el código de baja calidad
- Si se deja un "ventanal roto" (mal código), eso provoca más deterioro de la calidad
- Cuando se acumulan comentarios TODO, código muerto y advertencias sin resolver en un codebase, el nuevo código también tiende a escribirse con menor nivel
- Es importante una cultura de corregir incluso los problemas pequeños en cuanto se detectan
29. Deuda técnica (Technical Debt)
Todo aquello que reduce la velocidad del desarrollo de software
- Ward Cunningham usó por primera vez la metáfora financiera en OOPSLA 1992: tomar atajos en el código es pedir prestado tiempo al futuro
- Principal (costo de corregir) + interés (caída continua de productividad por código desordenado)
- La deuda técnica intencional a veces es razonable (timing de salida al mercado, prototipado), pero un plan de pago es indispensable
- Omitir pruebas automatizadas es un caso típico: el release sale bien, pero luego aparecen bugs inesperados en cada cambio
- Cómo resolverla: refactorización, agregar pruebas faltantes, mejorar el diseño
30. Ley de Linus (Linus's Law)
Con un número suficiente de revisores, todos los bugs son fáciles de encontrar
- Principio central del desarrollo open source: muchos ojos revisando el código hacen que los bugs se vuelvan problemas triviales
- Eric Raymond la nombró en The Cathedral and the Bazaar a partir del nombre de Linus Torvalds
- Respalda la importancia de la cultura de code review
31. Ley de Kernighan (Kernighan's Law)
Depurar es el doble de difícil que escribir el código en primer lugar
- Por lo tanto, si escribes código lo más ingenioso posible, luego no serás lo suficientemente ingenioso para depurarlo
- Esta es la razón por la que se debe escribir código simple y altamente legible
- Propuesto por Brian Kernighan en The Elements of Programming Style
32. Pirámide de testing (Testing Pyramid)
Un proyecto debe tener muchas pruebas unitarias rápidas, pocas pruebas de integración y solo unas cuantas pruebas de UI
- Pruebas unitarias (base): rápidas y de bajo costo, son las que más se escriben
- Pruebas de integración (medio): validan la interacción entre componentes
- Pruebas UI/E2E (cima): como son lentas y frágiles, deben minimizarse
- Modelo de estrategia de testing presentado por Mike Cohn en Succeeding with Agile
33. Paradoja del pesticida (Pesticide Paradox)
Si ejecutas las mismas pruebas repetidamente, su efectividad disminuye con el tiempo
- Como las pruebas existentes ya detectaron todos los bugs que podían atrapar, es necesario seguir agregando nuevos casos de prueba
- Es indispensable revisar y actualizar el conjunto de pruebas periódicamente
34. Leyes de evolución del software de Lehman (Lehman's Laws of Software Evolution)
El software que refleja el mundo real necesariamente debe evolucionar, y esa evolución tiene límites predecibles
- El software de tipo E (que refleja el mundo real) requiere cambios continuos para seguir siendo útil
- Con cada cambio, la complejidad aumenta y, si no se gestiona activamente, la calidad se deteriora
35. Ley de Sturgeon (Sturgeon's Law)
El 90% de todo es inútil
- Propuesta por Theodore Sturgeon en respuesta a críticas de la literatura de ciencia ficción
- También aplica al software: entre la mayoría del código, herramientas y frameworks, solo una minoría es realmente excelente
- Hace falta mantener estándares altos de calidad y enfocarse en el 10% que sí aporta valor
Escala (Scale)
36. Ley de Amdahl (Amdahl's Law)
La mejora de velocidad por paralelización está limitada por la proporción de trabajo que no puede paralelizarse
- Si el 5% de un programa es secuencial, por más procesadores que se agreguen, la mejora teórica máxima de velocidad es de 20x
- Reconocer los límites de la paralelización y reducir los cuellos de botella secuenciales es más efectivo
- Propuesta por Gene Amdahl en 1967
37. Ley de Gustafson (Gustafson's Law)
Al aumentar el tamaño del problema, se puede lograr una mejora considerable de velocidad con procesamiento paralelo
- Perspectiva complementaria a la ley de Amdahl: en problemas escalables, y no fijos, agregar procesadores sí resulta efectivo
- En procesamiento de big data, simulaciones científicas y otros casos, más recursos permiten resolver problemas más grandes
38. Ley de Metcalfe (Metcalfe's Law)
El valor de una red es proporcional al cuadrado del número de usuarios
- Si hay 10 usuarios, el valor aumenta a 100 unidades; con 100 usuarios, a 10,000 unidades
- Base teórica del efecto de red en redes sociales, mensajería, marketplaces y más
- Propuesta por Robert Metcalfe para explicar el valor de la tecnología Ethernet
Diseño (Design)
39. Principio DRY (Don't Repeat Yourself)
Todo conocimiento debe tener una sola representación, clara y autoritativa
- Incluye no solo duplicación de código, sino también duplicación de conocimiento, lógica y datos
- La duplicación obliga a modificar varios lugares al mismo tiempo cuando algo cambia, por lo que es fuente de bugs e inconsistencias
- Formalizado por Andy Hunt y Dave Thomas en The Pragmatic Programmer
40. Principio KISS (Keep It Simple, Stupid)
El diseño y los sistemas deben ser lo más simples posible
- La complejidad incrementa el costo de comprensión, mantenimiento y depuración
- Las soluciones simples suelen ser más efectivas en la mayoría de los casos y también tienen menos probabilidad de fallar
- Se origina en un principio de diseño planteado por la Marina de EE. UU. en la década de 1960
41. Principios SOLID (SOLID Principles)
Cinco lineamientos clave para mejorar el diseño de software
- S — Principio de responsabilidad única (Single Responsibility): una clase debe cambiar solo por una razón
- O — Principio abierto-cerrado (Open-Closed): debe estar abierto a extensión y cerrado a modificación
- L — Principio de sustitución de Liskov: los subtipos deben poder sustituir a los tipos base
- I — Principio de segregación de interfaces: un cliente no debe depender de interfaces que no usa
- D — Principio de inversión de dependencias: los módulos de alto nivel no deben depender de módulos de bajo nivel, sino de abstracciones
- Robert C. Martin los formalizó y Michael Feathers acuñó el acrónimo SOLID
42. Ley de Demeter (Law of Demeter)
Un objeto debe interactuar solo con sus amigos directos y evitar la comunicación directa con objetos extraños
- Es el principio de evitar llamadas encadenadas como
a.getB().getC().doSomething() - Reduce el acoplamiento y fortalece la encapsulación, disminuyendo el alcance del impacto de los cambios
- También se conoce como el "principio del menor conocimiento"
43. Principio de la menor sorpresa (Principle of Least Astonishment)
El software y las interfaces deben comportarse de la manera que menos sorprenda a los usuarios y a otros desarrolladores
- Las funciones, API y UI deben tener un comportamiento predecible según sus nombres y convenciones
- Si una función
delete()en realidad solo archiva, genera sorpresa → defecto de diseño - Un comportamiento poco intuitivo provoca bugs y errores de usuario
44. YAGNI (You Aren't Gonna Need It)
No agregues funcionalidades hasta que realmente se necesiten
- Principio central de Extreme Programming (XP), planteado por Ron Jeffries a fines de los 90
- Escribir código "por si acaso se necesita en el futuro" genera sobreingeniería y carga de mantenimiento
- Para aplicar YAGNI hace falta confianza en el refactoring (buena cobertura de pruebas, CI)
- Si hoy solo hace falta exportar JSON, implementa solo JSON; agrega XML/YAML y otros cuando se pidan
Toma de decisiones (Decisions)
45. Efecto Dunning-Kruger (Dunning-Kruger Effect)
Cuanto menos sabes sobre algo, más confianza tiendes a tener
- Puede verse en desarrolladores principiantes que subestiman la dificultad de sistemas complejos, o en expertos que, al contrario, son más humildes respecto a su conocimiento
- Es importante mejorar la precisión de la autopercepción mediante code reviews, mentoría y aprendizaje continuo
46. Navaja de Hanlon (Hanlon's Razor)
No atribuyas a la malicia lo que puede explicarse suficientemente por estupidez o descuido
- Antes de interpretar el mal código o una mala decisión de un colega como sabotaje intencional, conviene considerar primero la ignorancia, el error o la falta de tiempo
- Es una base para la confianza y la comunicación constructiva dentro del equipo
47. Navaja de Occam (Occam's Razor)
La explicación más simple suele ser la correcta
- Al depurar, conviene revisar primero la posibilidad más simple antes que causas complejas
- También en diseño de arquitectura: antes de agregar capas innecesarias de abstracción, hay que explorar primero la solución más simple
48. Falacia del costo hundido (Sunk Cost Fallacy)
La tendencia a mantener una decisión perjudicial solo porque ya se invirtió tiempo o energía en ella
- Incluso si una funcionalidad desarrollada durante 6 meses iba en la dirección equivocada, existe la tendencia psicológica de no poder descartarla por el tiempo invertido
- La decisión correcta debe basarse en el valor futuro, no en la inversión pasada
49. El mapa no es el territorio (The Map Is Not the Territory)
Una representación de la realidad (modelo) no es lo mismo que la realidad en sí
- Los diagramas UML, la documentación de arquitectura y los modelos de datos son solo aproximaciones de la realidad
- No hay que confiar ciegamente en el modelo; hay que observar cómo funciona el sistema real y actualizar el modelo en consecuencia
50. Sesgo de confirmación (Confirmation Bias)
La tendencia a preferir información que respalda creencias o ideas previas
- Es la trampa de recopilar selectivamente solo información favorable al stack tecnológico o a la decisión de diseño que uno ya eligió
- Buscar activamente evidencia en contra y aceptar distintas perspectivas es clave para una toma de decisiones equilibrada
51. El Hype Cycle y la ley de Amara (The Hype Cycle & Amara's Law)
Existe una tendencia a sobreestimar los efectos de la tecnología a corto plazo y subestimar su impacto a largo plazo
- El Hype Cycle de Gartner: disparador tecnológico → pico de expectativas sobredimensionadas → valle de la desilusión → pendiente de la iluminación → meseta de productividad
- Al adoptar nuevas tecnologías (blockchain, IA, etc.), no hay que dejarse arrastrar por el sobrecalentamiento de corto plazo; hay que evaluar su utilidad práctica a largo plazo
52. Efecto Lindy (The Lindy Effect)
Cuanto más tiempo se ha usado algo, más probable es que siga usándose en el futuro
- Tecnologías usadas durante décadas, como UNIX, SQL y el lenguaje C, tienen altas probabilidades de seguir vigentes por mucho tiempo
- Es una base teórica para elegir tecnologías probadas en lugar de frameworks nuevos
- Nassim Nicholas Taleb lo popularizó en Antifragile
53. Pensamiento desde primeros principios (First Principles Thinking)
Una forma de pensar que descompone un problema complejo en sus componentes más básicos y luego lo reconstruye a partir de ellos
- Elimina prácticas y supuestos existentes, y parte de verdades fundamentales para llegar a una solución
- Es conocido por el caso de Elon Musk aplicándolo a la reducción de costos de los cohetes de SpaceX
- Al diseñar sistemas complejos, hay que desconfiar del pensamiento de “siempre se ha hecho así”
54. Inversión (Inversion)
Un método para resolver problemas imaginando el resultado opuesto y razonando en sentido inverso
- En vez de pensar “¿cómo tener éxito?”, conviene pensar primero “¿cómo fracasar?” para identificar factores de riesgo
- Es la base teórica del análisis de modos de falla (Failure Mode Analysis) y del pre-mortem
- Es un modelo mental que Charlie Munger usa con frecuencia
55. Principio de Pareto / regla 80/20 (Pareto Principle)
El 80% de los problemas proviene del 20% de las causas
- Existe una tendencia a que el 80% de los bugs se concentre en el 20% del código
- Concentrar recursos en el 20% de mayor impacto es una estrategia eficiente de asignación de recursos
- Se origina en un principio que Vilfredo Pareto observó en la distribución de la propiedad de la tierra en Italia
56. Ley de Cunningham (Cunningham's Law)
La mejor manera de obtener una respuesta correcta en internet no es hacer una pregunta, sino publicar una respuesta equivocada
- La gente participa más activamente en corregir información incorrecta que en responder preguntas
- Aunque la ley lleva el nombre de Ward Cunningham (inventor de la wiki), en realidad fue Steven McGeady quien le dio ese nombre
- Es una idea útil que puede aprovecharse para la documentación y el intercambio de conocimiento en comunidades open source
2 comentarios
Opiniones de Hacker News
Me molesta especialmente la frase de que la "optimización prematura es la raíz de todos los males". Esa frase salió en el contexto de 1974 y parte de supuestos distintos a los de hoy. En ese entonces optimizar era algo más cercano a ensamblador y contar ciclos, pero hoy el rendimiento es sobre todo una cuestión de elección de arquitectura, así que hay que pensarlo desde el inicio. El consejo de usar profiling para detectar bugs de rendimiento accidentales como un O(n²) sigue siendo válido, pero cuando el costo de las abstracciones ya se volvió el cuello de botella, es fácil terminar agregando caché y paralelismo encima y acabar con un sistema más complejo y más lento. Hoy veo la optimización tardía como algo igual de malo que la optimización prematura, o quizás peor
ConcurrentHashMapporque después tal vez terminemos en un contexto multihilo, y en la mayoría de los casos la diferencia de rendimiento no es grande. Pero luego un PR se bloquea porque "HashMap es más rápido" y se arma una discusión interminable. Mejor enfocarse en cosas que sí cambian lo que siente el usuario, como 40 llamadas bloqueantes a PostgreSQL o requests web innecesarias. Dicho eso, sí me parece totalmente razonable optimizar temprano a nivel de algoritmosMe da pena que falte Curly's Law. Una variable debería tener un solo significado, y no guardar valores de dominios distintos según el contexto ni cumplir dos funciones al mismo tiempo. La analogía de no ser "cera para pisos y topping de postre" le queda perfecta
Siento que cuando juntas todas estas "leyes" del software, hay tanta contradicción interna entre ellas que al final se vuelve muy fácil escoger la frase que mejor justifique lo que ya querías defender. Lo difícil de verdad es saber cuándo romper una ley, y por qué hacerlo
Como ley de ingeniería de software edición 2026, me gustaría bromear con que todos los sitios web van a estar hechos con vibe coding usando Claude Opus. El resultado va a ser un fondo en tono crema que recuerde a Anthropic, una mezcla exagerada de fuentes y grosores como si alguien que apenas empieza en diseño acabara de descubrir la tipografía, y una sobreabundancia de card UI con patrones repetidos como bordes redondeados de color en un solo lado de la tarjeta
También creo que debería estar Boyd's Law of Iteration. La idea es que al lidiar con complejidad, la iteración rápida muchas veces da mejores resultados que el análisis profundo, y sabiendo además que Boyd fue quien creó el OODA loop, suena todavía más potente
Creo que entre los comentarios borrados había una mejor meta-ley para este texto. Decía algo como: "todas las leyes de ingeniería de software se malinterpretan de inmediato y se aplican sin crítica de formas que horrorizarían a su autor original". Viendo cómo se comportan los LLM a los que les falta el contexto clave, se entiende todavía mejor por qué pasa eso. Al final, hay un límite para comprimir décadas de sabiduría y experiencia en una sola frase memorable
Si ya iban a hacer vibe coding de un sitio entero de "leyes de ingeniería de software", me gustaría preguntar qué ley violaron al no hacer simplemente una página en Wikipedia
Ojalá este tipo de cosas fuera cultura general básica al nivel de un requisito de contratación. Se siente como algo que todo el mundo debería conocer
Aunque no sea una ley exclusiva del software, yo suelo enseñar Chesterton's Fence primero que nada a interns y juniors
Siento que la ley de conservación de la complejidad de Tesler ya da una intuición potente solo con la frase. Dice que toda aplicación tiene una complejidad inherente que no se puede eliminar, solo mover. Pero cuando entras a la explicación, al final parece reducirse al consejo bastante común de molestar menos al usuario. El usuario igual termina cargando con el nivel de complejidad necesario, y si lo reduces sin criterio, es fácil terminar con un juguete sin flexibilidad. Por eso me parece más útil recordar, al refactorizar, que si simplificas una parte, otra puede volverse más compleja
Cuando haces
vibe coding, en el momento está bien, pero al final parece que termina regresando como karma...