O "ponto de excesso de complexidade" é referido em inglês como:
OH MEU DEUS O QUE É ESSE CRAP.
O problema é que isso pode se aplicar a algo realmente simples, mas é implementado de maneira tão horrível que você tem a mesma reação.
Então, separar algo muito complexo de algo muito horrível pode ser difícil.
NO ENTANTO: O que realmente tende a acontecer com todos os softwares é um processo assim:
Etapa 1: tenha uma boa especificação, faça um bom design, implemente coisas legais. Todo mundo feliz.
No final da etapa 1: os desenvolvedores se parabenizam pela maravilhosa elegância de seu design e vão embora pensando felizes "Eu tenho um legado maravilhoso aqui para que outros possam adicionar coisas no futuro, será maravilhoso e o mundo será um melhor lugar."
Etapa 2: Algumas alterações são feitas, as coisas são adicionadas, novas funções estão incluídas. A arquitetura e a estrutura da Etapa 1 tornaram esse processo bastante indolor. [Opa, o "fator cruft" aumentou um pouco.]
No final da etapa 2: os desenvolvedores se parabenizam pela maravilhosa elegância de seu design e vão embora pensando felizes "Nossa, sou tão esperto por ter feito todas essas concessões na Etapa 1. Isso foi tão bom. Tenho um legado maravilhoso aqui para que outros possam adicionar coisas no futuro, será maravilhoso e o mundo será um lugar melhor ".
Etapa 3: Mais alterações são feitas, mais coisas são adicionadas, mais novas funções, várias coisas são alteradas, o feedback do usuário está realmente sendo ouvido.
No final da etapa 3: os desenvolvedores se parabenizam pela maravilhosa elegância de seu design e se afastam com um pensamento bastante feliz "Nossa essa arquitetura é muito boa para permitir que tantas mudanças se encaixem facilmente. Mas estou um pouco infeliz sobre X e Y e Z. Eles podem ser limpos um pouco agora. Mas !!! Ahhh! Eu sou tão esperto por ter feito todos aqueles subsídios na Etapa 1. Isso foi tão bom. Tenho um legado maravilhoso aqui para outros para adicionar coisas no futuro, será maravilhoso e o mundo será um lugar melhor ".
Etapa 4: assim como a etapa 3. Exceto:
No final da etapa 4: os desenvolvedores pensam: "Esse material que é tão bom está deixando o FEIO manter. Ele realmente precisa de algumas mudanças sérias. Não estou gostando muito de trabalhar nisso. Precisa de refatoração. Gostaria de saber o que o chefe dirá que quando eu disser a ele que precisa de 6 semanas e não haverá nada para os usuários verem no final disso ... mas terei outros 5 anos de escopo de modificação futura saboroso fazendo isso .... hmmm .. tempo para ir ao pub tomar um pouco de cerveja ".
Etapa 5: É necessário fazer várias alterações.
E DURANTE a etapa 5, os desenvolvedores dizem um para o outro: "Esse código é péssimo. Quem escreveu isso? Eles devem levar um tiro. É horrível. Temos que reescrevê-lo".
O passo 5 é fatal. É aqui que o fator de falha se torna tão ruim que o código não pode apenas ter mais algumas alterações, ele precisa ter algumas grandes alterações.
O problema na Etapa 5 é o desejo de jogá-lo fora e começar de novo. A razão disso ser fatal é "O fator Netscape". Vá para o Google. As empresas morrem nesse momento, porque começar de novo significa que você começa com cerca de 50% de premissas em vez de fatos, 150% de entusiasmo em vez de conhecimento, 200% de arrogância em vez de humildade ("Esses caras eram tão estúpidos!"). E você apresenta um monte de novos bugs.
A melhor coisa a fazer é refatorar. Mude um pouco de cada vez. Se a arquitetura estiver ficando um pouco cansada, corrija-a. Adicione, estenda, melhore. Gradualmente. Em cada etapa do processo, teste, teste e teste um pouco mais. Mudanças incrementais como essa significam que, dez anos depois, o código atual e o original são como o machado do avô ("ele tinha 10 cabeças novas e 3 alças novas, mas ainda é o machado do avô"). Em outras palavras, não resta muito em comum. Mas você mudou do antigo para o novo de forma gradual e cuidadosa. Isso reduz o risco e, para os clientes, reduz o fator de irritação.