Sto realizzando 4-5 volte più punti trama rispetto alla media, ma producendo bug a metà del ritmo. I grafici dicono che sono 2 volte più bug, come gestirli?

Pertanto, è generalmente accettato che i programmatori di livello superiore possano produrre un codice di ordine di grandezza maggiore / migliore rispetto ai loro pari più medi.

È anche generalmente accettato che il tasso di errori commessi nel codice sia relativamente costante per i programmatori.

Al contrario, tende a essere influenzato dai processi utilizzati durante la scrittura del codice e dopo la scrittura del codice . (A quanto ho capito) Gli umani tendono a commettere errori a un ritmo abbastanza costante - i programmatori migliori ne notano solo di più e sono più veloci a risolverli.

• Nota che entrambe le affermazioni di cui sopra provengono da Code Complete di Steve McConnell, quindi non si tratta di prospettive diverse.

Quindi ho iniziato a vederlo di recente nel mio codice. Sono in grado di calcolare circa 4-5 volte la quantità di codice di molti dei miei colleghi (misurati in base ai punti della storia stimati dal team), con una qualità superiore (basata su metriche delle prestazioni e numero di modifiche apportate dopo il check-in). Ma faccio ancora errori. Tra test unitari migliori, una migliore comprensione di ciò che sta facendo il codice e una migliore attenzione ai problemi quando si eseguono revisioni del codice, non sto producendo 4-5 volte il numero di bug.

Ma sto ancora producendo circa il doppio di bug trovati dal QA rispetto agli altri sviluppatori del mio team. Come puoi immaginare, questo causa alcuni problemi con persone non tecniche che eseguono misurazioni metriche (leggi: il mio capo).

Ho cercato di sottolineare che sto producendo bug a metà del tasso dei miei coetanei (e ne correggo il doppio), ma è una vendita difficile quando ci sono grafici che dicono che produco il doppio di bug.

Quindi, come affrontare il fatto che una maggiore produttività porterà ad un aumento del numero di bug?

Penso che stai mescolando le tue preoccupazioni. E non c'è niente dalla tua parte che devi cambiare.

La produttività è un indizio della rapidità con cui un progetto verrà completato. Ai project manager e a tutti gli altri piace sapere quando il progetto verrà consegnato. Una produttività più alta o più veloce significa che vedremo il progetto consegnare prima.

Il tasso di bug non è legato alla produttività ma piuttosto alle dimensioni del progetto. Ad esempio, potresti avere dei Nbug per ogni Yriga di codice. Non c'è nulla all'interno di quella metrica che dice (o se ne frega!) Di quanto velocemente vengono scritte quelle righe di codice.

Per metterlo insieme, se hai una maggiore produttività, sì, "vedrai" i bug che vengono scritti più rapidamente. Ma avresti comunque avuto quel numero di bug dato che è legato alle dimensioni del progetto.

Semmai, una maggiore produttività significa che avrai più tempo alla fine del progetto per dare la caccia a quei bug o lo sviluppatore sarà più veloce nel trovare i bug che hanno creato. ¹

Per affrontare gli aspetti più personali della tua domanda.

Se il tuo capo sta osservando rigorosamente il numero di bug che produci rispetto al tasso di bug che produci, una sessione educativa è in ordine. Il numero di bug creati non ha senso senza una frequenza di supporto.

Per fare l'esempio estremo, per favore dì al tuo capo che voglio raddoppiare il tuo stipendio. Perché? Non ho creato alcun bug sul tuo progetto e sono quindi un programmatore molto superiore a te. Che cosa? Avrà un problema che non ho prodotto una sola riga di codice a beneficio del tuo progetto? Ah. Ora capiamo perché il tasso è importante.

Sembra che la tua squadra abbia le metriche per valutare i bug per punto della trama. Se non altro, è meglio che essere misurati dal numero grezzo di bug creati. I tuoi migliori sviluppatori dovrebbero creare più bug perché stanno scrivendo più codice. Chiedi al tuo capo di lanciare quel grafico o almeno di lanciarne un'altra dietro che mostri quanti punti della storia (o qualunque valore commerciale misuri) insieme al numero di bug. Quel grafico racconterà una storia più accurata.

