TL;DR
- El 90% de data engineers sufren con data modeling según el 2026 State of Data Engineering Survey
- La causa #1 no es falta de conocimiento, es presión organizacional por moverse rápido
- Las organizaciones con modelado ad-hoc gastan 38% de su tiempo en firefighting vs 19% con modelos canónicos
- El sistema te premia por ser rápido hoy y te culpa por la deuda técnica mañana
- Tienes tres opciones: aceptar la tumba, pelear contra el sistema, o usar datos estratégicamente
Intro
Tu modelado de datos no falla porque seas mal ingeniero.
Falla porque hacer las cosas bien en tu organización te está perjudicando. Y eso es mucho más peligroso que no saber modelar.
Cuando el sistema te premia por velocidad y te culpa por la deuda técnica, no importa cuánto sepas. Estás construyendo la tumba que va a enterrar tu carrera.
El 2026 State of Data Engineering Survey reveló algo que muchos sospechaban pero nadie decía en voz alta: el 90% de los data engineers están sufriendo con data modeling, y la causa número uno no es falta de conocimiento.
La causa número uno es la presión organizacional por moverse rápido.
El ciclo de la urgencia
El patrón es casi universal. Llega un ticket con algo como “Feature XYZ para el dashboard del CEO”. El deadline es para ayer. Tu product owner está presionando porque “esto es crítico para el negocio”.
Tú ya sabes lo que se necesita hacer: normalizar los datos, definir tipos correctamente, documentar el schema, pensar en cómo escala cuando llegue al millón de usuarios.
Pero también sabes que si haces todo eso, no vas a entregar a tiempo.
Así que haces lo que hace el 90% de nosotros: apagas la parte del cerebro que piensa en arquitectura correcta y solo haces que funcione. Ad-hoc. Tabla aquí, columna allá. Feature entregado rápido. Jefe feliz.
Seis meses después: “¿Por qué se rompe todo?” “¿Quién hizo esto?”
Y ahí está la clave: el problema no es que hayas decidido hacerlo mal. El problema es que el sistema te premió por hacerlo mal.
Los incentivos rotos del data engineering moderno
Las organizaciones modernas de data engineering tienen incentivos completamente rotos cuando se trata de calidad técnica.
Cuando entregas rápido con modelado ad-hoc, el stakeholder está feliz, el feature está shipped, y tú eres el “fast engineer”. El sistema te premia.
Seis meses después, cuando todo está roto, el mismo stakeholder pregunta “¿por qué tan lento?”, el producto tiene bugs por todos lados, y tú te conviertes del “fast engineer” al “bad engineer”. El sistema te culpa.
¿Ves el patrón?
El momento en que empezaste a acumular esa deuda técnica fue cuando el sistema te premió por ser rápido. Pero cuando llega el momento de pagarla, nadie recuerda esa presión original. Solo ven el desastre.
El ciclo de muerte del “Move Fast”
Es como usar tarjetas de crédito para pagar otras tarjetas de crédito. Al principio todo funciona. Tienes liquidez. El negocio está feliz. Pero eventualmente, el interés te mata.
En datos, el interés se llama firefighting.
Así evoluciona típicamente:
Mes 1: Feature A entregado rápido con modelado ad-hoc.
Mes 3: Feature B se agrega. “Solo agrégale columnas”. Más ad-hoc sobre ad-hoc.
Mes 6: Tienes 15 features interconectados, cero documentación, cero claridad sobre ownership.
Mes 12: Firefighting completo. “¿Quién creó esta tabla?” “¿Por qué este dato es NULL?” “¿Cuál es la fuente de verdad?”
Tumba técnica completa.
Y cuando llegas al mes 12, ¿a quién culpan? ¿Al product owner que exigió velocidad? ¿Al VP que midió KPIs de delivery?
No. Culpan a ti. “Tus modelos son un desastre.” “Tus pipelines son lentos.” “Tú no escalaste bien.”
Lo que el survey revela
El 2026 State of Data Engineering Survey, con 1,101 data engineers respondiendo, tiene las cifras que confirman este patrón.
Los pain points de data modeling son claros:
- 59.3% — Presión para moverse rápido
- 50.7% — Falta de ownership claro
- 39.2% — Difícil de mantener en el tiempo
- Solo 11.3% dicen que el modelado va bien
Pero el dato más revelador es la correlación entre approach de modelado y tiempo en firefighting:
| Approach | Tiempo en Firefighting |
|---|---|
| Ad-hoc modeling | 38% |
| Canonical/Semantic models | 19% |
Casi la mitad del tiempo perdido. Solo por hacer las cosas bien.
Y aquí está lo más interesante: solo el 5.4% de las organizaciones usan modelos canónicos o semánticos. El 17.4% usan ad-hoc.
La pregunta no es “¿cuál es mejor?”. La pregunta es: ¿por qué el 95% de las organizaciones no están haciendo lo que saben que es mejor?
Respuesta: Porque el sistema no les permite.
Qué puedes hacer hoy
El sistema está roto. Pero tú vives dentro de ese sistema. Tienes tres opciones.
Opción 1: Aceptar la tumba técnica
Si prefieres vivir en constante firefighting, acepta que este es el costo. Pero entiende qué estás eligiendo.
Opción 2: Pelear contra el sistema
Puedes negarte a entregar sin modelado correcto. Puedes documentar y normalizar todo. Vas a ser el ingeniero que “no es fast”. Tu carrera puede sufrir.
Opción 3: El enfoque estratégico
Esta es la que recomiendo.
Comprueba el survey primero. La próxima vez que te presionen, muéstrales: “Si usamos ad-hoc, vamos a perder 38% de nuestro tiempo en firefighting según el survey de 1,101 engineers. ¿Es esto lo que quieres?”
No es tu opinión. Son datos.
Define ownership explícito. Antes de crear cualquier tabla, pregunta: “¿Quién es el owner de este modelo? ¿Qué sucede cuando cambia?” Si nadie tiene una respuesta, documenta que no hay ownership. Cuando falle, no es tu culpa.
Comienza pequeño con canonical models. No intentes refactorizar todo. Empieza con un área crítica. Define un schema canónico para esa área. Documenta el why. Cuando esa área tenga la mitad de bugs que el resto, los datos hablarán por sí mismos.
Métricas antes que intuición. Mide cuánto tiempo tu equipo pierde en firefighting. Preséntalo en retros: “El mes pasado perdimos 40 horas en debugging de schemas ambiguos.”
Nadie puede ignorar números.
El insight clave: no estás pidiendo permiso para hacer “mejor ingeniería”. Estás pidiendo permiso para no desperdiciar el 38% del tiempo de tu equipo.
Trade-offs: ¿Qué camino tomar según tu contexto?
No hay respuesta universal. Depende de dónde está tu organización.
Si es una startup sin product-market-fit: Usa ad-hoc. La velocidad de aprender es más importante que el modelado perfecto. Pero documenta que es deuda técnica.
Si es una empresa establecida con product-market-fit: El costo de no modelar bien ya superó el beneficio de la velocidad hace meses. Si no cambias, vas a estar en firefighting permanente.
Pero aquí está la realidad difícil: no todas las organizaciones se van a salvar. Algunas prefieren la tumba técnica porque el costo de cambiar su cultura es demasiado alto.
Si estás en una de esas, es una conversación de carrera, no de ingeniería.
Outro
Tu modelado de datos no falla por ti. Falló por el sistema que te premia por velocidad y te culpa por deuda técnica.
El survey es claro: el 90% de nosotros estamos en la misma situación. No es un problema de skills. Es un problema de incentivos rotos.
Pero ahora tienes algo que yo no tenía cuando empecí: datos para defender tu trabajo. Usa el survey. Mide tu firefighting. Documenta el ownership.
No vas a cambiar el sistema de tu empresa en un día. Pero puedes dejar de ser el culpable cuando todo explote.
Fuentes
- 2026 State of Data Engineering Survey — https://joereis.github.io/practical_data_data_eng_survey/