¿Cómo generar deuda técnica en dos horas?

Cuando las verdades más absolutas fallan

La semana pasada estuvimos refinando un caso de uso sencillo. ¿Cómo asignar una factura de la luz a una casa utilizando el campo CUPS (Código Unificado de Punto de Suministro) de ambos objetos?

Nos llevamos enfrentando a este problema desde el primer día que creamos Clevergy. ¿Cómo asocio los consumos a una casa? ¿Cómo asocio los electrodomésticos a una casa? ¿Cómo asocio un enchufe inteligente a una casa? …

Para crear la relación entre las casas y las facturas, la solución parece obvia:

• Creas un campo CUPS a la tabla casas

• Creas un campo CUPS a la tabla facturas

• A partir de ahí puedes hacer una query con un INNER JOIN por el campo CUPS y para obtener un listado de todas las casas con sus facturas

Si este desarrollo lo hubiéramos hecho hace un año, no nos habríamos complicado más. Las casas ya tienen un campo CUPS. Creamos una tabla nueva con los datos que necesitamos de la factura con ese campo CUPS, exponemos vía API los datos y los mostramos en la aplicación.

De hecho, hace dos años definimos el CUPS como identificador único de la casa para estandarizar nuestro ID de las casas con el del mercado. Usar el CUPS tenía dos ventajas muy claras:

• Es un campo único en toda España

• Nuestros clientes y proveedores lo utilizan

Y vivimos felizmente durante casi 18 meses. Durante 18 meses, todas nuestras casas usaban ese identificador único que habíamos adoptado de las distribuidoras. Durante el camino nos encontramos con alguna anomalía, como el hecho de que en algunos sitios se utilizan 20 caracteres, y en otros se añaden dos caracteres extra con el denominado Punto de Frontera, el cual a efectos prácticos puedes obviar. Pero quitando estos pequeños matices, en los distintos clientes, sistemas y proveedores con los que interactuábamos el CUPS nos servía como identificador único.

Después de haber construido toda la plataforma con el CUPS como identificador central de todas las peticiones y consultas que hacíamos, nos encontramos con un problema.

¿Qué pasa cuando no tenemos el CUPS de la casa? Esto nos empezó a pasar en distintas situaciones:

• En el onboarding, antes de conectar los consumos, necesitábamos una casa “vacía” para guardar la configuración de la casa

• A la hora de dar de alta una casa con dispositivos, pero sin conectarnos a las distribuidoras

• En otros países

Parecía que el Código Unificado de Punto de Suministro tenía fecha de caducidad dentro de Clevergy. Después de analizar el impacto y los beneficios que obtendríamos cambiando el CUPS por un identificador único nuestro, comenzamos un bonito y tedioso proceso de adaptar todas nuestras tablas, endpoints, queries, para que, en vez de consultar por CUPS, se pudiera consultar por nuestro ID de casa.

Este cambio lo realizamos poco a poco, empezando por los sitios que más nos bloqueaban y dejando para el final aquellas funcionalidades aisladas que dependían del CUPS, pero no interactuaban con otras partes de la plataforma. He de puntualizar aquí que, si no hubiéramos tenido el nivel de cobertura de pruebas automáticas que tenemos sobre el código, este proyecto habría durado el doble y con muchos más dolores de cabeza de los que hemos tenido (que no han sido pocos).

La historia del cambio de CUPS a ID de casa tiene dos moralejas muy importantes:

• Al principio, hay que simplificar tu arquitectura y asumir deuda técnica. Si hoy tuviera que empezar un proyecto nuevo, elegiría el CUPS otra vez. Elegir el CUPS nos ha evitado crear muchas tablas uniendo el ID de casa a un CUPS de distintos proveedores, dónde el identificador del proveedor era el mismo. Esto nos ha permitido simplificar algunas operativas y aunque a medio plazo puede que hayamos tenido que cambiarlo, la velocidad que conseguimos al inicio fue fundamental.

• La deuda técnica hay que pagarla. La deuda técnica genera intereses, y tarde o temprano hay que pagarlos. Si acumulas demasiada deuda, todo tu esfuerzo de desarrollo puede acabar destinado a pagar esos intereses, haciendo que tu producto se quede estancado. Hay desarrollos que han durado más de lo que esperábamos, porque el CUPS carecía de algunas propiedades que necesitábamos como ser un identificador único entre clientes. Esto ha originado algunos errores, que, aunque no han alterado la experiencia del cliente, han hecho que invirtamos más tiempo del necesario en identificar algunos comportamientos extraños.

