Por qué construí un motor genérico en vez de otro panel más

¿Alguna vez lideraste un equipo y notaste que, una y otra vez, todos terminaban construyendo casi lo mismo, solo que para un caso distinto? En algún momento tienes que decidir: ¿seguimos armando uno más a medida, o paramos a construir la herramienta que saca a todo el equipo de ese ciclo?

Entre 2021 y 2023 fui desarrollador frontend senior y líder técnico de un equipo de 7 personas en Alohub, una plataforma que le construía su sitio web a inmobiliarias. Cada inmobiliaria quería su propia marca, sus propias secciones y su propio diseño, y alguien de mi equipo tenía que construir, sección por sección, la pantalla donde esa inmobiliaria pudiera editar su contenido.

Al principio eso funcionaba bien. Pero después del segundo o tercer tipo de sección nuevo, vi hacia dónde íbamos: si seguíamos así, mi equipo iba a pasar los siguientes años construyendo un panel de edición distinto por cada tipo de contenido que a un cliente se le ocurriera pedir.

Lo que me llevé

• Un patrón que se repite 2 veces todavía puede ser casualidad. La tercera vez ya es una señal de que hay algo que construir de una sola vez.
• La abstracción correcta no le ahorra trabajo a una persona. Le ahorra el mismo trabajo, para siempre, a todo un equipo.
• Construir bien la pieza difícil una sola vez es lo que le permite al resto del equipo entregar rápido después, sin volver a pensarla.

El motor que reemplazó un panel nuevo por una fila en un mapa

En vez de construir un panel a medida por cada tipo de sección, construí un motor genérico: unos 15 controles reutilizables, un mapa que dice qué control edita qué campo, y una función que recorre cualquier ruta del contenido hasta encontrar el valor correcto. Agregar un tipo de sección nuevo pasó a ser una fila más en ese mapa. Ninguna pantalla nueva que programar.

Ese motor es el núcleo del mismo framework que después le ahorró al equipo un 75% del tiempo de desarrollo en cada sitio nuevo.

¿Por qué no simplemente construir el panel que pedían?

Porque construir un panel más solo resuelve ese pedido puntual. El motor genérico resuelve todos los pedidos que todavía no habían llegado, pero recién tenía sentido construirlo cuando el patrón ya se había repetido lo suficiente para confiar en que iba a seguir apareciendo. Construirlo desde el primer pedido hubiera sido apostar a ciegas.

Lo que hizo posible que mi equipo avanzara sin mí

Una vez que el motor existía, agregar un tipo de sección nuevo dejó de ser un proyecto de varios días para pasar a ser una entrada en un mapa y una pantalla que ya existía.

Eso es lo que de verdad estaba resolviendo con esa decisión. No mi propio trabajo: el de las 7 personas que dependían de esa base para poder avanzar rápido después.

No estaba tratando de ahorrarme trabajo a mí. Estaba tratando de ahorrarle el mismo trabajo, para siempre, a todo un equipo.

La misma regla, ahora escrita para toda mi fábrica

Esa decisión (esperar a que el patrón se repita, y recién ahí construir la única pieza que lo resuelve para siempre) hoy no vive solo en mi memoria de lo que aprendí en Alohub.

La escribí como una regla real: no abstraer antes de la tercera repetición, tolerar la segunda copia. Es una de las reglas de ingeniería que aplico en cada proyecto que construyo ahora, incluyendo este mismo sitio.

Tolerar la segunda copia sale más barato que construir la abstracción equivocada.

Si lideras un equipo, tarde o temprano te va a tocar decidir entre construir otro parche más o parar a construir la pieza que los saca del ciclo. Yo aprendí a mirar la tercera vez que pasa algo, no la primera. Gracias por leer hasta acá. 🙂