El término full stack developer fue popularizado por Facebook a finales de la década del 2000, inicialmente refiriéndose a una persona que era capaz de desarrollar software en el front end y en el backend, es decir, un desarrollador con los conocimientos necesarios y suficientes para lograr una solución de software completa por sí mismo. Facebook se refería a desarrolladores que hacían uso de las herramientas que en dicha década facilitaron algunas partes del software sin tener que ser un experto en el tema, por ejemplo, fueron desarrollados frameworks y componentes para el acceso a datos, el manejo de servidores de aplicaciones se redujo a usar herramientas provistas por plataformas que fueron ofrecidas como servicio y salieron al mercado frameworks que permitieron modelar la vista de manera más natural para los desarrolladores full stack, sin requerir grandes habilidades en front end para lograr interfaces y usabilidad aceptable para una solución rápida. Este full stack developer se parecía a una navaja suiza, una solución a varios tipos de problemas en una sola herramienta:
En la medida en que el tiempo pasó, fuimos creando sistemas más complejos, buscando satisfacer diferentes tipos de necesidades y problemas que cada vez vienen siendo más exigentes, y con esta complejidad diferentes especialidades se han ido requiriendo para la construcción de una aplicación, es así como, hoy en día el desarrollo de un software web requiere conocimiento en html, css, javascript, bootstrap, polymer, angularJS, algoritmos de machine learning, big data, nosql, procesamiento paralelo, middleware de comunicaciones, programación orientada a aspectos, programación funcional, computación distribuida, seguridad, desarrollo mobile, una gran variedad de lenguajes y frameworks. Y es entonces cuando a nuestro full stack developer lo imaginamos como la siguiente navaja suiza:
La verdad es que con este artículo quiero compartir algunas ideas que he venido desarrollando con diferentes personas, en especial con Hernán Wilkinson, colega apasionado por el desarrollo de software y cofundador de la empresa 10Pines. Con Hernán he tenido la oportunidad de discutir diferentes aspectos de esta temática, y hemos construido juntos esta idea de lo que sería en la actualidad, que realmente no creemos que se parezca mucho a la navaja suiza de excesivas herramientas, y por esto, me gustaría tratar algunos mitos que nos ayudarán a construir una buena definición del full stack developer de hoy:
MITO 1:
El programador no debe conocer el negocio, sólo “codifica”
Históricamente hemos desarrollado software siguiendo procesos por etapas y trabajando en silos organizacionales, es decir, teníamos un equipo experto que se encargaba de realizar un análisis completo del software, luego pasábamos sus especificaciones a un equipo de arquitectura que diseñaba la solución, de ahí el control pasaba a un equipo de programadores… y así sucesivamente, cada equipo tenía una responsabilidad única, independiente de las responsabilidades de los demás equipos y nadie era responsable del producto o el valor final del producto.
Resumiendo lo anterior, no solíamos trabajar en equipo para desarrollar software y esto generaba tremendos teléfonos rotos, pérdida de información, ineficiencias, el programador hacía lo que creía que resolvía un problema de negocio pero no entendía el valor, no sabía para qué servía o qué problemática se estaba tratando de resolver con la solución desarrollada, esto además, impedía que el desarrollador pudiera proponer alternativas de solución, siendo el experto conocedor, tal vez, desaprovechando tecnologías y herramientas que seguramente ayudarían de mejor manera el propósito del usuario final del software.
Esto es un mito completo, esta forma de trabajo solo trae consigo problemas, hemos tenido experiencias terribles de fracaso desarrollando productos de esta manera, el programador debe conocer el negocio, debe saber cuál problema está resolviendo.
MITO 2:
El programador no debe testear, solo programa
En esa forma tradicional de trabajo, basados en silos organizacionales, desarrollo iba por una parte, y QA (Quality Assurance) por otra, QA era un equipo que verificaba, es decir, eran ellos los que daban el visto bueno o no, después de que los desarrolladores entregaban las funcionalidades. Solían ser dos mundos completamente distintos: cuando el equipo de desarrollo terminaba, pensaban que lo que ocurriera después no era su problema, a menos que que se encontraran errores, y viceversa. A QA no le importaba el desarrollo, solo verificaban que estuviera todo funcionando como ellos entendían que debía funcionar.
La historia en Ceiba no difiere mucho de ese escenario, tuvimos un equipo de calidad que llegó a ser de 10 personas, solía ser un tema muy complejo de manejar, había momentos en que los proyectos no estaban a tiempo y los cronogramas no encajaban, entonces el equipo de calidad no tenía trabajo por hacer, otras veces teníamos todos los proyectos listos para probar y el equipo no daba a basto. Los desarrolladores con la presión de “hágalo como sea pero para ya”, entregaban desarrollos sin importar la calidad de los mismos, y QA empezaba a devolver desarrollos. Esto se convertía en ciclos infinitos de nunca acabar.
Hace algunos años el tema ha cambiado, nos hemos dado cuenta de que la calidad es responsabilidad de todo el equipo, los desarrolladores somos el primer tester de las aplicaciones, y como tales debemos poner atención continua al estado de nuestro producto. Uno de los principales objetivos de la agilidad, es mejorar la calidad del software y entregar continuamente pequeños incrementos de software garantizando que todo está funcionando adecuadamente, y debemos hacerlo rápido, no tendría sentido que desarrollaramos un pequeño incremento, pero para garantizar que todo está funcionando adecuadamente nos tardemos demasiado tiempo.
Para responder rápido, necesitamos entornos altamente colaborativos; equipos multidisciplinarios, capaces de producir incrementos y mejoras en el software con la calidad esperada, objetivos comunes y una visión clara, esto no quiere decir que algunas personas dentro de este equipo no puedan ser expertas en testing, de hecho requerimos personas expertas para lograr que el equipo en si pueda lograrlo.
Ahora, el objetivo del testing no solo es detectar fallos, sino en la medida de lo posible, prevenir dichos fallos; por esto, la calidad, y el testing empiezan en fases tempranas de desarrollo y es una responsabilidad que un desarrollador full stack lleva a cabo de manera continua.
MITO 3:
Solo se modela/diseña cuando se usa UML
Este es quizás el mito que más me gusta, pues en varias conversaciones con Hernán Wilkinson, él ha compartido conmigo su visión sobre lo que significa desarrollar software, para él desarrollar software es en sí mismo, es un proceso de modelado, de diseño, una definición con la que congenio completamente, pues escribir código no es más que representar entidades de la realidad en un lenguaje.
Nosotros realmente no construimos, la construcción la hace el compilador, entonces nuestra labor como desarrolladores es precisamente abstraer realidades, crear modelos en un dominio concreto, no solo modelamos cuando usamos UML o diagramas, cuando escribimos código modelamos, cuando hacemos TDD modelamos, y tenemos que tener esto claro, porque de lo contrario, vamos a seguir pensando que alguien se encarga del diseño haciendo unos diagramas y luego cuando codificamos, no representamos correctamente el dominio al que pertenece el software que estamos construyendo.
MITO 4:
El programador sólo puede programar en front o en backend
Hace algunos años cuando los desarrollos que hacíamos eran basados en arquitecturas cliente servidor o aplicaciones web 2.0, teníamos especialistas del backend con conocimientos como:
-Algún lenguaje de programación, por ejemplo Java, C#, PHP, Python, Ruby
-Y conocimientos importantes en temas de Bases de datos relacionales como diseño ER, tercera Forma normal, SQL, triggers, procedimientos almacenados e índices.
Recuerdo mis primeras experiencias como developer en empresas desarrolladoras de software en las que, como desarrollador backend principalmente, no sabía escribir ni manejar HTML ni Javascript, estas eran especialidades de personas que se encargaban del Front End, un área diferente a la mía a la que en aquel entonces llamábamos diseño gráfico.
En esos tiempos, el programador definitivamente solo podía programar en backend o en frontend, sin embargo, eso cambió por la época del 2000, cuando Facebook popularizó este tema de los full stack developers y cuando las arquitecturas evolucionaron y creamos frameworks y herramientas que permitieron que los developers pudieran hacer algunas tareas de manera más autónoma sin requerir conocimientos altamente especializados, logrando que un único desarrollador pudiera construir características de principio a fin, desde el front hasta el back, desmitificando ese sesgo que solíamos tener de que un desarrollador solo podía hacer desarrollos en uno u otro.
Pero ahí no termina la historia, los tiempos han cambiado, las necesidades del mercado han traído consigo un crecimiento exponencial de tecnologías que cada día deseamos más en nuestras soluciones. Hoy no concebimos una solución que no tenga interacción con dispositivos móviles, algún algoritmo de predicción o clasificación, un repositorio de datos no estructurado o el manejo de volúmenes de información que superan los teras, un middleware de comunicaciones altamente disponible y por supuesto, garantizar características como escalabilidad y disponibilidad en soluciones globalizadas, y estos son los retos a los que nos enfrentamos ahora.
Entonces estamos en días en los que el desarrollo de una solución tiene más caras que la de Back y Front, exige especialidades en diferentes áreas que hacen que tan solo pensar que una persona entienda funcionalmente todos los actores de un ecosistema como este, sea ya en sí mismo complejo.
No importa el tipo de desarrollo que queramos hacer, los full stack developers de hoy debemos buscar conocimientos especializados pero debemos estar en capacidad de hablar y entender los términos de las demás caras de la solución, pero lo que es aún más importante, es contar con habilidades como:
-La atención al detalle
-La capacidad de aprender rápidamente
-La capacidad para resolver problemas de modo eficiente
-Habilidades de investigación, comunicación, y de argumentación
MITO 5:
Los de operaciones no desarrollan
El software que desarrollamos no genera valor si no está disponible, habilitado, funcionando y es usado por las personas. Debemos entender esto para concientizarnos de que el ciclo de desarrollo de una característica debe considerarse desde la solicitud y priorización de la característica, hasta el delivery de esa funcionalidad en los ambientes productivos o reales en los que nuestros usuarios puedan hacer uso de dichas características. Es así como, nos encontramos retos en operaciones como:
Velar porque las nuevas características, configuraciones y componentes, no afecten la estabilidad del sistema, realizar las verificaciones de compatibilidad y reducir los tiempos de delivery, automatizar la mayor cantidad de tareas posibles para lograr reducir dicho tiempo, monitorear de manera continua los ambientes, y adaptarse a las necesidades de demanda de uso de las aplicaciones de manera rápida.
Es evidente que el equipo de operaciones hace parte del ciclo de vida del desarrollo, por tanto, deben hacer parte de dicho equipo, cross funcional; debe entonces enfrentar los retos con que cuenta hoy esa última milla del delivery del desarrollo del software.
Además, para ello contamos hoy con herramientas que nos permiten hacer definiciones de infraestructura como código por ejemplo, y por supuesto, si tenemos infraestructura como código, podremos hacer gestión de la configuración de estos artefactos, y así poder realizar los cambios con un control más automático, manejar versionamiento de las configuraciones, realizar pruebas automáticas de cómo se va a comportar un cambio o un ajuste en la configuración de un servidor. Definir los procesos de delivery y automatizar la mayor cantidad de pasos de dicho proceso de manera que garanticemos la entrega oportuna de los desarrollos que hagamos.
Conclusiones
De los anteriores mitos, podemos concluir entonces que:
Necesitamos equipos en los que de manera conjunta tengamos las capacidades necesarias para sacar adelante los proyectos, sin que esto signifique que todos seamos expertos en todo, pueden existir especialidades, pero hablamos el mismo lenguaje y somos capaces de comunicarnos y trabajar por lo mismos objetivos.
Necesitamos desarrolladores completos; nos referimos a desarrolladores con skills humanos que faciliten el logro de dichos objetivos, solucionadores de problemas, buenos comunicadores, comprometidos, que seamos capaces de aprender rápidamente, y por supuesto, que tengamos skills técnicos.
Como full stack developers de hoy, debemos comprometernos con el negocio, con el resultado final, solo generamos valor si mejoramos el negocio y la vida de nuestros clientes y/o usuarios finales.
Definitivamente, el término full stack developer ha cambiado, la definición popularizada por Facebook a trascendido de una definición que consideraba sólo al individuo, a una en la que este individuo hace parte de un equipo, con el cual comparte una visión, un lenguaje, unas capacidades y unos conocimientos técnicos especializados.
