Como lidar com conceitos errôneos sobre "a otimização prematura é a raiz de todo mal"?

26

Eu encontrei muitas pessoas que são dogmaticamente contra qualquer coisa que possa ser considerada "otimização" no sentido geral da palavra em inglês, e elas frequentemente citam literalmente a citação (parcial) "otimização prematura é a raiz de todo mal" como justificativa para a posição deles, o que implica que eles interpretam o que estou falando como "otimização prematura". No entanto, essas visões às vezes são tão ridiculamente arraigadas que descartam praticamente qualquer tipo de desvio algorítmico ou de estrutura de dados da mais pura implementação "ingênua" ... ou pelo menos qualquer desvio da maneira como fizeram as coisas antes.Como alguém pode abordar pessoas como essa de maneira a fazê-las "abrir os ouvidos" novamente depois que elas ficam impedidas de ouvir sobre "desempenho" ou "otimização"? Como discuto um tópico de design / implementação que afeta o desempenho sem que as pessoas pensem instantaneamente: "Esse cara quer passar duas semanas em dez linhas de código?"

Agora, a posição de "toda otimização é prematura e, portanto, má" já foi abordada aqui e em outros cantos da Web , e já foi discutido como reconhecer quando a otimização é prematura e, portanto , , mas infelizmente, ainda existem pessoas no mundo real que não são tão abertas a desafios quanto à sua fé na antit Otimização.

Tentativas anteriores

Algumas vezes, tentei fornecer a citação completa de Donald Knuth para explicar que "a otimização prematura é ruim" ↛ "toda a otimização é ruim":

Devemos esquecer pequenas eficiências, digamos, 97% das vezes: a otimização prematura é a raiz de todo mal. No entanto, não devemos desperdiçar nossas oportunidades nesses 3% críticos.

No entanto, ao fornecer a cotação inteira, essas pessoas às vezes ficam mais convencidas de que o que estou fazendo é Premature Optimization ™, desenterram e se recusam a ouvir. É quase como se a palavra "otimização" os assusta: em algumas ocasiões, fui capaz de propor alterações reais no código para melhorar o desempenho sem que elas fossem vetadas, simplesmente evitando o uso da palavra "otimização (e | ação)" ( e "desempenho" também - essa palavra também é assustadora) e, em vez disso, usa alguma expressão como "arquitetura alternativa" ou "implementação aprimorada". Por essa razão, realmente parece que isso é realmente dogmatismo e não eles, de fato, avaliando o que digo criticamente e depois descartando-o como desnecessário e / ou muito caro.

errantlinguist
fonte
10
Bem, da última vez que discutiu, você realmente mediu que o desempenho seria ruim pela implementação mais pura e ingênua? Ou, pelo menos, fez uma estimativa aproximada do tempo de execução esperado? Caso contrário, essas outras pessoas poderiam estar totalmente corretas com sua opinião, você não tem como saber.
Doc Brown
12
@errantlinguist: Se o programa realmente é "lento como o melaço", então você claramente deve ser capaz de detectar facilmente os "3% críticos" de Knuth e, portanto, superar qualquer argumento contra a otimização. E se você não consegue detectar isso ... então ainda não fez sua lição de casa e ainda não está pronto para otimizar. Portanto, não está claro onde está o problema.
Nicol Bolas 12/04
6
@errantlinguist: se você apresentou evidências de que essa seção de código é um problema de desempenho significativo para o aplicativo, e o aplicativo como um todo era mais lento do que o necessário, e eles ainda negavam a necessidade de modificar o código, isso não significa ' não importa. Você está lidando com pessoas que são impermeáveis ​​ao raciocínio baseado em evidências e, portanto, não são razoáveis.
Nicol Bolas 12/04
6
@errantlinguist: A questão principal: os clientes estavam reclamando que o aplicativo naquela área era lento?
Gort the Robot
5
Estou votando para fechar porque o OP claramente está apenas procurando alguém para validar uma opinião, em vez de uma resposta para uma pergunta real. Eu não acho que isso iria (ou deveria) permanecer aberto no Workplace.SE também.
BlueRaja - Danny Pflughoeft 12/04

Respostas:

35

Parece que você está procurando atalhos para não experimentar a "implementação ingênua mais pura" primeiro e implementar diretamente uma "solução mais sofisticada porque você sabe de antemão que a implementação ingênua não fará isso". Infelizmente, isso raramente funciona - quando você não possui fatos concretos ou argumentos técnicos para provar que a implementação ingênua é ou será muito lenta, você provavelmente está errado e o que está fazendo é a otimização prematura. E tentar discutir com Knuth é o oposto de ter um fato difícil.

