¿Los errores están matando tu impulso?

Los errores de software son una ocurrencia común en el mundo de la tecnología. Si alguna vez escribió más de diez líneas de código, es probable que haya causado una accidentalmente.

Ahora, me gustaría que pensara en la última vez que recibió un mensaje de un cliente o colega asustado por un error. ¿Cómo terminó? ¿El error era tan urgente que tuviste que dejar de hacer lo que estabas haciendo?

En este artículo, intentaremos desafiar el pensamiento convencional sobre los errores y explorar cuánto le está costando a usted y a su equipo cada error.

Acerca de mí

Hola 👋, mi nombre es Krste y soy un desarrollador full-stack que ha estado trabajando en nuevas empresas durante más de siete años. Recientemente, cofundé Bugpilot , una plataforma de monitoreo de errores que alerta a los equipos de software sobre errores críticos que enfrentan los usuarios.

Escribí este artículo con el objetivo de desafiar el pensamiento convencional sobre los errores y el "¡tenemos que solucionarlo lo antes posible!" mentalidad, cuestionando la necesidad de explorar el verdadero costo de cada problema.

Software 100% libre de errores. ¿Mito o Realidad?

El objetivo de lograr un software 100% libre de errores siempre ha sido complicado. La idea de crear una aplicación sin errores puede parecer ideal, pero ¿es realmente posible?

La verdad es que los errores de software son inevitables debido a la lógica comercial compleja, los errores humanos y las actualizaciones continuas de la tecnología. Incluso con pruebas cuidadosas y controles de calidad, es difícil eliminarlos por completo.

Sin embargo, gracias a las nuevas herramientas para desarrolladores y los procesos mejorados, los equipos ahora están enviando nuevas funciones a un ritmo vertiginoso para poder seguir siendo relevantes y competitivos.

Y, con cualquier cambio en el código base, siempre es posible romper algo. (Tener que admitir muchos dispositivos y múltiples navegadores no ayuda en absoluto).

Por supuesto, hay casos en los que los errores deben estar cerca de cero. Ciertas industrias, como la banca, la médica y la aeroespacial, deben asegurarse de que los errores se reduzcan al mínimo, ya que podrían costar vidas .

Eso explica por qué la mayoría del software en estas industrias está escrito en tecnologías de hace décadas y por qué la gente ahora duda en tocarlo.

Pero al final, tenemos que preguntarnos: "¿Vale la pena todo esto? " Para la mayoría de los que creamos herramientas de marketing y CRM, creo que corregir errores suele ser más costoso que dejarlos tirados. Intentaré explicar por qué.

No todos los errores son iguales

Imagine que está trabajando en un sitio web de comercio electrónico y un error interrumpe el proceso de pago, lo que hace imposible que los clientes completen sus compras.

Es dolorosamente obvio que este error necesita atención inmediata, ya que afecta directamente la funcionalidad principal y puede resultar en pérdidas de ventas y clientes insatisfechos.

Del mismo modo, no podemos tratar un error en la página de registro que impide que los nuevos usuarios se unan a nuestra nueva aplicación de viajes compartidos de la misma manera que un problema relacionado con la actualización de la foto de perfil .

Estos ejemplos en blanco y negro muestran que no solo necesitamos detectar, sino que necesitamos una forma de comprender el impacto de los errores. Sin embargo, en realidad, las cosas no son en blanco y negro. La mayoría de las situaciones caen dentro del área gris. La pregunta entonces es: ¿cómo sabemos qué arreglar?

“TENEMOS QUE ARREGLARLO AHORA O EL CLIENTE SE VA A IR”

He notado que tendemos a agregar un sentido de urgencia "adicional" a los errores que encuentran nuestros clientes.

Probablemente haya estado en una situación similar cuando uno de sus clientes más grandes tiene un problema menor y todo su equipo se inunda con mensajes como si el mundo estuviera en llamas 🔥

”Giovanni se quejó de que no pueden alinear a la derecha el texto 11 1 Son un cliente importante. ¡Debemos arreglar el error AHORA!”

- su jefe

Según mi experiencia, los roles de cara al cliente, como el éxito del cliente, el soporte y las ventas, tienden a priorizar los problemas según cómo reaccione el cliente y cómo afecte su reputación. Es por eso que todo puede parecerles un gran problema, lo cual es comprensible.

