El Sesgo Tech del 'NewDev': Cuando la Novedad Nubla la Eficiencia

Source: Dev.to

Por qué elegí construir un sistema empresarial con PHP plano y PostgreSQL después de 15 años en la industria

Hace seis meses, un desarrollador junior me preguntó: “¿Por qué no usas React y microservicios? Tu stack parece de 2010”. La pregunta me hizo sonreír y reflexionar. Llevo 15 años construyendo sistemas empresariales y he visto tecnologías venir e irse. Una lección permanece: el software empresarial debe durar más que las modas tecnológicas.

El sesgo de la novedad

Últimamente veo equipos reescribiendo sistemas estables simplemente porque salió “una versión nueva del framework”. Conozco un caso donde migraron un ERP de AngularJS a Angular 15: 6 meses de trabajo para cero funcionalidades nuevas. El negocio pagó 200 k USD por… tener lo mismo con dependencias más recientes.

La realidad:

• PostgreSQL lleva 25 años funcionando.
• PHP lleva 28 años funcionando.

¿Realmente necesitamos cambiar lo que funciona?

Costos ocultos de la arquitectura excesiva

Observo sistemas con la siguiente estructura:

API Gateway → Auth Service → Business Logic → Database

• 15 microservicios para 100 usuarios diarios.
• GraphQL para 3 entidades básicas.

Cada capa añade latencia, puntos de falla y complejidad cognitiva. ¿De verdad necesitamos tanta arquitectura para un CRUD de clientes?

Tendencias en los CVs

Revisé CVs la semana pasada. El 80 % mencionaba React, Node.js, Docker. Cero menciones a “mantenibilidad” o “estabilidad a largo plazo”. Entiendo la presión, pero el desarrollo no debería ser una carrera por coleccionar tecnologías trendy.

Casos reales

• Sistema contable (2015): construido con PHP + PostgreSQL, sigue funcionando con 4 equipos diferentes manteniéndolo. Clave: cero dependencias externas, sin package.json que actualizar ni composer.lock que romper.
• Migración Vue 2 → Vue 3: 3 meses después, seguían con bugs en producción. Costo: 500 k USD en horas de desarrollo + pérdida de clientes por inestabilidad.
• Startup con Kubernetes: implementó service mesh y circuit breakers para 50 usuarios concurrentes. El sistema era tan complejo que solo 2 developers lo entendían—y ambos renunciaron.

Principios para software empresarial

El software empresarial debe durar 10 + años. Esto implica:

• Tecnologías maduras, no experimentales.
• Dependencias mínimas (o ninguna).
• Documentación de arquitectura, no solo de código.
• Menos capas = menos puntos de falla.

Regla: “Si no añade valor al negocio, no entra en el sistema”.

Nuestro stack recomendado

• PHP 8.4 + PostgreSQL: estables por décadas.
• SQL directo: máximo rendimiento, mínimo overhead.
• JavaScript vanilla por módulo: cero dependencias npm.

Resultados de una decisión deliberada

Hace un año, decidí rechazar React, TypeScript y GraphQL para un nuevo sistema fiscal. El resultado:

• Respuesta constante < 100 ms.
• 60 % menos costo de mantenimiento.
• Cualquier developer puede entender el código en 2 días.

¿Fue popular la decisión? No. ¿Funciona? Impecablemente.

Preguntas para guiar la elección tecnológica

1. ¿Esto sirve al negocio o a mi currículum?
2. ¿Podrá mantenerse por 10 años?
3. ¿Qué pasa si el mantenimiento principal se va?

El desarrollo de software no es una pasarela tecnológica; es construir cimientos para que los negocios funcionen, aunque los cimientos sean “aburridos”.

Conclusión

¿Prefieres un sistema que dure 10 años o uno que parezca moderno en Twitter?
Comparte tus experiencias y opiniones en los comentarios.

#opinion