Get best of the week

Por que estamos escrevendo programas de tão baixa qualidade?


:
— , ,  — .
- :
— . .
:
— .
— ?
— . , .
— ?
— , , , , , .
- Eles dizem que a confiabilidade é garantida por uma tecnologia chamada blockchain.
- Ahhhhhhhh !!! O que eles dizem, não toque! Cavar mais fundo. Não esqueça as luvas!
Fonte: XKCD , licença Creative Commons 2.5. Uma

falha no aplicativo de contagem móvel da semana passada causou estragos no Congresso do Partido Democrata de Iowa. Poucas horas após a abertura das reuniões em todo o estado, ficou claro que algo havia dado errado. Os resultados ainda são desconhecidos. Havia mensagens descrevendo problemas técnicos e mal-entendidos. O Partido Democrata de Iowa divulgou uma declaração que nega rumores de um ataque cibernético, mas confirma problemas técnicos com o aplicativo móvel.

Uma semana depois, já entendemos melhor o que aconteceu. Um aplicativo móvel foi escrito especificamente para este evento em Iowa. Foi distribuído como uma versão beta , ignorando grandes diretórios de aplicativos. Os usuários sofreram, mas lutaram para que o programa funcionasse. Após a instalação, era muito provável que ela não respondesse às chamadas. Em alguns locais de reunião, não havia conexão com a internet, o que tornava inútil o aplicativo on-line. Os democratas tinham um plano alternativo: relatar os resultados por telefone, como sempre. Mas as linhas telefônicas estavam congestionadas com trolls on-line, que as congestionavam por uma questão de lulz.

O Twitter seguiu uma onda de hashtags #app e #problems, e os engenheiros de software citaram o KDPV. Também achei. As palavras desta caricatura resumem bem o sentimento geral do que está acontecendo: "Não sei como expressá-lo, mas toda a nossa área é ruim no que fazemos, e se você confiar em nós, todos morrerão". Os engenheiros de software não dizem isso diretamente. Mas parece muito semelhante. O que queremos dizer com isso?

Aqui está o que queremos dizer: desenvolvemos bem o software, desde que as consequências da falha não importem. Em média, os programas são bons o suficiente para funcionar de alguma forma. No entanto, não estamos particularmente surpresos com erros na maioria dos programas. Estes não são alguns incidentes raros. Muitas práticas comuns em engenharia de software partem do pressuposto de que as falhas são a norma e, mais importante, os novos recursos. Falha é realmente barato. Se o serviço online de uma das maiores empresas for completamente desconectado por duas horas, eles o esquecerão em uma semana. Essa suposição está incorporada nos mantras comuns: "Mova-se rápido e quebre tudo" (Mova-se rápido e quebre coisas), "Lance e repita o ciclo" (inicie e repita).

O mercado recompensa generosamente por esse comportamento "irresponsável". Em muitas empresas da web, um pequeno lucro por usuário é multiplicado por milhões (ou bilhões!) De usuários. Isso é benéfico para empresas com aplicativos ou sites de consumo. A implementação é cara, mas o custo é finito e a distribuição é quase gratuita. A indústria de software para consumidores encontrou um compromisso: estamos reduzindo a taxa de implementação apenas o suficiente para manter nosso nível de defeitos moderadamente baixo, mas não muito.

Chamamos esse desenvolvimento de software de “modelo econômico de um site”: quando os benefícios da implementação são altos e o custo de novas tentativas é baixo, o gerenciamento incentiva a liberação de funções em alta velocidade. Isso se reflete nas práticas modernas de gerenciamento de projetos e sua implementação, que discutirei abaixo.

Mas, como eu disse, "fazemos bem o software, desde que as consequências da falha não importem". Essa abordagem leva a falhas terríveis se as consequências não forem baratas, como em Iowa. A prática comum do desenvolvimento de software cresceu a partir do modelo econômico da Internet e, quando as premissas desse modelo são violadas, os engenheiros de software fazem um mau trabalho.

Como a programação funciona em empresas da web?


