Não é um bug, é uma feature — significado, origem e diferenças

O que significa “Não é um bug, é uma feature”

“Não é um bug, é uma feature” — uma frase usada por desenvolvedores ou gerentes para indicar que um comportamento inesperado do programa é intencional, não errôneo. No caso clássico, é uma piada: todos entendem que o comportamento está errado, mas o chamam de “feature” para aliviar a tensão. No entanto, em projetos reais, a frase também é usada seriamente — quando o comportamento realmente corresponde à especificação, mas não atende às expectativas do usuário.

A diferença entre um bug e uma feature é frequentemente subjetiva. Para um desenvolvedor que escreveu o código, um certo comportamento pode parecer lógico. Para um usuário, pode parecer inesperado e errado. A subjetividade da percepção é a principal razão pela qual a frase é tão persistente. Ela transfere a conversa de “quem é o culpado” para “foi assim que foi projetado”. De acordo com a UX Collective, 40% dos bugs relatados por usuários são, na verdade, problemas de UX, não erros de código.

Em equipes ágeis, a frase é frequentemente usada como mecanismo de defesa durante as demonstrações. O desenvolvedor mostra um comportamento inesperado, o product owner franze a testa, e a fatídica frase “não é um bug, é uma feature” é dita. A confiança na equipe determina se a frase será levada como piada ou como tentativa de esconder um problema. Em uma equipe saudável, essa piada alivia a tensão; em uma tóxica, causa conflito.

História da frase icônica

O primeiro uso conhecido da frase foi registrado em 1976 em um boletim da DECUS (Digital Equipment Corporation User Society). Um usuário reclamou que o processador de texto RUNOFF lidava incorretamente com linhas em branco. A resposta do desenvolvedor: “Não é um bug, é uma feature — é assim que os parágrafos são processados.” Desde então, a frase se tornou um símbolo de defender o código escrito “tal como está”, independentemente de sua qualidade real.

A frase ganhou popularidade graças ao Jargon File — um dicionário de gíria de hackers que, na década de 1990, serviu de base para o livro “The New Hacker’s Dictionary”. No Jargon File, a entrada “feature” refere-se diretamente a bugs que se tornaram features porque era impossível ou indesejável corrigi-los. Exemplo: a tecla Caps Lock em terminais antigos não tinha indicador luminoso — isso era um bug que se tornou uma feature “para digitação cega”.

Na década de 2000, a frase passou para a cultura popular através de memes da internet. Uma imagem de um gato com a legenda “It’s not a bug, it’s a feature” se espalhou por fóruns e redes sociais. Na indústria de jogos, a frase é usada com especial frequência: glitches que não afetam a jogabilidade são declarados “features” para atmosfera. O fenômeno cultural se espalhou muito além da TI — a frase pode ser ouvida em qualquer contexto onde um erro é justificado.

Psicologia da desculpa: por que se diz isso

A base psicológica da frase é a dissonância cognitiva. Um desenvolvedor passou horas escrevendo código, e admitir que o resultado está errado significa desvalorizar seu trabalho. A frase “não é um bug, é uma feature” reduz a dissonância: o erro se transforma em uma decisão deliberada, e o desenvolvedor passa de culpado a autor da ideia. É um mecanismo de defesa psicológica que preserva a autoestima.

A segunda razão é o medo de retrabalho. Admitir um bug significa passar por revisão de código, testes e implantação novamente. Uma “feature” não requer correção — a tarefa é fechada, a carga de trabalho diminui. De acordo com a Microsoft Research, os desenvolvedores minimizam deliberadamente a gravidade dos bugs para evitar retrabalho em 23% dos casos. A frase é uma forma branda dessa minimização.

A terceira razão é a cultura corporativa. Em algumas empresas, os bugs afetam os KPIs do desenvolvedor, e encontrar um bug na revisão de código é considerado um erro do autor. Nesse ambiente, a frase “não é um bug, é uma feature” é uma forma de evitar consequências negativas para a carreira. Uma cultura de erro saudável (cultura sem culpa) elimina essa causa: se os bugs não são punidos, é mais fácil admiti-los.

