BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos Perguntas e respostas sobre o livro "Humanos vs. Computadores"

Perguntas e respostas sobre o livro "Humanos vs. Computadores"

Favoritos

Pontos Principais

  • Humanos vs. Computadores é uma coleção de histórias sobre pessoas comuns que se encontraram entre erros de software e lógica binária, algumas divertidas e outras um tanto assustadoras;
  • A entrega moderna de software é uma luta constante para abstrair, simplificar e modelar parte do mundo real em um processo automatizado útil. No entanto, a falta de domínio deste conhecimento, a pressão de tempo e informações imperfeitas muitas vezes nos levam a simplificar demais o mundo real, gerando muitos casos inesperados;
  • Dado o quanto o software está se tornando parte da vida cotidiana, circunstâncias que parecem pequenos erros podem ter um sério impacto sobre as pessoas;
  • Muitos times de software atualmente são tão desconectados de seus usuários finais que nem sequer conseguem imaginar como algo tão trivial como um erro de exibição no formato decimal pode levar pessoas para o hospital;
  • Este livro ajudará os leitores a terem mais empatia pelas pessoas que sofrem pelos nossos enganos, já que são sempre pessoas que pagam o preço no final.

Gojko Adzic, desenvolvedor de software, autor e líder de pensamento, lançou o livro Humanos vs. Computadores. Este lançamento junta-se a outros trabalhos de Adzic, Mapeamento de Impacto e Especificação por Exemplo. O novo livro conta histórias do impacto de erros de software e falhas no mundo real, com conselhos para desenvolvedores de software sobre como evitá-los.

O tema do livro pode ser resumido nesta citação:

Nossas vidas estão sendo cada vez mais rastreadas e monitoradas por software. Neste bravo novo mundo, humanos não podem lidar com a sobrecarga de informação. Governos e empresas dependem de computadores para automaticamente detectar fraude, prever comportamentos e reforçar leis. Autômatos inflexíveis - pouco mais inteligentes do que uma geladeira - agora tomam decisões que impactam a vida. Computadores estão determinados a seguir instruções ao pé da letra -- mas as instruções são humanas .. e falham! Os resultados podem ser inesperados, catastróficos e muito, muito engraçados.

Uma amostra de trechos do livro pode ser baixada aqui e pode ser adquirida aqui.

A versão impressa pode ser adquirida aqui.

Adzic conversou com a InfoQ sobre o livro, o porquê de escrevê-lo e para quem é indicado.

InfoQ: O que o levou a escrever este livro? Qual é o problema que procura abordar com ele?

Humanos vs. Computadores é uma coleção de histórias sobre pessoas comuns que se encontraram entre erros de software e lógica binária, algumas divertidas e outras um tanto assustadoras. Desde o homem que, com uma placa nova com números personalizados, recebeu 2.000 multas de estacionamento por mês até o prisioneiro liberto 3 anos antes por conta de uma revisão automatizada de sua liberdade condicional. Esses contos de ensinamentos poderão ajudar as pessoas a prevenir, evitar e reduzir o impacto de tais problemas em seu próprio trabalho.

A entrega moderna de software é uma luta constante para abstrair, simplificar e modelar parte do mundo real em um processo automatizado útil. No entanto, a falta de domínio do conhecimento, a pressão do tempo e informações imperfeitas muitas vezes nos levam a simplificar demais o mundo real, gerando muitos casos inesperados. Por exemplo, sistemas distribuídos complexos, construídos em torno de microserviços que geralmente requerem algum tipo de monitoramento de produção para processar transações de ponta a ponta com dados de teste e remover esses casos de teste ao final de um teste bem-sucedido. É difícil imaginar como algo assim possa provocar danos sérios até você ouvir que alguém chamado Jeff Sample acabou confinado em Buenos Aires quando a companhia aérea que operava o voo de conexão excluiu o seu bilhete sem deixar qualquer vestígio.

Em retrospectiva, é fácil ver que alguém cometeu um pequeno descuido sobre o que torna um nome válido, mas isto realmente não ajuda a pessoa que passou horas no telefone argumentando com agentes de viagem, companhias de cartão e representantes da companhia aérea para ser capaz de continuar sua rota.

Visto o quanto o software está se tornando parte da vida cotidiana, coisas que parecem ser pequenos erros podem ter um impacto sério para as pessoas. Atualmente, muitos times de software são tão desconectados de seus usuários finais que nem sequer conseguem imaginar como algo tão trivial como um erro de exibição no formato decimal pode levar pessoas para o hospital.

Queria aumentar a conscientização sobre essas questões e ajudar as pessoas a desenvolverem melhor o software, evitando erros comuns.

InfoQ: Qual é o público-alvo? E o que eles podem aprender do livro?

