Quando se torna um exagero?

Primeiro, peço desculpas porque não sei como criar um tópico da comunidade; então alguém me ajude por favor.

Como desenvolvedor, em várias plataformas, tecnologias e até em nível de infraestrutura; Eu sempre me pergunto, quando estou fazendo MUITO DEMAIS?!?

Foi um processo de aprendizado sem fim, desde que comecei. Uma (1) coisa que aprendi é que os requisitos mal são válidos por um longo período de tempo e, como tal, uma pequena previsão pode percorrer um longo caminho.

Mas onde está o equilíbrio e como você sabe quando está perdendo tempo, não está ganhando ?!

Você está fazendo muito quando o desenvolvedor médio não consegue entender o que você fez lendo seu código.

• Faça análises frequentes de código com sua equipe.
• Discuta com as arquiteturas, tecnologias ou padrões que planeja usar. (em reuniões stand-up diárias, se você as tiver)

Eu luto com todos os "arquitetos" orientados por CV que encontro. Eu gostaria que a cúpula existisse! ;)

Acredito que o mundo está desperdiçando uma pilha enorme de dinheiro que poderíamos usar para melhorar nossa vida (do programador).

Quando os processos ultrapassam os resultados.

Muitas vezes vimos que, se os desenvolvedores estão focando mais no processo do que nos resultados (como em qualidade, prazo final etc.), coisas ruins começam.

É por isso que nunca se deve esquecer que o objetivo das revisões de código, padrões de design etc. é melhorar o código, mas eles não são o alvo em si.

Para mim, eu gosto da abordagem que Kent Beck propõe no XP (não tenho certeza se é "dele" ou de outra pessoa, mas foi aí que eu a ouvi pela primeira vez):

Já é difícil resolver os problemas de hoje sem tentar descobrir quais são os problemas de amanhã e resolvê-los também.

Os desenvolvedores podem gastar muito tempo em soluções para requisitos que não existem, casos extremos que nunca ocorrerão ou até mesmo problemas genuínos em que o impacto do problema é significativamente menor que o custo para evitá-lo.

Este é o momento que pode ser colocado nas coisas que os usuários realmente desejam e usarão, coisas que lhes trarão benefícios que superam em massa os inconvenientes causados ​​no improvável evento de que uma dessas coisas realmente aconteça.

Além desse resultado não ideal para o usuário, o impacto sobre o desenvolvedor de mais de engenharia dessa maneira tende a ser sobre códigos complexos que são mais difíceis de suportar e mais difíceis de aprimorar.

Então, para mim, se você sabe, ou pode ter certeza, que algo é um requisito ou vai causar um problema, resolva-o, se não, então não.

Talvez seja necessário voltar e reformular o processo quando houver um requisito mais amplo do que o implementado originalmente, mas geralmente o esforço total que você coloca no projeto ainda será menor, porque na maioria dos casos isso não acontece.

Sua pergunta é bastante aberta, então eu a interpretarei como "fazendo muito em uma parte do projeto":

Para mim, é fácil gastar muito tempo em algo que realmente não fornece muito ganho para o cliente. Frequentemente, são as pequenas coisas como "Bem, funciona, mas não inteiramente como eu também quero", onde o cliente provavelmente não se importaria se funcionasse dessa maneira ou de outra.

Quando isso acontece, devo parar e dedicar tempo a coisas que são mais importantes. É melhor que o produto funcione como um todo, mas você tem essas peças menores que funcionam perfeitamente.

Escrever código rastreador (do Code Complete ) provavelmente é uma boa idéia para evitar isso: Você inicia seu projeto escrevendo um código que conecta todo o código - desde a GUI (ou próxima a ele) até o back-end e depois o back-end. Dessa forma, você sempre tem algo que funciona e não perde tempo aperfeiçoando as pequenas coisas até que tudo corra.

Mas, ainda assim, é uma questão de disciplina e priorização.

Quando eu respondo não a "vou ficar bravo, não fiz isso mais tarde e isso me morde .."

IRL As restrições de recursos e tempo geralmente me levam antes que eu tenha que fazer muito essa pergunta. Nesse ponto, você apenas se concentra nos bits mais importantes / alcançáveis ​​e espera pelo melhor.

um processo de aprendizado sem fim! ... e acho que continua assim! O equilíbrio é quando as coisas são eficientes o suficiente e você tem tempo para fazer outra coisa além da programação. Concordo com Gablin "uma questão de disciplina e priorização" e Jim Hopkins, de que isso se torna instinto depois de um tempo. Sei que aperfeiçoar as pequenas peças é o que nos faz felizes, mas no final tudo se resume ao que faz o usuário final feliz. então eu diria que o saldo (ou talvez o compromisso) é fazer o usuário final / cliente / cliente feliz primeiro (que deve ser o plano A) e, se houver tempo trabalhando para aperfeiçoar - tornando mais eficientes suas "pequenas peças" e / ou tudo o que você quiser. Em algum momento você tem que dizer "basta": :) caso contrário, sim, isso se tornará um exagero!

o pior cenário, é claro, é quando o usuário final / cliente / cliente é você! :)