Con quale frequenza è evidente la velocità del software agli occhi dei clienti?

Sebbene @jwenting rende alcuni punti positivi, non sono d'accordo con la valutazione generale.

A user often does not notice minor performance improvements.

Con ciò, posso essere d'accordo.

Dove non sono d'accordo ruota attorno a questa affermazione:

most end-user facing applications spend most of their time waiting for user input.

Ora, prima di saltare su e giù, sono d'accordo anche con questa affermazione! Tuttavia, questa affermazione mette in evidenza un fatto spesso trascurato da coloro che non comprendono adeguatamente come un utente percepisca realmente un sistema.

Un utente noterà che un'applicazione è lenta quando deve attendere il caricamento. Un utente lo lo noterà quando deve mettere in pausa il programma inserendo i propri dati.

Le prestazioni del software sono evidenti per un utente quando interrompe un'interazione naturale e fluida con il sistema.

Un utente non noterà le prestazioni del sistema solo quando funziona perfettamente e non ostacola l'utente.

Alcuni miglioramenti delle prestazioni non vengono notati come prestazioni. Il cliente noterà che il sistema "sembra" più bello.

Il subconcio funziona a velocità molto più veloci di quanto non lo sia. I nostri cervelli sono programmati per un feedback istantaneo e di fronte a una sequenza di compiti abbiamo bisogno di sfogliarli uno dopo l'altro. Una leggera pausa nel feedback fa sì che questo processo diventi sconnesso, il che aumenta i livelli di stress. Le persone fanno doppio clic automaticamente su un pulsante senza pensarci se c'è una pausa nel feedback.

Molto spesso i miglioramenti delle prestazioni sono così esigui che il cliente non si accorge mai direttamente. Nella migliore delle ipotesi, potrebbero avere un flusso di applicazione leggermente più fluido rispetto al loro utilizzo, ma non abbastanza da essere notati in modo consapevole.

Ricorda che la maggior parte delle applicazioni di utenti finali trascorrono la maggior parte del tempo in attesa di input da parte dell'utente, non elaborando tale input. Quindi, anche se si riduce del 10% i 100ms necessari per elaborare quel pulsante clic e si aggiorna lo schermo, l'utente noterà a malapena che non farà nulla con quello schermo aggiornato per altri 10000ms dopo.

Chi noterà è il sysadmin che vede un processo batch che richiedeva 2 ore per completarlo ora completato in 90 minuti, ma si accorgerà solo che se deve attendere il risultato e si arrabbia il ritorno più veloce lo interrompe a metà del suo film:)

Come altri dicono oggi, si tratta di prestazioni percepite e "fluidità" rispetto alla velocità effettiva.

Ciò significa che puoi farla franca con un sistema lento (er) semplicemente avendo una sensazione e un ritmo naturali nell'interfaccia utente del tuo software, invece di avere alcune cose troppo veloci e altre molto lente. (Come esseri umani, notiamo molto bene le irregolarità, dal momento che potrebbe trattarsi di una tigre che ci sta inseguendo ...)

Questo è essenziale per nascondere le latenze di cui non puoi fare nulla, quindi è una buona abilità da praticare.

Volevo solo entrare qui e offrire un caso insolito in cui ....

*_{THE CUSTOMERS FREAKING CARE ABOUT PERFORMANCE AND NOTICE EVERY LITTLE CHANGE!}.

È nel mio campo in cui trattiamo il rendering di produzione che tende ad essere analizzato fino alla morte in termini di prestazioni da parte dei clienti stessi. Un rallentamento del 2% delle prestazioni rispetto a una versione secondaria può equivalere ai rallentamenti segnalati in forma di "segnalazioni di bug" in massa.

I thread del forum sono spesso avviati con i clienti che confrontano le loro scene con varie versioni del software, in cui i clienti sono in realtà un benchmarking più degli stessi sviluppatori. "Questa scena impiegava 1 ora e 40 minuti per il rendering nella versione X. Ora sono necessari 32 minuti nella versione Y."

"Questa scena impiegava 18 minuti per caricare nella versione X, ora ci vogliono 4 minuti per caricare nella versione Y."

Sono estremamente riconoscenti quando vengono applicate le ottimizzazioni, e questo da solo può giustificare l'acquisto di un nuovo aggiornamento molto costoso del software, e talvolta con solo modesti miglioramenti come una riduzione del 10% nei tempi.

In alcuni contesti più ampi, può anche risparmiare al cliente enormi quantità di denaro quando il prodotto è accelerato, dal momento che alcuni studi più grandi usano le fattorie di rendering dove devono pagare centinaia di macchine per tutto il giorno e qualsiasi miglioramento I tempi qui possono accelerare il loro intero processo di produzione (e possibilmente anche produrre risultati migliori quando gli artisti sono più produttivi a creare arte piuttosto che aspettare che faccia il rendering).