O livro é indicado para qualquer pessoa envolvida na entrega de software, independentemente do seu cargo. Pessoas envolvidas com requisitos e gerenciamento de produto obterão boas ideias de como evitar análise típica de pontos-cegos. Pessoas envolvidas com arquitetura, design e desenvolvimento aprenderão sobre simplificações excessivas comuns e sobre como questionar melhor ao dialogar detalhes de implementação. Pessoas envolvidas com testes e melhoria da qualidade poderão ver alguns bons exemplos e heurísticas para experimentar, e também aprender sobre a raiz de certos tipos de problemas para serem capazes de resolvê-los o quanto antes no processo.

As categorias de problemas sobre as quais escrevo são perfeitamente previsíveis e preveníveis, e realmente não há mais desculpas hoje em dia para continuar criando estes tipos de bugs. Eles já foram documentados em vários livros de testes, mas tendem a serem listados como taxonomias de heurísticas, dificultando sua lembrança e tornando-se uma leitura tediosa. Em geral, são lidos apenas por testadores, com pouquíssimos desenvolvedores se importando em aprender sobre eles. E claro, sob pressão, é difícil recordar instantaneamente todas aquelas taxonomias, então as pessoas acabam gerando repetidamente os mesmos tipos de erros.

Este é o porquê de eu querer ilustrar problemas com histórias memoráveis em um livro que será interessante para qualquer um envolvido com entrega de software, independentemente do seu cargo. Histórias fazem com que as ideias colem em nossos cérebros. Talvez você não relembre todas as formas possíveis de desordenar os dados do teste na próxima vez que trabalhar no monitoramento, mas você se lembrará de Jeff Sample, e isso lhe dará uma sacudida para pensar um pouco mais e evitar problemas semelhantes.

Com sorte, este livro também ajudará os leitores a terem mais empatia pelas pessoas que sofrem com nossos enganos, visto que sempre são estas as que pagam o preço no final. Isto, sozinho, deveria ajudar a entregar melhores softwares, independentemente de relembrar qualquer técnica específica.

InfoQ: Você dividiu o livro em uma série de seções que tratam de diferentes tipos de problemas relacionados a software - o que elas são e por que você usou essa estrutura?

A primeira parte do livro, "Artificial, mas não inteligência", lida com erros típicos em algoritmos de tomada de decisão causados por uma extrema simplificação do mundo real. Algumas das histórias desta seção explicam como irmãos gêmeos quebram verificações biométricas, ou como a confusão do fuso-horário pode causar o caos no trânsito ou, ainda, sobre problemas de mapeamento geo-IP que geram acusações errôneas de pessoas por crimes sérios.

A segunda parte, "Os fatos surpreendentes sobre nosso mundo", conta histórias de casos estranhos e maravilhosos que quebraram regras de validação aparentemente sensíveis, como pessoas que possuem apenas um nome, ou nomes com muito mais caracteres do que há espaço na carteira de habilitação. Algumas das boas histórias desta seção explicam como um banco de investimento quase perdeu US$ 100 milhões em dois minutos devido a um problema bobo de validação decimal, e quais tipos de problemas acabam acontecendo com todas as pessoas cujo último nome é "Null".

A terceira parte, "Algoritmos tão rápidos quanto um fast-food", cobre negligências típicas e problemas de automação de processos. Isso inclui histórias de algoritmos que acabaram presos em laços de auto-incremento e levaram a falhas no mercado de ações, uma empresa de camisetas implodindo quando seu software de design começou a defender a violência contra as mulheres, e o estilo de vida pródigo de um australiano que obteve crédito ilimitado do banco devido a uma falha no software.

A quarta parte, "Selvagem, tecnologia selvagem", abrange questões que ocorreram por conta de um mapeamento problemático entre conceitos do mundo real como tempo, dinheiro e quantidades para números em um computador. Isto inclui histórias sobre como um erro no arredondamento decimal mudou os resultados de uma eleição, como uma senhora de 107 anos teve que lutar contra o poder local para não a matricularem na escola e como um cupom de desconto causou um jogo de luta livre envolvendo centenas de pessoas.

InfoQ: Qual é sua história favorita no livro e por quê?

Se eu tivesse que escolher uma, provavelmente seria a história sobre Robert Barbour, de Los Angeles. Barbour tentou obter placas de carro customizadas com os temas de veleiros ou lanchas. Ele não queria nada mais, mas o formulário do computador tinha três campos, todos obrigatórios. Então no terceiro campo ele escreveu "sem placa". E, claro, a placa foi emitida com base no terceiro campo. Isso parecia estranho o suficiente para que Barbour decidisse não se queixar.