Na minha experiência, você terá que concordar e tentar a "implementação ingênua" primeiro (e provavelmente ficará surpreso com a frequência com que isso é rápido o suficiente), ou pelo menos fará uma estimativa aproximada do tempo de execução, como:

"A implementação ingênua será O (n³), e n é maior que 100.000; isso durará alguns dias, enquanto a implementação não tão ingênua será executada em O (n), que levará apenas alguns minutos" .

Somente com esses argumentos em mãos, você pode ter certeza de que sua otimização não é prematura.

Há apenas uma exceção no IMHO : quando a solução mais rápida também é a mais simples e mais limpa, você deve usar a solução mais rápida desde o início. O exemplo padrão é o de usar um dicionário em vez de uma lista para evitar códigos de loop desnecessários para pesquisas ou o uso de uma boa consulta SQL que fornece exatamente o registro de um resultado necessário, em vez de um grande conjunto de resultados que deve ser filtrado posteriormente no código. Se você tiver esse caso, não discuta sobre desempenho- o desempenho pode ser um benefício adicional, mas provavelmente irrelevante, e quando você o menciona, as pessoas podem ficar tentadas a usar Knuth contra você. Discuta sobre legibilidade, código mais curto, código mais limpo, capacidade de manutenção - não é necessário "mascarar" nada aqui, mas porque esses (e somente esses) são os argumentos corretos aqui.

De acordo com a minha experiência, o último caso é raro - o mais comum é o caso de se poder primeiro implementar uma solução simples e ingênua, que seja melhor compreensível e menos propensa a erros do que uma mais complicada, mas provavelmente mais rápida.

E, é claro, você deve conhecer os requisitos e o caso de uso suficientemente bem para saber qual desempenho é aceitável e quando as coisas ficam "muito lentas" aos olhos dos usuários. Em um mundo ideal, você obteria uma especificação formal de desempenho por seu cliente, mas em projetos do mundo real, o desempenho exigido costuma ser uma área cinzenta, algo que seus usuários só dizem quando observam que o programa se comporta "muito devagar" na produção. E, muitas vezes, essa é a única maneira de descobrir quando algo é muito lento - o feedback do usuário, e então você não precisa citar Knuth para convencer seus colegas de equipe de que a "implementação ingênua" não era suficiente.

Doc Brown
fonte
15
@errantlinguist: talvez eu não tenha me deixado claro, ou simplesmente não é o que queria ouvir? Meu conselho é:.. Não tente usar * argumentos filosóficos" de Knuth sobre '3%' ou '97%' Mantenha-o factual, caso contrário, seus colegas são mais provavelmente está certo de que seus argumentos de desempenho são inadequadas
Doc Brown
4
@errantlinguist: no caso que você descreveu em seu comentário à resposta de Karl Bielefeld, você parece ter todos os argumentos do seu lado, sem a necessidade de usar o "desempenho". Eu daria um passo adiante e diria que, se você argumenta sobre desempenho nesse caso, comete um erro tremendo, porque seus colegas estão certos: o desempenho normalmente não importa lá. Discuta sobre simplicidade, legibilidade, facilidade de manutenção, menos linhas de código, mas não (!) Sobre desempenho, nem mesmo como uma observação lateral. Não ofereça a eles a possibilidade de usar Knuth contra você.
Doc Brown
2
@errantlinguist: não o enterre - coloque esses aspectos em foco, quando estiver correto que esses aspectos estejam em foco e não use o desempenho como argumento quando você não puder provar que isso faz uma diferença importante para o usuário final.
Doc Brown
2
@errantlinguist: Não sei ao certo como você chega a essa conclusão. A resposta de Doc Brown parece perfeitamente clara: você discute esses argumentos improdutivos que está tendo com seus colegas, aderindo a declarações factuais sobre o que é e o que não é desempenho aceitável.
Jl6 #
1
Esse é um bom conselho para programar em tamanho pequeno, mas ignorar as questões de desempenho no nível do design de arquitetura pode levar uma equipe a um longo beco sem saída, porque pode ser feito muito antes de ser forçado a enfrentar o problema, e não há garantia de que grande parte desse trabalho seja reutilizável quando o problema é arquitetural (vi matar um produto). Sei que você tem uma exceção em sua resposta, mas para saber se isso se aplica, você ainda precisa fazer a pergunta , e até fazer a pergunta é aparentemente um anátema para os colegas de trabalho errantes.
sdenham
18

