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.
• Una abstracción útil, una solución compartida para un problema que se repite, puede ahorrarle ese trabajo a todo el equipo.
• Construir bien esa base permite que el equipo agregue funcionalidades sin resolver el mismo problema cada vez.

Un motor de edición para distintos tipos de contenido

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 busca el valor correcto dentro de la estructura del contenido. Agregar un tipo de sección nuevo pasó a ser una fila más en ese mapa. Ninguna pantalla nueva que programar.

En Alohub, el framework basado en un motor de edición compartido redujo en 75% el tiempo de desarrollo de 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 podía resolver también pedidos parecidos, 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.

Una base sobre la que el equipo podía construir

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.

Esa era la intención: darle al equipo de 7 una base para agregar secciones sin volver a construir el editor cada vez.

Un motor de edición compartido le ahorró al equipo construir un panel por cada tipo de sección nuevo.

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 una solución compartida) 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á. 🙂