Quindi esistono campi come questo in cui i clienti notano davvero, davvero, davvero - a volte persino più degli stessi sviluppatori, e questo è al di fuori dei concetti di interazione dell'interfaccia utente che riguardano più la latenza che il throughput.

How often is it that programmers need to go the extra length to "write up" performance analyses for which the audience is not fellow programmers, but managers and customers?

Nel nostro caso, tutto il tempo, con quasi tutte le versioni minori. La velocità è uno dei principali punti di forza e anche i benchmark più tecnici e le analisi delle prestazioni sono effettivamente apprezzati e compresi dai clienti e dai gestori. La percezione dei clienti è spesso come lupi rabbiosi, affamati di ulteriori ottimizzazioni e cerca di dare suggerimenti agli sviluppatori su come potenzialmente far andare le cose più velocemente. In questo caso, in realtà richiede disciplina per resistere ad alcune delle richieste dei clienti di ottimizzare ulteriormente e concentrarsi su altre metriche come la manutenibilità e miglioramenti delle funzionalità.

Le uniche volte in cui mi imbatto sono:

1. Il software migliora facendo più lavoro nello stesso intervallo di tempo.
2. Il rendering o l'elaborazione offline è marcatamente più veloce, ma non visto.
3. I boost di velocità sono in qualche modo nominali ma i miglioramenti impediscono future bottlenecking
4. Elaborazione parallela che realizza lo stesso lavoro alla stessa velocità, per molti.
5. Ogni volta che aumenti di velocità impercettibili incide strongmente sulla produttività.

Se il cliente non noterà miglioramenti della velocità, perché lo sviluppatore ha lavorato su di essi? C'è probabilmente una buona ragione. Perché monetizzare questo lavoro se è trasparente per l'utente?

Un esempio: Apple addebita circa $ 130 per ciascun aggiornamento di Mac OS X. Tranne che su Snow Leopard venduto a $ 30. Gli sviluppatori hanno lavorato duramente su quella versione, ma ci sono pochissimi miglioramenti visibili dal punto di vista dell'utente. Quindi Apple ha deciso di addebitare un minimo.

Quante volte è necessario che i programmatori facciano tutta la lunghezza necessaria per "scrivere" le analisi delle prestazioni per le quali il pubblico non è un collega programmatore, ma manager e clienti?

Credo che dipenda dall'industria. Nel folle mondo dei contratti di difesa, lo facciamo abbastanza frequentemente. Abbiamo requisiti specifici per eseguire i prodotti in determinati modi e queste metriche di rendimento non sono sempre direttamente correlate a qualcosa che un utente finale ha sperimentato. E generalmente facciamo i nostri test per vedere dove il prodotto torna in basso. Entrambi i tipi di test sono scritti in relazioni con qualche pensiero serio su cosa significhi.

Detto questo, non sono sicuro che sia vero in situazioni in cui il cliente e la base di distribuzione sono meno specializzati (cioè il mondo commerciale). Dato che compriamo COTS che devono soddisfare le specifiche di performance, posso dire che alcuni acquirenti chiedono tali specifiche di prestazioni, ma nella mia esperienza, le società COTS che ho frequentato non sempre dispongono di tanti white paper sull'analisi delle prestazioni a disposizione. Sembra dipendere dall'industria, dalle dimensioni dell'azienda e dalla natura della competizione. Ah ... capitalismo.

La mia opinione è se i guadagni in termini di prestazioni non sono evidenti, quindi non sono commerciabili. In altre parole, perché qualcuno dovrebbe pagare di più per il software che non è notevolmente migliorato?

Ritengo che le dichiarazioni di marketing di miglioramenti delle prestazioni non percepibili abbiano indotto gli utenti in generale a dare poco peso a tali affermazioni. Ad esempio, quando volevo iniziare a utilizzare il controllo della versione distribuita, ignoravo le affermazioni sulle prestazioni git perché ritenevo che le differenze sarebbero state trascurabili. È stato solo provandolo per me stesso che ho scoperto che erano credibili, specialmente se combinato con il supporto inotify.

Creerò un'eccezione per i guadagni in termini di prestazioni che non sono direttamente correlati all'esperienza dell'utente finale. Ad esempio, il throughput del server sarebbe importante per le persone che acquistano e gestiscono i server, anche se l'utente non nota alcuna differenza. In tal caso, è sufficiente un semplice "miglioramento percentuale su X".

Dipende da chi stai vendendo il tuo prodotto software.

Più spesso poi no, il tuo cliente non è l'utente finale / giornaliero. Così spesso si finisce per creare report più belli e brillanti invece di risolvere i problemi di prestazioni. Perché in realtà stai vendendo alla gestione, non all'utente finale.

Il che significa che in tal caso, sarà difficile segnare per alcuni problemi di prestazioni, ma renderà il dollaro più alto per l'automazione di tale rapporto.