Onde está a linha entre um bug e uma feature

Um limite claro existe apenas quando há Critérios de Aceitação. Se o comportamento não corresponder a nenhum item dos CA — é um bug. Se o comportamento corresponder aos CA, mas o usuário não gostar — é um problema de UX, não um bug. Se não houver CA — qualquer comportamento pode ser declarado feature, e esta é a principal razão da persistência da frase.

Uma regra prática: um bug é quando um programa faz algo que não deveria, ou não faz algo que deveria, de acordo com a especificação. Uma feature é quando um programa faz o que foi pretendido, mesmo que o resultado surpreenda o usuário. Casos limítrofes: comportamento indefinido (a linguagem não define o resultado), condições de corrida (manifestam-se intermitentemente), casos extremos (funciona para 99% dos dados).

Para maior clareza, use uma matriz de decisão:

• O comportamento está descrito na especificação e implementado corretamente — feature, mesmo que você não goste
• O comportamento está descrito mas implementado incorretamente — bug, precisa de correção
• O comportamento não está descrito mas decorre logicamente dos requisitos — feature não documentada, precisa ser adicionada à especificação
• O comportamento não está descrito e é ilógico — bug, os requisitos precisam de esclarecimento

O caso mais perigoso é quando não há especificação, e o desenvolvedor decide por si mesmo o que é uma feature. Nesses projetos, qualquer erro pode ser declarado “feature”, tornando o código imprevisível para toda a equipe. Critérios de Aceitação claros para cada tarefa — a única maneira de traçar a linha objetivamente.

Por que a confusão de conceitos é perigosa na equipe

O primeiro perigo é a erosão da qualidade. Se todo bug pode ser declarado feature, a equipe não tem incentivo para escrever código de qualidade. Os erros param de ser corrigidos, a dívida técnica cresce, e os usuários se acostumam com “comportamento estranho”. Mais cedo ou mais tarde, um concorrente lança um produto que funciona de forma previsível, e os usuários vão embora.

O segundo perigo é o conflito na equipe. Um engenheiro de QA encontra um bug, um desenvolvedor diz “é uma feature”. Sem critérios objetivos (Critérios de Aceitação), a discussão se torna pessoal: “você testa mal” vs “você programa mal”. De acordo com o PractiTest State of Testing 2023, as disputas “bug vs feature” são uma das três principais causas de atrito entre QA e desenvolvedores.

O terceiro perigo são os riscos legais. Em indústrias regulamentadas (medicina, finanças, aviação), os conceitos de “bug” e “feature” têm peso legal. Se em um software médico um comportamento for declarado feature, mas levar a um cálculo incorreto de dosagem — não é uma piada, é uma violação regulatória. Sistemas críticos para a segurança não toleram substituição de conceitos, por isso sempre usam verificação formal.

Como evitar confusão entre bug e feature

A principal ferramenta são Critérios de Aceitação claros em cada tarefa. Os CA são escritos antes do desenvolvimento começar: “Ao inserir X, o sistema deve produzir Y”. Se o comportamento não estiver descrito — é um bug por padrão, mesmo que o desenvolvedor pense o contrário. Os CA devem ser mensuráveis e verificáveis: “o botão é verde” é ruim, “HEX #00FF00” é bom.

A segunda ferramenta é uma Definição de Pronto na equipe. Uma descrição clara do que significa “tarefa concluída”: código escrito, testes escritos, testes aprovados, revisão de código concluída, implantado em staging, testado pelo QA. Se todos os itens da Definição de Pronto forem atendidos e o usuário ainda reclamar — não é um bug, mas um requisito ausente que vai para o backlog como uma nova feature.

A terceira ferramenta é uma cultura de análise post-mortem sem culpa. Se um bug foi declarado feature e foi para produção — analisamos as causas, não procuramos culpados. Por que o desenvolvedor achou que era uma feature? Por que o QA não percebeu? Por que os CA estavam incompletos? As respostas a essas perguntas melhoram o processo, não punem as pessoas. Melhorias sistêmicas funcionam melhor do que proibir a frase “não é um bug, é uma feature”.