Hecho... hasta que ya no lo está: cómo abordan las tareas la mayoría de los ingenieros de datos

La mayoría de los ingenieros conocen ese momento. Terminas una tarea, funciona y el ticket pasa al estado «Hecho». Publicas el código y pasas a la siguiente tarea.

Entonces, unas semanas o unos meses después, algo cambia. Un requisito evoluciona, alguien necesita ampliar lo que has creado, surge un problema en producción o, simplemente, vuelves a abrir tu propio código. Y piensas:

¿En qué demonios estaba pensando?

…o algo un poco menos educado. Según mi experiencia, el problema rara vez es que no supiéramos cómo resolverlo. Mirando atrás, normalmente podemos identificar una o dos cosas que haríamos de otra manera. No es que de repente nos hayamos convertido en mejores ingenieros; simplemente dejamos de pensar en cuanto la solución funcionó.

‍

Por supuesto, nos centramos en que «funcione».

Todos trabajamos con personas competentes que resuelven problemas complejos cada día. Rara vez es que falte saber cómo hacer que las cosas funcionen, y tampoco es que a la gente no le importe. En el sector de la consultoría, estamos constantemente buscando el equilibrio entre la calidad, los plazos, las expectativas de los clientes y las nuevas peticiones, y siempre hay otro proyecto esperando.

Por eso es natural centrarse en que «funcione», y ese es el punto de partida adecuado. El problema surge cuando «que funcione» se convierte, sin que nos demos cuenta, en nuestra definición de «terminado».

Lo que creamos sigue evolucionando después de entregarlo: los requisitos cambian, los datos cambian, los volúmenes aumentan y alguien más tendrá que entender lo que hemos hecho. Muy a menudo, ese alguien somos nosotros mismos en el futuro.

Hay una diferencia entre terminar una tarea y dar por concluida una solución. A veces, la tarea está terminada, pero la solución merece que le dediquemos otros cinco minutos de reflexión.

Cinco preguntas que hay que plantearse antes de dar por concluido un trabajo con datos

Normalmente intento plantearme algunas preguntas antes de dar algo por terminado. No es una lista de comprobación formal, y no siempre acierto. Las preguntas simplemente me ayudan a tomar distancia respecto a la tarea por un momento y a ver la solución desde otro punto de vista.

‍

¿Qué podría salir mal?

Por naturaleza, diseñamos pensando en el escenario ideal, pero en producción siempre acaba surgiendo ese único caso que no habíamos tenido en cuenta. Una tarea se ejecuta dos veces y, de repente, un informe muestra el doble de ingresos. Una columna de origen cambia de nombre de la noche a la mañana. Llega un archivo con valores NULL donde nadie los esperaba, o una API simplemente agota el tiempo de espera. Nada de esto es nada del otro mundo.

Así pues, más allá de preguntarnos «¿funciona?», merece la pena plantearnos: «si no funciona, ¿sabremos qué ha pasado?». Un registro útil o una simple validación suelen marcar la diferencia entre un incidente grave y una solución rápida.

¿Qué es lo que probablemente cambiará?

Intentar predecir todos los futuros posibles es una forma segura de complicar demasiado cualquier cosa. Pero normalmente podemos detectar lo que es probable que evolucione: una fecha o un identificador fijado de forma rígida, una regla de negocio oculta en una consulta, un esquema de origen, una suposición sobre el volumen que se cumple para las diez mil filas actuales, pero no para los diez millones del año que viene.

A menudo, lo mejor es no complicar las cosas. Lo importante es tomar esa decisión de forma consciente.

¿Podemos confiar en esto en el entorno de producción?

La cuestión no es si técnicamente puede funcionar en entorno de producción, sino si nos sentiríamos tranquilos sabiendo que está funcionando esta noche sin que nadie lo supervise.

Si eso nos hace dudar, suele haber algo que merece la pena examinar: la validación, el registro de eventos, la gestión de errores, lo que ocurre al volver a ejecutar el código o esa parte delicada que esperábamos que no se convirtiera en un problema. A todos nos ha pasado alguna vez.

Una prueba sencilla: imagina que la tarea falla a las 3 de la madrugada. ¿Quién se entera y cómo? Si la respuesta sincera es «el cliente, el lunes por la mañana», vale la pena volver a analizarlo.

