Es más que un lenguaje de programación
Luego de entender qué debe hacer una solución tecnológica, viene la angustia de decidir cómo implementar, es decir, definir la arquitectura de software.
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change. — Grady Booch.
¿Es importante definir con precisión qué lenguaje, base de datos, sistemas operativos y tecnologías usar desde el principio? ¿Debemos tratar de cubrir todos los escenarios y escoger la mejor herramienta?
Nos dicen en las escuelas de ingeniería que debemos conocer las herramientas y tomar las que mejor se adecúen y así obtener la solución óptima. Esto es ideal en ingeniería de la construcción o hasta en electrónica. Pero esto no es tan cierto en la industria del software. El software debe cambiar tanto como cambian los procesos y necesidades.
El software, entonces, está obligado desde su nacimiento a ser orientado al cambio o mejor dicho, a reducir su costo de cambiar. El diseño de software debe tener un acercamiento orgánico.
Viene la supuesta contradicción: ¿pensamos en el software como quien construye un edificio: piensa primero, programa/construye después?; o ¿el software debe ser ligero como para cambiar muy rápido a costa de rehacer inclusive hasta los cimientos? En general, esto suele suceder:
- El área funcional detecta un problema y redacta el requisito
- El área técnica convoca a una consultoría externa o a la oficina de tecnología para determinar cómo desarrollar el requisito
- Los ingenieros y técnicos desarrollan el software
- Se prueba y se entrega
Entre los pasos 1 a 4 suelen pasar muchos meses o hasta años. Es fácil entender que el requisito cambió y lo desarrollado no se ajusta a lo requerido. Y ni qué decir de lo gastado y desechado.
Al desarrollar software, es la rápida entrega de valor y la agilidad ante el cambio lo que marca la pauta en estos días. Pensar en desarrollo “en cascada” es más bien pensar en edificios fuertes pero “inmuebles” o inmutables. Ahora, lo mejor es pensar en desarrollo ágil y en arquitecturas pequeñas y desacopladas, es decir, en microservicios. Lo anterior se resume en el manifiesto ágil:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Un ejemplo: ¿qué lenguaje usar en www.gob.pe? La rotación de los desarrolladores es alta y quien ingrese al equipo debe entender la solución y ponerse al trabajar rápidamente. Mantenibilidad y Agilidad prevalecen sobre velocidad de procesamiento. Veamos dos trozos de código:
¿Cuál es más mantenible, fácil de entender y, por lo tanto ágil? ¿Qué lenguaje domina más el equipo? ¿Dónde es más rápido hacer cambios y hasta desechar y rehacer? Preguntas clave que se hace el equipo de desarrollo al elegir.
Finalmente, es común escuchar, en industria de software, que hay mejores alternativas para una solución y la respuesta que veremos es el infame “depende”. El equipo es el llamado a decidir en cuanto a su experiencia, mantenibilidad y facilidad de uso. Siempre es más que sólo el lenguaje.
