Estamos estragando o software

• Estamos estragando o software ao não considerar mais a complexidade quando adicionamos funcionalidades ou otimizamos partes específicas
• Estamos estragando o software com sistemas de build complexos
• Estamos estragando o software ao tornar tudo inchado e frágil com cadeias de dependências absurdas
• Estamos estragando o software ao dizer aos novos programadores "Don’t reinvent the wheel!". Mas reinventar a roda é uma forma de aprender como as coisas funcionam e o primeiro passo para criar rodas novas e diferentes
• Estamos estragando o software ao não considerar mais a compatibilidade retroativa das APIs
• Estamos estragando o software ao pressionar pela reescrita de coisas que já funcionam
• Estamos estragando o software ao correr atrás de cada nova linguagem, paradigma e framework que aparece
• Estamos estragando o software ao sempre subestimar a dificuldade de lidar com bibliotecas complexas existentes em comparação com implementar algo diretamente
• Estamos estragando o software ao considerar que o padrão de fato XYZ é sempre melhor para nosso caso de uso específico do que algo que poderíamos implementar diretamente
• Estamos estragando o software ao afirmar que comentários no código são inúteis
• Estamos estragando o software ao confundir software com uma disciplina puramente de engenharia
• Estamos estragando o software ao criar sistemas que já não podem mais ser reduzidos: em qualquer sistema, o simples deveria poder ser alcançado de forma simples
• Estamos estragando o software ao tentar produzir código o mais rápido possível sem fazer esforço para criar um código o melhor projetado possível
• Estamos estragando o software, e o que restará já não oferecerá mais a alegria de hackear

[dohyun682]

Reinventar a roda <-> reinventar algo que já foi escrito

Esses dois não são conceitos completamente opostos entre si?

[roxie]

Vem aí o boom dos comentários

[tujuc]

Nossa, isso bate forte kkkkk. Sempre que entram pessoas mais novas... fico pensando em como devo explicar, e acho que isso pode ser um bom jeito.

[ilikeall]

Por favor, parem de bater em mim ;_;

[bus710]

....vou só ficar quieto...

[laeyoung]

Parece que há muitas coisas que se sobrepõem aos "10 sinais de que um país está ruindo" de que Han Feizi falava.

[GN⁺]

Comentários do Hacker News

• Isso me faz lembrar de uma palestra do Jonathan Blow. Software, como qualquer outra coisa, se deteriora se não for cuidado

  • A tecnologia de software parece avançar na superfície, mas na prática está em declínio
  • Melhorias de hardware e avanços em machine learning criam a ilusão de progresso, mas a robustez e a confiabilidade fundamentais do software estão piorando
  • O desenvolvimento moderno de software ficou desnecessariamente complexo, tornando difíceis até tarefas simples
  • Essa complexidade reduz a produtividade dos programadores e atrapalha a transmissão de conhecimento entre gerações
  • A sociedade passou a aceitar como normal um software cheio de bugs e pouco confiável
  • Se não simplificarmos os sistemas de software em todos os níveis, do sistema operacional às ferramentas de desenvolvimento, a civilização corre o risco de enfrentar uma regressão tecnológica semelhante a colapsos históricos

• Isso me faz lembrar dos "10 princípios do bom design" de Dieter Rams

  • Bom design é inovador
  • Bom design torna o produto útil
  • Bom design é estético
  • Bom design torna o produto fácil de entender
  • Bom design é discreto
  • Bom design é honesto
  • Bom design dura muito tempo
  • Bom design é minucioso até o último detalhe
  • Bom design é ambientalmente amigável
  • Bom design é o mínimo de design possível

