Disclaimer
Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de dois episódios do nosso canal, Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.
Introdução
Neste post, vamos fazer uma revisão completa do famoso artigo "No Silver Bullet", escrito por Frederick Brooks em 1986. Brooks, também autor do livro "The Mythical Man-Month", traz nesse artigo reflexões sobre as dificuldades essenciais da construção de software que continuam extremamente relevantes mesmo após mais de 30 anos.
Vamos explorar as quatro dificuldades fundamentais descritas por Brooks, assim como suas sugestões para atacar a raiz desses problemas. Apesar de antigas, essas lições permanecem atuais e valiosas para quem trabalha com desenvolvimento de software nos dias de hoje.
As Quatro Dificuldades Essenciais
Antes de entrar nas sugestões, vamos recapitular as quatro dificuldades essenciais na construção de software apontadas por Brooks:
1. Complexidade
A primeira dificuldade é a complexidade inerente ao software. Existem muitas variáveis que se combinam, muitos estados diferentes a serem lidados. Conforme o software cresce, atender a diferentes escalas de usuários introduz novos desafios.
2. Conformidade
A segunda dificuldade é a conformidade. É difícil fazer o software atender a interfaces de uso muito diferentes. Cada pessoa que solicita algo, pensa de um jeito diferente sobre como usar aquele software. Adaptar o software para responder a essas diferentes interfaces é inerentemente complexo.
3. Mutabilidade
A terceira dificuldade é a mutabilidade, ou gestão de mudanças no software. Diferente de outras construções humanas, como prédios ou carros, o software muda constantemente com o tempo. Essa gestão de mudanças, mantendo a qualidade, é um grande desafio no dia a dia.
4. Invisibilidade
A quarta dificuldade é a invisibilidade do software. Ao contrário de um projeto de uma casa ou um desenho de um carro, não temos uma representação visual abrangente do software. As técnicas atuais de visualização ainda não resolvem plenamente essa dificuldade.
A Maior Dificuldade: Especificar o Software
Além das quatro dificuldades essenciais, Brooks destaca que, para ele, a maior dificuldade na construção de software não é a produção em si, mas sim especificar o que se deseja. Traduzir as necessidades de forma que possam ser escritas e automatizadas através de um software é um grande desafio.
4 Lições Que Continuam Atuais
Na última parte do artigo, Brooks sugere 4 formas de atacar a raiz do problema da dificuldade essencial de idealizar e construir software, em vez de focar em detalhes técnicos como ferramentas e linguagens.
1. Buy vs Build - Compre software em vez de desenvolver
Antes de sair desenvolvendo um software novo, avalie se já não existe um sistema pronto que atenda sua necessidade e que você possa comprar/assinar.
Com a explosão de sistemas SaaS (Software as a Service), muitas vezes não vale a pena gastar tempo e recursos desenvolvendo soluções para problemas que não são o core do seu negócio, quando outra empresa já resolveu isso como seu negócio principal.
Cada linha de código deveria valer a pena ser escrita. O melhor sistema é aquele que não precisa ser desenvolvido. Então se existe um software que você pode pagar para usar e que resolve seu problema, aproveite.
2. Grow, not Build - Cresça o software em vez de desenvolvê-lo de uma vez
Em vez de tentar chegar no design perfeito logo de cara, construa o software de forma incremental, em várias iterações.
Determine ciclos de refatoração antes de considerar o código pronto. Comece com poucos ciclos e vá aumentando conforme perceber que está recebendo feedbacks úteis. Use a quantidade de revisões como métrica para avaliar a qualidade do código.
3. Requirements Refinement and Prototyping - Refine os requisitos e prototipe
É muito difícil o usuário saber exatamente o que quer. Ele sabe o resultado esperado, mas não como chegar lá. Por isso, as especificações (histórias, casos de uso, etc) geralmente focam no "o que" e no "por quê", mas não no "como".
A sugestão é envolver toda a equipe (desenvolvedores, designers, etc) para prototipar a solução de forma rápida, criando telas e fluxos que possam ser validados com o usuário antes de partir para a implementação. Considero que o livro shape up endereçou isso aqui muito bem.
Isso reduz o vai-e-vem durante o desenvolvimento, aquelas situações em que a funcionalidade é implementada mas não atende totalmente o usuário, gerando retrabalho.
4. Great Designers - Valorize e desenvolva grandes designers de código
Estudos comprovam que os melhores designers e programadores produzem estruturas de código mais rápidas, menores, mais simples, mais limpas e com menos esforço.
Um grande designer vale por 5 a 7 designers ruins/medianos. Então invista no seu desenvolvimento, estude, pratique, varie os tipos de sistemas que você desenvolve, não espere a empresa te entregar projetos para treinar.
Opinião: É Uma Pena Ficar Só na Superfície
O artigo traz muito mais do que a famosa frase "não existe bala de prata". É uma pena que muitas pessoas na indústria ficam apenas na superficialidade, repetindo essa expressão sem se aprofundar.
Brooks cita possíveis "balas de prata" e ações que poderiam ser tomadas para lidar com a complexidade do software. Ele vai além das dificuldades e aponta caminhos valiosos.
Conclusão
O artigo "No Silver Bullet" de Frederick Brooks é uma leitura obrigatória para quem trabalha com desenvolvimento de software. Mesmo após mais de 30 anos, as reflexões sobre as dificuldades essenciais e as sugestões de como lidar com elas continuam extremamente relevantes.
Sobre a Jornada Dev + Eficiente
A Jornada Dev + Eficiente é um treinamento focado em fazer você crescer na carreira como uma pessoa cada vez mais especializada em Design e Arquitetura de Software.
A Jornada pavimenta este caminho fazendo com que você seja cada vez mais capaz de colocar código de qualidade em produção com cada vez mais velocidade.
Para conhecer mais, acesse https://deveficiente.com
Top comments (0)