O fato de serem interessantes para resolver não significa que alguém precise deles

“Um grupo de pessoas está fazendo um brainstorming em um laptop e uma folha de papel”, foto de Stefan Stefanchik, da Unspalsh

Existem muitos fatores que levam à criação de software ruim: a escolha de ferramentas, a comunicação da equipe, o desinteresse pessoal dos desenvolvedores em sucesso, a metodologia de teste. Parece-me que tudo isso tem a principal causa raiz: são problemas imaginários.

Software excessivamente complexo ou inoperante não foi concebido como tal. Ele é simplesmente projetado para outra coisa, e não para uma tarefa real.

Suponha que você publique podcasts e precise de um site onde possa vender produtos relacionados, ganhar dinheiro com publicidade e, o mais importante, publicar podcasts, vídeos e blogs.

Os requisitos para este pequeno aplicativo Web podem ser algo como isto:

• Download rápido para a América do Norte com transmissão ao vivo de podcast
• Nenhuma falha nos primeiros 15 minutos para 99,99% dos usuários, de preferência uma completa falta de falhas
• Boa integração com o Google Adwords e possivelmente outros sistemas de anúncios de terceiros, se você tiver tempo
• Links dinâmicos para os produtos mais recentes da loja e, se possível, recomendações para os usuários com base nas páginas exibidas.
• Integração com o Facebook Live player. Se você pode criar facilmente uma solução alternativa de streaming sem o Facebook, é ainda melhor

Você fornece essas especificações à equipe contratada e conversa um pouco com elas. Tudo parece estar no mesmo comprimento de onda. Mas quando eles mostram um protótipo em dois meses, seu rosto está cheio de sangue. Você gastou US $ 15 mil em um pedaço de lixo - e deseja recuperar seu dinheiro.

Quando você abre o aplicativo congela. Você pergunta como escolher o tipo de banners - e eles mostram uma interface do usuário feia e incompreensível. Metade dos links para as mercadorias da loja estão quebrados ou não há imagens, e a transmissão ao vivo via Facebook fica lenta!

Mas a equipe de desenvolvimento não entende sua raiva. De fato, do ponto de vista deles, eles conseguiram fazer um trabalho infernalmente difícil.

Eles colocaram sua alma na criação do aplicativo, com recursos incríveis:

• O sistema de recomendação mais avançado
• Algoritmo de descriptografia de texto em tempo real para todos os fluxos de áudio
• A página inicial é carregada com mais de 200 ms em todo o mundo
• O protocolo de streaming e o cliente são feitos quase do zero, a menos que você queira confiar no Facebook Live
• Foi desenvolvido um serviço que facilita a integração de mais de 20 trocas de publicidade

O problema é que você solicitou um produto básico com vários recursos adicionais, desde que eles sejam bastante simples de implementar. E a equipe de desenvolvimento entendeu de maneira diferente. Eles ouviram algumas tarefas emocionantes para fazer ... e muitos recursos básicos e chatos que não merecem muita atenção e testes rigorosos.

Pior, você não se comunicou diretamente com os desenvolvedores - falou através de um telefone danificado. Você conversou com um vendedor que realizou reuniões com alguns gerentes de nível intermediário. Eles escreveram algumas especificações de negócios para o gerente de projeto, que escreveu as especificações técnicas - e as entregou ao líder da equipe ou ao arquiteto, e ele e sua equipe começaram a desenvolver o produto. Cada link introduziu distorção ao longo do caminho.


Problemas imaginários costumam ser mais interessantes de resolver do que problemas reais. Pessoas com excesso de inteligência jogam jogos competitivos, inventam e resolvem problemas de matemática e escrevem livros para responder perguntas abstratas sobre a natureza humana - e tudo isso é gratuito, apenas por diversão. Mas um programador medíocre provavelmente cobrará uma taxa alta pela criação de um aplicativo Android simples. Isso não ocorre porque os programadores medíocres são mais difíceis de encontrar do que os gênios, mas porque as primeiras atividades são interessantes e as últimas são muito chatas.

A maioria dos programadores deseja receber o pagamento e se divertir ao mesmo tempo. Obviamente, a definição de "interessante" é diferente para todos, mas para muitos engenheiros se resume a resolver problemas interessantes e complexos que estão no campo da resolubilidade.

