Com que frequência a velocidade do software é evidente aos olhos dos clientes?

Em teoria, os clientes devem sentir as melhorias de desempenho do software com a experiência em primeira mão.

Na prática, algumas vezes as melhorias não são perceptíveis o suficiente, de modo que, para gerar receita com as melhorias, é necessário usar índices de desempenho cotáveis ​​em marketing para atrair clientes.

Já sabemos a diferença entre o desempenho percebido (latência da GUI, etc.) e o desempenho do servidor (máquinas, redes, infraestrutura, etc.).

Com que frequência os programadores precisam se esforçar para "escrever" as análises de desempenho para as quais o público não é um programador, mas um gerente e um cliente?

Embora @jwenting faça alguns pontos positivos, tenho que discordar da avaliação geral.

Um usuário geralmente não percebe pequenas melhorias no desempenho.

Com isso, eu posso concordar.

Onde eu discordo gira em torno desta afirmação:

a maioria dos aplicativos voltados para o usuário final passa a maior parte do tempo aguardando a entrada do usuário.

Agora, antes que você pule para cima e para baixo, eu também concordo com essa afirmação! No entanto, essa declaração destaca um fato geralmente ignorado por aqueles que não entendem adequadamente como um usuário realmente percebe um sistema.

Um usuário irá notar que uma aplicação é lento quando eles têm que esperar por ele para carregar. Um usuário irá notar que quando eles têm que fazer uma pausa para o programa entre digitando seus dados.

O desempenho do software é evidente para um usuário quando ele interrompe uma interação natural e fluida com o sistema.

Um usuário só não notará o desempenho do sistema quando estiver funcionando perfeitamente e não o sustentando.

Alguns aprimoramentos de desempenho não são percebidos como desempenho. O cliente apenas notará que o sistema "se sente" melhor.

O subconsciente trabalha em velocidades muito mais rápidas que o consciente. Nossos cérebros são programados para feedback instantâneo e, diante de uma sequência de tarefas, precisamos agitá-los um após o outro. Uma leve pausa no feedback faz com que esse processo fique desarticulado, o que aumenta os níveis de estresse. As pessoas clicam automaticamente em um botão sem pensar nisso, se houver uma pausa no feedback.

Muitas vezes, as melhorias de desempenho são tão pequenas que o cliente nunca percebe diretamente. Na melhor das hipóteses, eles podem ter um fluxo de aplicação um pouco mais fluente sobre o uso, mas não o suficiente para serem percebidos conscientemente.

Lembre-se de que a maioria dos aplicativos voltados para o usuário final passa a maior parte do tempo aguardando a entrada do usuário, não processando essa entrada. Portanto, mesmo que você economize 10% dos 100ms necessários para processar o clique do botão e atualize a tela, o usuário mal notará, pois não fará nada com a tela atualizada por mais 10000ms depois.

Quem notará é o administrador de sistemas que vê um trabalho em lotes que costumava levar 2 horas para ser concluído agora em 90 minutos, mas só notará que se tiver que esperar pelo resultado e ficar com raiva, o retorno mais rápido o interrompe no meio do caminho através de seu filme :)

Como dizem outros hoje, trata-se mais de desempenho percebido e "fluidez" do que de velocidade bruta real.

Isso significa que você pode ter um sistema lento (er) apenas por ter uma sensação e ritmo naturais na interface do usuário do seu software, em vez de ter algumas coisas muito rápidas e outras muito lentas. (Como seres humanos, notamos irregularidades muito bem, pois pode ser um tigre esgueirando-se sobre nós ...)

Isso é essencial para ocultar latências que você não pode fazer nada, por isso é uma boa habilidade para praticar.

Eu só queria pular aqui e oferecer um caso incomum em que ....

* _{OS CLIENTES QUE CUIDAM DE DESEMPENHO E AVISAM CADA MUDANÇA!} .

É no meu campo que cobrimos a renderização da produção que tende a ser analisada até a morte em termos de desempenho pelos próprios clientes. Uma desaceleração de 2% no desempenho em relação a uma versão secundária pode ser igual à desaceleração relatada na forma de "relatórios de erros" em massa.

Os tópicos do fórum geralmente são iniciados com os clientes comparando suas cenas com várias versões do software, onde os clientes estão comparando mais do que os próprios desenvolvedores. "Esta cena levou 1 hora e 40 minutos para renderizar na versão X. Agora são necessários 32 minutos na versão Y."

"Esta cena levou 18 minutos para carregar na versão X, agora leva 4 minutos para carregar na versão Y."

Eles são extremamente gratos quando as otimizações são aplicadas, e isso por si só pode ser suficiente para garantir a compra de uma nova atualização muito cara do software e, às vezes, com apenas melhorias modestas, como uma redução de 10% no tempo.

