El código es una carga

Como profesionales en el área de tecnología generalmente tratamos el desarrollo de un sistema o aplicación, como la solución a muchos problemas en el negocio o en lo personal.

Creo que este comportamiento está atado al hecho de que es nuestra herramienta principal, somos desarrolladores de software, y muchas veces caemos en el vicio de que si tenemos un martillo todo lo vemos como un clavo.

Con la experiencia adquirida en mi recorrido profesional, he comenzado a ver al desarrollo no como un activo sino como una carga, cuando se escribe software no solo se hace el desarrollo para ese problema inmediato, tenemos que ver a futuro, los lenguajes, plataformas, etc. requieren mantenimiento, se deben hacer actualizaciones, se debe verificar que las dependencias sean estables y soportadas, verificar que haya actualizaciones de seguridad, se debe entrenar a los colegas o escribir documentación ya que no siempre vas a estar ahí como el único que sabe cómo funciona un sistema. Y si eso no se hace se puede caer en un problema ya que pueden emerger problemas de seguridad de la información.

En este momento de mi carrera prefiero comprar software hecho o rentar como servicio en el que se incluya todo el mantenimiento, muchas veces esto resulta más barato que hacerlo dentro de casa, ya que a la larga en el mejor de los casos los costos de mantener un sistema son altos, y en el peor de los casos el no hacerlo abre un hueco de seguridad que creo que ninguna empresa o persona esté dispuesto a tener.

Cuando ya tienes un sistema en marcha, más código también es una carga, un nuevo requerimiento puede hacerse pero genera deuda técnica o incrementa la complejidad del sistema, hay que pensarlo bien antes de decir SÍ a un nuevo requerimiento, me parece que los desarrolladores de docker tenían esta filosofía: SÍ es para siempre, NO es temporal que quiere decir que si dices SÍ a una nueva característica la tienes que soportar a futuro, el NO es para pensarlo y ver una mejor solución sin incrementar la complejidad o deuda técnica y puede volverse SÍ una vez simplificado y con responsabilidad.

Suscríbete y cuéntame si alguna vez hubieras preferido decir que NO a un nuevo requerimiento.