Hay desarrolladores que resuelven todo con .NET.
Otros intentan convertir SQL Server en una aplicación completa.
Y siempre aparece alguien que cree que Excel puede sustituir cualquier sistema si añadimos suficientes macros.
El problema no es dominar una tecnología.
El problema es enamorarse tanto de ella que dejas de mirar el problema.
La comodidad es una mala arquitecta
Cuando conoces bien una herramienta, puedes avanzar rápido.
Eso produce una sensación peligrosa: si puedo hacerlo aquí, entonces debo hacerlo aquí.
Pero poder no significa convenir.
Puedes construir un workflow complejo dentro de procedimientos almacenados. Puedes crear un CRM con hojas enlazadas. Puedes utilizar SharePoint como base de datos relacional.
La pregunta es cuánto costará mantenerlo cuando crezca.
Síntomas de que estás forzando la herramienta
Presta atención cuando:
- Necesitas demasiadas excepciones para cubrir el caso.
- La solución depende de una sola persona.
- Cada cambio rompe algo que parecía no estar relacionado.
- Los usuarios trabajan alrededor del sistema en lugar de con él.
- La seguridad se basa en ocultar botones o columnas.
- El rendimiento empeora con cada nueva función.
- Explicar la arquitectura requiere empezar con “ya sé que no es lo ideal, pero…”.
Empieza por las necesidades
Antes de elegir tecnología, define usuarios, volumen, integraciones, seguridad, disponibilidad, presupuesto y evolución esperada.
Después compara opciones.
Una solución interna pequeña puede encajar perfectamente en Power Apps.
Un proceso crítico con alta concurrencia quizá necesite una aplicación a medida.
Un informe puede resolverse en Power BI. Una operación transaccional no debería convertirse en un informe editable.
La mejor tecnología no es la más potente. Es la que resuelve el problema con el menor coste total razonable.
El coste no es solo construir
Incluye licencias, infraestructura, formación, soporte, seguridad, migración y dependencia del proveedor.
También incluye el tiempo que perderá el siguiente equipo intentando entender una decisión tomada por comodidad.
Una solución barata hoy puede ser carísima dentro de dos años.
Haz una prueba antes de comprometerte
Cuando haya dudas, construye una pequeña prueba de concepto.
Valida el punto difícil: rendimiento, integración, permisos o experiencia de usuario.
No utilices la prueba para demostrar que tu opción favorita funciona.
Utilízala para intentar descubrir por qué podría no funcionar.
Saber más herramientas no es el objetivo
No necesitas dominar veinte tecnologías.
Necesitas reconocer cuándo tu herramienta habitual deja de ser adecuada y pedir ayuda.
Un buen profesional no presume de resolver todo con lo mismo.
Presume de no obligar al cliente a pagar por sus preferencias.
La tecnología es un medio.
Cuando se convierte en el objetivo, el problema original desaparece y solo queda una solución buscando dónde colocarse.
No metas todo donde te sientes cómodo.
Colócalo donde tenga sentido.