Pergunte a si mesmo:

  • O software NÃO está atendendo às especificações de desempenho?
  • O software tem um problema de desempenho?

Essas são razões para otimizar. Portanto, se as pessoas se opuserem, apenas mostre a especificação e volte a elas e explique que precisamos otimizar porque não estamos atendendo às especificações. Fora isso, seria difícil convencer os outros de que a otimização é necessária.

Acho que o principal ponto da citação é que, se você não tiver um problema, não execute otimizações desnecessárias, pois tempo e energia poderiam ser gastos em outros lugares. Do ponto de vista comercial, isso faz todo o sentido.

Secundário, para aqueles que temem a otimização, sempre faça backup das descobertas de desempenho com métricas. Quanto mais rápido é o código? Quanto o desempenho melhorou em relação ao anterior? Se alguém gastasse duas semanas apenas para melhorar o código em 2% em relação à versão anterior, se eu fosse seu chefe, não ficaria feliz. Essas duas semanas poderiam ter sido gastas implementando um novo recurso que poderia atrair mais clientes e ganhar mais dinheiro.

Finalmente, a maioria dos softwares não precisa ser altamente otimizada. Somente em algumas indústrias especializadas a velocidade é realmente importante. Portanto, na maioria das vezes é possível usar bibliotecas e estruturas preexistentes com bons resultados.

Jon Raynor
fonte
4
Embora sejam boas informações, isso realmente não responde à minha pergunta sobre como trabalhar com pessoas que impedem uma discussão no minuto em que ela tem a ver com desempenho.
errantlinguist
7
Eu concordo com tudo isso, exceto "Apenas em algumas indústrias especializadas a velocidade é realmente importante". Eu acho que você subestima a quantidade de software que apresenta problemas de desempenho da perspectiva do cliente.
Gort the Robot
@StevenBurnap: Sim - existem aplicativos da Web em estado selvagem que, na verdade, não são lentos? - Gostaria de ver um na mesma ciência.
errantlinguist
1
google.com é muito rápido. :-P
Gort the Robot
Tente usar google.com em uma conexão móvel EDGE. Sim, esse é um caso ridículo, mas definitivamente não será muito rápido . ;) (Pun realmente não intended-- realmente)
errantlinguist
7

Como trabalhar com pessoas que impedem uma discussão no minuto em que ela tem a ver com desempenho?

Comece com princípios compartilhados que se baseiam na direção estratégica do seu grupo.

Meus princípios:

Meus princípios pessoais sobre como escrever código devem primeiro buscar a correção no meu programa, depois analisá-lo e determinar se ele precisa de otimização. Eu perfil meu código porque outros programadores são consumidores potenciais do meu código - e eles não o usarão se for lento - portanto, para o meu código, a velocidade é um recurso.

Se seus consumidores são clientes, eles lhe dirão se você precisa de um código mais rápido.

No entanto, existem escolhas comprovadamente melhores no código que se pode fazer. Prefiro acertar no meu primeiro rascunho por vários motivos:

  1. Se eu acertar na primeira vez, posso esquecer a implementação (aproveitando a ocultação de informações) e não entupir meu código com os TODOs.
  2. Outros (particularmente aqueles que apenas aprendem no trabalho) veem o processo da maneira correta e aprendem e usam o mesmo estilo de código daqui para frente. Por outro lado, se eles me virem fazer da maneira errada, também farão da maneira errada.

Supondo que a necessidade de otimização esteja correta

Supondo que essa é uma parte realmente importante do seu código que precisa de otimização, você pode contar a parábola de Schlemiel, o Pintor , ou enfatizar o restante da citação:

"Os programadores perdem muito tempo pensando ou se preocupando com a velocidade das partes não críticas de seus programas, e essas tentativas de eficiência realmente têm um forte impacto negativo quando a depuração e a manutenção são consideradas. Devemos esquecer as pequenas eficiências, por exemplo, sobre 97% do tempo: a otimização prematura é a raiz de todo mal. No entanto, não devemos desperdiçar nossas oportunidades nesses 3% críticos ". - Donald Knuth

Pesar os custos de complexidade adicional

Às vezes, há um custo real em termos de manutenção da complexidade adicionada. Nesse caso, você pode manter a implementação secundária em uma função ou subclasse diferente e aplicar os mesmos unittests nela, para que não haja dúvida de que ela está correta. Posteriormente, se você criar um perfil de seu código e considerar a implementação ingênua um gargalo, poderá alternar seu código otimizado e comprovadamente melhorar seu programa.