Dê a uma pessoa inteligente muitas tarefas chatas que não podem ser automatizadas, e você acabará deixando-a louca. No entanto, o cérebro humano, após bilhões de anos de evolução, tornou-se muito inventivo para manter a razão. Assim como as vítimas de privação ou abuso infantil encontram salvação em livros de ficção científica, vítimas de programação corporativa e freelancers buscam a salvação na solução de problemas imaginários.



O número de problemas imaginários que um engenheiro de software pode criar para si depende de sua imaginação e da complexidade dos problemas reais que precisam ser resolvidos.

Deve-se notar que esse problema não é exclusivo dos desenvolvedores. Departamentos de gerenciamento, vendas, RH, suporte, jurídico e até contábil - todos têm suas próprias maneiras de criar problemas imaginários. Alguns tentam entrar no processo de tomada de decisão quando a presença deles na reunião é simplesmente uma formalidade ou não é necessária. Outros superestimam a questão menor associada ao seu papel ou empregam muito mais funcionários do que o necessário para demonstrar sua importância.

Quando os problemas são muito estúpidos, pessoas inteligentes encontrarão uma maneira de corrigir a situação.


Mas problemas imaginários não vêm apenas de desenvolvedores entediados. Eles também resultam de longas cadeias de comunicações.

Quando comecei a procurar clientes como freelancer, não podia me dar ao luxo de criar comunicação a meu critério. Portanto, tive que lidar com longos segmentos de mensagens com centenas de cartas, onde pequenos detalhes do MVP interno eram discutidos. As pessoas durante a semana mudaram todos os requisitos do projeto. Eu tive clientes que fizeram essas perguntas: "Será compatível com a OIC?" ou "Posso adicionar alguma IA aqui?"

Obviamente, a maioria dos clientes tem experiência suficiente, mas mesmo eles geralmente não têm conhecimento para formular ou construir alguns requisitos. Isso é normal, porque parte do meu trabalho como "técnico em informática" é ajudar as pessoas a entender o que estão fazendo e o que não precisam, com base em sua situação específica. Mas é muito mais difícil determinar quando existem várias juntas entre você e o cliente.

Os requisitos mudam porque alguém entendeu mal a intenção ou tentou lidar com o tédio mencionado acima

A maioria das empresas gosta de iniciar um vendedor que incomoda clientes em potencial, negocia e geralmente descreve o produto. Também existem especialistas com habilidades avançadas de comunicação para discutir com o cliente especificações e requisitos mais detalhados: geralmente esse é o mesmo vendedor, apenas um pouco com um cargo diferente. E existe um sistema corporativo interno, vários níveis de gerenciamento e, possivelmente, alguma hierarquia na equipe técnica.

Quando a lista de requisitos de um cliente passa por tantas pessoas, mesmo que essas pessoas tenham as melhores intenções, algo inevitavelmente se perde no processo. Às vezes, isso acontece porque o requisito original não fazia sentido ou precisava ser alterado. Talvez o vendedor tenha dito ao cliente: "Em apenas 39.999, faremos isso na blockchain de cima". Ele concordou, mas todo mundo tem que adivinhar o que significa fazer na blockchain.

Na maioria das vezes, os requisitos mudam porque alguém entendeu mal a intenção ou tentou lidar com o tédio mencionado acima, tentando tornar seu trabalho ou o trabalho de sua equipe mais interessante e impressionante.

Por trás de tudo isso, os requisitos iniciais são perdidos - os problemas reais que precisam ser resolvidos. Eles são substituídos por problemas e vazios imaginários, e você tem muitas pessoas prontas e dispostas a preencher esses vazios com seus problemas imaginários, porque os problemas reais que eles precisam resolver são chatos, e preencher os vazios lhes dá satisfação.

Complexidade excessiva e seleção natural

Muitas vezes, há uma razão mais sombria para o surgimento de problemas imaginários: esses problemas ajudam uma equipe ou empresa a crescer e podem até se tornar parte integrante de seu trabalho.

"As pessoas que são retiradas, selecionadas e incentivadas a procurar soluções complexas não têm incentivo para introduzir soluções simplificadas".
- Nassim Nicholas Taleb

Você já ouviu falar desses três programadores que encontraram uma solução verdadeiramente simples para web banking seguro? Eles desenvolveram software bancário impecável do zero, usando metodologia de design funcional e linguagens seguras, e depois começaram a transferir grandes bancos para sua incrível infraestrutura.

