Os insetos estão matando seu impulso?

Bugs de software são uma ocorrência comum no mundo da tecnologia. Se você já escreveu mais de dez linhas de código, é provável que tenha causado uma acidentalmente.

Agora, gostaria que você pensasse sobre a última vez que recebeu uma mensagem de um cliente ou colega surtando com um bug. Como acabou? O bug era tão urgente que você teve que parar o que estava fazendo?

Neste artigo, tentaremos desafiar o pensamento convencional sobre bugs e explorar quanto cada bug está custando para você e sua equipe.

Sobre mim

Olá 👋, meu nome é Krste e sou um desenvolvedor full-stack que trabalha em startups há mais de sete anos. Recentemente, co-fundei o Bugpilot , uma plataforma de monitoramento de bugs que alerta as equipes de software sobre bugs críticos enfrentados pelo usuário.

Escrevi este artigo com o objetivo de desafiar o pensamento convencional sobre bugs e o “precisamos consertar o mais rápido possível!” mentalidade, questionando a necessidade de explorar o verdadeiro custo de cada questão.

Software 100% livre de bugs. Mito ou Realidade?

O objetivo de alcançar um software 100% livre de bugs sempre foi complicado. A ideia de criar um aplicativo sem bugs pode parecer ideal, mas é realmente possível?

A verdade é que os bugs de software são inevitáveis devido à complexa lógica de negócios, erros humanos e atualizações contínuas da tecnologia. Mesmo com testes cuidadosos e verificações de qualidade, é difícil eliminá-los completamente.

No entanto, graças a novas ferramentas de desenvolvedor e processos aprimorados, as equipes agora estão lançando novos recursos em um ritmo acelerado para se manterem relevantes e competitivos.

E, com qualquer alteração na base de código, sempre é possível quebrar algo. (Ter que suportar muitos dispositivos e vários navegadores não ajuda em nada.)

Claro, há casos em que os bugs devem ser próximos de zero. Certos setores, como bancário, médico e aeroespacial, devem garantir que os erros sejam reduzidos ao mínimo, pois podem custar vidas .

Isso explica por que a maioria dos softwares nessas indústrias é escrito em tecnologias de décadas atrás e por que as pessoas agora hesitam em tocá-las.

Mas, no final, temos que nos perguntar: "Vale a pena? " Para a maioria de nós, que desenvolve ferramentas de marketing e CRMs, acredito que consertar bugs costuma ser mais caro do que deixá-los por perto. Vou tentar explicar por quê.

Nem todos os erros são iguais

Imagine que você está trabalhando em um site de comércio eletrônico e um bug interrompe o processo de checkout, impossibilitando que os clientes concluam suas compras.

É dolorosamente óbvio que esse bug precisa de atenção imediata, pois afeta diretamente a funcionalidade principal e pode resultar em perda de vendas e clientes insatisfeitos.

Da mesma forma, não podemos tratar um bug na página de inscrição que está impedindo que novos usuários entrem em nosso novo aplicativo de compartilhamento de viagens da mesma forma que um problema relacionado à atualização da foto do perfil .

Esses exemplos em preto e branco mostram que não apenas precisamos detectar, mas precisamos entender o impacto dos bugs. No entanto, na realidade, as coisas não são preto no branco. A maioria das situações se enquadra na área cinzenta. A questão então se torna: como sabemos o que consertar?

“TEMOS QUE CORRIGIR AGORA OU O CLIENTE VAI SAIR”

Percebi que tendemos a adicionar um senso de urgência "extra" aos bugs que nossos clientes encontram.

Você provavelmente já passou por uma situação semelhante quando um de seus maiores clientes está tendo um pequeno problema e toda a sua equipe está sendo inundada com mensagens como se o mundo estivesse pegando fogo 🔥

”Giovanni reclamou que não consegue alinhar o texto à direita 11 1 Eles são um cliente importante. Devemos corrigir o bug AGORA!”

- seu chefe

Com base na minha experiência, as funções voltadas para o cliente, como sucesso do cliente, suporte e vendas, tendem a priorizar questões dependendo de como o cliente reage e como isso afeta sua reputação. É por isso que tudo pode parecer grande coisa para eles, o que é compreensível.

