Principios de ingeniería

Cada proyecto comienza con la comprensión del dominio: las restricciones físicas, el vocabulario operativo y los modos de fallo relevantes. Para un operador de BESS, esto significa entender cuánto cuesta en ingresos de despacho la degradación del SOH antes de escribir una sola consulta. Para un emisor, significa entender por qué un solo frame perdido en la ingesta puede derivar en un paquete de entrega no conforme.

El conocimiento del dominio no es algo que el cliente proporciona y nosotros simplemente consumimos. Invertimos en él por nuestra cuenta: leemos documentos de estándares, ejecutamos simulaciones y hacemos las preguntas que parecen básicas — porque son precisamente las que con mayor frecuencia evitan retrabajos costosos en etapas avanzadas.

La consecuencia es que nuestras estimaciones se apoyan en la realidad del dominio, no en analogías optimistas con proyectos anteriores. Cuando el alcance contiene incertidumbres, las nombramos explícitamente en lugar de absorberlas en silencio en un margen de entrega.

Los sistemas complejos no se simplifican solos — requieren simplificación deliberada en cada capa de abstracción. Consideramos las decisiones arquitectónicas como artefactos de comunicación: un límite de componente es una afirmación sobre qué cambia de forma independiente; un modelo de datos es una afirmación sobre qué necesita saber el sistema.

En la práctica, esto significa que resistimos la tentación de recurrir a frameworks que resuelven problemas que todavía no tenemos. Cuando añadimos una dependencia, documentamos el porqué y cuánto costaría eliminarla. El objetivo es una base de código en la que el siguiente ingeniero pueda comprender la intención a partir de la estructura, no solo de los comentarios.

Las interfaces de usuario tienen la misma obligación. Un panel que requiere una sesión de formación para interpretarse es un panel que se ignorará en un momento crítico. Diseñamos para el operador que lee estas cifras a las 2 de la mañana, no para el entorno de demostración.

El progreso que no es visible genera ansiedad, y la ansiedad produce decisiones prematuras. Compartimos el trabajo en curso — no entregables pulidos, sino prototipos funcionales y borradores que permiten al cliente dar su opinión antes de que las inversiones se consoliden.

Cuando una decisión técnica implica un compromiso significativo, lo hacemos explícito en lugar de presentar una conclusión. Cuando una suposición sobre el alcance resulta ser incorrecta, la comunicamos de inmediato en lugar de ajustar silenciosamente el calendario de entrega para compensar.

Esto se aplica también a los hallazgos negativos. Si una tecnología que propusimos resulta ser la opción equivocada a medida que aprendemos más, lo decimos. El coste de una corrección temprana es casi siempre inferior al de una corrección tardía.

La calidad del código es necesaria, pero no suficiente. Un módulo bien probado que resuelve el problema equivocado, o que se entrega con seis semanas de retraso, no ha generado valor. Tratamos la fiabilidad en la entrega como una métrica de calidad de primer orden, junto con la cobertura de pruebas y los benchmarks de rendimiento.

Usamos pipelines de CI/CD, sistemas de tipos y linters no porque estén de moda, sino porque hacen que el siguiente cambio sea más barato. Escribimos pruebas en el nivel donde son más económicas de mantener y donde es más probable que detecten regresiones reales. Analizamos el rendimiento antes de optimizar, y optimizamos antes de reescribir.

Cuando nos comprometemos con una fecha de entrega, nos comprometemos con el alcance y los supuestos subyacentes que hacen esa fecha creíble. Si esos supuestos cambian, el calendario se reabre — y lo comunicamos de inmediato.

Los prototipos pensados para ser reemplazados raramente lo son. Cuando construimos algo que va a funcionar en producción, lo tratamos como tal desde el primer commit: paridad de entornos, logging estructurado, error boundaries, degradación elegante ante fallos parciales.

Para sistemas en tiempo real, esto significa pensar en el backpressure antes de la primera conexión WebSocket. Para paneles que manejan telemetría a escala, significa pensar en el modelo de datos bajo carga antes de que se renderice el primer gráfico. Para pipelines de streaming, significa probar con tasas de bits y latencias que representen condiciones operativas reales, no condiciones de demostración.

No pedimos un sprint de limpieza al final del proyecto. El coste de ese sprint es siempre mayor que la atención distribuida a lo largo del proyecto, y el sistema resultante es menos coherente.

Un proyecto completado no es un resultado — es un hito. El resultado es un sistema que continúa generando valor a medida que los requisitos evolucionan, la escala cambia y el propio dominio se transforma. Diseñamos para esa trayectoria desde el principio: puntos de extensión, justificación documentada de las decisiones y una entrega que deja al equipo del cliente genuinamente capaz de continuar sin nosotros.

Preferimos clientes que nos traten como un socio tecnológico a largo plazo frente a quienes nos ven como un proveedor de entregas. No por la relación comercial, sino porque el trabajo es mejor cuando comprendemos el contexto de negocio lo suficiente como para cuestionar especificaciones que crearán problemas doce meses después.

Cuando un proyecto termina, consideramos el conocimiento acumulado como un activo del cliente, no nuestro. La documentación, los diagramas de arquitectura y los runbooks son parte de cada entrega.