¹ _{Questo particolare commento ha attirato molta più attenzione di quanto fosse previsto. Quindi siamo un po 'pedanti (sorpresa, lo so) e ripristiniamo la nostra attenzione su questa domanda.}

_{La radice di questa domanda riguarda un manager che guarda le cose sbagliate. Stanno osservando i totali dei bug grezzi quando dovrebbero guardare il tasso di generazione rispetto al numero di attività completate. Non ossessioniamoci nel misurare contro "linee di codice" o punti della trama o complessità o altro. Questa non è la domanda attuale e quelle preoccupazioni ci distraggono dalla domanda più importante.}

_{Come indicato nei collegamenti dall'OP, è possibile prevedere un certo numero di bug in un progetto esclusivamente in base alle dimensioni del progetto da solo. Sì, puoi ridurre questo numero di bug attraverso diverse tecniche di sviluppo e test. Ancora una volta, non era questo il punto di questa domanda. Per comprendere questa domanda, dobbiamo accettare che per un dato progetto di dimensioni e metodologia di sviluppo, vedremo un determinato numero di bug una volta che lo sviluppo è "completo".}

_{Quindi torniamo finalmente a questo commento che alcuni hanno completamente frainteso. Se si assegnano attività di dimensioni comparabili a due sviluppatori, lo sviluppatore con un tasso di produttività più elevato completerà l'attività prima dell'altro. Lo sviluppatore più produttivo avrà quindi più tempo disponibile alla fine della finestra di sviluppo. Quel "tempo extra" (rispetto agli altri sviluppatori) può essere utilizzato per altre attività come lavorare sui difetti che percorrono attraverso un processo di sviluppo standard.}

_{Dobbiamo prendere in considerazione il PO che sono più produttivi di altri sviluppatori. Nulla all'interno di tali affermazioni implica che l'OP o altri sviluppatori più produttivi siano scivolati nel loro lavoro. Sottolineando che ci sarebbero meno bug se trascorressero più tempo sulla funzionalità o suggerendo che il debug non fa parte di questo tempo di sviluppo manca di ciò che è stato chiesto. Alcuni sviluppatori sono più veloci di altri e producono lavori comparabili o di qualità migliore. Ancora una volta, vedi i collegamenti che il PO espone nella loro domanda.}

Dedica un po 'di tempo extra a pulire, lucidare e testare il tuo codice. Ci saranno ancora errori, ma ci saranno meno. Ci vuole tempo. La velocità di output del codice diminuirà, ma l'output del codice privo di bug aumenterà e ciò comporterà una migliore produttività. Perché i bug sono costosi.

Riesci a conservare il tuo codice in un ramo o in un ambiente di test fino a quando non lo scarichi e catturi più bug? I bug in un ramo in genere causano meno onde rispetto ai bug nel codice di produzione.

Ma non sto scavando esattamente le tue affermazioni che portano alla tua domanda. E forse neanche il tuo capo.

Non penso che ogni programmatore produca la stessa percentuale di errori. Il tuo secondo link è in realtà completamente fuori tema in quanto confronta diverse lingue, non diversi livelli di abilità del programmatore. Il codice completo menziona alcune misurazioni di grandi campioni che stanno esaminando il processo piuttosto che l'abilità dei programmatori. E quando dicono che i programmatori di livello superiore producono codice più / migliore, parte di ciò significa che ha meno bug. Dipende dall'applicazione. Quindi, sì, penso che sia una questione di prospettiva diversa.

Alla fine, però, se il capo vuole un codice più pulito, dagli un codice più pulito.

Uscirò su un arto e diventerò l'avvocato del diavolo. Questo non vuol dire che non ho simpatia per la tua condizione, ma, beh, la mia simpatia non ti aiuterà. Quindi permettimi di aggiungere alla prospettiva di Filippo :

Il tuo capo si preoccupa della qualità del prodotto, in parte perché il suo nome e la sua reputazione saranno legati ad esso. Parte della qualità è la quantità percepita di bug . Se vendi un trapano fantastico che trapani quattro volte più veloce di qualsiasi altro trapano della concorrenza, ma si rompe anche due volte più spesso, avrai una cattiva reputazione. Anche se è discutibile che il trapano funzioni meglio, le persone si abituano alla velocità, ma ricorderanno i guasti.

Col senno di poi, la maggior parte dei bug è ovviamente prevenibile. Se solo fossi un po 'più attento, sentirà il tuo capo, potresti evitare questi problemi e l'eventuale pulizia necessaria. Dal suo punto di vista, è una cosa banale e sensata da chiedere, e qualsiasi discussione tu faccia al riguardo non funzionerà e ti farà apparire male.

Non può misurare la tua produttività superiore. Affermate una maggiore produttività basata su una metrica verificabile, quindi cosa ne pensano i vostri colleghi? Sono d'accordo, forse a malincuore, che sei un programmatore più produttivo o sei solo secondo te? Avrai un punto di forza se hai altre persone a sostegno delle tue affermazioni.

Questo è per la prospettiva. Ora, come fai a "riparare" questa situazione frustrante in cui ti trovi?

Rallenta un po '. Indica esplicitamente a chiunque distribuisca le attività che intendi tentare di ridurre la percentuale di bug (*), in modo che non siano sorpresi dalla tua minore assunzione. Se non altro, il rallentamento ridurrà il numero di bug assegnati per mancanza di offerta.

_{(*) C'è una differenza tra, da un lato, riconoscere che ci sono bug nel tuo nome e che proverai a ridurre tale importo e, dall'altro lato, ammettere che hai troppi bug nel tuo nome e dovresti agire.}

Non cercare di convincere il tuo capo, perché non funzionerà. Ancora una volta, ciò non significa che devi concedere il tuo punto; puoi presentare un contrappunto e mantenere la tua opinione senza respingere le sue preoccupazioni. Perché se discuti il ​​punto e non riesci a dimostrare in modo soddisfacente la tua produttività superiore (e anche se puoi), rischierai di insultare i tuoi colleghi o apparire sprezzante nei loro confronti. Non vuoi essere quel ragazzo .

Supponendo che produrrai la stessa "quantità" di codice dei tuoi colleghi nel 20% del loro tempo, potresti spendere 4 volte di più per eseguire il debug del codice e renderlo perfetto, il che ridurrebbe ulteriormente il tuo tasso di bug. Allora potresti definirti un buon programmatore.

La domanda più grande è perché stai programmando 5 volte tanto quanto gli altri invece di puntare alla qualità. È qualcosa che il tuo ego ti impone o il tuo capo ti costringe?

Inoltre è necessario considerare i costi per la correzione di un bug. Quando lo trovi in ​​anticipo, potresti essere ancora "dentro" il codice per risolverlo rapidamente. Se appare solo dopo un altro mese di sviluppo, potrebbe essere difficile da trovare o addirittura costringerti a cambiare grandi parti del codice già programmato.

Sembra che tu abbia le competenze per produrre codice e potresti renderlo fantastico se ti concentri sulla qualità anziché sulla velocità. Provalo un po ', suppongo che ti piacerà.

Il prossimo problema è quindi ottenere il riconoscimento (parlare di denaro) per le tue prestazioni migliori. Parla con il tuo capo e chiedigli come procedere, dopotutto è la sua compagnia e i suoi soldi, e se vuole che tu produca meno bug, dovrebbe anche decidere in che modo succede.

Gli sviluppatori possono essere brillanti, persino geniali, con un'attitudine per la comprensione e la codifica da soli, senza essere buoni sviluppatori. Un buon sviluppatore crea un lavoro di qualità e migliora l'intero progetto.

Non sto dicendo che sei tu, ma uno dei programmatori più frustranti con cui abbia mai lavorato ha scritto più codice di chiunque altro nel team, e abbiamo avuto brave persone nel team. Abbiamo monitorato gli impegni con un software di classificazione, quindi per alcuni è stata quasi una competizione. Ha sfornato fasce di codice, lasciandosi dietro la documentazione ZERO, foreste impenetrabili, e in realtà ha reso un po 'del mio codice difficile da capire per me (posso farlo da solo, grazie mille!). Alla fine ha quasi deragliato il progetto, perché è diventato un one man show. Le persone non potevano seguirlo. Non eravamo sincronizzati come una squadra. In realtà abbiamo riscritto alcune delle sue caratteristiche anni dopo, solo per riguadagnare manutenibilità.

Quello che volevo da lui era rallentare e dedicare più tempo: 1) Migliorare la qualità della base di codice 2) Comunicare con il team 3) Lavorare su cose che hanno aiutato gli altri e aiutarlo a completare funzionalità / storie 4) Correzione bug

