Hay una habilidad que separa a quien lleva dos años programando de quien lleva diez, y no es saber más frameworks: es poder nombrar lo que está pasando. Cuando puedes decir “esto es scope creep” o “estás haciendo yak shaving”, dejas de sufrir el problema y empiezas a manejarlo. Nombrar es el primer paso para evitar. Estos son los conceptos y leyes que más cambian la forma de trabajar en cuanto los tienes en el vocabulario.
I. Foco — la tentación de hacer de más
La mayoría del tiempo perdido no se va en bugs difíciles. Se va en hacer cosas que parecían necesarias y no lo eran.
1. Yak Shaving
Ibas a cambiar el color de un botón. Para eso tuviste que actualizar el componente; para eso, subir la versión de la librería; eso rompió el build; arreglarlo te pidió migrar la config de Node… y dos horas después no recuerdas qué tenía el botón. Eso es yak shaving: la cadena de subtareas que te aleja del objetivo real, cada una “necesaria” para la anterior.
Qué hacer: cuando notes que bajaste tres niveles, para y pregúntate si el objetivo original sigue valiendo el desvío. A veces sí —el yak hay que afeitarlo—; lo peligroso es no darte cuenta de que lo estás haciendo. Apunta el desvío y vuelve.
2. Scope Creep
El clásico “ya que estamos…”. Cada pequeña funcionalidad parece inofensiva, pero se acumulan hasta convertir un proyecto de dos semanas en un monstruo de seis meses. El scope creep no entra por la puerta; se cuela por las rendijas, una petición razonable a la vez.
Qué hacer: límites explícitos. Define qué entra y, sobre todo, qué no entra. “Buena idea — al backlog para la v2” es una de las frases más valiosas que puede decir un equipo. Lo nuevo no es gratis: cada función que sumas es código que mantener para siempre.
3. Bikeshedding (la ley de la trivialidad)
Una junta de dos horas: cinco minutos para aprobar un presupuesto de un millón, una hora y media discutiendo el color de un botón. La ley de la trivialidad de Parkinson dice que el tiempo que un grupo dedica a un tema es inversamente proporcional a su importancia — porque todos opinan de lo trivial y nadie se atreve con lo complejo.
Qué hacer: detéctalo en code reviews y reuniones. Si la discusión más larga es sobre lo más fácil de cambiar, redirige la energía a lo que de verdad es difícil de deshacer.
4. Optimización prematura
Hacer el código “más eficiente” antes de saber si hay un problema real de rendimiento. El resultado casi siempre es código más complejo, más difícil de leer y mantener, para resolver un cuello de botella que nunca existió.
La optimización prematura es la raíz de todos los males.
— Donald Knuth
Qué hacer: primero correcto y claro; después, si mides un problema, rápido. Optimizas lo que el profiler te señala, no lo que tu intuición teme. Es la otra cara de KISS y la navaja de Ockham: no añadas complejidad que no te han pedido los datos.
5. YAGNI — You Aren’t Gonna Need It
El primo hermano del punto anterior. Construyes hoy una capa de abstracción “por si algún día necesitamos soportar cinco bases de datos”. Spoiler: nunca las necesitas, y mientras tanto cargas con el peso de mantener flexibilidad que nadie usa. YAGNI, de la programación extrema, dice: no lo construyas hasta que lo necesites de verdad.
Qué hacer: distingue entre el código que el problema exige y el que tu imaginación anticipa. Lo tratamos a fondo en DRY, YAGNI y la regla del Boy Scout: la simplicidad de hoy es flexibilidad para mañana, no al revés.
II. Costo — la factura que llega después
Casi ninguna mala decisión cobra de inmediato. Cobra intereses.
6. Deuda técnica
La metáfora la acuñó Ward Cunningham: una solución rápida y sucia es como pedir un préstamo. Te deja avanzar hoy, pero contraes una deuda que pagarás con intereses cada vez que toques ese código. Cuanto más tardas en refactorizar, más caro sale el siguiente cambio.
Qué hacer: no toda deuda es mala —a veces endeudarte para llegar a una fecha es la decisión correcta—. Lo grave es la deuda no reconocida. Anótala, ponle un “interés” visible y paga la más cara antes de que te paralice un módulo entero.
7. La regla del Boy Scout
“Deja el campamento más limpio de como lo encontraste.” Aplicada al código (la popularizó Robert C. Martin): cada vez que tocas un archivo, déjalo un poco mejor — un nombre más claro, una función partida, un comentario que sobraba. No se trata de grandes refactors, sino de frenar la entropía con micro-mejoras constantes. Es el antídoto diario contra la deuda técnica.
Qué hacer: que sea parte del flujo, no un proyecto aparte. Lo desarrollamos junto a sus hermanas en los principios de Uncle Bob que sí aguantan.
8. La regla del 90/90
El primer 90% del código se lleva el 90% del tiempo. El 10% restante se lleva el otro 90% del tiempo.
— Tom Cargill (Bell Labs)
Suena a chiste hasta que llevas la cuenta. Lo “casi terminado” suele estar a mitad de camino, porque los últimos detalles —casos borde, errores, pulido, despliegue— esconden el trabajo de verdad. Es pariente de la ley de Hofstadter: siempre lleva más tiempo del que esperas, incluso contando con la ley de Hofstadter.
Qué hacer: desconfía del “ya casi”. Mete el caso borde y el despliegue en la estimación desde el principio, no como un apéndice.
III. Personas y conocimiento — el software lo hace gente
El código no es el único sistema que mantienes. El equipo también.
9. Bus Factor
La pregunta incómoda: ¿cuántas personas tendrían que ser atropelladas por un autobús (o, menos dramático, irse de vacaciones o renunciar) para que el proyecto se detenga? Si la respuesta es 1, tienes un punto único de fallo con forma de persona.
Qué hacer: comparte conocimiento de forma deliberada. Pair programming, documentación honesta, rotación de quién toca qué, y revisar que ninguna parte crítica viva solo en la cabeza de una persona. Un equipo con bus factor alto duerme tranquilo.
10. Ley de Conway
Las organizaciones que diseñan sistemas están condenadas a producir diseños que copian la estructura de comunicación de la organización.
— Melvin Conway (1968)
Si tienes cuatro equipos, vas a terminar con cuatro módulos — aunque el problema pidiera tres o cinco. Tu arquitectura es un espejo de tu organigrama, te guste o no.
Qué hacer: la “maniobra inversa de Conway” — si quieres cierta arquitectura, organiza los equipos para que la favorezcan. Las fronteras de tus equipos serán las fronteras de tu sistema.
11. Ley de Brooks
Añadir gente a un proyecto de software retrasado lo retrasa todavía más.
— Fred Brooks, The Mythical Man-Month
Contraintuitivo pero real: meter cinco personas nuevas a un proyecto que va tarde no lo acelera. Hay que formarlas, la comunicación crece de forma cuadrática (más gente = más canales que coordinar), y los que saben pierden tiempo explicando en vez de avanzando. Nueve mujeres no tienen un bebé en un mes.
Qué hacer: ante un retraso, antes de sumar gente, recorta alcance (scope creep al revés) o ajusta la fecha. Sumar personas es una palanca lenta, no rápida.
12. Rubber Duck Debugging
Llevas una hora atascado en un bug. Le explicas el código, línea por línea, a un compañero — o a un patito de goma sobre tu escritorio —, y a media frase… lo ves. El error estaba ahí todo el tiempo. Verbalizar la lógica te obliga a hacer explícito lo que tu cabeza daba por hecho, y ahí es donde se esconden los bugs.
Qué hacer: cuando te trabes, explícalo en voz alta antes de pedir ayuda. La mitad de las veces resuelves solo; la otra mitad, llegas a tu compañero con la pregunta ya bien formulada. (Lo popularizó The Pragmatic Programmer.)
IV. Humildad — entiende antes de tocar
Las trampas más caras no son por saber poco, sino por creer que entiendes algo que no.
13. Cargo Cult Programming
El nombre viene de los “cultos cargo” del Pacífico que, tras la guerra, construían pistas y torres de bambú esperando que volvieran los aviones con suministros. Copiaban la forma sin entender la causa. En código es igual: copias un patrón, una arquitectura o un fragmento de Stack Overflow porque “lo hacen los pros”, sin entender por qué — y arrastras complejidad que no necesitas o que ni siquiera aplica a tu caso.
Qué hacer: no imites, entiende. Antes de pegar ese microservicio, esa abstracción o ese decorador, responde: ¿qué problema resuelve, y yo lo tengo? El término lo inspiró Richard Feynman con su idea de “cargo cult science”.
14. La valla de Chesterton
Encuentras una valla en medio del campo que no parece servir para nada. El reformador impaciente dice “no le veo sentido, quitémosla”. Chesterton responde: si no entiendes para qué está, no la quites — primero averigua por qué la pusieron; quizá había una razón muy buena.
En código es ese if raro, ese // no tocar, esa espera de 200ms que alguien puso “sin motivo”. Casi siempre hubo un motivo, y casi siempre fue un incidente en producción.
Qué hacer: antes de borrar lo que no entiendes, investiga su historia (git blame es tu amigo). Entiende la valla antes de tumbarla.
15. Ley de Gall
Un sistema complejo que funciona, invariablemente, evolucionó de un sistema simple que funcionaba.
— John Gall
El corolario muerde: un sistema complejo diseñado desde cero, complejo, nunca funciona y no puedes parchearlo para que funcione; tienes que empezar de un sistema simple. Es la razón por la que el “gran rediseño desde cero” tan seductor casi siempre fracasa.
Qué hacer: empieza simple, ponlo a funcionar, y deja que la complejidad llegue solo cuando la realidad la exija. Es justo el espíritu de “worse is better”: un sistema simple que existe le gana a uno perfecto que no.
Por qué nombrar esto te hace mejor
Ninguno de estos conceptos es un truco técnico. Son lentes: formas de ver lo que ya te estaba pasando. El junior afila el yak sin saberlo; el senior lo nombra, decide si vale la pena y sigue. El junior optimiza por miedo; el senior mide. El junior copia; el senior entiende.
Y casi todos comparten una misma raíz: la disciplina de hacer lo justo, entender antes de actuar, y no dejar que la complejidad entre gratis. Si ese criterio es el que quieres en quien construye tu software, es exactamente lo que hacemos — y si tienes un proyecto donde estos nombres ya te suenan demasiado familiares, hablémoslo.
Referencias
- Fred Brooks — The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975) — ley de Brooks.
- Melvin E. Conway — How Do Committees Invent? (Datamation, 1968) — ley de Conway.
- Donald E. Knuth — Structured Programming with go to Statements (1974) — la cita sobre optimización prematura.
- Ward Cunningham — la metáfora de la deuda técnica (1992).
- C. Northcote Parkinson — Parkinson’s Law (1957) — ley de la trivialidad (bikeshedding).
- John Gall — Systemantics / The Systems Bible — ley de Gall.
- G. K. Chesterton — The Thing (1929) — la parábola de la valla.
- Andrew Hunt & David Thomas — The Pragmatic Programmer — rubber duck debugging y la teoría de las ventanas rotas.
- Robert C. Martin — Clean Code — la regla del Boy Scout.
- Richard P. Feynman — Cargo Cult Science (1974) — origen del término.