Imagine a hipotética empresa QwertyCo. É uma empresa de software orientada para o consumidor que fatura US $ 100 milhões por ano. Podemos estimar o tamanho da QwertyCo comparando com outras empresas. O WP Engine, hospedagem WordPress, atingiu $ 100 milhões em ARR em 2018 . A Blue Apron gerou US $ 667 milhões no ano . Assim, a QwertyCo é uma empresa de médio porte. Ela tem de várias dezenas a centenas de engenheiros e não emitiu ações em circulação pública.

Primeiro, considere a economia do gerenciamento de projetos na QwertyCo. Os líderes descobriram que você não deseja anunciar instantaneamente um novo recurso. Você tem um compromisso entre qualidade do software, prazo e velocidade de implementação.

Quão importante é a qualidade do software para eles? Na verdade não. Se o site da QwertyCo estiver inativo por 24 horas por ano, eles estimam a perda em apenas US $ 273.972 (assumindo que o tempo de atividade esteja linearmente correlacionado com a receita). Eles dizem que o site fica offline por 15 minutos e ninguém se importa. Se a função travar o site, eles reverterão e tentarão mais tarde. Tentativas repetidas são baratas.

Qual é o valor do novo recurso da QwertyCo? Com base em minhas observações pessoais, um mês de trabalho de um engenheiro é capaz de alterar a renda de um site otimizado na faixa de -2% a 1%. Essa é uma chance mensal de obter US $ 1 milhão em receita adicional da QwertyCo para cada engenheiro. Métodos como o teste A / B atenuam erros: dentro de algumas semanas, você pode detectar alterações negativas ou neutras e remover esses recursos. As más características são baratas - elas são ativas por um período finito de tempo. Ganhar é obtido para sempre. Mesmo uma baixa porcentagem de apostas vencedoras faz com que a QwertyCo lucre.

Dados os prós e os contras, quando a QwertyCo deve liberar uma função? O cálculo econômico mostra que mesmo funções de alto risco devem ser lançadas se às vezes obtiverem lucro. Assim, cada projeto se transforma em um jogo de otimização: “Quanto pode ser implementado até essa data?”, “Quanto tempo é necessário para implementar todo o projeto? E se você remover o X dele? E se você remover X e Y? Como acelerar a implementação de uma determinada parte? ”

Agora considere um projeto de software do ponto de vista de um engenheiro de software.

Seu principal recurso é o tempo. O desenvolvimento seguro de software é demorado. Assim que um produto ultrapassa um certo limite de complexidade, ele tem vários estágios de desenvolvimento (mesmo que não passem como parte de um processo explícito). Eles devem ser planejados com a ajuda do gerente de produto. O produto é convertido em um projeto ou plano técnico, se necessário, dividido em subtarefas. Em seguida, um código com testes é escrito, uma revisão de código é feita, as estatísticas são registradas, o produto é integrado aos painéis de informações e alertas. Se necessário, o teste manual é realizado. Além disso, a codificação geralmente possui uma sobrecarga extra conhecida como refatoração.: Modifique um sistema existente para facilitar a implementação de um novo recurso. Na implementação da função "pequena", a própria codificação pode levar apenas 10 a 30% do tempo.

Como os desenvolvedores perdem tempo? Na maioria das vezes, essas são falhas do sistema. Durante o tempo de inatividade do site, tudo é incluído no trabalho. Os engenheiros mais experientes interrompem os projetos em andamento para retomar o site. Mas o tempo necessário para extinguir um incêndio é o momento em que eles não trazem benefícios adicionais para a empresa. Seus projetos estão atrasados. Como reduzir o tempo de inatividade? Testes escritos, monitoramento, notificações automatizadas e testes manuais reduzem o risco de eventos catastróficos.

De que outra forma os engenheiros perdem tempo? Através de erros mais sutis e raros. Alguns erros aparecem raramente, mas causam grandes danos. Talvez os usuários percam dados se executarem uma certa sequência de ações. Quando um engenheiro recebe um relatório de tal erro, ele deve encerrar tudo e corrigi-lo. Isso distrai o projeto atual e, gradualmente, o tempo de inatividade pode aumentar.

Dessa forma, engenheiros de software experientes começam a prestar muita atenção à qualidade do código, desejam verificar com cuidado. É por isso que as organizações de engenharia usam métodos que, à primeira vista, diminuem a velocidade do desenvolvimento: análise de código, integração contínua, observabilidade, monitoramento etc. Os erros são mais baratos se você os detectar em um estágio inicial, então os engenheiros investem pesadamente na detecção precoce de erros . Eles também se concentram na refatoração, o que simplifica a implementação. Em uma implementação mais simples, há menos chance de erro.

