Bicicleta en programación: qué es, causas y cómo evitarla

Qué es una bicicleta en programación

Bicicleta es un término de la comunidad de desarrolladores que se refiere a crear tu propia implementación de una funcionalidad ya disponible como biblioteca, framework o servicio. En el mundo angloparlante se usa la expresión reinventing the wheel — reinventar la rueda.

El origen de la metáfora se relaciona con que la rueda es uno de los inventos más antiguos de la humanidad. Intentar crearla de nuevo en el siglo XXI no tiene sentido. En programación, la analogía es aún más precisa: las bibliotecas listas son “ruedas” que han sido optimizadas por miles de ingenieros durante años. Crear tu propia rueda de calidad inferior es un desperdicio de recursos.

RedMonk en un informe analítico (2023) calculó que una aplicación comercial promedio usa alrededor de 500 dependencias externas. Si los desarrolladores tuvieran que escribir cada una de ellas por separado, el costo del proyecto se multiplicaría por diez y el tiempo de comercialización se alargaría años. El ecosistema de gestores de paquetes (npm, Maven, PyPI, NuGet) existe precisamente para evitar reinventar la rueda.

Señales de una bicicleta

El código que es una bicicleta se reconoce por varias señales: resuelve un problema estándar de forma no estándar, no tiene pruebas ni documentación, y no maneja casos extremos que ya están contemplados en bibliotecas listas. A menudo ese código se escribe pensando en “requisitos únicos” del proyecto, cuando en realidad esos requisitos no difieren de los típicos.

Diferencia entre bicicleta y solución personalizada

Una solución personalizada se justifica cuando una biblioteca lista no encaja por limitaciones arquitectónicas o de licencia. Una bicicleta se crea sin razones objetivas — por ganas de “probar,” desconfianza del código ajeno o desconocimiento de las herramientas existentes. La diferencia es fundamental: lo personalizado es una elección consciente, la bicicleta es un error.

Por qué los desarrolladores reinventan la rueda

La primera y más común razón — el desconocimiento de las soluciones existentes. Un desarrollador junior puede no saber que la biblioteca estándar tiene una función incorporada para analizar JSON. En lugar de eso, escribirá un analizador manualmente. Este problema es especialmente relevante para principiantes que recién entran en el ecosistema del lenguaje.

La segunda razón es la ilusión de control. Los desarrolladores experimentados a veces están convencidos de que “pueden escribir algo mejor” que los autores de una biblioteca popular. Las estadísticas dicen lo contrario: la probabilidad de un error en una biblioteca usada por millones de proyectos es significativamente menor que en código recién escrito. Según Synopsys (2024), el código de código abierto contiene en promedio 0.1 errores por cada mil líneas, mientras que el código corporativo tiene 1–2.

La tercera razón es la falta de cultura de reutilización. En empresas donde no se acostumbra investigar las soluciones existentes antes de empezar a trabajar, cada desarrollador crea “su propia bicicleta.” Esto lleva a la fragmentación del código: en un proyecto puede haber tres implementaciones diferentes de un cliente HTTP escritas por distintos empleados.

Aspectos psicológicos

El efecto IKEA es un fenómeno psicológico por el cual una persona valora lo que ha creado por sí misma por encima de cosas ya hechas objetivamente mejores. En programación, esto se manifiesta como orgullo por “tu propia bicicleta” y falta de voluntad para reemplazarla con una biblioteca lista incluso cuando esta tiene ventajas evidentes.

Consecuencias de crear bicicletas en un proyecto

Las consecuencias económicas son las más obvias. Según una estimación de Stripe (2022), los desarrolladores pasan hasta el 35% de su tiempo laboral creando código que ya existe como soluciones listas. Para un equipo de 10 personas, esto equivale a unos 200.000 dólares al año gastados en reinventar la rueda.

Las consecuencias técnicas incluyen el crecimiento de la base de código, la reducción de la cobertura de pruebas (el código propio suele probarse peor) y un aumento de errores y vulnerabilidades. Además, cada componente propio es un punto de fallo más que hay que monitorizar y mantener.

Google en su estudio “Why Google Stores Billions of Lines of Code” (2023) señaló que incluso en la empresa tecnológica más grande existe un proceso estricto de toma de decisiones para añadir una nueva dependencia o escribir una implementación propia. La mayoría de los equipos internos primero buscan una solución ya hecha en el repositorio único de código.

Impacto en el equipo

Las bicicletas crean asincronía informativa: cuando un desarrollador se va, su componente propio queda sin documentación ni soporte. Los nuevos miembros del equipo tienen que entender código no estándar, perdiendo tiempo que podrían usar en trabajo productivo.

Ejemplos de bicicletas comunes en código

El ejemplo más común es el análisis manual de JSON o XML, aunque casi todos los lenguajes modernos tienen herramientas incorporadas. Los desarrolladores escriben funciones recursivas para recorrer árboles de objetos, sin saber que JSON.parse() resuelve el problema en una línea.