Liderança

Às vezes, o problema é o ego - algumas pessoas preferem usar código abaixo do ideal ou com erros do que alguém mais certo do que é. Você provavelmente quer evitar trabalhar com essas pessoas.

Liderança, especialmente quando você não tem autoridade posicional sobre as pessoas, é fazer sugestões razoáveis ​​e guiar outras pessoas a um consenso. Se você não pode guiar sua equipe para um encontro de mentes, talvez não valha a pena insistir no assunto. Provavelmente há peixes maiores para fritar.

Aaron Hall
fonte
6

O caminho a seguir é esquecer a citação real e as várias interpretações - é dogmatismo de qualquer maneira concentrar-se tanto em uma citação específica de um guru. Quem disse que Knuth está sempre certo, afinal?

Em vez disso, concentre-se no projeto em questão, o software que você está desenvolvendo junto com os colegas dos quais você não concorda. Quais são os requisitos para um desempenho aceitável para este software? É mais lento que isso? Então otimize.

Você não precisa chamá-lo de "otimização", pode chamá-lo de "consertar um bug", pois é por definição um bug se a implementação falhar em conformidade com os requisitos.

De maneira mais geral, existem duas possibilidades em relação às otimizações:

  1. O código otimizado também é mais curto, mais simples de entender e mais fácil de manter.

  2. O código otimizado é mais complexo de entender, leva mais tempo para escrever e testar ou seria mais complexo mudar no futuro se os requisitos mudarem de maneiras inesperadas.

Se o caso for (1), você nem precisa discutir sobre otimização. Mas se (2) for o caso, você estará envolvido em uma decisão de troca . Na verdade, essa é uma decisão em nível de negócios, não puramente técnica. Você precisa pesar o custo da otimização em relação ao benefício. Para que haja um benefício, a ineficiência deve ser um problema em primeiro lugar, como má experiência do usuário ou aumento significativo do custo de hardware ou outros recursos.

JacquesB
fonte
Bem, concordo plenamente com sua sentença inicial. No entanto, tenho certeza de que um software pode ser "irritantemente lento para o caso de uso pretendido" sem ter os requisitos de desempenho especificados explicitamente de maneira formal.
Doc Brown)
@DocBrown: Claro, mas, de qualquer forma, é o cliente quem decide se é muito lento ou não, não o desenvolvedor.
precisa saber é o seguinte
Nunca encontrei requisitos de negócios que declarassem explicitamente requisitos de desempenho.
errantlinguist
@errantlinguist: Na minha experiência, é bastante comum em empresas focadas no cliente, como lojas on-line. Mas para ferramentas e aplicativos para uso interno em uma empresa, a experiência do usuário geralmente não é uma preocupação para o proprietário do projeto.
precisa saber é o seguinte
4

Eu acho que a citação completa no contexto é instrutiva. Vou copiar de um post que fiz no Reddit sobre o tema:

Não há dúvida de que o graal da eficiência leva ao abuso. Os programadores perdem muito tempo pensando ou se preocupando com a velocidade das partes não críticas de seus programas, e essas tentativas de eficiência realmente têm um forte impacto negativo quando a depuração e a manutenção são consideradas. Devemos esquecer pequenas eficiências, digamos, 97% das vezes: a otimização prematura é a raiz de todo mal.

No entanto, não devemos desperdiçar nossas oportunidades nesses 3% críticos. Um bom programador não será levado à complacência por esse raciocínio; será prudente olhar atentamente para o código crítico; mas somente após esse código ter sido identificado.

- Donald Knuth, Programação Estruturada com ir para Declarações , ACM Computing Surveys, Vol. 6, No. 4, Dez. 1974, p.268

O ponto e a implicação é que há coisas mais importantes com que se preocupar do que dedicar sua atenção à otimização muito cedo. Certamente, você deve considerar cuidadosamente suas estruturas de dados e algoritmos (isso é de 3%), mas não deve se preocupar se a subtração é mais rápida que o módulo (sendo de 97%) até ficar claro que a otimização de baixo nível é necessário.

O primeiro não é necessariamente otimização no sentido em que seus colegas estão pensando, mas é otimização no sentido de que algoritmos e estruturas de dados mal escolhidos são abaixo do ideal.

desvanecer-se
fonte
2
Pode-se acrescentar que Knuth claramente não pensa que analisar a complexidade do tempo dos algoritmos e fazer escolhas de design nessa base seja uma otimização prematura.
sdenham
3

