WET

A visão oposta a DRY é chamada WET, um pode ser traduzido como "escrever tudo duas vezes". As soluções WET são comuns em arquiteturas multicamadas em que um desenvolvedor pode ser encarregado, por exemplo, de adicionar um campo de comentário em um formulário em um aplicativo da web. A string de texto "comment" pode ser repetida no rótulo, na tag HTML, em um nome de função de leitura, em uma variável privada, em DDL de banco de dados, em consultas e assim por diante.

DRY odeia repetição.
E parece uma boa solução, mas não é. Sua abstração geralmente está errada.

Aqui está o porquê:

1. Você vê duplicação.
2. Você extrai a duplicação em uma nova abstração (método, classe).
3. Você substitui a duplicação pela nova abstração.
4. Você acha que seu código é perfeito.
5. O tempo passa o gerente de produto tem novos requisitos. Sua abstração é quase perfeita para eles.
6. Você começa a implementar os novos requisitos.E aqui está o pequeno problema: Sua abstração é quase perfeita. Por quê? Os novos requisitos afetam apenas 95% do código antigo que você extraiu para a abstração. Os outros 5% não são afetados. E em vez de criar uma nova abstração com 95% do código copiado da atual, você decide alterar o código da sua abstração.
7. Você adiciona uma instrução condicional, if.. por exemplo, e passa um parâmetro, para que sua abstração possa realizar diferentes ações para diferentes decisões.
8. Agora sua abstração se comporta de maneira diferente para casos diferentes.
9. Mais um novo requisito chega. Outro parâmetro adicional. Imagine isso dezenas de vezes. Seu código agora é incompreensivel.

Parabéns, você criou uma abstração errada.
O código não representa mais uma abstração única e comum.

Torna-se um procedimento carregado de condições.

É difícil de entender e fácil de quebrar. Adicionar novos recursos é incrivelmente difícil e cada novo recurso complica ainda mais o código.

WET (Write Everything Twice) é o conceito oposto ao DRY. Quando você começa a desenvolver um novo sistema, você não conhece todos os requisitos futuros. Portanto, não se apresse em abstrações.

A duplicação é muito mais barata do que a abstração errada

WET é dogmático e normativo. Conlin Durbin a definiu como:

Você pode se perguntar "Eu não escrevi isso antes?" duas vezes, mas nunca três.

AHA

AHA (se pronuncia "Arra!") pode ser traduzido como "Evite Abstrações Apressadas".

Descrito por Kent C. Dodds como otimizar para a mudança primeiro e evitar a otimização prematura. Ele foi influenciado por Sandi Metz "prefira duplicação sobre a abstração errada".

A AHA está enraizada no entendimento de que quanto mais profundo o investimento que fizemos na abstração de um software, mais percebemos que o custo desse investimento nunca poderá ser recuperado.

A programação AHA assume que as soluções WET e DRY inevitavelmente criam softwares rígidos e difíceis de manter.

Ao invés de começar com uma abstração, ou abstrair em um número específico de duplicações, o software pode ser mais flexível e robusto se a abstração for feita quando for necessária, ou, quando a própria duplicação se tornou a barreira e se sabe como a abstração precisa funcionar.

AHA, tem a missão de ser um bom equilíbrio entre DRY e WET.

Fontes:
https://betterprogramming.pub/when-dry-doesnt-work-go-wet-6befda0444bf

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

https://gomakethings.com/aha-programming-a-nice-balance-between-dry-and-wet/

https://imasters.com.br/codigo/principio-avoid-hasty-abstractions-evite-abstracoes-precipitadas

https://www.allanramos.com.br/aha-programacao/