O Agile está matando a inovação em software

• Na conferência Black Hat, Moxie Marlinspike, fundador do Signal, afirmou que o desenvolvimento ágil está fazendo a inovação em software desaparecer nos últimos 20 anos
• Ele apontou que os desenvolvedores ficaram presos em "camadas de abstração de caixa-preta" e perderam a liberdade necessária para inovar
• "Qualquer pessoa que gerencie uma organização de engenharia provavelmente terá uma filosofia de gestão que seja um subconceito do Agile, um conceito derivado, algo dentro da esfera do Agile ou de alguma forma relacionado a ele"
  • Em vez de se moverem de baixo para cima, combinando expertise de engenharia com a visão para enxergar novas capacidades nas tecnologias existentes,
    ele argumenta que equipes Agile acabam isoladas em silos, trabalhando separadamente e sem conseguir entender o que outras equipes estão fazendo
• Também na sessão de encerramento, Window Snyder, fundadora e CEO da Thistle Technologies, acrescentou que essas equipes de caixa-preta também tendem a ter pouca visibilidade sobre os princípios de funcionamento de seus próprios produtos
  • Snyder também argumentou que estudantes que aprendem programação não aprendem a interagir com linguagens de baixo nível ou código de máquina, mas apenas com linguagens de alto nível que facilitam o desenvolvimento de apps, e por isso os engenheiros ficam sem o contexto necessário para entender como as peças do quebra-cabeça se encaixam em um todo maior

Pesquisadores de segurança detêm a chave da inovação

• Marlinspike também disse que, enquanto a engenharia de software vem sendo abstraída nas últimas décadas para ficar mais rápida, mais flexível e avançar mais, os pesquisadores de segurança têm tentado olhar além das abstrações
  • "Segurança é o processo de olhar para dentro do que é abstrato para entender como aquilo realmente funciona, o que existe por baixo e, às vezes, entender isso melhor do que a pessoa que o criou inicialmente"
• Assim, ele defende que os pesquisadores de segurança detêm a chave para impulsionar novas inovações
• Ele também fez uma analogia de que entender software é como entender magia, e que os especialistas em segurança são "as pessoas sentadas na biblioteca estudando magia"

Opinião do GN⁺

• Foi uma fala perspicaz de Marlinspike, apontando com precisão problemas fundamentais do Agile
• Faz sentido a observação de que, ao se concentrar demais em abstração e velocidade de desenvolvimento, os desenvolvedores estão gradualmente deixando de conhecer conceitos básicos
• Foi marcante a atenção dada ao papel dos pesquisadores de segurança. Como segurança é o trabalho de investigar a realidade escondida por trás das abstrações, ela pode se tornar uma força motriz para a inovação
• De certa forma, a mensagem é que engenheiros de software precisam buscar uma compreensão mais profunda
• As vantagens do Agile também existem claramente, então será necessária uma abordagem equilibrada. É preciso buscar formas de manter a agilidade e a flexibilidade do Agile sem deixar de fortalecer os fundamentos
• Para isso, será necessário melhorar desde a formação em desenvolvimento. Além de linguagens de alto nível, será preciso reforçar o ensino de fundamentos como linguagens de baixo nível e arquitetura de computadores

[jeokrang]

Parece que estão confundindo o problema de gestores que entenderam errado o Agile com um problema do próprio Agile.

[yangeok]

Também parece que, seguindo o fluxo dos tempos, como aprender conhecimentos de baixo nível não gera ROI, as pessoas acabam ficando só no aprendizado de conhecimentos de alto nível.

[andrewchaa]

Por que estão implicando com o Agile à toa ...

[lordang]

Você está misturando os conceitos de north-south e east-west na explicação, então o conteúdo fica confuso.
Dizer que não se sabe o que os outros times fazem me parece mais um problema da estrutura organizacional cross-functional do que do agile em si.

Quanto a não conhecer bem o low level, pelo texto parece mais algo como “nesses casos, também há uma tendência de não conhecer bem o low level”.

Mesmo que a questão de não saber o que os outros times fazem tenha alguma relação com agile, eu realmente não consigo entender o que não conhecer low level tem a ver com agile kkkkk

[lordang]

Se for analisar a fundo, com a ampla difusão do open source, não há mais tanta necessidade de construir tudo do zero; em vez de reinventar a roda, todo mundo simplesmente pega pronto o lado low level, então o mais correto talvez seja dizer que as pessoas não estudam isso porque não precisam, não?

Se eu tentar entender aquela fala, até dá para interpretar como: por causa do Agile, a preocupação é só fazer rápido e por isso não se estuda low level. Mas me parece que o mais certo é dizer que não estudam porque não é necessário.

