Se O Software Fosse Construído Como o Cybertruck

Se o Cybertruck da Tesla fosse um projeto de software, seria um exemplo perfeito das práticas modernas de desenvolvimento.

Vocês conhecem essas práticas. Lançar o produto e resolver os problemas depois. O único problema é que as correções nem sempre chegam, e quem sofre é o cliente. Estamos todos cientes de correções que chegam tarde, e quando chegam, elas estão segurando o caminhão com goma e fita metafóricos.

Parece que isso é exatamente o que aconteceu com o Cybertruck e seus painéis.

Vamos dar uma olhada na jornada do Cybertruck e então nos perguntar a questão dolorosa. É assim que devemos construir qualquer coisa?

Movam-se rápido e quebrem coisas

O Cybertruck foi anunciado como uma máquina indestrutível, um modelo de engenharia moderna. Portanto, é chocante que seus painéis metálicos consigam simplesmente cair de um caminhão que é à prova de balas.

Se isso soa parecido com lançamentos de software, isso é porque é exatamente assim que alguns dos lançamentos de software que vemos se comportam.

Eu me lembro quando “acidentalmente” lançamos uma versão para iPad do nosso aplicativo para iPhone, e não testamos nada com esse tamanho de tela. E a experiência do usuário? Continua quebrada até hoje (embora estejamos “corrigindo”, não é mesmo?)

Quando trazemos essas práticas ruins para a produção de veículos, o impacto é o mesmo. Se você lança primeiro e lida com as consequências depois, as correções nem sempre são implementadas.

Quando a Apple lança e esquece de proteger a privacidade de seus usuários, as pessoas nos fóruns dirão que “É assim que a inovação funciona.” Eu vou me opor a isso. Isso não é. Isso é como engenharia apressada funciona, nem mais nem menos.

Zero-Day

A Tesla não é estranha a recalls. Eles estão administrando sua empresa como uma empresa de software (embora eu realmente espero que eles tenham QA para o chassi) então eles estão mais do que felizes em lançar funcionalidades sem estar completamente prontas.

Eles tiveram que emitir patches de software via ar para prevenir coisas como aceleração não intencional (porque colocar um pedal de acelerador em um painel de acabamento é uma decisão ousada).

Os engenheiros de software conhecem essa dança muito bem. Lembram-se do Log4j? Aquela pequena vulnerabilidade de zero-day que fez todos os engenheiros correrem para implementar um hotfix enquanto fingiam que não estavam em pânico?

A questão é que você não pode fazer um CrowdStrike e fingir que a culpa é de outra pessoa quando você está lançando um veículo que vai se mover na rodovia em alta velocidade com painéis literais caindo. A falha adesiva em software é quando seus módulos não se comunicam corretamente entre si, em um veículo é um nível massivo de falha.

Assim como exploits de zero-day, as falhas do Cybertruck parecem aparecer do nada. No entanto, suspeita-se que um pouco mais de tempo em QA, ao invés de exaltar a próxima funcionalidade, poderia ter produzido uma melhor experiência.

Testes de Software?

Não estou criticando o design do Cybertruck, por mais tentador que seja. O fato é que o veículo aparentemente não foi testado adequadamente antes do lançamento.

Quem deixa um carro ser lançado quando o pedal do acelerador fica preso (além da Nissan)? Quem não perceberia que as condições ambientais afetam a cola dos painéis? E depois diria: “isso está pronto para produção”?

A fascinação em colocar as coisas em produção sem testes adequados, e até mesmo desmantelar os departamentos de QA está acontecendo com frequência demais hoje em dia. O Cybertruck é apenas a degradação do QA ao longo do tempo em grande escala.

Refatoração?

Eu realmente espero que a Tesla tenha uma plataforma adequada para seus veículos. Com isso, quero dizer o chassi do carro. O problema é que no caso do Cybertruck a Tesla decidiu abandonar o design de veículo tradicional e optar por um esqueleto de aço inoxidável peculiar. Parece legal, mas funcionalmente é uma bagunça. Isso significa que as pessoas que trabalham no carro precisam se adaptar à situação ao invés de usar suas experiências anteriores, assim como quando meu chefe mudou o framework que usamos para um que ninguém entende.

Lembre-se de que existem alguns casos de uso que requerem dados relacionais e NoSQL simplesmente não serve. O Cybertruck é o que acontece quando alguém toma decisões arquitetônicas por razões de marketing em vez de técnicas, e esse é um problema que todos os desenvolvedores conhecem bem.

Beta

A Tesla lançou o Cybertruck em beta, mas eles simplesmente não chamaram assim. Isso seria “hmm, tudo bem” mas este é um produto de $100.000 mal feito. Em vez de admitir que estava inacabado, eles deixaram os clientes encontrarem os problemas primeiro.

Parece familiar? Deveria. É o que a maioria das empresas de software faz agora.

Chamamos isso de desenvolvimento ágil, mas às vezes é apenas uma desculpa para lançar software quebrado.

Quando os usuários reclamam, a resposta é:

• “Estamos iterando!”

• “Isso é um lançamento faseado!”

• “O feedback dos usuários faz parte do processo!”

A verdade é que às vezes estamos apenas vendendo um produto inacabado. Isso não é inovação. Isso é abusar da base de clientes.

Expectativa

Musk afirmou que o Cybertruck tinha mais de um milhão de pré-encomendas. Então, após o lançamento, a Tesla começou a oferecer descontos para fazer as pessoas comprarem.

As empresas de software fazem isso por:

• Exaltando uma nova funcionalidade que ainda não funciona.

• Anunciando uma atualização revolucionária de aplicativo que ninguém pediu, e chamando-a de transformadora.

• Vendendo um novo produto com uma valorização 10x, apenas para mudar quando os usuários percebem que é essencialmente um golpe.

Todos nós já vimos uma grande empresa de tecnologia soltar uma funcionalidade que acaba sendo pior do que o que substituiu. (Olhando para você, Google Chat.) O Cybertruck é apenas a versão física desse nonsense, e é hora de parar.

Você Está Construindo um “Cybertruck”?

Se você está no desenvolvimento de software, pergunte-se:

• Você realmente está testando antes do lançamento ou os usuários são sua equipe de QA?

• Você está priorizando a expectativa em vez de uma engenharia sólida?

• Você está consertando os problemas raiz ou apenas colando e torcendo para que cole?

Porque se sua resposta for “Estamos consertando na produção”, você está seguindo o caminho de Elon Musk. Você está construindo o equivalente em software a um Cybertruck.

Conclusão

O Cybertruck da Tesla é a manifestação física da promessa excessiva e da entrega deficiente que vemos no desenvolvimento de software.

De patches de zero-day a atualizações quebradas, estamos todos lançando “Cybertrucks” mais frequentemente do que gostaríamos de admitir.

Na próxima vez que você estiver prestes a lançar uma atualização, talvez teste-a adequadamente primeiro. Se a empresa não tiver processos que o apoiem, exija isso deles. Defenda o usuário. Garanta que enviemos software de qualidade, porque se você não fizer isso, quem o fará?