El lenguaje de programación debe permitir construir y mantener el sistema que necesita el negocio. Elegirlo por popularidad o por una comparación aislada de velocidad deja fuera buena parte del costo.
Cuatro datos antes de elegir
Identifica dónde se ejecutará la aplicación, qué sistemas deberá conectar, quién la mantendrá y qué requisitos son indispensables. Una integración disponible sólo en cierto entorno puede pesar más que una preferencia personal del desarrollador.
| Criterio | Evidencia que pedir |
|---|---|
| Compatibilidad | Operación necesaria ejecutada en el entorno previsto. |
| Mantenimiento | Versiones soportadas y plan de actualización. |
| Equipo | Capacidad para revisar y modificar el código. |
| Despliegue | Cómo se instala, registra errores y recupera una versión. |
Los principios de arquitectura de Microsoft proponen diseñar según las necesidades del negocio y considerar operación y evolución. Son una referencia de diseño, no una clasificación del mejor lenguaje. Principios de diseño de aplicaciones.
Compara con la misma tarea
Ejemplo hipotético: se evalúan dos tecnologías para un portal. En ambas, prueba consultar información, validar un formulario y registrar un error con el mismo conjunto de datos. Comparar una demostración simple con un sistema completo llevaría a una conclusión engañosa.
Si existe software que conviene conservar, incluye el costo de integrarlo. Reescribirlo sólo para unificar lenguajes puede consumir presupuesto sin mejorar el resultado del usuario.
Deja la decisión por escrito
Una nota breve debe explicar qué alternativa se eligió, por qué, qué inconveniente se acepta y qué dato justificaría revisarla. Evita comprometer el proyecto a una herramienta sin saber cómo se mantendrá cuando cambie el responsable.
La conversación comercial puede empezar por el objetivo y las conexiones necesarias. La tecnología viene después de esa definición y debe poder explicarse con sus consecuencias para el proyecto.
Ejemplo de una nota de decisión
| Campo | Ejemplo hipotético |
|---|---|
| Restricción | El portal debe integrarse con una biblioteca ya utilizada por la empresa. |
| Alternativas | Mantener ese entorno o añadir una integración entre tecnologías. |
| Comprobación | Ejecutar la operación necesaria con datos de ensayo. |
| Costo aceptado | Mantener la dependencia y documentar cómo actualizarla. |
| Motivo para revisar | La dependencia deja de cubrir una operación indispensable. |
La prueba debe permitir rechazar la alternativa preferida si no cumple la restricción. Conserva resultados y límites; no conviertas una preferencia del equipo en una necesidad del negocio. Evita copiar comparativas de rendimiento que midieron una tarea distinta.
Para profundizar en las tareas relacionadas: Framework o código propio: cómo decidir; Qué decisiones resuelve la arquitectura de software.
¿Hay un proceso que necesitas mejorar?
Cuéntanos qué ocurre hoy y qué resultado buscas. Podemos revisar una primera etapa para desarrollar o integrar la solución.
Explorar desarrollo de software