Um mês depois, ele começou a receber notificações de toda a Califórnia sobre multas atrasadas de estacionamento. Isso porque mesmo quando um veículo estacionado de forma irregular não possui uma placa, os oficiais ainda tinham que emitir uma notificação, porém os computadores não tinham como aceitar isto. Oficiais tinham que encontrar uma solução alternativa e, como humanos são humanos, muitos tiveram a mesma ideia de Barbour. Os oficiais apenas direcionavam as multas para "sem placa". Normalmente todas estas notificações não terminariam em nenhum lugar, até surgir algo com o qual os computadores pudessem associar.

Quando o problema de Barbour chamou a atenção da mídia, ele já recebia mais de 2000 notificações por mês. Ele teve que comparecer ao tribunal algumas vezes para explicar a situação. Uma vez que o problema se tornou político, porque todos os sistemas relacionados não podiam ser atualizados rapidamente, as autoridades passaram a emitir uma nova diretriz para gravar carros sem placas como "ausente". Mas, é claro, alguém já tinha exatamente essa placa, e o ciclo apenas se repetiu.

É fácil atribuir culpa. Os UX designers que criaram formulários inflexíveis, ou os analistas de requisitos que não cobriram o caso de carros estacionados sem placas de licença, ou os desenvolvedores que escreveram consultas comparando os dados faltantes com entradas válidas e testadores que não conseguiram descobrir esse erro. Alguém sempre é culpado em retrospectiva. Mas, em primeiro lugar, a questão mais interessante é o porquê deste problema ter ocorrido.

Adoro esta história pois ilustra muito bem o que acontece quando computadores insistem em solicitar uma informação que ainda não está disponível ou que sequer existe, forçando os usuários a encontrarem soluções alternativas. A verdadeira diversão começa quando vários sistemas precisam trocar informações e todos usam soluções alternativas diferentes. Espaços e marcadores em um tornam-se dados válidos no outro, e os erros se multiplicam e se propagam. Os problemas com os marcadores de dados podem passar despercebidos por um longo tempo. Uma vez que todos os registros nunca esperados começam a se relacionar com uma informação válida - assim como alguém que finalmente obteve a placa "sem placa" - o caos começa.

Esta situação toda é perfeitamente evitável se todas as pessoas envolvidas na entrega apenas considerassem um pouco mais sobre o fato de que tornar coisas obrigatórias não significa necessariamente que os dados inseridos serão os certos, muito pelo contrário. Eventualmente tenho problemas com meu editor de livros; ele requer um número de telefone para as ordens de entrega e raramente tenho esta informação. Aí recebo ligações no meio da noite de entregadores perdidos em algum lugar pelo mundo.

InfoQ: O último capítulo lida com a "Regra do Macaco Inverso". O que é isso e qual é o conselho dado aqui aos tecnologistas?

Minha intenção com este livro é ilustrar alguns erros típicos e comuns com histórias memoráveis. Entretanto, mais do que apenas ter algumas boas histórias de bar, quis deixar conselhos claros e viáveis. A parte final do livro contém boas dicas e truques combinados de todas as histórias, com heurísticas para análise, desenvolvimento e teste de sistemas de computador.

O nome vem do famoso teorema do macaco infinito, de Émile Borel, proposto em 1913. Borel sugeriu que com infinitas tentativas e tempo, macacos poderiam criar qualquer texto, inclusive trabalhos como o de Shakespeare. Esse teorema é uma ótima ilustração de cálculo e estatística, mas na prática sua probabilidade é extremamente baixa. Por outro lado, inverter o teorema nos dá algo muito mais prático, em muito menos tempo, gerando a maioria dos problemas que apresentei no livro. "Pessoas inteligentes, pressionando um teclado de computador intencionalmente, por apenas alguns meses, quase certamente irão produzir algum tipo de caca de macaco". Nomeei isto como o princípio da Regra do Macaco Inverso.

A última parte não é de forma alguma uma lista abrangente de casos de teste - ou mesmo uma estratégia de teste completa; é apenas um rápido resumo das histórias do livro. Minha intenção é que as pessoas o usem com outras ferramentas e como uma inspiração ao procurar mais ideias.

Sobre o autor do livro

Gojko Adzic é sócio na Neuri Consulting LLP. Campeão do Prêmio europeu de destaque em teste de software de 2016 e do Prêmio de profissional de testes ágeis mais influente de 2011. Seu livro Especificação por Exemplo ganhou o Prêmio Jolt 2012 de melhor livro e seu blog ganhou o Prêmio Agile Reino Unido como a melhor publicação online no ano de 2010. É palestrante frequente em conferências líderes de desenvolvimento de software e um dos autores do MindMup e do Claudia.js. Como consultor, auxiliou diversas empresas ao redor do mundo a melhorar sua entrega de software, desde algumas das maiores instituições financeiras até pequenas startups inovadoras. Especialista em aprimoramento da qualidade ágil e lean, em particular em mapeamento de impactos, testes ágeis, especificações por exemplo e desenvolvimento orientado por comportamento.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT