Post actualizado el día octubre 29, 2026 by DeiviSanzPlay
Un equipo pequeño de desarrollo freelance aceptó un encargo para una clínica veterinaria. Necesitaban un buscador de historiales clínicos dentro de su sistema interno. Nada del otro mundo, en teoría. El programador principal escribió una función que recorría la lista completa de pacientes por cada consulta y, dentro, volvía a recorrer las visitas asociadas. Con trescientos registros de prueba iba rápido. El algoritmo Big O notación era O(n²), pero nadie se paró a pensarlo. Al año, la clínica tenía miles de historiales y el buscador tardaba casi un minuto en devolver resultados. La recepcionista empezó a usar Ctrl+F sobre un Excel exportado. Ahí empezó el problema real.
Este caso resume por qué entender la complejidad algorítmica no es un tema de entrevistas técnicas ni de académicos. Es algo que afecta a una web, a una app interna o a un script casero que alguien dejó corriendo. La notación Big O describe cómo crece el tiempo o la memoria de un algoritmo cuando crece la entrada. No mide segundos exactos: mide la forma de la curva.
Qué mide realmente la complejidad algorítmica
La idea central es simple: si doblas los datos, ¿cuánto más tarda? Un algoritmo O(n) tarda el doble. Uno O(n²) tarda el cuádruple. Uno O(log n) apenas crece. Esa diferencia, invisible con veinte registros, se vuelve brutal con cien mil.
En el caso de la clínica, el bucle anidado multiplicaba el trabajo por cada paciente nuevo. Con la notación Big O aplicada al análisis, el equipo habría visto el problema en una servilleta antes de escribir la primera línea. No hace falta ser matemático: basta con preguntarse qué pasa si la lista se multiplica por diez.
Hay un matiz que casi nadie menciona: Big O describe el peor caso asintótico, no el comportamiento promedio. Un algoritmo puede ser O(n²) en teoría y funcionar bien en la práctica si los datos vienen casi ordenados. Eso no lo salva de un día malo.
El error doméstico que casi nadie detecta
No todo pasa en empresas. Un usuario aficionado montó un pequeño script en Python para ordenar y renombrar las fotos de su familia por fecha. Usaba una búsqueda lineal dentro de un bucle para localizar duplicados. Con dos mil fotos tardaba unos segundos. Cuando acumuló veinte mil, el ordenador se quedaba minutos con el ventilador a tope. Pensó que era el disco. Era complejidad algorítmica.
La solución típica —usar un diccionario o un conjunto para búsquedas O(1)— reduce el tiempo de forma drástica, pero no siempre está disponible si el lenguaje o la librería no lo permiten con comodidad. Ahí entra otra limitación: la notación Big O no dice nada sobre constantes. Un O(n) con operaciones carísimas puede perder contra un O(n log n) bien optimizado en entradas pequeñas.
Dónde falla aplicar solo la teoría
Esto no funciona para todo. Si tu conjunto de datos es pequeño y estable, optimizar la complejidad algorítmica es perder el tiempo. Un script que procesa cincuenta filas al día no necesita ordenaciones sofisticadas. La notación Big O importa cuando el volumen crece, cuando el usuario espera, o cuando el coste se multiplica por peticiones concurrentes.
También hay que desconfiar de quien reduce todo a O(1) como si fuera magia. El acceso a un diccionario es O(1) promedio, pero puede degradarse con colisiones. La memoria también cuenta: un algoritmo rapidísimo en tiempo puede consumir RAM hasta tumbar el servidor. Big O cubre tiempo y espacio, pero rara vez se analizan los dos a la vez.
Cómo detectar el problema antes de que explote
La práctica más útil no es memorizar tablas, sino mirar los bucles anidados y preguntar qué estructura de datos se recorre por dentro. Un bucle dentro de otro sobre la misma colección es sospechoso. Un `find` dentro de un `map` también. Esas son las señales típicas de un O(n²) disfrazado.
Para el equipo de la clínica, la corrección fue indexar los historiales por identificador y usar una búsqueda directa. Pasaron de casi un minuto a una fracción de segundo. No cambió el lenguaje ni el servidor. Cambió la forma de pensar el algoritmo.
Si algo saco en claro tras ver casos así es que la notación Big O no es una etiqueta académica: es una herramienta de olfato. Te dice cuándo un código que hoy va bien mañana será un problema. Y en la mayoría de incidentes reales, el fallo no fue de infraestructura. Fue de no haber hecho esa pregunta incómoda antes de desplegar.
Perfiles verificables: Sitio web
Publicado el 29 de October de 2026. Última revisión: 29 de October de 2026.