Você pode não ter ouvido falar deles, porque eles não existem. Mas existem muitas equipes de milhares de desenvolvedores que não conseguem aprender conceitos simples, como "reversão para a versão antiga" , e estão constantemente ocupadas criando software bancário.

Armazenar e transmitir números não é um problema particularmente difícil. Indexar todo o conteúdo da Internet e exibir o resultado correspondente para uma consulta em linguagem natural em uma fração de segundo é outra questão. Mas apenas alguns caras inteligentes conseguiram resolver esse problema.

O problema crônico do banco on-line é que o ecossistema bancário realmente se destacou em sua própria hierarquia de apropriação de dinheiro. Seus líderes são sanguessugas corruptos que aderem ao corpo da sociedade, mas os líderes das organizações refletem apenas o estado de todo o sistema.

Não estou dizendo que a maioria dos funcionários comuns do banco são personalidades cruéis e prejudiciais. Nem um pouco. Como regra, são caras amigáveis ​​que ganham dinheiro com comida, moradia e educação para suas famílias. Mas o principal incentivo não é consertar o software bancário, mas economizar trabalho. Perder um emprego na economia moderna é um problema sério para algumas pessoas, e no setor bancário uma palavra descuidada ou uma iniciativa excessiva é uma maneira fácil de aparecer diante de um comitê disciplinar.

Assim, os sistemas bancários permanecem os mesmos - não por serem eficazes, mas por inércia. Essa inércia se manifesta na forma de resolver problemas imaginários, a fim de evitar a solução de problemas reais - cuja solução, como já observado, ameaça o trabalho de outras pessoas. Resolver esses problemas reais pode levar à demissão ou, no caso de algumas "instituições" particularmente desagradáveis, como o Goldman Sachs, a várias cartas que arruinam a vida do ex-funcionário e terminam com um estranho suicídio .

"É difícil fazer com que uma pessoa entenda alguma coisa se seu salário depende do que ela não entende!"
- Upton Sinclair

As empresas comuns ignoram o fato de que a alta gerência gasta 90% do tempo em "reuniões com clientes", incluindo viagens a ilhas tropicais e milhões de orçamentos para despesas gerais. Por sua vez, a alta gerência fecha os olhos à corrupção nas fileiras.

Como os gerentes de nível intermediário incentivam suas fantasias de Wall Street no estilo lobo, a gerência sênior ignora o comportamento desses gerentes, que compram escritórios bizarros, contratam três secretárias e uma dúzia de estagiários.

Como os gerentes comuns não se queixam de suas fantasias ditatoriais e sede de poder, os gerentes de nível médio ignoram o fato de que, em vez de cortar custos, passam um tempo nas apresentações do PowerPoint sobre "Melhorando nossa metodologia ágil e ágil".

Como os líderes de equipe nem prestam atenção que seus chefes nem sabem usar o Excel e vão ao escritório algumas vezes por semana, os gerentes comuns fecham os olhos quando os líderes de equipe e arquitetos falam sobre “a próxima geração de interação entre nossos sistemas através de JRPC e microsserviços usando Hibernate e Spring ”, quando essas malditas consultas MySQL são executadas por mais de um dia.

Como os desenvolvedores parecem não perceber que os líderes de sua equipe não escrevem nenhum código além de diagramas, os líderes de equipe não reclamam de seus desenvolvedores, que, em vez de EXPLICAR os freios da solicitação acima, refazem a interface do usuário pela décima vez em um ano usando a nova estrutura JavaScript.

Este é um círculo vicioso para resolver problemas imaginários: do CEO que não entende que roubar outros 30 milhões não lhe dará amor paternal, ao estagiário que não entende que o novo botão "Enviar" no Angular-Material-Bootstrap 19.13.5 não será alterado essas senhas são armazenadas em texto sem formatação (e são usadas para verificar cookies).

Mas todo mundo precisa continuar resolvendo problemas imaginários, porque, se parar de fazer isso, começará a se concentrar em problemas reais - e entenderá que todo o sistema está quebrado. Eles podem entender que, no canto do escritório, Debra analisa os gráficos de tempo de atividade do cluster de servidores há dez anos, embora cinco anos atrás a empresa tenha se mudado para a AWS. Eles podem entender que 99% de suas tarefas são necessárias apenas para salvar o trabalho de outra pessoa. E essa consciência é difícil de aceitar, ouso dizer, até impossível para a maioria. Portanto, a maioria encontra uma maneira de se adaptar.