Tu código en producción debería de tener bugs

Lucas Pauker:

Cada línea de código en producción es una apuesta entre velocidad, seguridad y corrección. Cuando envías software, estás equilibrando:

1. Hacerlo rápido → enviar más rápido significa que la funcionalidad aparece antes para los clientes y, en última instancia, el negocio gana más dinero.
2. No introducir bugs → los bugs pueden causar caídas de servicio u otros errores que llevan a pérdidas.

El problema es que cualquiera que haya trabajado con software sabe que, pase lo que pase, no puedes garantizar que el software que envías no tendrá bugs. De hecho, tu software siempre tendrá bugs. No importa cuántos “lgtm” reciba tu pull request, los bugs siempre encuentran la manera de colarse.

La habilidad más importante a desarrollar lo antes posible si quieres trabajar en software: resiliencia. No se trata de si falla, sino de cuándo va a fallar.

Propongo que, como ingenieros de software, cambiemos nuestra mentalidad de “no debería haber bugs en mi código” a “debería gestionar el riesgo de nuevos bugs”. Deberías tener bugs en tu código si quieres enviar el mejor software. Un equipo de software tiene capacidad limitada, y el intercambio entre nuevas funcionalidades y la reducción de bugs debería considerarse seriamente. Necesitamos un marco para tomar decisiones sobre cuánto tiempo deberías dedicar a una tarea para gestionar el riesgo de bugs.

Lucas propone que los ingenieros comencemos a factorizar el riesgo en nuestra toma de decisiones (las negritas son mías):

El valor que aporta una funcionalidad es proporcional al tiempo que está disponible para los usuarios. En otras palabras, cuanto más retrases una nueva funcionalidad, menor será el valor total que aportará a la empresa. El riesgo de la funcionalidad es difícil de cuantificar, ya que es desconocido. Sin embargo, con base en la experiencia, existe un rango de bugs posibles para un cambio de código determinado. En general, deberíamos pensar en el peor escenario posible que podría ocurrir al implementar una nueva funcionalidad.

Una vez que tenemos una idea del valor que aporta una funcionalidad y del riesgo de bugs, podemos sopesarlos entre sí. Debería existir un punto en el que esperar más para lanzar una funcionalidad no reduzca el riesgo de bugs lo suficiente, y ese es el momento en el que deberíamos lanzar la funcionalidad.

Muchos ingenieros se quedan en el riesgo técnico de su trabajo e ignoran el riesgo para el negocio de no lanzar la funcionalidad. Si no tienes la capacidad de entender el impacto de tu funcionalidad en el negocio y en el usuario, no estás haciendo tu chamba como desarrollador de software: buscar la manera de resolver problemas.