Durante años pensé que las matemáticas y la ingeniería de datos eran etapas distintas de mi trayectoria. Ahora creo que la primera influye bastante en cómo aprendo y practico la segunda.

La conexión no consiste en aplicar matemáticas avanzadas a cada tarea. Aparece, sobre todo, en preguntas más elementales: qué estamos suponiendo, qué significa que un resultado sea correcto y cómo sabremos que una premisa ha dejado de cumplirse.

1. Hacer explícitos los supuestos

Todo sistema de datos se apoya en hipótesis, aunque no siempre estén escritas. Esperamos que un identificador sea único, que una fecha use una zona horaria determinada, que una fuente llegue antes de cierta hora o que una columna conserve su significado.

Antes de implementar, intento convertir esas expectativas en condiciones que puedan explicarse y, cuando sea posible, comprobarse. Un supuesto implícito solo se descubre cuando falla; uno explícito puede formar parte del diseño y de las pruebas.

2. Distinguir ejemplos de validaciones

Ver unas cuantas filas correctas es útil durante el desarrollo, pero no demuestra que el proceso funcione para el conjunto completo ni que vaya a seguir haciéndolo mañana. Una validación reproducible necesita un criterio claro: qué se mide, contra qué se compara y qué ocurre cuando el resultado sale de los límites aceptables.

3. Buscar contraejemplos

En matemáticas, un solo contraejemplo basta para desmontar una afirmación universal. En ingeniería de datos, pensar de esa manera ayuda a anticipar los casos que suelen revelar las debilidades del diseño: valores nulos, duplicados, llegadas tardías, reintentos, cambios de esquema o registros fuera de orden.

No es posible prever cada incidente, pero sí buscar deliberadamente los casos que contradicen el camino ideal. Esa búsqueda mejora tanto las pruebas como la observabilidad del sistema.

4. Separar ejecución de corrección

Un estado verde puede significar que no hubo una excepción técnica. La corrección exige algo más: comprobar volúmenes, integridad, frescura, unicidad y coherencia con las reglas del dominio. También exige decidir qué tolerancias son razonables, porque no todos los sistemas tienen el mismo coste de error.

5. Construir soluciones que puedan explicarse

Una solución mantenible no depende solo de que el código sea legible. Debe ser posible reconstruir el razonamiento: qué problema resolvía, por qué se tomaron ciertas decisiones, qué garantías ofrece y dónde están sus límites.

Documentar esas decisiones reduce la distancia entre quien construye el sistema y quien tendrá que operarlo, revisarlo o modificarlo en el futuro. También permite discutir el diseño con argumentos, no solo con preferencias de herramientas.

Una forma de pensar, no una receta

Ninguno de estos hábitos garantiza por separado un sistema fiable. Tampoco sustituye la experiencia técnica, el conocimiento del negocio o una buena operación. Su valor está en introducir disciplina en las preguntas que hacemos antes y después de construir.

Al final, la fiabilidad de un sistema de datos depende tanto de cómo razonamos sobre él como de las herramientas con las que lo construimos.