O valor da simplicidade

Continuando a tradução...

Dois dos maiores gritos de guerra em XP são os slogans “faça a coisa mais simples que poderia possivelmente funcionar”, e “você não vai precisar disso” (conhecido como YAGNI - “You Aren´t Going to Need It”). Ambos são manifestações da prática XP chamada Design Simples.

O modo como YAGNI é normalmente descrita diz que você não deveria adicionar nenhum código hoje que será usado apenas por funcionalidades que serão necessárias amanhã. Diante disso, parece simples. O problema surge com coisas como frameworks, componentes reusáveis, e design flexível. Essas coisas são complicadas de construir. Você paga um custo extra antecipado para construi-los, na esperança de receber de volta mais tarde. Essa idéia de construir flexibilidade antecipadamente é vista como uma parte chave do design de software efetivo.

Todavia, o conselho de XP é que você não construa componentes e frameworks flexíveis para o primeiro caso que necessite deles. Deixe essas estruturas crescerem à medida em que são necessárias. Se preciso hoje de uma classe Dinheiro que trate adição, mas não multiplicação, então eu construo apenas a adição na classe Dinheiro. Mesmo que eu tenha certeza de que vou precisar da multiplicação na iteração seguinte, saiba como fazê-la facilmente, e pense que será realmente rápido fazer, ainda assim vou deixá-la para a próxima iteração.

Uma razão para isso é econômica. Se eu tenho que fazer qualquer trabalho que somente será necessário amanhã, significa que eu perco o esforço das funcionalidades que precisam ser feitas nessa iteração. O plano da release diz o que precisa ser feito para essa iteração, trabalhar em outras coisas para o futuro é contrário ao acordo que os desenvolvedores tem com o cliente. Existe um risco de que as histórias dessa iteração possam não ser concluídas. Mesmo que as histórias dessa iteração não estejam em risco, é o cliente quem deve decidir qual trabalho extra deveria ser feito - e isso pode não incluir a multiplicação.

Esse des-incentivo é composto pela chance de que podemos não ter entendido a funcionalidade direito. Por mais certo que possamos estar sobre como essa funcionalidade deveria funcionar, podemos ainda assim estar errados - especialmente já que não temos os requisitos detalhados ainda. Trabalhar na solução errada cedo é um desperdício ainda maior do que trabalhar na solução certa cedo. E os XPerts normalmente acreditam que somos muito mais propensos a errar do que acertar (e eu concordo com esse sentimento.)

A segunda razão para o design simples é que um design complexo é mais difícil de entender que um design simples. Portanto qualquer modificação do sistema é feita com mais dificuldade pela complexidade adicionada. Isso adiciona um custo durante o período desde que o design mais complicado foi adicionado até quando ele foi necessário.

Agora, esse conselho parece totalmente sem sentido para um monte de gente, e eles estão certos por pensarem assim. Certos, dado que você imagine o mundo usual do desenvolvimento onde as práticas habilitadoras de XP não estão presentes. Entretanto quando, o balanço entre o design planejado e evolutivo é obtido, então YAGNI se torna uma boa prática (e somente então).

Portanto, para sumarizar. Você não quer desperdiçar esforço adicionando nova capacidade que não será usada até uma iteração futura. E mesmo se o custo for zero, você ainda assim não quer adiciona-la porque ela aumenta o custo de modificação, mesmo que não custe nada para colocá-la. Entretanto, você apenas pode se comportar assim quando você está usando XP, ou uma técnica similar que reduza o custo das mudanças.