Assim, gerenciamento e desenvolvimento têm pontos de vista opostos sobre a qualidade. O manual concorda com uma alta taxa de erros (mas não muito alta), e os engenheiros desejam que o erro seja um mínimo absoluto.

Como isso afeta o gerenciamento de projetos? Gerentes e desenvolvedores dividem o projeto em pequenas tarefas. O prazo de entrega do projeto depende do número de tarefas e do número de engenheiros. Na maioria das vezes, um projeto leva muito tempo - e é ajustado pela remoção de funções. Em seguida, os engenheiros executam as tarefas. A realização da tarefa geralmente é realizada dentro do sprint.. Se o tempo de sprint for de duas semanas, cada tarefa terá um cronômetro implícito de duas semanas. No entanto, as tarefas geralmente levam mais tempo do que você pensa. Os engenheiros tomam decisões difíceis de priorização para concluir no prazo: "Eu posso fazer isso até o final do sprint se eu escrever testes básicos e se eu pular a refatoração que estava planejando". Os sprints exercem pressão constante, empurrando o desenvolvedor. Isso significa que o engenheiro pode comprometer a qualidade ou admitir falha na próxima reunião.

Alguns dirão que sou muito duro com sprints e eles estão certos. De fato, tudo isso é devido à pressão do tempo. O processo de sprint é apenas uma maneira conveniente de aumentar essa pressão aplicando-a várias vezes: uma vez durante a avaliação de todo o projeto e uma vez para cada tarefa. Se o produto é avaliado pelo valor agregado da empresa, é natural que o momento da implementação seja ajustado por si próprio. Os engenheiros também estão interessados ​​na implementação rápida, mas geralmente tentam otimizar custos a longo prazo, e não a curto prazo. No entanto, muitas organizações geralmente apenas estimulam a velocidade atual no curto prazo.

Tendo estabelecido esses incentivos, o gerente obtém o que deseja: ele pode nomear a função e a data futura, e a gerência e os desenvolvedores discutirão como fazê-lo. "Quero que você faça compras com um clique dentro de dois meses sem criar uma conta." Gerentes e desenvolvedores escreverão todas as tarefas por duas semanas e encurtarão a lista até que possam iniciar a função chamada "compras com um clique". Ela terá um risco moderado de falha e provavelmente só funcionará após algumas iterações. Mas a falha é temporária e a função é para sempre.

O que acontece se as premissas desse modelo econômico forem violadas?


Como eu disse, desenvolvemos bem o software, desde que as consequências da falha não importem. Isso é indicado pelos slogans "Mova-se rápido e quebre tudo", "Abra e repita". Mas todos podem imaginar uma situação em que o remake é caro ou até impossível. Em uma pitada, o colapso de um prédio pode matar milhares de pessoas e causar bilhões de dólares em danos. O Congresso de Facções de 2020 em Iowa é um exemplo mais brando. Se o evento falhar, à noite todos voltarão para casa vivos. Mas o partido não pode organizar essas reuniões pela segunda vez ... sem gastar muito tempo, dinheiro e esforço.

Nota breve: nesta seção, uso a frase “alto risco” como uma abreviação de “situações com impossibilidade de tentar novamente” e “situações com uma possibilidade cara de tentar novamente”.

O que acontece quando um modelo de site econômico é aplicado em uma situação de alto risco? Vamos dar um exemplo aleatório: digamos que você esteja escrevendo um aplicativo para relatar os resultados de uma reunião em Iowa. Quais etapas você seguirá para escrever, testar e testar o aplicativo?

Primeiro, a logística de engenharia: você precisa escrever um aplicativo para Android e um aplicativo para iPhone. Os relatórios são um requisito central, portanto, um servidor é necessário. Regras de coleta confusas devem ser codificadas no cliente e no servidor. O sistema deve relatar os resultados ao usuário final; essa é outra interface que precisa ser programada. O Partido Democrata provavelmente possui requisitos de validação e relatório que você deve escrever no aplicativo. Além disso, será muito inadequado se o servidor falhar durante a reunião, portanto, você precisa implementar algum tipo de sistema de monitoramento.