Ninguém quer causar uma má impressão ou ter uma reputação negativa, e é exatamente isso que os bugs podem causar.

Quanto mais usuários são afetados por um bug, mais importante (provavelmente) é corrigi-lo

Às vezes, os problemas de produção são tratados à medida que ocorrem. Especialmente nós, desenvolvedores, saltamos imediatamente em qualquer bug ou erro de codificação que chega à sua caixa de entrada.

Você ou sua equipe podem estar usando uma ferramenta como Sentry ou Bugsnag para monitorar e ser notificado quando ocorrem erros. Quando algum erro é encontrado, ele é rapidamente atribuído a um desenvolvedor enquanto todos aguardam impacientemente uma atualização no Slack.

Normalmente, essas ferramentas priorizam erros com base na frequência com que ocorrem e quantos usuários são afetados.

Human.priorizarBugs()

No entanto, a prioridade da maioria dos bugs na maioria das equipes provavelmente é determinada pelo proprietário do produto ou pelo desenvolvedor líder. Essas funções geralmente compreendem a lógica de negócios, a tecnologia subjacente, a carga de trabalho atual e as prioridades futuras e planejam de acordo.

Seus critérios de priorização podem ser mais ou menos assim:

É crítico ou não? Primeira pergunta, mas já está ficando um pouco complicado. O que é crítico? Crítico não tem uma definição clara. Se uma função principal estiver inutilizável, é bastante óbvio que devemos corrigi-la. No entanto, como você viu no exemplo acima, e se um cliente importante for afetado?

Quantos clientes está impactando? Apenas um? Todos? Será que sabemos? Quando um número significativo de usuários é afetado, convém resolver o problema, mesmo que esteja relacionado a uma funcionalidade menor.

Quanto tempo leva para corrigi-lo? Em seguida, o proprietário do processo de “Bug Triage” perguntará quanto tempo leva para corrigir o problema. Mesmo que leve apenas algumas horas, eles encontrarão maneiras de espremer isso no trabalho desta semana.

“Consertar (o mais rápido possível) ou não consertar, eis a questão.”

Os desenvolvedores geralmente enfrentam um dilema ao lidar com um bug "urgente". Eles podem correr para terminar sua tarefa atual e corrigir o bug, possivelmente introduzindo novos bugs no processo; eles freqüentemente ignoram a sobrecarga de troca de contexto , pois podem mudar abruptamente sua atenção para o bug, abandonando completamente sua tarefa atual.

Há três problemas significativos com esses cenários:

1. A equipe prioriza incorretamente, possivelmente resultando em perda de tempo e correção de bugs menos relevantes.

   
   

2. Adicionar urgência desnecessária a bugs não críticos faz com que a equipe mude o foco desnecessariamente.

   
   

3. Antes de abordar um bug, é importante considerar seu custo . Então, quanto um bug realmente custa à equipe? Consertá-lo é um custo razoável?

Quão caro é corrigir um bug?

Você já ouviu falar da frase "Não existe almoço grátis?"

Quando falamos de custo, a primeira coisa que pensamos como desenvolvedores é o custo de infraestrutura, o custo de um servidor, uma Função Lambda, um Cluster MongoDB e assim por diante. No entanto, quando se trata de bugs, estou falando de um custo humano: atenção .

Mudança de Contexto

Se você estudou engenharia da computação ou já leu sobre como os sistemas operacionais funcionam, provavelmente já ouviu falar em troca de contexto.

Na computação, uma troca de contexto é o processo de armazenar o estado de um processo ou thread, para que possa ser restaurado e retomar a execução posteriormente e, em seguida, restaurar um estado diferente, salvo anteriormente.

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

Um caso de alternância de contexto do sistema operacional pode ser multitarefa: a alternância de contexto é uma característica da multitarefa que permite que o processo seja alternado da CPU para que outro processo possa ser executado.

Onde já ouvi essas palavras antes 🤔? - Ah sim:

“Eu sou um mestre em multitarefa.”

A multitarefa pode ocorrer quando alguém tenta executar duas tarefas simultaneamente, alternar de uma tarefa para outra ou executar duas ou mais tarefas em rápida sucessão.

Lavar a roupa enquanto conversa com um amigo provavelmente funcionará bem. A parte complicada surge quando estamos realizando tarefas mentalmente complexas, como escrever código.

Os psicólogos conduziram vários experimentos sobre troca de tarefas para determinar seus custos. Eles mediram o tempo que as pessoas levam para concluir as tarefas e o custo do tempo para alternar entre elas. Os resultados foram os seguintes:

“ Embora os custos de troca possam ser relativamente pequenos, às vezes apenas alguns décimos de segundo por troca, eles podem aumentar muito quando as pessoas alternam repetidamente entre as tarefas. … alternar entre tarefas pode custar até 40% do tempo produtivo de alguém.”

"Você tem um minuto?"

Imagine o seguinte: você está preso, totalmente imerso e nada pode impedi-lo de terminar este novo e brilhante recurso. O mundo exterior nem existe - é só você e seu código. Mas então, você ouve um toque do nada... uma nova notificação em seu telefone.

É o seu amigo convidando você para beber neste fim de semana. E assim, puf , os próximos 20 minutos da sua vida se foram.

Ou talvez você tenha acabado de receber uma mensagem do Slack de seu colega perguntando se você tem um minuto para ajudar com um problema específico.

A segunda situação é mais aceitável do que a primeira?

Bem, no final, não importa. Com base em uma análise de 10.000 sessões de programação gravadas de 86 programadores usando Eclipse e Visual Studio e uma pesquisa com 414 programadores ( Parnin:10 ) descobriu:

• Um programador leva de 10 a 15 minutos para escrever mais código depois de retomar o trabalho após uma interrupção.

• Quando interrompido durante a edição de um método, apenas 10% das vezes o programador retomava o trabalho em menos de um minuto.

• É provável que um programador tenha apenas uma sessão ininterrupta de 2 horas por dia.

Os desenvolvedores tendem a evitar ( e odiar ) a troca de contexto quando se trata de reuniões inúteis. Ainda assim, acredito que podemos estar de alguma forma cegos quando alternamos o contexto entre as “tarefas do desenvolvedor” e ignoramos completamente seu efeito negativo.

Pensamentos finais

No mundo real, estamos sempre lidando com recursos limitados, seja dinheiro, tempo ou atenção .

Corrigir erros tem um preço.

“Não” é não para uma coisa. “Sim” é não para muitas coisas. -Jason Fried

Dizer “sim” para corrigir um bug significa dizer “não” para um recurso. A multitarefa pode parecer eficiente na superfície, mas alternar entre tarefas leva mais tempo e apresenta mais bugs no final.

Compreender os custos ocultos da troca de contexto ajuda você a fazer escolhas melhores sobre quais bugs valem a pena abandonar tudo e quais não valem (a maioria não vale).

Devemos parar de nos importar com insetos?

Bem não. No entanto, devemos pelo menos estar cientes do custo de corrigir bugs e nos perguntar: "Vale a pena consertar?" Pode ser desafiador sentar-se calmamente e aceitar bugs. Todos nós temos um desejo interior de produzir um trabalho de alta qualidade e construir algo do qual possamos nos orgulhar.

Infelizmente, esses bugs irritantes geralmente atrapalham.

Como Tom De Marco escreve em seu livro "Peopleware" , isso pode explicar por que é difícil parar de se preocupar com a qualidade:

Todos nós tendemos a vincular fortemente nossa auto-estima à qualidade do produto que produzimos - não à quantidade do produto, mas à qualidade. (Por alguma razão, há pouca satisfação em produzir grandes quantidades de coisas medíocres, embora isso possa ser exatamente o que é necessário para uma determinada situação.)

– Pessoas

Devemos nos esforçar mais na prevenção de bugs?

Como mencionei anteriormente, você não tem escolha em muitos setores. Lá, você deve tomar todas as medidas necessárias para evitar que erros ocorram e corrigi-los o mais rápido possível.

Mas, para a maioria dos aplicativos, o esforço extra vale a pena?

PS No final das contas, mesmo se tivéssemos uma varinha mágica que consertasse todos os bugs, nossos usuários ainda encontrariam uma maneira de fazer mau uso de nosso aplicativo 😅