Em alguns contextos maiores, também pode economizar enormes quantias de dinheiro para o cliente quando o produto é acelerado, uma vez que alguns estúdios maiores usam fazendas de renderização onde precisam pagar por centenas de máquinas renderizadas o dia todo, e qualquer melhoria nos tempos aqui pode acelere todo o seu processo de produção (e possivelmente até produz melhores resultados quando os artistas são mais produtivos criando arte do que esperando que ela seja renderizada).

Portanto, existem campos como este em que os clientes percebem realmente, realmente, realmente - às vezes até mais do que os próprios desenvolvedores, e isso está fora dos conceitos de interação da interface do usuário, que são mais sobre latência do que taxa de transferência.

Com que frequência os programadores precisam se esforçar para "escrever" as análises de desempenho para as quais o público não é um programador, mas um gerente e um cliente?

No nosso caso, o tempo todo, com quase todos os lançamentos menores. A velocidade é um dos principais pontos de venda, e mesmo os benchmarks e análises de desempenho mais técnicos são realmente apreciados e compreendidos pelos clientes e gerentes. A percepção dos clientes geralmente é como lobos raivosos, ávidos por mais otimizações e tentando fazer sugestões aos desenvolvedores sobre como potencialmente tornar as coisas mais rápidas. Nesse caso, é necessário disciplina para resistir a alguns dos desejos do cliente de otimizar ainda mais e se concentrar em outras métricas, como manutenção e aprimoramentos de recursos.

As únicas vezes em que me deparo são:

1. O software melhora fazendo mais trabalho no mesmo período de tempo.
2. A renderização ou processamento offline é notavelmente mais rápida, mas invisível.
3. O aumento de velocidade é um tanto nominal, mas as melhorias impedem futuros gargalos
4. Processamento paralelo que realiza o mesmo trabalho na mesma velocidade, para muitos.
5. Sempre que a velocidade imperceptível aumenta, afeta fortemente a produtividade.

Se o cliente não perceber melhorias na velocidade, por que o desenvolvedor trabalhou nelas? Provavelmente existe uma boa razão. Por que gerar receita com esse trabalho se é transparente para o usuário?

Um exemplo: a Apple cobra cerca de US $ 130 por cada atualização do Mac OS X. Exceto no Snow Leopard, que é vendido por US $ 30. Os desenvolvedores trabalharam duro nessa versão, mas há muito poucas melhorias visíveis do ponto de vista do usuário. Então, a Apple decidiu cobrar um mínimo.

Com que frequência os programadores precisam se esforçar para "escrever" as análises de desempenho para as quais o público não é um programador, mas um gerente e um cliente?

Eu acredito que depende da indústria. No mundo maluco das contratações de defesa, fazemos isso com bastante frequência. Temos requisitos específicos para fazer com que os produtos funcionem de determinadas maneiras - e essas métricas de desempenho nem sempre estão diretamente relacionadas a algo que um usuário final experimentou. E geralmente fazemos nossos próprios testes para ver onde o produto chega ao fundo. Ambos os tipos de testes são escritos em relatórios com uma reflexão séria sobre o que isso significa.

Dito isto, não tenho certeza se isso é verdade em situações em que a base de clientes e implantação é menos especializada (ou seja, o mundo comercial). Dado que compramos COTS que precisam atender às especificações de desempenho, posso dizer que alguns compradores solicitam essas especificações de desempenho, mas, na minha experiência, as empresas de COTS que visitei nem sempre têm tantos documentos técnicos sobre análise de desempenho acessível. Parece depender da indústria, do tamanho da empresa e da natureza da concorrência. Ah ... capitalismo.

Minha opinião é que, se os ganhos de desempenho não são perceptíveis, eles não são comercializáveis. Em outras palavras, por que alguém pagaria mais por software que não é visivelmente aprimorado?

Penso que as alegações de marketing de melhorias de desempenho imperceptíveis levaram os usuários em geral a dar pouco peso a essas alegações. Por exemplo, quando eu queria começar a usar o controle de versão distribuído, ignorei as alegações de desempenho do git porque acreditava que as diferenças seriam desprezíveis. Foi apenas tentando fazer por mim que descobri que eram credíveis, especialmente quando combinadas com o suporte à inotificação.

Farei uma exceção para ganhos de desempenho que não estão diretamente relacionados à experiência do usuário final. Por exemplo, a taxa de transferência do servidor seria importante para as pessoas que compram e mantêm servidores, mesmo que o usuário final não note diferença. Nesse caso, uma simples "melhoria percentual sobre X" é suficiente.

Depende de quem você está vendendo seu produto de software.

Na maioria das vezes, seu cliente não é o usuário final / dia a dia. Com frequência, você acaba gerando relatórios mais agradáveis ​​e brilhantes em vez de corrigir problemas de desempenho. Porque você realmente está vendendo para a gerência, não para o usuário final.

O que significa que, nesse caso, você será pressionado a marcar alguns problemas de desempenho, mas ganhará muito dinheiro ao automatizar esse relatório.