Non sono d'accordo con la misurazione della produttività per righe di codice, ma è una metrica chiave. Il tuo contatore di codice include commenti? In tal caso, esiste un modo semplice per mantenere l'output di linea riducendo il "bug ratio"; aumenta semplicemente la qualità e la quantità dei commenti che scrivi. I commenti hanno raramente dei bug (anche se possono) e in generale, non abbiamo abbastanza commenti di qualità. Io non giustificassi codice di inflazione, ma l'atto di commentare è come un mini recensione del codice, costringe si pensa, il refactoring e migliorare.

Cercare di illuminare la gestione non è un inizio. C'è un vecchio cliché "Credi a me o ai tuoi occhi bugiardi?" Ciò che riguarda i tuoi capi sono i conteggi dei bug. Nessuna quantità di razionalizzazione dirà loro che è accettabile. È più del doppio del rischio. Inoltre, non sei l'unico interessato dal conteggio dei bug. Il QA ha il doppio del lavoro cercando di identificare i tuoi bug, quindi il management vorrà che tu ne faccia meno.

La soluzione migliore è ridurre il numero di bug che produci , punto. Non solo la gestione sarà più felice, ma lo sarai anche tu. Vero? Causa Sono abbastanza sicuro tanto quanto ti piace che vanta si sovraperformare i colleghi di un fattore di quattro, che ci si ama dire lo fai fare lo stesso numero di, o anche meno, di quanto non facciano gli insetti.

