En tecnología, normalmente asociamos el «diseño» con los desarrolladores front-end y la estética visual: un sitio web hermoso o una interfaz de usuario visualmente atractiva. Pero los desarrolladores backend también son diseñadores. Son maestros en el diseño de sistemas y elaboran meticulosamente la arquitectura, las dependencias y las estructuras de datos que influyen en las experiencias de los usuarios. Esta publicación explorará el arte oculto en su trabajo.
Internet está repleto de memes de “dev vs diseñador”, y es innegable que es una colaboración que puede producir resultados tanto espectaculares como divertidos. “Diseñador” es un término que a menudo – y a veces exclusivamente – asociamos con roles relacionados con el “diseño de interfaz” como Diseñador Web, Diseñador UI/UX, Diseñador de Producto, etc. Quizás, incluso inconscientemente, lo asociamos con alguien artístico, creativo y con un enfoque en crear productos hermosos e intuitivos con una estética cuidadosamente cultivada.
Sin embargo, centrarse en el arte del “diseño” a menudo nos lleva a olvidar su lado pragmático. En última instancia, diseñar significa tomar decisiones sobre cómo deben verse, funcionar y operar las cosas para cumplir objetivos específicos. Es por eso que los ingenieros de software backend también son diseñadores y el «diseño de sistemas» es también una categoría de diseño.
Más allá del hecho de que los ingenieros de backend pueden contribuir al diseño de un producto con comentarios e ideas, lo cual es una toda la conversación en sí mismo, también tienen que decidir y dar forma consistentemente al diseño del software. Desde toda la arquitectura de un sistema hasta sus dependencias individuales y estructura de datos, los desarrolladores deben tomar cientos de decisiones que impactan la experiencia del usuario final y la usabilidad y mantenibilidad del software.
Aunque a menudo se enfrentan entre sí en divertidos memes, en realidad son más similares de lo que la gente piensa.
Publicación de Andy Bell en x (Twitter)
El lado pragmático del diseño
El diseño es una moneda de dos caras: estética y creatividad por un lado y pragmatismo por el otro. Ambos coexisten y son esenciales para ofrecer un producto que cumpla con las expectativas y requisitos del usuario, pero el lado artístico suele ser más visible: prioriza cosas como una interfaz atractiva e intuitiva, que es lo que los usuarios notan y aprecian de inmediato.
El lado pragmático es igualmente importante a la hora de orientar las opciones hacia soluciones que sean eficaces, escalables y mantenibles… sin embargo, estos aspectos no siempre son tan visiblemente evidentes para los usuarios.
Las opciones de diseño de un ingeniero de software impregnan cada capa de la pila tecnológica y tanto los ingenieros de frontend como de backend luchan con ellas a diario. Incluyen cosas como:
- Definición de la arquitectura del sistema.
- Agregar un nuevo microservicio
- Incorporación de un nuevo proveedor de SaaS
- Cambiar una API
- Editar la estructura de datos
Es un error pensar que los desarrolladores de backend simplemente “producen código”: las decisiones de diseño tomadas al crear el backend de una aplicación dan forma indirectamente a la experiencia del usuario y son tan importantes como las decisiones de front-end. Por ejemplo, piense en el tiempo de carga de una aplicación, qué tan rápido puede buscar los datos, qué tan fluida es la experiencia del usuario en cualquier ubicación, etc.
La confiabilidad, la escalabilidad, el rendimiento y la eficiencia son aspectos de una aplicación que damos por sentado la mayor parte del tiempo, pero es dolorosamente obvio cuando faltan y algo sale mal, es decir, cuando tomamos malas decisiones de diseño del sistema backend.
El arte de los ingenieros backend
Llamar “artistas” a los ingenieros de backend parece ser una exageración hasta que te das cuenta de la cantidad de creatividad, intuición, adaptabilidad y resolución de problemas necesarias para construir el backend de un sistema distribuido complejo. Entre los muchos enfoques posibles para lograr un objetivo determinado, el ingeniero de backend debe seleccionar el diseño que cumpla perfectamente con los requisitos y que al mismo tiempo pueda evolucionar con gracia con el tiempo.
Desde una perspectiva macro, los ingenieros de backend deben evolucionar su enfoque en función de los cambios tecnológicos en toda la industria.
Piense, por ejemplo, en cómo la programación solía requerir escribir código desde cero, línea por línea. Ahora es un enfoque similar a un ensamblaje, donde los ingenieros de backend deben seleccionar y combinar meticulosamente componentes, bibliotecas y marcos para crear un sistema completo donde cada pieza encaje a la perfección.
O considere tener que adoptar nuevos tipos de arquitecturas de software, paradigmas de programación, etc. para cumplir con los requisitos impuestos con el cambio hacia sistemas distribuidos y aplicaciones nativas de la nube.
A nivel empresarial, es posible que necesiten elaborar diseños que cambien deliberadamente con el tiempo (es decir, diseño de sucesión y arquitectura evolutiva) debido a requisitos futuros del producto conocidos o desconocidos. O tal vez necesiten revisar sus opciones tecnológicas y evolucionar sus opciones de pila tecnológica para aprovechar las nuevas tecnologías (por ejemplo, LLM)
Como nota personal, a lo largo de mis años en tecnología he conocido a una gran cantidad de ingenieros que también son músicos o artistas visuales talentosos. Si bien no pude encontrar ningún estudio oficial que corrobore esta observación, no me sorprendería saber que existe una correlación entre ser un gran desarrollador y ser un gran músico o artista.
También vale la pena señalar que muchos ingenieros realizan diseño lógico/funcional implícitamente, sin darse cuenta (por ejemplo cuando desglosan una Historia de Usuario). Sin embargo, aceptar plenamente la necesidad de Diseño de Sistemas y aplicarlo en su trabajo diario se convierte en una enorme ventaja competitiva, incluso sólo por su capacidad para evitar la deuda técnica, es decir, identificar áreas de «alta cohesión» y resaltar dependencias potencialmente de «alto acoplamiento» que debería ser evitado.
En el panorama en constante evolución del desarrollo de software, las líneas entre los roles de «desarrollador» y «diseñador» seguirán volviéndose más borrosas.