El Sesgo Tech del 'NewDev': Cuando la Novedad Nubla la Eficiencia
Por qué elegí construir un sistema empresarial con PHP plano y PostgreSQL después de 15 años en la industria
La Paradoja del Desarrollo Moderno
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. Pero una lección permanece: el software empresarial debe durar más que las modas tecnológicas.
Los Tres Sesgos Peligrosos del NewDev
1. El Sesgo de Novedad: "Si es nuevo, es mejor"
Ú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ó 200k USD por... tener lo mismo con dependencias más recientes.
La realidad: PostgreSQL lleva 25 años funcionando. PHP 28 años. ¿Realmente necesitamos cambiar lo que funciona?
2. El Sesgo de Complejidad: "Más capas = más profesional"
Observo sistemas con:
- API Gateway → Auth Service → Business Logic → Database
- 15 microservicios para 100 usuarios diarios
- GraphQL para 3 entidades básicas
El costo oculto: Cada capa añade latencia, puntos de falla y complejidad cognitiva. ¿De verdad necesitamos tanta arquitectura para un CRUD de clientes?
3. El Sesgo del CV: "Uso lo que mi próximo empleador quiera ver"
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 Donde la Simplicidad Gana
Caso 1: El ERP que sobrevivió al equipo
Un sistema contable que construí en 2015 con PHP + PostgreSQL sigue funcionando—con 4 equipos diferentes manteniéndolo. La clave: cero dependencias externas. No hay package.json que actualizar, ni composer.lock que romper.
Caso 2: La migración fallida
Un equipo migró su aplicación de Vue 2 a Vue 3. 3 meses después, seguían con bugs en producción. El costo: 500k USD en horas de desarrollo + pérdida de clientes por inestabilidad.
Caso 3: La sobre-ingeniería que colapsó
Conocí un startup que implementó Kubernetes, service mesh y circuit breakers para 50 usuarios concurrentes. El sistema era tan complejo que solo 2 developers lo entendían—y ambos renunciaron.
El Antídoto: Principios sobre Herramientas
Estabilidad Decenal
El software empresarial debe durar 10+ años. Esto significa:
- Tecnologías maduras, no experimentales
- Dependencias mínimas (o ninguna)
- Documentación de arquitectura, no solo de código
Simplicidad Radical
Menos capas = menos puntos de falla. Nuestra regla: "Si no añade valor al negocio, no entra en el sistema".
Soberanía Tecnológica
Controla tu destino tecnológico. Nuestro stack:
- PHP 8.4 + PostgreSQL: Estables por décadas
- SQL directo: Máximo rendimiento, mínimo overhead
- JS vanilla por módulo: Cero dependencias npm
La Elección Incómoda
Hace un año, decidí rechazar React, TypeScript y GraphQL para un nuevo sistema fiscal. ¿El resultado? Un sistema que:
- Responde en <100ms constantes
- Cuesta 60% menos en mantenimiento
- Cualquier developer puede entender en 2 días
¿Fue popular la decisión? No. ¿Funciona? Impecablemente.
Conclusión: No Es Tech Stack vs. Tech Stack, Es Negocio vs. Ego
La próxima vez que elijas una tecnología, pregúntate:
- ¿Esto sirve al negocio o a mi currículum?
- ¿Podrá mantenerse por 10 años?
- ¿Qué pasa si el mantenimiento principal se va?
El desarrollo software no es una pasarela tecnológica. Es construir cimientos para que los negocios funcionen—aunque los cimientos sean "aburridos".
¿Prefieres un sistema que dura 10 años o uno que parece moderno en Twitter?
¿Estás de acuerdo? ¿Has vivido situaciones similares? Los comentarios están abiertos para discusión constructiva.
Tags para Dev.to
php #postgresql #webdev #architecture #programming #tech
#opinion
Top comments (0)