Come hai affermato, "... il tasso di errori commessi nel codice ... tende ad essere influenzato dai processi utilizzati durante la scrittura del codice e dopo la scrittura del codice". Se vuoi modificare la velocità con cui produci i bug dovrai cambiare i processi che usi per scrivere il codice.

I programmatori usano metodi di produzione per produrre codice, così come una catena di montaggio usa metodi per produrre alcuni oggetti prodotti in serie. Va bene, le pratiche del settore del software sono più simili a schioccare i soprammobili dai rami trovati nei boschi. Ma dal momento che produciamo macchine, dovremmo usare lo stesso rigore e la stessa disciplina usati per le macchine ad alta velocità di produzione in serie.

Ciò include le stesse tecniche utilizzate nella produzione di massa per ridurre il tasso di difetti: analisi delle cause alla radice per determinare il motivo per cui i bug vengono creati e modificare il processo in modo che non lo siano. O almeno che catturi prima del QA.

1. Crea un elenco dei tuoi bug. Probabilmente ne hai già uno grazie ai ragazzi del QA. Forse anche classificato. Tipo di bug, gravità, il punto in cui il bug è stato inserito nel codice, ecc.

2. Scegli la più grande categoria di bug. Poiché il tuo volume è così elevato, dovresti prima scegliere come target quella categoria. Altre categorie includono quelle più facili da trovare e quelle più facili da creare.

3. Sapendo dove vengono introdotti questi bug nel codice, cerca di apportare modifiche in quella fase (e precedenti) che impediscono che si verifichino tali bug e come rendere più semplice la cattura in quella fase.

4. Assicurati di guardare gli accessi non correlati alla programmazione e potrebbero fare la differenza nella qualità del tuo lavoro. Musica di sottofondo, interruzioni, pasti, lavoro troppo a lungo senza interruzione, fame, ecc.

Ciò che trovi potrebbe indurti a rallentare. D'altra parte, potrebbe aiutarti a produrre ancora più velocemente poiché avrai meno bisogno di rielaborare le cose che hai già messo dietro di te. Così com'è, quattro volte più codice non è vicino ad essere un ordine di grandezza migliore dei tuoi colleghi, quindi cambiare il tuo processo è sicuramente la strada da percorrere.

Cambia il tuo obiettivo da produrre il maggior numero di codice per aiutare l'azienda a progredire di più.

Dal momento che sembra che tu abbia molti colleghi più tempo extra disponibile, l'effetto più che puoi avere su una consegna più rapida di funzionalità e correzioni di bug è quello di aiutare i tuoi colleghi.

Aiuta i tuoi colleghi

• utilizzando le recensioni del codice per migliorare la qualità e l'educazione del codice.
• creare automazione di processo per rendere il loro lavoro più veloce e la vita più facile.
• scrivere test migliori con loro
• attaccare il codice tecnico per migliorare la base di codice
• essere il ragazzo che è sempre disponibile per aiutare gli altri.
• scrivere / migliorare strumenti che aiutano la produttività degli sviluppatori
• preparare il caso con la direzione per strumenti / attrezzature / condizioni di lavoro migliori per i tuoi colleghi se hai più influenza.
• preparare e condurre sessioni educative sulla scrittura di codice migliore.
• praticare l'umiltà

Quindi, come affrontare il fatto che una maggiore produttività porterà ad un aumento del numero di bug?