¿Nos sentiríamos cómodos manteniendo esto?

A menudo hablamos del «próximo desarrollador», pero muchas veces ese somos nosotros mismos, seis meses más tarde, y mucho menos indulgentes. ¿Entenderemos por qué se tomó una decisión? ¿Será fácil depurar el código? ¿Cambiar un pequeño detalle supondrá tener que cambiar otros cinco?

En el trabajo con datos, esto se nota enseguida: una transformación con cinco CTE anidadas y sin comentarios, una columna llamada «flag2» o un proceso en el que un pequeño cambio implica actualizar tres cuadernos y un panel de control. A menudo, basta con un nombre claro, un breve comentario que explique el motivo o dividir una consulta enorme en pasos. Parece algo teórico hasta el día en que somos nosotros quienes tenemos que mantener lo que hemos creado.

¿Se lo presentaríamos con confianza a un cliente?

Probablemente, esta sea la que más valoro. Imagina que el cliente pregunta: «¿Por qué lo has hecho así?», «¿Qué pasaría si esto fallara?» o «¿Sería muy complicado cambiarlo más adelante?». ¿Nos sentiríamos cómodos respondiendo?

En los proyectos de datos, estas preguntas surgen con más frecuencia de lo que cabría esperar. ¿Por qué esta cifra no coincide con la de la hoja de cálculo del departamento financiero? ¿Qué pasa si falla la carga de anoche? ¿Podemos añadir una nueva fuente sin tener que reconstruirlo todo? Una respuesta clara, aunque sea «aceptamos esta compensación a propósito», genera mucha más confianza que una solución pulida que nadie sabe explicar.

La solución no tiene por qué ser perfecta, ni la respuesta tiene por qué ser impresionante. Pero debemos comprender y respaldar las decisiones que tomamos. Si no me sintiera cómodo explicando una decisión a un cliente, eso es señal de que hay que replanteársela.

No se trata de la perfección: se trata de la calidad de nuestro trabajo

Nada de esto significa crear un software perfecto, añadir más procesos o convertir cada tarea en un taller de arquitectura. La solución más sencilla suele ser la correcta. Un valor codificado directamente puede estar bien, y un atajo temporal puede estar justificado cuando el contexto lo requiera.

La diferencia radica en si esa sencillez fue una decisión consciente... o simplemente lo primero que funcionó.

Esto es importante porque lo que creamos en el ámbito de la consultoría se utiliza, a menudo durante años. Un compañero de equipo, el cliente o nosotros mismos lo mantendremos, lo ampliaremos y dependeremos de ello. Merece la pena reflexionar un poco más sobre lo que ofrecemos.

Cuando esos 5 minutos extra dan sus frutos

No todas las tareas merecen el mismo nivel de atención. Un análisis puntual o un prototipo rápido pueden permitirse algunos atajos. Con el tiempo, he observado algunos indicios que indican que una tarea merece una segunda revisión:

• Funciona sin que nadie lo supervise. Tareas programadas, cargas nocturnas, cualquier cosa que pueda fallar sin que nadie se dé cuenta.
• Ofrece cifras en las que la gente confía. Informes , cuadros de mando, cualquier elemento que influya en la decisión del cliente.
• Otros se basarán en ello. Una tabla compartida, una función común, un modelo que otros equipos reutilizarán.
• Es difícil revertir el proceso. Borrar datos, migrar un esquema, modificar algo de lo que dependen otros sistemas.

Cuando una tarea cumple uno de estos requisitos, esos cinco minutos suelen ser el tiempo más barato que dedicaré a ella.

Una pregunta que intento hacer más a menudo

A veces sigo deteniéndome demasiado pronto, y sigo abriendo código antiguo y preguntándome en qué estaba pensando. Pero he empezado a hacerme una pregunta más antes de dar por terminada una tarea:

¿De verdad lo he pensado bien?

A veces la respuesta es sí. Otras veces me obliga a volver atrás para añadir un registro, eliminar un valor predefinido, añadir una comprobación de calidad de los datos o probar un escenario más. No es nada revolucionario, pero suele ser de ayuda la mayoría de las veces.

Y, con un poco de suerte, la próxima vez que revise mi propio código, diré menos palabrotas.