• Compartilha uma experiência de trabalho em uma empresa nos anos 2000

  • Realizava o trabalho com dezenas de computadores, montou uma sala de servidores e construiu uma SAN para armazenar 3 TB de dados
  • Coordenava tarefas entre computadores executando scripts Object Rexx com um agendador de tarefas em VB6 desenvolvido internamente
  • Usava load balancer interno, servidor web, servidor de e-mail, servidor FTP e software próprio para enviar e receber arquivos
  • Agora é possível reproduzir toda a configuração em menos de uma semana com arquivos yaml e serviços de nuvem
  • A arquitetura de servidores foi "abstraída"
  • Há críticas à retrocompatibilidade, apontada como um dos problemas do Windows
  • A Apple quebrou a retrocompatibilidade, migrou entre 5 processadores e removeu a compatibilidade com código de 32 bits nos chips ARM

• Há muitas opiniões contraditórias

  • É preciso manter a retrocompatibilidade evitando a complexidade
  • Deve-se evitar árvores de dependências gigantes e reinventar a roda por conta própria
  • A única maneira de atender a todas as exigências é que nem todo mundo escreva código
  • Tem dias em que desejo isso pelo menos uma vez, mas não me orgulho disso

• Compartilha uma experiência no primeiro emprego

  • Escrevia software em C, e era a única linguagem com a qual se podia realisticamente desenvolver software comercial
  • Só uma pessoa conseguia fazer o build, usávamos uma ferramenta comercial de build, e ela era a única que sabia usá-la
  • O build levava horas
  • Achávamos que estávamos indo bem

• Opinião sobre por que estamos destruindo o software

  • Destruímos o software ao sempre achar que o padrão de facto de XYZ é melhor do que algo feito sob medida para nós
  • Uma abordagem genérica permite trocar facilmente por soluções superficiais para muitos problemas
  • Engenheiros gostam dessa abordagem, especialmente porque mudam de emprego com frequência, então acumulam algumas dessas preferências
  • Mas soluções sob medida têm desempenho muito melhor do que as genéricas

• Toda afirmação é uma troca

  • Em todos os casos, abre-se mão de algo para obter outra coisa
  • Às vezes faz sentido não reinventar a roda
  • Às vezes é preciso reinventar a roda para aprender
  • No geral, estamos criando mais do que destruindo
  • Não sinto necessidade de adotar uma posição negativa

• Respeito o antirez, mas acho que este post está cheio de frases curtas de efeito que não se sustentam em uma discussão

  • Ex.: iniciantes não deveriam reinventar a roda
  • Eles deveriam usar as ferramentas disponíveis no contexto dado
  • Se quiserem experimentar, deveriam escrever o próprio compilador
  • Mas não deveriam usá-lo em produção
  • Compatibilidade retroativa de API é, na maioria dos casos, uma decisão de negócios
  • Começar toda frase com "Estamos destruindo o software" não ajuda
  • Isso soa muito mais sombrio do que a realidade

• Opinião sobre o grafo de complexidade/dependências

  • O grafo de complexidade/dependências de um aplicativo aleatório é absolutamente insano
  • Não inclui firmware e o OS, mas chega perto o suficiente
  • Precisamos resolver o problema das dependências transitivas
  • Considera o OS (Win32 API, Linux syscalls) como a única dependência rígida de tudo que é escrito em C
  • Ao migrar para Java/Python, você perde controle sobre essa camada
  • É necessário escrever algumas centenas de linhas de código adequadas à situação específica em vez de depender de toda biblioteca
  • O custo de manutenção aumenta, mas dependências também precisam de manutenção
  • Elas podem ter APIs ruins, quebrar compatibilidade aleatoriamente, ser abandonadas ou virar malware
  • O máximo pessoal de linhas para um projeto útil é 5-10 KLOC em Java/JS/Python
  • Dá para revisar em poucas horas e modificar facilmente anos depois

• Elementos que estão destruindo o software

  • Entrevistas estilo Leetcode, desenvolvimento orientado a currículo, mudanças frequentes de emprego, fraude de investimento em crescimento, jogo de métricas, corrida por promoção, teatro de sprint, fanfarronice em todos os níveis do organograma, indiferença da indústria