Nadie quiere dar una mala impresión o tener una reputación negativa, y eso es exactamente lo que pueden causar los errores.

Cuantos más usuarios se ven afectados por un error, más importante (probablemente) es solucionarlo

A veces, los problemas de producción se tratan a medida que ocurren. Especialmente nosotros, los desarrolladores, saltamos de inmediato ante cualquier error o error de codificación que llega a su bandeja de entrada.

Usted o su equipo pueden estar usando una herramienta como Sentry o Bugsnag para monitorear y recibir notificaciones cuando ocurran errores. Cuando se encuentra algún error, se asigna rápidamente a un desarrollador mientras todos esperan con impaciencia una actualización en Slack.

Por lo general, estas herramientas priorizan los errores según la frecuencia con la que ocurren y la cantidad de usuarios afectados.

Human.prioritizeBugs()

Sin embargo, es probable que la prioridad de la mayoría de los errores en la mayoría de los equipos la determine el propietario del producto o el desarrollador principal. Estos roles suelen tener una comprensión de la lógica comercial, la tecnología subyacente, la carga de trabajo actual y las próximas prioridades y planificar en consecuencia.

Sus criterios de priorización podrían verse así:

¿Es crítico o no? Primera pregunta, pero ya se está complicando un poco. ¿Qué es crítico? Crítico no tiene una definición clara. Si una función central no se puede usar, entonces es bastante obvio que debemos arreglarla. Sin embargo, como vio en el ejemplo anterior, ¿qué sucede si un cliente importante se ve afectado?

¿A cuántos clientes está impactando? ¿Solo uno? ¿Todos? ¿Lo sabemos? Cuando se ve afectada una cantidad significativa de usuarios, es posible que desee abordar el problema, incluso si está relacionado con una funcionalidad menor.

¿Cuánto tiempo se tarda en arreglarlo? A continuación, el propietario del proceso "Evaluación de errores" preguntará cuánto tiempo lleva solucionar el problema. Si solo toma un par de horas, encontrarán formas de incluirlo en el trabajo de esta semana.

“Arreglar (lo antes posible) o no arreglar, esa es la cuestión”.

Los desarrolladores a menudo se enfrentan a un dilema cuando se trata de un error "urgente". Pueden apresurarse a terminar su tarea actual y corregir el error, posiblemente introduciendo nuevos errores en el proceso; con frecuencia ignoran la sobrecarga de cambio de contexto , ya que pueden cambiar abruptamente su atención al error, abandonando su tarea actual por completo.

Hay tres problemas significativos con estos escenarios:

1. El equipo prioriza de forma incorrecta, lo que puede provocar una pérdida de tiempo y corregir errores menos relevantes.

   
   

2. Agregar una urgencia innecesaria a los errores no críticos hace que el equipo cambie de enfoque innecesariamente.

   
   

3. Antes de abordar un error, es importante considerar su costo . Entonces, ¿cuánto le cuesta realmente un error al equipo? ¿Es arreglarlo a un costo razonable?

¿Qué tan caro es arreglar un error?

¿Alguna vez has oído hablar de la frase "No existe tal cosa como un almuerzo gratis?"

Cuando hablamos de costos, lo primero que pensamos como desarrolladores es el costo de la infraestructura, el costo de un servidor, una función Lambda, un clúster MongoDB, etc. Sin embargo, cuando se trata de errores, estoy hablando de un costo relacionado con el ser humano: la atención .

Cambio de contexto

Si estudió ingeniería informática o alguna vez leyó sobre cómo funcionan los sistemas operativos, probablemente haya oído hablar del cambio de contexto.

En informática, un cambio de contexto es el proceso de almacenar el estado de un proceso o subproceso, de modo que pueda restaurarse y reanudar la ejecución en un punto posterior, y luego restaurar un estado diferente, previamente guardado.

(de [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch))

Un caso de cambio de contexto del sistema operativo podría ser la multitarea: el cambio de contexto es una característica de la multitarea que permite que el proceso se cambie desde la CPU para que se pueda ejecutar otro proceso.

¿Dónde he escuchado estas palabras antes 🤔? - Ah, sí:

"Soy un maestro en la multitarea".

La multitarea puede ocurrir cuando alguien intenta realizar dos tareas simultáneamente, cambiar de una tarea a otra o realizar dos o más tareas en rápida sucesión.

