Il costo è uno dei motivi.
Quando implementi una funzione utilizzata dalla metà dei tuoi 1 000 000 utenti, significa che il costo della funzione è diviso per 500 000. Anche se l'implementazione è terribilmente costosa, non importa. Se questa funzione ti costa $ 100.000, ogni utente pagherà dieci centesimi, dato che solo la metà degli utenti pagherà per la funzione che non usa.
Quando, d'altra parte, una funzione viene utilizzata solo da alcuni dei tuoi utenti, non solo non vale la pena di implementarla, ma spesso smetterà anche di supportarne una esistente e rimuoverla dal prodotto . Questo è ciò che accade spesso nei prodotti Microsoft: quando si legge che una funzione, utilizzata da migliaia di utenti, è stata interrotta nella prossima versione di Windows, è facile capire: mantenere un codice utilizzato da solo poche migliaia di utenti sono troppo costosi per un prodotto con così tanti clienti.
Lo stesso vale per i bug. Se l'1% dei tuoi utenti incontra un bug, potrebbe essere troppo costoso risolverlo. Il modo meno costoso sarebbe quello di rimborsare quegli utenti e di non ricevere più loro notizie.
Il secondo motivo è che è difficile trovare i casi limite .
Un esempio. Recentemente ho lavorato a una standardizzazione dell'autenticazione nome utente / password per la mia azienda.
-
Un modo era farlo nello stesso modo in cui viene fatto da Microsoft, PayPal e altri: il modo sbagliato. In altre parole, non ti interessa davvero i casi limite e cerca di aggirarli avendo password con la lunghezza massima di 16 caratteri, ecc.
Quelle aziende sanno che molti utenti useranno una password come "horse123" e non avranno mai problemi. D'altra parte, io con i miei 25 caratteri generati casualmente le password, non posso accedere al mio account Microsoft dalle app Metro di Windows 8 fatte da Microsoft stessa, e non posso accedere al mio account PayPal, a meno che non modifichi manualmente la password per essere in realtà diverso da quello che ho usato durante la registrazione.
Ma a loro davvero non interessa, perché sono diverso dal 99,9% degli utenti.
-
L'altro modo è cercare di trovare tutti i casi limite. Ad esempio, se vuoi supportare qualsiasi carattere unicode in una password, dovresti sapere che alcuni personaggi possono avere più rappresentazioni Unicode e mentre l'utente crede di inserire la stessa password, la tua app risponderà che la password a volte è giusta , a volte sbagliato, a seconda della forma Unicode. Allo stesso modo, alcuni personaggi dovrebbero essere vietati: se il sistema consente \ u0014, ad esempio, accadranno cose brutte (come Internet Explorer 10 sospeso per 30 secondi quando si invia un modulo con una password contenente tali caratteri).
In generale, arriva a ciò che è più conveniente fare business-wise .
-
Puoi passare i prossimi mesi alla ricerca di casi limite,
-
oppure puoi implementare tre o quattro funzioni interessanti nel tuo prodotto.
Chiedi al tuo capo cosa dovresti fare tra queste due opzioni.