"Errore libero" è decisamente troppo soggettivo . La "Richiesta di funzionalità non riempite" di un uomo è "Errore" di un altro uomo. Qualcosa come "dovrebbe sostanzialmente soddisfare le specifiche di progettazione" sarebbe più appropriato. Non ho mai visto veramente quello che descrivi in una descrizione del lavoro. L'ho visto per lavoro a contratto , ma non per i dipendenti.

Prenderò una posizione opposta alla maggior parte delle risposte e dirò che è assolutamente ragionevole e realistico.

Lo sviluppo sarà completato in tempo? Certo che no, non sempre.

Tutto lo sviluppo sarà completato entro le specifiche? Ti piacerebbe sperare di sì, ma a volte ciò non sarà semplicemente possibile e dovrai segnalare una deviazione da una specifica impossibile o contraddittoria.

E lo sviluppo di tutti sarà privo di errori? Mai .

Ma è a questo che serve un KPI. È qualcosa che può essere misurato e con cui è possibile tenere traccia delle prestazioni e dei progressi.

Se le specifiche cambiano regolarmente, non c'è un processo formale di controllo delle modifiche e gli ambienti sono imprevedibili, quindi sarà una sfida mantenere questa cifra vicino a "senza errori". Ma questa sfida è il tuo lavoro , ed è un lavoro che, si spera, riuscirà a fare abbastanza bene, e ancora meglio l'anno prossimo, con una maggiore pratica nel gestire il particolare sapore del caos della tua azienda.

Domanda contrapposta: quali KPI vorrebbe tu proporre per un programmatore? È difficile. Molto di ciò che facciamo è difficile da misurare.

Se si tratta di una descrizione del lavoro, non mi preoccuperei troppo di questo perché lavorare su un codice privo di errori fa parte del tipico lavoro di un programmatore (anche se non potremo mai realizzarlo).

Tuttavia, come KPI è troppo ampio, ma non incolpare la persona che lo ha suggerito se non sono programmatori. Spiega solo che questa affermazione stabilisce un obiettivo che potrebbe non essere auspicabile per l'organizzazione. Cioè, "privo di errori" è uno standard estremamente alto per software che costerebbe una fortuna per consegnare effettivamente. Spiega che un progetto software ben eseguito richiede che vengano prese delle decisioni in merito alla valutazione di ciascun difetto che spenda tempo prezioso per lo sviluppo.

Ecco un esempio che rende bene il punto.
Un programmatore scopre che il nostro software ha un bug "anno 3000" e cesserà di funzionare dopo il 31 dicembre 1999. Ci vorranno 6-8 mesi per risolvere il problema. Basato sul KPI è incoraggiato ad assumere questo progetto pur non avendo alcun valore reale per l'azienda.

Ok, quindi l'esempio è un po 'estremo, ma in qualsiasi progetto software ci saranno letteralmente dozzine di piccoli difetti scoperti che allo stesso modo non generano il ROI necessario per risolverli. Se il KPI fosse invece inteso a implicare che il programmatore non introduca mai il difetto in primo luogo, sembra ragionevole che QUALSIASI dipendente sia tenuto allo standard di non commettere mai errori nell'esecuzione del proprio lavoro?

Purtroppo questo sembra solo un modo per "coprire tutte le basi", ed è chiaramente sconsigliato e rischia di generare disillusione negli sviluppatori.

Tuttavia, detto questo, ciò conta solo una volta che vedete cosa fanno con quel testo durante il periodo di revisione. Quindi non reagire in modo eccessivo troppo rapidamente - potrebbe esserci ancora sanità mentale alla fine del tunnel.

No

Non solo non è appropriato, è ridicolo

I test possono solo dimostrare l'esistenza di errori, non la loro assenza, quindi ogni programma scritto in questo impegno dovrebbe includere una rigorosa dimostrazione di correttezza ... e copertura del test del 100%

"Beware of bugs in the above code; I have only proved it correct, not tried it." -- D. Knuth

Ovviamente è compito di ogni programmatore, e responsabilità, scrivere codice che sia privo di errori. Questa è un'aspettativa perfettamente ragionevole. Come puoi essere un programmatore professionista se rilasci un codice che non funziona? Come puoi considerarti un programmatore professionista se rilasci un codice che non conosci funziona?

Se assumi un pittore ti aspetti che faccia bene il suo lavoro. Ti aspetti che il risultato del suo lavoro sia privo di errori. Se ci sono errori, ti aspetti che si assuma la responsabilità di quegli errori e li aggiusti gratuitamente. Inoltre, se gli errori ti costano dei soldi, ti aspetti che ti rimborsi. Perché hai queste aspettative? Perché il pittore è un professionista.

I programmatori amano dare la colpa a tutti gli altri per i loro errori. "Il mio programma ha dei bug a causa dei requisiti, o a causa del programma, o perché la Luna è nell'ottava casa" Ma non c'è davvero nessun altro da incolpare. Se il tuo programma ha errori, tu mettili lì.

La nostra professione non sarà essere una professione finché i programmatori non si renderanno conto che il problema si ferma con loro. Che loro sono responsabili della qualità dei loro programmi.

Sai perché le aziende hanno creato reparti di controllo qualità del software? Perché i programmatori non stavano facendo il loro lavoro! I programmatori rilasciavano così tanto schifo che le aziende dovevano formare reparti completamente nuovi per controllarli.

Quanto è lungo l'elenco degli errori? È professionale avere migliaia di bug nel database dei bug? Abbastanza chiaramente non lo è. È un riflesso del cattivo comportamento, della scarsa disciplina e, francamente, del disonore.

Non saremo mai una professione finché non ci rendiamo conto che è nostro compito assicurarci che il QA non trovi nulla.

"Senza errori" come in "perfetto?" Come in "scritto da Dio e dagli angeli, non dagli umani?" (stiamo parlando di logica del programma e forse errori di logica hardware)

Non posso dire sinceramente nemmeno una sola riga di codice che sia senza errori. Questo perché noi umani, beh, non possiamo dimostrare nessuna ipotesi negativa!

Il meglio che posso dire è che la probabilità di un errore è un numero compreso tra 0 e 1. Raggiungo quel numero per mezzo di mal- definito o mal definito principi di sviluppo e test del software; da un conteggio delle linee software di origine in questione; da una comprensione di quanto bene o male candidato, povero bastardo, si applicano quei principi nella produzione di quelle linee di codice; e altro ancora.

E posso esprimere che solo come una probabilità. Quindi il termine "privo di errori logici" significa quasi niente.

Se vedessi un annuncio per un ingegnere del software che produceva codice "senza errori", lo applicherei immediatamente o verrei subito eseguito: l'azienda non ha riflettuto molto su come si sviluppa, sui test e consegna il suo software. Quindi sarà una grande opportunità o un incubo senza fine.

Di qualsiasi software, però, posso facilmente - e devo - dire che mi aspetto codice che non abbia errori che facciano cadere al di fuori quella roba fiacca, oscura, logica: codice che compila e collegamenti senza errori o avvertenze; cioè "html valido" o "css valido"; JavaScript (per esempio) che non genera messaggi di errore o errori del browser non spiegati. Quella parte che posso misurare direttamente e segnare in bianco e nero su un grafico.

Questa parte è facile come torta. Chiunque può fare quello .

Ehi, buona fortuna nella tua ricerca :-)

Sono stupido o "errore" non significa "messaggio del compilatore fatale che ammonta a codice non compilabile"?

Secondo questa definizione, è un requisito molto ragionevole ...