Em seguida, como verificar o aplicativo? Uma opção é o teste do usuário. Você mostra fotos de um aplicativo hipotético para usuários em potencial - e faz perguntas como "O que você acha que essa tela faz?" e "Se você deseja acessar $ a_thing, onde clicará?" O design sempre exige várias iterações; portanto, é razoável esperar alta qualidade após várias rodadas de tais testes. As grandes empresas costumam passar várias rodadas antes de introduzir recursos importantes. Às vezes, eles até cancelam funções após receber feedback antes de escrever pelo menos uma linha de código. O teste do usuário é barato. É difícil encontrar cinco pessoas que passarão 15 minutos no questionário, tendo recebido um vale-presente de cinco dólares como presente? No nosso caso, o mais difícil é fazer uma amostra representativa,que corresponde aos representantes democráticos de Iowa.

Então você precisa verificar o aplicativo em ação: instale e configure-o no seu smartphone. O Partido Democrata deve entender como obter resultados. No caso de uma falha, você precisa de um plano de backup. Um bom teste pode incluir uma "reunião de teste", na qual vários membros do Partido Democrata de Iowa baixam o aplicativo e relatam os resultados para um servidor central em uma determinada data. Isso identificará problemas e descreverá a situação geral. A verificação pode ser realizada em etapas, à medida que partes individuais do produto são introduzidas.

Além disso, a Internet está cheia de vilões. Por exemplo, grupos russos disseminaram amplamente informações erradasvia mídias sociais como Facebook, Reddit e Twitter. Portanto, você precisa garantir que nenhum estranho intervenha. Como verificar a autenticidade dos resultados? Além dos vilões, a Internet está cheia de curingas que estão prontas para atrapalhar qualquer evento apenas por diversão . Como nosso sistema resiste aos ataques DDoS? Caso contrário, existe um plano de backup? Quem é responsável por introduzir um plano de fallback relatando isso nas reuniões? O que acontece se as contas dos membros forem invadidas? Se a empresa não tiver especialistas em segurança, é provável que o aplicativo seja submetido a uma auditoria independente.

Além disso, como você garante que não há erro no software que distorcerá os resultados? Assim, o Partido Democrata deve desconfiar de si mesmo: é possível acreditar nos resultados se houver um traidor em suas fileiras? Os resultados devem estar disponíveis para verificação usando cópias em papel.

Ok, vamos parar de listar problemas. Uma coisa é clara: são necessários muito tempo e recursos para garantir que tudo funcione.

Os criadores do aplicativo Iowa Caucus receberam US $ 60.000 e dois meses. Eles tinham quatro programadores. Esse valor não é suficiente para pagar quatro bons programadores e outras despesas. O dinheiro não pode ser trocado por tempo. Praticamente não há ajuda externa.

Imagine que você esteja usando a prática geralmente aceita de remover tarefas de um projeto até que a linha do tempo seja viável. Você fará o seu melhor para economizar tempo. Uma visualização do catálogo de aplicativos geralmente leva menos de um dia, mas, na pior das hipóteses, pode durar uma semana e o aplicativo pode ser rejeitado. Então, vamos pular isso: os membros democratas farão o download do aplicativo via links beta. Mesmo com uma verificação de segurança gratuita, levará muito tempo para cumprir todas as recomendações. Portanto, recusamos a verificação de segurança. Talvez, durante o desenvolvimento do back-end, você pagou ao designer US $ 1000 pela criação do layout do aplicativo e do logotipo. Você planeja uma rodada de teste do usuário (mas a ignora quando os prazos expiram).Abra rapidamente e repita o ciclo! Tudo sempre pode ser consertado.

