Una visión pragmática sobre el desarrollo de software

Rubén Salado
Genially Tech
Published in
4 min readJun 22, 2021

--

Si algo nos caracteriza a los desarrolladores de software es la pasión que tenemos por la tecnología. En general, nos encanta estar al día, aprender y probar ese último framework o implementar esa nueva arquitectura o patrón de desarrollo del que tanto se empieza a hablar y que es la solución a todos nuestros problemas. Sin embargo, esta misma pasión puede llevarnos a caer en el lado oscuro, y es que también tendemos a infravalorar, o directamente ignorar, todo aquello que no está de moda o que creemos obsoleto. Conocer la historia del desarrollo de software debe servirnos, entre otras cosas, para mejorar y para no acabar reinventando la rueda.

Cada biblioteca, cada framework o cada base de datos se sustenta sobre unas bases teóricas, unos fundamentos que tienen por objetivo dar solución a un problema o rango de problemas. Es casi obligatorio, como profesionales del software, comprender e interiorizar la naturaleza de la tecnología para poder tomar la mejor decisión para nuestro negocio. Porque no debemos olvidar nunca que la tecnología debe estar al servicio de nuestro negocio, y no a la inversa.

El código no es bueno ni malo, depende del contexto

Una startup tecnológica, como cualquier empresa, no es un ente estático ni inmutable, más bien todo lo contrario. Si algo caracteriza a este tipo de empresas es su rápido crecimiento y su gran capacidad de innovación y cambio, lo que en el mundo startup se conoce como “pivotar”. Así, desde el momento de su fundación, una startup está sometida a un ritmo frenético de evolución y adaptación, desde todos los puntos de vista.

Desde un punto de vista humano, toda la responsabilidad del negocio recae inicialmente sobre pocas personas, que asumen múltiples roles con el objetivo de validar su producto, captar clientes y lograr cierta situación económica que permita su continuidad. Si todo va bien, la incorporación de nuevos compañeros permite la especialización y ampliación de las responsabilidades a asumir. Desde un punto de vista tecnológico, el producto igualmente está sometido a una continua validación, crecimiento y mejora. Lo que hoy es válido, mañana puede que no lo sea. Adaptarse o morir.

Genially, como startup tecnológica de producto, es un claro ejemplo. A lo largo de todos estos años, tanto nuestra organización interna como nuestro producto (y por ende nuestro código) han sufrido numerosos cambios según las necesidades propias de cada una de las etapas en las que nos hemos encontrado. ¡Y aún seguimos evolucionando! Pero estos cambios no son arbitrarios, son respuesta a los mismos cambios que experimenta nuestro negocio, a los nuevos problemas y nuevas necesidades de nuestros usuarios.

Aunque parezca que nada de esto tiene nada que ver con el desarrollo software, nada más lejos de la realidad. Tan importante como analizar y entender el código es entender el contexto en el que se encuentra. Si obviamos esto último, podemos caer en el error de tomar decisiones que van en contra de nuestro propio negocio. Los aspectos puramente técnicos no deben guiar la arquitectura de nuestro software. O dicho de otra forma, la arquitectura del software debe estar directamente influenciada por el contexto de nuestro negocio.

Por ejemplo, no parece muy adecuado, en una fase inicial de una startup que cuenta con dos personas en el equipo de desarrollo y cuyo producto debe ser aún validado, pensar en una arquitectura basada en microservicios. Igual de dudoso es tener un monolito con un equipo de desarrollo de cien personas, en una empresa con un modelo de negocio validado en un claro estado de crecimiento. Todo depende del contexto. La clave está en entender cuáles son nuestras necesidades para poder adoptar la mejor solución en cada situación.

Todo esto es algo que hemos comprendido a base de aciertos y errores, de tirar muchas líneas de código, y de dedicar tiempo a analizar y a darle vueltas a la cabeza. Entendemos el software como algo cambiante, algo que evoluciona constantemente en consonancia con nuestro negocio.

Todo cambia, todo evoluciona

Nuestro código no es más que la consecuencia de las decisiones tomadas en un contexto específico, en pro de nuestro producto y de nuestros usuarios. Es lo que nos lleva a estar donde estamos hoy en día y a ser lo que somos. Estamos orgullosos de ello. No nos avergonzamos. Es más, estamos dispuestos a seguir mejorando.

Este afán de mejora va de la mano de las necesidades de nuestro negocio. Como empresa de producto que somos, nuestro código es nuestro principal valor y debe estar preparado para evolucionar. No damos nada por sentado porque lo que hoy vale, mañana puede que ya no. Es lo que nos lleva a estar inmersos en un continuo proceso de mejora y crecimiento. Eso de “si funciona, no lo toques” no va con nosotros, aunque siempre aplicando el sentido común.

Ejemplo de ello es el cambio de lenguaje de programación (nuestra primera versión fue desarrollada en C# y actualmente trabajamos con JavaScript en cliente y servidor), migración de infraestructura (nos movimos de Azure a AWS), utilización de bases de datos relacionales y no relacionales (actualmente nuestros datos están repartidos entre PostgreSQL, MongoDB y S3) y un largo etcétera.

Conclusiones

Nuestra visión sobre el desarrollo de software es la consecuencia de todo lo que hemos experimentado desde nuestros comienzos. Una mezcla entre pragmatismo e inconformismo pero siempre poniendo el foco en nuestro producto y en las necesidades de nuestros usuarios. Hasta ahora no nos ha ido mal, pero eso no significa que seamos perfectos ni que no tengamos margen de mejora. Eso es lo mejor de todo, que aún nos queda mucho más por aprender.

--

--