¿Con qué frecuencia es evidente la velocidad del software a los ojos de los clientes?

En teoría, los clientes deberían poder sentir las mejoras en el rendimiento del software a partir de la experiencia de primera mano.

En la práctica, a veces las mejoras no son lo suficientemente notorias, de modo que para obtener beneficios económicos de las mejoras, es necesario utilizar cifras de rendimiento cotizables en marketing para atraer clientes.

Ya conocemos la diferencia entre el rendimiento percibido (latencia GUI, etc.) y el rendimiento del lado del servidor (máquinas, redes, infraestructura, etc.).

¿Con qué frecuencia es necesario que los programadores hagan un esfuerzo adicional para "redactar" análisis de desempeño para los cuales la audiencia no es programadores, sino gerentes y clientes?

Aunque @jwenting hace algunos buenos puntos, tengo que estar en desacuerdo con la evaluación general.

Un usuario a menudo no nota mejoras menores en el rendimiento.

Con eso, estoy de acuerdo.

Donde no estoy de acuerdo gira en torno a esta declaración:

La mayoría de las aplicaciones orientadas al usuario final pasan la mayor parte de su tiempo esperando la entrada del usuario.

Ahora, antes de saltar arriba y abajo, ¡también estoy de acuerdo con esa afirmación! Sin embargo, esta declaración destaca un hecho que a menudo pasan por alto aquellos que no entienden adecuadamente cómo un usuario realmente percibe un sistema.

Un usuario se dio cuenta de que una aplicación es lenta cuando tienen que esperar a que cargue. Un usuario lo notará cuando tenga que pausar el programa entre el ingreso de sus datos.

El rendimiento del software es evidente para un usuario cuando interrumpe una interacción natural y fluida con el sistema.

Un usuario solo no notará el rendimiento del sistema cuando funciona perfectamente y no detiene al usuario.

Algunas mejoras de rendimiento no se notan como rendimiento. El cliente solo notará que el sistema "se siente" mejor.

El subconsciente trabaja a velocidades mucho más rápidas que el consciente. Nuestros cerebros están programados para recibir comentarios instantáneos y, cuando nos enfrentamos a una secuencia de tareas, debemos realizarlos uno tras otro. Una pequeña pausa en la retroalimentación hace que este proceso se desarticule, lo que aumenta los niveles de estrés. La gente automáticamente hará doble clic en un botón sin pensarlo si hay una pausa en los comentarios.

Muy a menudo, las mejoras de rendimiento son tan pequeñas que el cliente nunca se da cuenta directamente. En el mejor de los casos, pueden tener un flujo de aplicación ligeramente más fluido sobre su uso, pero no lo suficiente como para ser notado conscientemente.

Recuerde que la mayoría de las aplicaciones para usuarios finales pasan la mayor parte de su tiempo esperando la entrada del usuario, no procesando esa entrada. Por lo tanto, incluso si reduce el 10% de los 100 ms necesarios para procesar ese botón y actualizar la pantalla, el usuario apenas se dará cuenta, ya que no hará nada con esa pantalla actualizada durante otros 10000 ms después.

Quien lo notará es el administrador de sistemas que ve que un trabajo por lotes que solía tardar 2 horas en completarse ahora se completa en 90 minutos, pero solo se dará cuenta de que si tiene que esperar el resultado y puede enojarse, el retorno más rápido lo interrumpe hasta la mitad a través de su película :)

Como dicen otros hoy, se trata más del rendimiento percibido y la "fluidez" que de la velocidad bruta real.

Eso significa que puede salirse con la suya con un sistema lento (er) simplemente teniendo una sensación y un ritmo naturales en la interfaz de usuario de su software, en lugar de tener algunas cosas demasiado rápidas y otras muy lentas. (Como humanos, notamos irregularidades muy bien, ya que podría ser un tigre escabulléndose entre nosotros ...)

Esto es esencial para ocultar latencias sobre las que no puede hacer nada, por lo que es una buena habilidad para practicar.

Solo quería saltar aquí y ofrecer un caso inusual donde ...

* ¡ _{LOS CLIENTES SE IMPULSAN POR EL RENDIMIENTO Y NOTIFICAN CADA PEQUEÑO CAMBIO!} .

Es en mi campo donde cubrimos la producción que tiende a ser analizada hasta la muerte en términos de rendimiento por los propios clientes. Una ralentización del rendimiento del 2% en una versión menor puede equivaler a la ralentización que se informa en forma de "informes de errores" en masa.

Los hilos del foro a menudo se inician con clientes que comparan sus escenas con varias versiones del software, donde los clientes realmente comparan más que los propios desarrolladores. "Esta escena tardó 1 hora y 40 minutos en renderizarse en la versión X. Ahora toma 32 minutos en la versión Y".

"Esta escena tardó 18 minutos en cargarse en la versión X, ahora tarda 4 minutos en cargarse en la versión Y".

Son extremadamente agradecidos cuando se aplican optimizaciones, y eso solo puede ser suficiente para garantizar la compra de una actualización nueva y muy costosa del software, y a veces con solo mejoras modestas, como una reducción del 10% en los tiempos.