E a programação sempre leva mais tempo do que o esperado! Você encontrará plugues. Primeiro, as regras para a realização de reuniões não são totalmente claras. Sempre acontece quando uma solução digital é imposta ao mundo analógico. O mundo real pode chegar a um acordo com ambiguidade e inconsistência, mas o mundo digital não pode. Em resposta às suas perguntas, o Comitê do Partido Democrata preparará esclarecimentos. Isso vai te segurar. O comitê também pode alterar as regras no último segundo. Isso fará com que você altere o aplicativo antes do prazo final. Em seguida, você tem vários desenvolvedores, o que significa sobrecarga de coordenação. Cada codificador é 100% versado em dispositivos móveis,e no desenvolvimento de servidores? Todos eles dominam o React Native perfeitamente? Js? Texto datilografado? Comunicações cliente-servidor? Quais estruturas e bibliotecas você escolheu? Cada "Não" acrescenta tempo ao desenvolvimento para levar em conta a coordenação e o treinamento. Todos estão felizes com as estruturas de teste que você usa? Só brincando. Quais testes existem ... Sim, no início eles escreveram alguns testes, mas o aplicativo mudou tão rapidamente que foram excluídos.

O tempo não espera. Dois meses se passaram - você chega à linha de chegada com o último esforço e lança o lançamento final.

Com base no modelo econômico de um site, é bom terminar com pressa. No final, a pressa não importa, porque você cruzou a linha de chegada! Todos os problemas podem ser resolvidos em algumas semanas e depois passar para o próximo projeto.

Mas a pressa se refletiu na Assembléia Democrática de Iowa. No decorrer do evento, as chamadas começaram a chegar com reclamações sobre o aplicativo. Teoricamente impossíveis resultados ou duplicatas começaram a chegar. Em breve, programadores divertidos publicam com alegria fotos do KDPV e dizem que o Congresso de Facções de Iowa não deveria ter pedido um pedido, e que a votação só pode ser confiável com a tecnologia de papel.

achados


Este ensaio me ajudou a concluir: ao planejar um projeto, você precisa formalizar o custo da alteração. Fiz isso intuitivamente no passado, mas deve ser concretizado concretamente. Essa formalização ajuda a entender quais tarefas não podem falhar em nenhum caso. É como na minha robótica móvel: há longos ciclos de implementação e os danos do mau funcionamento podem atravessar o telhado. Passamos muito tempo desenvolvendo o monitoramento e criando métodos confiáveis ​​para suprimir e parar sistemas fora de controle. Também trabalho com serviços da Web para consumidores há dez anos, onde as consequências da falha são menores. Há uma maior disposição para assumir dívidas de curto prazo e avançar com o risco de falha temporária, especialmente quando a reversão é barata e a perda de dados é improvável. No mínimo, os estímulos estão pressionando por esse comportamento.Existem técnicas especiais em nossa indústria para evitar esses problemas. Um deles -investigação de falhas imaginárias (pre-mortem). Você precisa fazer isso com mais frequência.

A falha de Iowa tem um resultado positivo. Alguns não relacionados à TI perceberam que havia erros nos programas. Nos próximos anos, os patrocinadores do desenvolvimento de aplicativos para partidos políticos começarão a perguntar: "O que garante que a situação no Congresso de frações em Iowa não se repita?" Talvez eles se familiarizem com a literatura, que está tentando ensinar aos gerentes como trabalhar adequadamente com os engenheiros. Por exemplo, o Departamento de Defesa dos EUA tem um guia chamado "Como reconhecer projetos falsos ágeis", que descreve sinais suspeitos sobre um contrato. Os fóruns para startups estão cheios de não-técnicos que pedem (e recebem) conselhos sobre a contratação de desenvolvedores.

O setor de TI não aprendeu nada. O Congresso da Facção de Iowa ofereceu uma oportunidade para examinar como a suposição de um "alto custo de erro" mudará nossos processos principais. Mas não aproveitamos essa oportunidade e não extraímos nada dela. A indústria de software para consumidores não presta atenção aos riscos de erros. De fato, estamos felizes com os erros. Se o mundo exterior estiver interessado em melhorar a qualidade do nosso código em determinadas áreas, eles deverão regulamentar essas áreas. Esta não será a primeira vez. Lei Sarbanes - Oxley e HIPAA são exemplos de regulamentação no desenvolvimento de um modelo econômico de um site. A regulamentação não é suficiente, mas pode ser necessária.

É isso que queremos dizer quando dizemos: "Não sei como expressá-lo, mas toda a nossa área é ruim no que fazemos, e se você confiar em nós, todos morrerão". Nossa indústria foi formada em um ambiente em que os contratempos são baratos. E estamos interessados ​​em progresso rápido. Se a alteração é impossível ou muito cara, nossos processos habituais funcionam mal.

More articles:


All Articles