---

Volvamos a nuestro refinamiento de hace dos días. La plataforma ya funciona con el ID de casa, por lo que la pregunta realmente no era si podemos unir las facturas por CUPS. La realidad es que esa relación hoy se hace entre el ID de la casa y el ID de la factura.

El reto era el siguiente: ¿Cómo asignar una factura de la luz a una casa utilizando el campo CUPS de ambos objetos?

Es decir, tenemos por un lado un listado de facturas, que importamos en lotes del cual podemos extraer un CUPS para luego unirlo a aquella casa que tenga la misma propiedad CUPS.

Entonces vino la pregunta que desencadenó este artículo:

¿El CUPS pertenece a la casa o al medidor de energía?

Técnicamente, al medidor de energía. Si el CUPS pertenece al medidor, igual tiene más sentido crear una tabla distinta con los medidores y unirlos a las casas de tal forma que una casa pueda tener su medidor con sus datos. Además, aunque no nos hemos tenido que enfrentar a este caso, estamos convencidos de que algún edificio en España tendrá más de un CUPS asociado. Lo que pasa es que al ser un corner case tan raro, por ahora hemos decidido asumir un poco más de deuda técnica.

Por otro lado, el CUPS es un identificador que genera la distribuidora cuando da de alta el punto de suministro y que es inmutable e inalterable. Es decir, no depende del contrato de la luz, ni del propietario de la vivienda. Aunque es un valor del contador, podemos decir que es un dato de la casa.

Si tenéis curiosidad, la reunión la cerramos haciendo una analogía: el CUPS podría ser como el DNI de una persona. Todos los DNIs están asociados a una persona y ese valor es el mismo siempre, pero hay veces que no te lo has sacado o desconoces ese DNI.

Y aquí es donde viene la mayor lección de toda esta historia:

— 18 meses trabajando con el CUPS como identificador.

— 6 meses deshaciendo todo el lío para dejarlo limpio con ID de casa.

Todo para tomar una decisión:

Las casas tienen un campo único llamado CUPS que podremos usar para asociar facturas y otros elementos del sistema eléctrico español, siempre y cuando la casa disponga de ese indicador.

Ese axioma que sería inamovible dentro del producto duró 3 horas.

En la comida, sin estar relacionado con este tema, empezamos a fantasear sobre la idea de incluir la monitorización de gas dentro de la aplicación para poder ayudar a las personas a tener una visión más completa sobre su consumo energético dentro del hogar.

— ¿Y qué identificador tienen todos los contadores de gas?

Efectivamente, un CUPS.

Es decir, a pesar de todo el tiempo invertido en entender el problema de vincular elementos del sistema eléctrico español en un modelo de datos que escale, el mero hecho de incluir gas dentro del sistema tambaleó un axioma que parecía infalible.

Lo bueno es que como el CUPS ya no es ese ID central dentro de la aplicación del que dependen todos los datos, configuraciones, integraciones, etc., podemos crear un campo cups_gas y seguir creciendo la aplicación en esa línea. Pero ese no es el punto. No hay verdad por cierta que parezca que perdure para siempre. Y esto es la deuda técnica. Hay veces que somos conscientes y generamos deuda técnica de forma consciente, y hay veces que es el producto el que te dice – Así no se puede hacer.

Al final, este proceso de adaptación y cambio en la identificación de casas y facturas no solo nos ha enseñado la importancia de la flexibilidad y la adaptabilidad en la arquitectura del producto, sino también la relevancia de la gestión de la deuda técnica en el ciclo de vida del producto. La capacidad de pivotar y ajustar nuestras soluciones en función de nuevas necesidades y oportunidades es crucial para mantenernos competitivos y seguir ofreciendo valor a nuestros usuarios. La gestión efectiva del producto no solo trata de resolver problemas actuales, sino de anticipar futuros desafíos y prepararse para ellos. Por el camino seguro que nos encontraremos para más retos, pero por ahora, estamos listos para enfrentar cualquier cambio que venga siempre que no incluya multi-punto, multi-país o agua. Por ahora.

Cuando llegue ese día, saldaremos nuestra deuda técnica con una sonrisa, sabiendo que hemos hecho una buena inversión de nuestro tiempo, lo que nos ha permitido avanzar rápidamente y seguir ayudando a nuestros usuarios a ahorrar en casa y a ser parte de la transición energética.