Lavar la ropa mientras hablas con un amigo probablemente funcionará bien. La parte complicada viene cuando estamos haciendo tareas mentalmente complejas, como escribir código.

Los psicólogos han realizado múltiples experimentos sobre el cambio de tareas para determinar sus costos. Midieron el tiempo que les toma a las personas completar tareas y el costo de tiempo de cambiar entre ellas. Los resultados fueron los siguientes:

“Aunque los costos de cambio pueden ser relativamente pequeños, a veces solo unas pocas décimas de segundo por cambio, pueden sumar grandes cantidades cuando las personas cambian repetidamente de una tarea a otra. … cambiar de tarea puede costar hasta el 40 % del tiempo productivo de una persona”.

"¿Tienes un minuto?"

Imagínese esto: está encerrado, completamente inmerso, y nada puede impedir que termine esta nueva y brillante función. El mundo exterior ni siquiera existe, solo eres tú y tu código. Pero luego, escuchas un timbre de la nada... una nueva notificación en tu teléfono.

Es tu amigo invitándote a tomar algo este fin de semana. Y así, puf , los próximos 20 minutos de tu vida se han ido.

O tal vez acaba de recibir un mensaje de Slack de su colega preguntándole si tiene un minuto para ayudar con un problema específico.

¿Es la segunda situación más aceptable que la primera?

Bueno, al final, no importa. Basado en un análisis de 10,000 sesiones de programación registradas de 86 programadores usando Eclipse y Visual Studio y una encuesta de 414 programadores ( Parnin:10 ) encontró:

• Un programador tarda de 10 a 15 minutos en escribir más código después de reanudar el trabajo después de una interrupción.

• Cuando se interrumpió durante la edición de un método, solo el 10 % de las veces un programador reanudó el trabajo en menos de un minuto.

• Es probable que un programador obtenga solo una sesión ininterrumpida de 2 horas en un día.

Los desarrolladores tienden a evitar ( y odiar ) el cambio de contexto cuando se trata de reuniones inútiles. Aún así, creo que podríamos estar de alguna manera ciegos cuando cambiamos de contexto entre "tareas de desarrollador" e ignoramos por completo su efecto negativo.

Pensamientos finales

En el mundo real, siempre lidiamos con recursos limitados, ya sea dinero, tiempo o atención .

Arreglar errores tiene un precio.

“No” es no a una cosa. “Sí” es no a muchas cosas. – Jason frito

Decir "sí" a corregir un error significa decir "no" a una función. La multitarea puede parecer eficiente en la superficie, pero cambiar entre tareas lleva más tiempo y al final presenta más errores.

Comprender los costos ocultos del cambio de contexto lo ayuda a tomar mejores decisiones sobre qué errores vale la pena dejar todo y cuáles no (la mayoría no lo son).

¿Deberíamos dejar de preocuparnos por los insectos?

Bueno no. Sin embargo, al menos deberíamos ser conscientes del costo de corregir errores y preguntarnos: "¿Vale la pena corregirlo?" Sentarse con calma y aceptar errores puede ser un desafío. Todos tenemos un deseo interno de producir un trabajo de alta calidad y construir algo de lo que podamos estar orgullosos.

Desafortunadamente, esos molestos errores a menudo se interponen en el camino.

Como escribe Tom De Marco en su libro "Peopleware" , esto podría explicar por qué es difícil dejar de preocuparse por la calidad:

Todos tendemos a atar fuertemente nuestra autoestima a la calidad del producto que producimos, no a la cantidad del producto, sino a la calidad. (Por alguna razón, hay poca satisfacción en producir grandes cantidades de cosas mediocres, aunque eso puede ser justo lo que se requiere para una situación dada).

– Peopleware

¿Deberíamos esforzarnos más en la prevención de errores?

Como mencioné anteriormente, no tienes elección en muchas industrias. Allí, deberás tomar todas las medidas necesarias para evitar que se produzcan errores y corregirlos lo más rápido posible.

Pero, para la mayoría de las aplicaciones, ¿vale la pena el esfuerzo adicional?

PD Al final del día, incluso si tuviéramos una varita mágica que corrige todos los errores, nuestros usuarios aún encontrarían una manera de hacer un mal uso de nuestra aplicación 😅