Un segundo ejemplo es una implementación propia de un cliente HTTP. Las bibliotecas estándar (fetch, axios, OkHttp, URLSession) soportan caché, reconexión, tiempos de espera y seguridad. Un cliente propio normalmente no cumple al menos uno de estos requisitos, lo que provoca errores en producción.

Un tercer ejemplo es un sistema de registro propio en lugar de usar SLF4J, Winston o Log4j. Un desarrollador pasa semanas escribiendo lo que las bibliotecas listas hacen de serie con soporte para rotación, niveles de registro, escritura asíncrona e integración con sistemas de monitoreo.

# bicicleta — análisis manual de CSV
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# usando la biblioteca estándar en su lugar
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

Antipatrón: ORM propio

Escribir tu propio ORM (Object-Relational Mapping) es quizá la bicicleta más cara. Los ORM ya hechos como Hibernate, Entity Framework o SQLAlchemy se han desarrollado durante años, soportando caché, carga perezosa, migraciones y docenas de bases de datos. Un ORM propio suele limitarse a una base de datos y contiene errores críticos en la gestión de conexiones.

Cuándo está justificada una bicicleta

El aprendizaje es la única situación en la que una bicicleta no solo está justificada sino que es útil. Escribir tu propio analizador, servidor HTTP u ORM con fines educativos ayuda a entender cómo funcionan estas herramientas internamente. Es importante no confundir un proyecto de aprendizaje con código de producción: lo que es bueno para un pet-project es inaceptable en el desarrollo comercial.

Los requisitos únicos pueden requerir una implementación propia. Si ninguna biblioteca soporta un protocolo, formato de datos o plataforma de hardware específicos, crear una solución personalizada está justificado. Pero antes hay que asegurarse de que la tarea es realmente única y no solo mal investigada.

Las restricciones de licencia son otra razón legítima. Algunas licencias de código abierto (GPL, AGPL) pueden ser incompatibles con el modelo de negocio de una empresa. En tales casos, desarrollar tu propia implementación con una licencia más permisiva está justificado.

La regla de tres intentos

Existe una regla práctica: antes de escribir tu propia implementación, intenta encontrar y probar tres soluciones ya hechas diferentes. Si ninguna encaja, crea la tuya, pero documenta por qué se rechazaron las opciones existentes. Esto protege de reinventar la rueda inconscientemente.

Cómo evitar crear bicicletas

El primer paso es formar el hábito de buscar soluciones ya hechas antes de empezar cualquier tarea estándar. Usa búsquedas en gestores de paquetes, GitHub, Stack Overflow. El tiempo dedicado a investigar se amortiza muchas veces al evitar escribir código propio.

El segundo paso es implantar revisiones de código centradas en detectar bicicletas. En la revisión, pregunta: “¿Por qué no usamos una biblioteca ya hecha para esta tarea?” Si la respuesta no contiene razones objetivas, es una bicicleta. En grandes empresas (Google, Meta), la revisión de código incluye un punto obligatorio para detectar la reinvención de la rueda.

El tercer paso es crear un registro interno de conocimiento. Documenta qué bibliotecas y herramientas se usan en el proyecto y qué tareas resuelven. Los nuevos desarrolladores deben tener acceso a esta información para no crear bicicletas por desconocimiento. Mantén una lista de Decisiones de Arquitectura (ADR) con la justificación de cada elección.

• Investiga el gestor de paquetes antes de empezar una nueva tarea
• Revisa la biblioteca estándar del lenguaje — cubre el 80% de las tareas típicas
• Usa la revisión de código para detectar bicicletas
• Documenta las decisiones sobre la elección de bibliotecas
• Actualiza tus conocimientos del ecosistema en conferencias y blogs

Síndrome de No Inventado Aquí

El síndrome NIH (Not Invented Here) es un sesgo organizativo contra el uso de soluciones externas. Las empresas con síndrome NIH prefieren desarrollar todo internamente, rechazando las bibliotecas de código abierto incluso cuando superan a sus propios desarrollos. Este síndrome es la versión corporativa de la bicicleta.

Un ejemplo clásico es Netscape a finales de los 90, cuando la empresa pasó años reescribiendo el navegador desde cero en lugar de evolucionar la base de código existente. El resultado — pérdida de cuota de mercado y absorción por AOL. Por el contrario, Android se construyó sobre el núcleo Linux y usa miles de componentes de código abierto — esto permitió sacar el producto al mercado en un tiempo récord.

Un estudio de Harvard Business Review (2023) mostró que las empresas con bajo nivel de síndrome NIH lanzan productos al mercado un 40% más rápido y gastan un 30% menos en desarrollo. La cultura de reutilización de código es una ventaja competitiva en el desarrollo moderno.

// bicicleta — implementación de ordenación personalizada
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// ordenación incorporada — solución estándar
arr.sort((a, b) => a - b);