En algunos contextos más grandes, también puede ahorrarle al cliente enormes cantidades de dinero cuando se acelera el producto, ya que algunos estudios más grandes usan granjas de render donde tienen que pagar cientos de máquinas de renderizado durante todo el día, y cualquier mejora en los tiempos aquí puede acelerar todo su proceso de producción (y posiblemente incluso producir mejores resultados cuando los artistas son más productivos creando arte en lugar de esperar a que se renderice).

Por lo tanto, existen campos como este donde los clientes realmente, realmente, realmente se dan cuenta, a veces incluso más que los propios desarrolladores, y esto está fuera de los conceptos de interacción de la interfaz de usuario que tienen más que ver con la latencia que con el rendimiento.

¿Con qué frecuencia es necesario que los programadores hagan un esfuerzo adicional para "redactar" análisis de desempeño para los cuales la audiencia no es programadores, sino gerentes y clientes?

En nuestro caso, todo el tiempo, con casi todos los lanzamientos menores. La velocidad es uno de los principales puntos de venta, e incluso los puntos de referencia más técnicos y los análisis de rendimiento son realmente apreciados y entendidos por los clientes y gerentes. La percepción de los clientes es a menudo como lobos rabiosos, hambrientos de más optimizaciones y tratando de hacer sugerencias a los desarrolladores sobre cómo hacer que las cosas vayan más rápido. En este caso, se necesita disciplina para resistir algunos de los impulsos del cliente para optimizar aún más y centrarse en otras métricas, como la capacidad de mantenimiento y las mejoras de las características.

Las únicas veces que me encuentro son:

1. El software mejora haciendo más trabajo en el mismo marco de tiempo.
2. El procesamiento o procesamiento fuera de línea es notablemente más rápido, pero invisible.
3. El aumento de velocidad es algo nominal, pero las mejoras evitan futuros cuellos de botella.
4. Procesamiento en paralelo que realiza el mismo trabajo a la misma velocidad, para muchos.
5. Cada vez que aumenta la velocidad imperceptible afecta fuertemente la productividad.

Si el cliente no nota mejoras en la velocidad, ¿por qué el desarrollador trabajó en ellas? Probablemente hay una buena razón. ¿Por qué monetizar ese trabajo si es transparente para el usuario?

Un ejemplo: Apple cobra alrededor de $ 130 por cada actualización de Mac OS X. Excepto en Snow Leopard que se vende a $ 30. Los desarrolladores han trabajado duro en esa versión, pero hay muy pocas mejoras visibles desde el punto de vista del usuario. Entonces Apple decidió cobrar un mínimo.

¿Con qué frecuencia es necesario que los programadores hagan un esfuerzo adicional para "redactar" análisis de desempeño para los cuales la audiencia no es programadores, sino gerentes y clientes?

Creo que depende de la industria. En el loco mundo de los contratos de defensa, hacemos esto con bastante frecuencia. Tenemos requisitos específicos para que los productos funcionen de ciertas maneras, y estas métricas de rendimiento no siempre están directamente relacionadas con algo que un usuario final experimentó. Y generalmente hacemos nuestras propias pruebas para ver dónde toca el producto. Ambos tipos de pruebas se redactan en informes con una reflexión seria sobre lo que significa.

Dicho esto, no estoy seguro de que sea cierto en situaciones en las que la base de clientes y despliegue es menos especializada (es decir, el mundo comercial). Dado que compramos COTS que necesita cumplir con las especificaciones de rendimiento, puedo decir que algunos compradores solicitan tales especificaciones de rendimiento, pero en mi experiencia, las compañías COTS a las que he ido no siempre tienen tantos informes técnicos de análisis de rendimiento disponible. Parece depender de la industria, el tamaño de la empresa y la naturaleza de la competencia. Ah ... capitalismo.

Mi opinión es que si las ganancias de rendimiento no son notables, entonces no son comercializables. En otras palabras, ¿por qué alguien pagaría más por un software que no mejora notablemente?

Creo que las afirmaciones de marketing de mejoras de rendimiento imperceptibles han llevado a los usuarios en general a dar poco peso a tales afirmaciones. Por ejemplo, cuando quería comenzar a usar el control de versiones distribuido, ignoré las afirmaciones sobre el rendimiento de git porque creía que las diferencias serían insignificantes. Fue solo al probarlo por mí mismo que descubrí que eran creíbles, especialmente cuando se combinaban con el apoyo de inotify.

Haré una excepción para las ganancias de rendimiento que no están directamente relacionadas con la experiencia del usuario final. Por ejemplo, el rendimiento del servidor sería importante para las personas que compran y mantienen servidores, incluso si el usuario final no nota una diferencia. En ese caso, un simple "porcentaje de mejora sobre X" es suficiente.

Depende de a quién le esté vendiendo su producto de software.

Más a menudo que no, su cliente no es el usuario final / día a día. Muy a menudo terminas haciendo informes más agradables y brillantes en lugar de solucionar problemas de rendimiento. Porque realmente estás vendiendo a la gerencia, no al usuario final.

Lo que significa que en ese caso, será difícil marcar algunos problemas de rendimiento, pero obtendrá el mejor precio al automatizar ese informe.