[bbulbum]

Também acho que, por causa do Agile, escolhas que fazem a gente olhar os problemas de uma perspectiva mais ampla e manter a sustentabilidade no longo prazo acabam sendo deixadas de lado, e que isso, do ponto de vista do software, também faz com que o foco fique cada vez mais apenas em resolver o problema imediato.
Fazer algo funcionar de qualquer jeito não é, por si só, ser ágil, mas parece existir uma tendência a optar por decisões muito voltadas à velocidade, e acho que isso pode se tornar um fator que dificulta a busca por uma compreensão mais profunda.

[savvykang]

Não entendo por que estão tentando encontrar no ágil a causa do problema de as organizações de engenharia não terem poder de decisão.

[galadbran]

O que a situação de não saber o que outras equipes estão fazendo tem a ver com Agile...? ;;;

Mas, dito isso, o nome Window Snyder é bem peculiar...

[xguru]

Estou querendo ver o vídeo original, mas ainda não está lá. Acho que daqui a pouco ele deve aparecer no YouTube oficial.
https://www.youtube.com/@BlackHatOfficialYT/

[GN⁺]

Comentários do Hacker News

• A estrutura corporativa moderna é a raiz do problema

  • Existe uma teoria de gestão moderna segundo a qual responsabilidade e tomada de decisão devem subir pela hierarquia corporativa
  • Parte-se do princípio de que os funcionários da base são os que menos entendem do produto
  • Porém, na prática, os funcionários da linha de frente são os que têm mais informação
  • Quando a engenharia de software vira um processo de linha de montagem, a inovação para
  • Uma hierarquia de gestão totalmente igualitária não é a resposta, mas é preciso encontrar uma forma de não incapacitar quem está na linha de frente
  • O livro <i>Reinventing Organisations</i> explica estruturas corporativas inovadoras

• As boas ideias do Agile foram absorvidas pela engenharia de software em geral

  • Costuma-se pensar que programadores Agile seguem reuniões diárias rígidas, quadros Kanban etc.
  • Não acha que o Agile tenha causado a fragmentação do conhecimento e a desqualificação técnica da engenharia de software
  • É um problema causado pela tendência à produção em massa
  • Fenômenos parecidos aparecem também em montadoras e fábricas de móveis

• Reclamações sobre Agile, Scrum e OKR

  • Todos prometem empurrar liberdade e responsabilidade para os funcionários da base, mas na prática tudo se centraliza
  • Gostaria de aplicar OKR ao contrário
  • Cada funcionário deveria definir os resultados-chave na sua própria área, e os gestores deveriam orientar a direção da equipe com base nisso
  • É preciso uma abordagem de baixo para cima, não de cima para baixo
  • É preciso contratar bem, treinar bem e confiar nos funcionários

• Experiência em reuniões de refinamento de backlog

  • Teve que estimar a correção de bugs em um código que não conhecia
  • Como era difícil estimar, acabou dizendo um número qualquer
  • O Agile funcionava de forma parecida em três lugares diferentes

• Uma teoria sobre os problemas do Agile

  • Dividir o trabalho em partes pequenas é útil, mas programação exige criatividade
  • No processo de dividir o trabalho, muita informação se perde
  • O desenvolvedor precisa encontrar soluções criativas, mas não recebe as informações necessárias
  • São necessários desenvolvedores mais experientes ou melhores diagramas de arquitetura e documentação

• Queda na qualidade do software

  • Nas últimas décadas, o software piorou
  • Usamos máquinas mais potentes, mas com menor responsividade
  • Isso pode estar relacionado à ascensão do Agile

• Os engenheiros deveriam "possuir" partes do código

  • Foi a época em que o software da equipe era melhor

• Experiência evitando reuniões diárias em pé

  • Retrospectivas constantes e divisão de tarefas eram ineficientes
  • Só eram úteis para gestores não técnicos

• Problemas de organizações de grande porte

  • Os desenvolvedores já não lideram mais
  • Visão, produto, UX e gestão de projetos são decididos no topo
  • Os desenvolvedores executam o trabalho usando tecnologias de nuvem
  • Não conseguem entender o quadro geral nem fazer sugestões importantes

• Opinião de que é preciso recuperar a "mágica" do desenvolvimento de software

  • Dá para perceber que a pessoa está no setor há mais de 20 anos
  • Ao passar tempo com programadores mais jovens, ainda vê que a mágica existe
  • Havia reclamações parecidas 20 anos atrás, mas ainda assim o trabalho era divertido

[savvykang]

> Existe uma teoria moderna de gestão segundo a qual responsabilidade e tomada de decisão devem subir pela hierarquia corporativa.

Isso não seria uma característica de organizações burocratizadas?