Un desarrollador, múltiples sombreros
Y entonces, un día después de una larga época en la oscuridad. En los rincones más oscuros y los escritorios más empolvados, a la sombra de gerentes, analistas y arquitectos de [introduzca aquí cualquier tecnología] los codificadores regresaron a su lugar bajo todos los reflectores de la industria; con menos medallas y menos títulos. Pero con un papel mas preponderante en los proyectos de implementación de plataformas y aplicaciones empresariales.
Todo el impulso tecnológico de finales de los 90’s y los 00’s estaba prácticamente estancado al final de la década con sus metodologías cada vez mas elaboradas, herramientas sofisticadas, costosas y complejas; generando departamentos y proveedores de tecnología sumamente costosos que no lograban satisfacer las necesidades y mucho menos la velocidad de crecimiento requerida por las compañías.
Es en este momento, cuando las corporaciones de mercados diferentes a las tecnologías de la información empezaron a preguntarse cómo los gigantes (Facebook, Amazon, Google, Microsoft) podían soportar su operación basados únicamente en tecnología, mientras ellos no podían confiar en sus propias plataformas aparentemente menos complejas. Y la respuesta iba en la ruta contraria a lo que estuvieron haciendo la ultima década, el mensaje era “Volver a lo Simple” y es justo en este punto donde las habilidades de desarrollo desempeñan un papel primordial.
¿Y qué Significa “Volver a lo Simple”?
La unidad mas básica, simple y compleja de lograr en el software es el código. Volver a lo simple significaba estimar, planear, gestionar, implementar y monitorizar el software desde su componente básico 'el código' y esto requería de las personas que mejor lo conocen, los desarrolladores. Y es aquí cuando las diferentes disciplinas del software empresarial empiezan a requerir en mayor cantidad y calidad de desarrolladores.
¿En la metodología?
Los ciclos de vida de software y metodologías tales como RUP requerían de analistas tan expertos en la metodología como en el negocio. Sus resultados eran tan buenos como demorados, además de un time-to-market elevado tenían a los stakeholders cubiertos bajo montones de documentos y artefactos de software (no código) que dejaban poco espacio para el desarrollo de soluciones pertinentes. Generaban equipos, clientes y usuarios insatisfechos y productos de software de baja calidad, ya qué dejaban menos de un tercio del tiempo del proyecto a la implementación de solución.
Pese a que en un comienzo muchos confundían la agilidad con ‘facilidad’ o con ‘poco formal’, el tiempo y la experiencia de los equipos han llevado a las metodologías ágiles (pe. Scrum) a ocupar un lugar privilegiado en equipos, compañías y proyectos exitosos no solo de software sino de otras ramas de la ingeniería. Las metodologías ágiles tienen como principios fundamentales involucrar al usuario como parte activa del proceso de implementación y generar productos de valor mas rápido en el ciclo de desarrollo. Sin embargo tiene un costo, en consecuencia todos los stakeholders deben estar dispuestos a ceder en el resultado esperado debido a que las primeras versiones de un producto (versiones alfa o beta) seguramente van a requerir mejoras y ajustes.
En resumen, una metodología ágil trae consigo equipos comprometidos con el resultado, usuarios satisfechos y productos de software pertinentes de mejor calidad. Como consecuencia, los desarrolladores producen componentes de software mas rápido, extensibles y mantenibles entendiendo mejor los requisitos del producto. Dado que, una metodología ágil requiere código prácticamente desde su primer momento y todo el proceso gira en torno a la evolución de este código
>¿Y en desarrollo?
Pese a que hoy parezca obvio, en la década anterior el desarrollo de software era cada vez menos código, con los grandes fabricantes y algunos referentes de la industria cada vez mas enfocados en soluciones orientadas a servicios (Productos SOA, Middleware, Servidores de Aplicaciones, etc) que en su promesa de valor requerían cada vez menos código. Como consecuencia, los desarrolladores pasaron a un papel secundario, su rol era la configuración e implementación de estas plataformas y cada vez menos código dejando a los desarrolladores en la pregunta de “¿Me convierto en experto en alguna plataforma o me especializo en gestión de proyectos?”, pero cuando aparecían los problemas, las plataformas no funcionaban, se quedaban cortas respecto a los requerimientos del cliente o simplemente no alcanzaban, todos pensaban en el desarrollador que estaba en el escritorio mas empolvado de la oficina.
Pero ocurrió lo que muchos vieron venir antes, los negocios crecieron y cada vez requerían más de sus aplicaciones empresariales. Debido a ello, las plataformas y tecnologías se quedaron cortas entonces todos se dijeron lo mismo, “¿si antes todo era código y funcionaba bien, por que no volver allí?”, y así fue que apareció un concepto algo confuso al comienzo “Microservicios”. Al comienzo, se pensaba que era otra promesa fallida como SOA o que se trataba simplemente de piezas de código minúsculas. Sin embargo, se trata de componentes de software que cumplen un único propósito dentro de un software o compañía, pero fundamentalmente su base es código, y su configuración implementación y despliegue hace parte integral del mismo código.
Es así como desde el mismo desarrollo de microservicios, los desarrolladores están obligados a pensar e implementar (oh sorpresa, como código) las pruebas, la infraestructura, despliegue, administración y monitoreo de cada microservicio, dándole al desarrollador la responsabilidad total del ciclo de vida de un componente de software. Este principio, se basa en conceptos particulares que cada desarrollador debe tener en cuenta a la hora de implementar microservicios: desarrollo, pruebas [Unitarias, integrales, regresión], infraestructura [Contenedores], despliegue [pipelines, CI+CD] y monitoreo [Logs y trazabilidad distribuida] y cada uno de estos conceptos es más y más código.
En conclusion
Volver a lo simple ha recuperado la confianza en los departamentos y proveedores de tecnología, dando cabida a nuevas habilidades de desarrollo y nuevas herramientas (no enfocadas en soluciones completas sino en el soporte de soluciones implementadas) disminuyendo el time to market, plataformas de software generando valor real en los negocios y con valor no solo operativo sino estratégico dentro de las compañías. Por esto y muchas otras razones se debe aun re-evaluar el rol que rol secundario que desempeñan los desarrolladores en cada vez menos compañías.
Al diligenciar la descripción de su perfil en el currículum piénselo muy bien antes de escribir “Desarrollador Full Stack” quizá el mejor concepto sea solo “Desarrollador”.