Na minha experiência, se você se opõe a esse tipo de otimização regularmente , as pessoas não estão realmente reclamando da otimização. Eles estão reclamando do que você está sacrificando em nome da otimização. Isso geralmente é legibilidade, capacidade de manutenção ou pontualidade. Se o seu código for entregue na mesma quantidade de tempo e fácil de entender, as pessoas não se importarão se você estiver usando estruturas e algoritmos de dados mais eficientes. Minha sugestão nesse caso é trabalhar para tornar seu código mais elegante e sustentável.

Se você está recebendo esse tipo de oposição em relação ao código de outras pessoas, geralmente é porque está sugerindo uma quantidade significativa de retrabalho. Nesses casos, você realmente precisa de algumas medidas reais para mostrar que vale a pena o esforço, ou talvez tente se envolver mais cedo na fase de design, antes que o código seja escrito. Em outras palavras, você precisa provar que está nos 3%. Se reescrevéssemos todo o código que não era exatamente como gostávamos, nunca conseguiríamos realizar nada.

Karl Bielefeldt
fonte
Infelizmente, na verdade, fiz o caso oposto, onde utilizo, por exemplo, um Dequeda biblioteca padrão Java para substituir uma enorme quantidade de lógica construída em torno de uma ArrayListusada como uma pilha enquanto trabalhava no código ... e isso foi marcado como mudança na revisão. Em outras palavras, o revisor queria ter mais código, que também é mais lento e mais propenso a erros, porque ele não estava familiarizado Deque.
errantlinguist
3
Não querer aprender algo que está no seu idioma há 10 anos é uma atitude tóxica para um programador e um problema muito mais profundo do que o descrito originalmente. Pessoalmente, nessa situação, eu recusaria o conselho e o encaminharia para a gerência, se necessário.
Karl Bielefeldt
5
@errantlinguist: quando o revisor sugeriu uma solução claramente pior (o que significa mais complicada) como substituta de uma solução limpa e simples, você deve argumentar sobre isso. Não discuta sobre desempenho! Sério, nunca use a palavra "desempenho" nessa discussão. Discuta apenas sobre legibilidade e manutenção. E se o revisor insistir em seu código incorreto, aumente.
Doc Brown
+1 Não sabe ao certo por que essa resposta tem votos negativos em vez de positivos, além de ser a resposta aceita. Ele sugere uma maneira de lidar com o problema, além de uma análise do que pode ser o verdadeiro problema subjacente (ou seja, que ninguém quer que o código seja escrito radicalmente).
Andres F.
2

De fato, existem muitos mal-entendidos sobre essa citação; portanto, é melhor dar um passo atrás e analisar qual é o problema real. O problema não é tanto que você nunca deve "otimizar". É que "otimizar" nunca é uma tarefa que você deve se preparar. Você nunca deve acordar de manhã e dizer para si mesmo "ei, eu deveria otimizar o código hoje!".

Isso leva ao desperdício de esforço. Basta olhar para o código e dizer "Eu posso torná-lo mais rápido!" leva a muito esforço para fazer algo mais rápido que foi rápido o suficiente em primeiro lugar. Você pode se orgulhar de dizer a si mesmo que fez um pouco de código quatro vezes mais rápido, mas se esse código era um cálculo que acontecia com o pressionar de um botão e, em primeiro lugar, eram necessários 10 ms antes de exibir para um usuário humano, ninguém vai dar a mínima.

Esse é o "prematuro" na "otimização prematura". Quando não é "prematuro"? Quando os clientes dizem "isso é muito lento, conserte!" É quando você digita o código e tenta torná-lo mais rápido.

Isso não significa que você deve desligar seu cérebro. Isso não significa que você deve manter 10.000 registros de clientes em uma lista vinculada individualmente. Você sempre deve entender os impactos no desempenho do que faz em mente e agir em conformidade. Mas a ideia é que você não gaste tempo extra deliberadamente tentando torná-lo mais rápido. Você está simplesmente escolhendo a opção com melhor desempenho dentre as opções iguais.

Gort the Robot
fonte
Isso não significa que você deve desligar seu cérebro. Isso não significa que você deve manter 10.000 registros de clientes em uma lista vinculada individualmente. > Enquanto eu concordo 100% com você, eu realmente vi listas vinculadas usadas dessa maneira e me disseram para "não tocar nela".
errantlinguist
Embora sejam boas informações, isso realmente não responde à minha pergunta sobre como trabalhar com pessoas que impedem uma discussão no minuto em que ela tem a ver com desempenho.
errantlinguist
3
Infelizmente, a coisa da "lista vinculada individual" não foi um exemplo aleatório, mas algo que eu encontrei pessoalmente.
Gort the Robot
1

