YAGNI — You aren’t gonna need it!

YAGNI e uma sigla que significa "You aren’t gonna need it" (Você não vai precisar disso), que segundo Martin Fowler foi a origem do princípio da Simplicidade do Extreme Programming (XP).

Qual a origem da sigla YAGNI?

Segundo Martin Fowler esta sigla surgiu dentro do projeto C3, no qual Kent Beck sempre perguntava para Chet Hendrickson se determinada funcionalidade do sistema seria realmente necessária naquele momento.

Ainda segundo Martin Fowler YAGNI virou um tipo de mantra dentro do projeto, sendo incorporado e difundido posteriormente através do princípio da Simplicidade (Simplicity) do Extreme Programming (XP), uma metodologia de desenvolvimento de software Ágil.

Quem nunca passou por este tipo de situação? Apesar do senário ser um projeto de software, acredito que o questionamento de Kent Beck deve ser repetido em vários momentos da nossa vida.

De onde surgiu a ideia de falar sobre este assunto?

Sabemos que 2020 foi um ano atípico para todos e muito triste para várias pessoas ao redor do mundo, entretanto, me sinto privilegiado por poder estar mais perto da minha família e trabalhar em um ambiente muito saudável. Isto não seria possível sem a parceria constante da minha esposa, filhos e colegas de trabalho.

Entre os privilégios que tive neste ano, um deles foi reaprender a ler livros, principalmente os livros físicos, que me inseriram em um ambiente totalmente desconectado do mundo digital.

Em 2021 não poderia ser diferente, logo adquiri uma coletânea de livros que pretendo ler este ano. Veja que maravilha:

Então iniciei o ano lendo o livro Refatoração do Martin Fowler que fala brevemente sobre a sigla YAGNI, sendo que isto acendeu uma luz de curiosidade, principalmente por ser algo que realmente afeta meu dia a dia.

O que é o princípio da Simplicidade do XP?

O princípio da Simplicidade diz que devemos fazer apenas o que for necessário e solicitado, mais nada além disto. Através de pequenas iterações vamos evoluindo nossa base de código, minimizando assim o custo e maximizando o retorno.

O que o manifesto ágil tem haver com o YAGNI?

Claramente o Manifesto Ágil possui princípios que estão relacionados com o YAGNI. Sempre que evitamos que funcionalidades desnecessárias naquele momento sejam desenvolvidas, nós estamos aplicando um dos princípios abaixo:

• “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado”;

• “Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente”;

• “Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo”;

• “Simplicidade — a arte de maximizar a quantidade de trabalho não realizado — é essencial”.

Ao inserirmos ou alterarmos funcionalidades em um software estamos aumentando sua complexidade. Quando fazemos isto em momentos errados, podemos afetar diretamente a entrega contínua de valor para o cliente, bem como gerando um custo e esforço maior para evoluir e modificar o software.

Mas algumas pessoas podem questionar que isto não vai gerar mais complexidade, sendo apenas uma funcionalidade simples, então, deixo aqui uma frase do livro Refatoração: “Quanto mais código houver, mais difícil será modificá-lo corretamente” (FOWLER, 2019, p. 70).

Exemplo hipotético de uso do YAGNI dentro do processo de desenvolvimento de software

Uma empresa de desenvolvimento de software recebeu a missão de desenvolver um software para cálculo do preço de frete municipal para uma transportadora local, entretanto, a mesma está negociando com os órgãos regulatórios para poder operar frete interestadual. Este processo regulatório pode durar de 6 meses a 1 ano.

Diante desta informação a equipe de desenvolvimento está em um dilema entre desenvolver ou não o cálculo de frete interestadual. Além do cálculo de frete municipal ser muito mais simples que o interestadual, a transportadora não possui um conhecimento aprofundado sobre o mesmo.

O primeiro caminho seria desenvolver apenas o cálculo de frete municipal, entregando o software em um prazo/custo menor. Já o segundo seria desenvolver o cálculo de frete municipal e interestadual, entregando o software em um prazo/custo maior. Se a equipe decidir seguir a segunda opção, consigo vislumbrar algumas situações, entre elas:

• A empresa conseguiu a autorização do órgão regulatório, mas ficou muito tempo esperando para operar frete municipal;

• A empresa conseguiu a autorização do órgão regulatório, mas no intervalo deste processo regulatório as regras de cálculo foram alteradas;

• A empresa não conseguiu autorização do órgão regulatório.

Se esta equipe tivesse em mente o YAGNI, com certeza seguiria a primeira opção e desenvolveria apenas o cálculo de frete municipal. Qualquer decisão além desta vai elevar o prazo e o custo do projeto, podendo gerar perdas no curto como no longo prazo.

No cenário de desenvolvimento do cálculo do frete municipal e interestadual a única vantagem é para a empresa de desenvolvimento de software, visto que vai realizar a cobrança de um valor maior para o projeto. Entretanto, isto pode gerar uma grande insatisfação por parte do cliente, podendo influenciar na perda deste e outros clientes no futuro.

Para quem tem esta visão deturpada e privilegia o retorno no curto e não no longo prazo, eu deixo aqui um ditado popular: “Mais vale um pássaro na mão que dois voando”.

Por hoje é só!

Obrigado por chegar até aqui, espero que tenha evoluído como eu, durante a escrita deste pequeno artigo.

Em diversos momentos na minha carreira me deparei com estas situações e hoje vejo o tanto de esforço que dediquei no desenvolvimento de funcionalidades que não eram necessárias naquele momento e outras tantas que nunca foram se quer utilizadas.

Desejo realmente aplicar o YAGNI na minha vida pessoal e profissional, e a todo momento me perguntar se algo realmente é necessário naquele momento.