Il tuo capo è l'unica persona che può rispondere a questo nel tuo caso. Parla con lui, indica il tuo rapporto migliore e lascia che decida. Se la sua decisione non ha senso, è tempo di cercare un'azienda con il tuo modo di pensare.

Come professionista dovresti essere in grado di lavorare con qualsiasi condizione del cliente, assicurati solo che capiscano le conseguenze. Un bel diagramma di bug / storie può aiutare il tuo capo a capire quanto la tua produttività affonderà se ti prendi il tempo per produrre meno bug.

È inoltre necessario considerare questi punti:

• complessità delle storie, ad esempio semplici wrapper getter / setter rispetto a calcoli statistici o programmazione in tempo reale o persino statistiche in tempo reale ...
• gravità dei bug, piccoli errori di battitura sui campi di testo o risultati di calcolo errati, crash del programma
• costo per correggere i bug, sia se lo fai ora, più tardi o se qualcun altro deve capire il tuo codice perché te ne sei andato

La situazione è che lavori quattro volte più veloce del programmatore medio, ma fai il doppio degli errori in un determinato periodo di tempo. Rispetto alla quantità di lavoro che fai, in realtà fai MEZZO tanti errori quanti sono "nella media".

Potresti provare a evidenziare i tuoi bassi errori nel rapporto di lavoro o persino gli errori nel prodotto completato (che puoi completare in un quarto del tempo normale). La maggior parte dei capi lo accetterà.

Ci sono alcuni capi che non lo faranno perché lavorano con una mentalità "tollerante" degli errori alla volta. Quindi potresti rallentare il tuo ritmo di lavoro, facendo DUE VOLTE più lavoro della media in un dato tempo e commettere gli stessi (o meno) errori perché hai più tempo per controllare il tuo lavoro.

Se il tuo capo vuole che tu migliori la qualità del tuo lavoro, allora migliora la qualità del tuo lavoro.

Dovresti mirare a zero bug, non mirare a produrre solo il doppio del prossimo miglior programmatore.

Dovresti dire al tuo capo che le metriche che sta usando sono piuttosto imperfette. Se dai un'occhiata ai fatturati delle guardie dell'NBA, scoprirai che tendono ad avere un numero maggiore di quelli in avanti. Ma è perché stanno gestendo di più la palla. Se una guardia non in partenza gioca 1/5 quanto una guardia in partenza e gira la palla più di 3 volte in media .vs. una guardia di partenza che gira la palla oltre 7 volte a partita - a prima vista potrebbe sembrare che la guardia di partenza sia peggiore. Ma, se dividi il numero di fatturati per il numero di minuti giocati, allora chiaramente la guardia iniziale ha numeri molto migliori in base ai minuti giocati.

Allo stesso modo, hai numeri molto migliori se il numero di bug è diviso per il numero di punti trama completati. Quindi, è quello che proporrei al tuo manager. Modifica la metrica in modo che sia il numero di bug diviso per i punti della storia completati, o almeno aggiungi una nuova metrica per questo se è necessario il numero totale di bug per sviluppatore. Tuttavia, poiché alcuni punti della storia sono molto più difficili e più complessi di altri punti della storia, ci può e sarà un po 'di varianza e questo deve essere preso in considerazione anche dal manager.

Quello che non penso che dovresti fare è rallentare.

Misura il valore aggiunto

Sostieni che ciò che conta davvero è il valore che aggiungi. Quindi vai e introduce una misurazione approssimativa (manuale) di quello:

• Stimare il valore della funzionalità prodotta
• Sottrai il tuo stipendio
• Sottrai il costo stimato dei tuoi bug (almeno il costo per risolverli)
• Sottrai il costo stimato di tutti gli altri debiti tecnici prodotti

Il resto è il tuo valore aggiunto. Allo stesso modo per tutti gli altri.

Queste stime sono difficili, ma anche quelle approssimative possono essere utili. E il semplice processo di discussione di queste stime è utile per il team e il progetto.

I migliori programmatori hanno la tendenza a scrivere codice molto regolare, facile da eseguire il debug e da comprendere, utilizzano gli strumenti disponibili (analisi statica, errori del compilatore, codice di debug) al massimo. Inoltre, i migliori programmatori hanno già appreso il valore del test unitario attraverso la propria esperienza.

Quindi, mentre la quantità iniziale di problemi per riga è la stessa, i problemi vengono eliminati più rapidamente.