Você pode fazer as coisas da maneira errada ou fazer as coisas da maneira certa.

Freqüentemente, as coisas são feitas da maneira errada e o código é refatorado para que seja feito da maneira certa. Se você vai escrever um novo código e sabe que pode fazer as coisas da maneira certa sem uma grande penalidade, eu iria errar ao fazê-lo da maneira certa. (Observe que, após testes de desempenho, etc., algumas coisas podem precisar mudar - mas tudo bem. Como alternativa, uma implementação completamente ingênua raramente é, se é que alguma vez, é correta.)

Não é necessariamente uma otimização prematura se você a) souber que isso ajudará no futuro ou b) saber que o caminho abaixo do ideal levará a problemas futuros. É como um jogo de xadrez, na verdade.

Eu acho que as pessoas tendem a querer fazer as coisas certas, ao invés de fazerem errado. Use isso quando discutir estratégias alternativas com seus colegas.

lunchmeat317
fonte
5
Nunca existe "o caminho errado" ou "o caminho certo". Geralmente, há um número infinito de maneiras que são executadas em um continuum de "Meu Deus, como isso funciona !?" para "John Carmack e Donald Knuth não poderiam melhorar isso durante a programação em pares".
Gort the Robot
@StevenBurnap Isso é verdade. No entanto, acho que, para os indivíduos, geralmente existem algumas maneiras certas e muitas maneiras erradas. (À medida que nos tornamos melhores programadores, esse espectro começa a mudar - nossos velhos "caminhos certos" podem às vezes se tornar nossos novos "caminhos errados", enquanto nossos novos caminhos certos são melhores que os antigos.) Acho que é bom fazer as coisas de maneira correta. o melhor e mais correto caminho para você . Isso nos leva a nos tornarmos melhores programadores, nos tornarmos melhores colegas de equipe (assuntos de mentoria!) E a escrever melhores códigos.
precisa saber é o seguinte
" Acho que as pessoas tendem a querer fazer as coisas certas, em vez de fazê-las erradas " - O problema é que existem opiniões muito diferentes sobre o que é certo ou errado. Alguns até começam guerras sagradas sobre isso (no sentido literal).
JensG
1

Isso parece ser um problema de comunicação e não um problema de programação. Tente entender por que as pessoas se sentem assim e tente cristalizar por que você acha que seu caminho seria melhor. Quando você tiver feito isso, não inicie uma discussão de confronto em que seu objetivo é contar aos outros porque eles estão errados e você está certo. Explique seus pensamentos e sentimentos e deixe as pessoas reagirem a isso. Se você não consegue chegar a nenhum tipo de consenso e sente que esse é um problema muito crítico, provavelmente há alguns problemas sérios na equipe em geral.

Mais focado na programação real, não perca tempo com longas discussões sobre algo que você apenas sente que é "mais rápido". Se você vir alguém escrevendo um método chamado uma vez por solicitação em um aplicativo Web e ele tem complexidade de tempo O (n ^ 2) quando você SABE que é realmente um problema de tempo O (log (n)), então é claro, se é um acéfalo, vá em frente.

Esteja ciente, porém, que, como seres humanos, nós programadores somos péssimos (e quero dizer INCRÍVEIS) em adivinhar quais partes de nossos aplicativos serão prejudicadas. Eric Lippert escreve sobre esse assunto interessante nesta postagem do blog. Sempre favorecer a manutenção. Quaisquer problemas de desempenho que eventualmente sejam encontrados podem ser corrigidos facilmente (bem, relativamente) quando você tiver mais informações.

sara
fonte
Eu editei a resposta e aprimorei um pouco mais as coisas, o downvoter poderia adicionar algum feedback? :)
sara
Embora eu não seja o menos favorável, seu primeiro parágrafo é direto ao abordar a questão em questão, mas o resto não responde à minha pergunta sobre como trabalhar com pessoas que impedem uma discussão no minuto em que ela tem a ver com desempenho. (embora ainda seja um bom conselho).
errantlinguist
basicamente, o que eu quero passar nos últimos dois parágrafos é "essas otimizações podem nem importar". Nesse caso, é melhor escolher suas lutas.
Sara #