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.