In genere è una cattiva idea chiamare il tuo capo un idiota, quindi i miei suggerimenti iniziano con la comprensione e la discussione delle metriche, piuttosto che respingerle.
Alcune persone che in realtà non sono considerate idioti hanno utilizzato metriche basate su righe di codice. Fred Brooks, Barry Boehm, Capers Jones, Watts Humphries, Michael Fagan e Steve McConnell li hanno usati tutti. Probabilmente li hai usati anche se solo per dire a un collega, questo modulo di Dio ha 4000 linee, deve essere suddiviso in classi più piccole.
Esistono dati specifici relativi a questa domanda da una fonte che molti di noi rispettano.
http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html
http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22
Ho il sospetto che il miglior uso della riga di codice all'ora del programmatore sia quello di dimostrare che per tutta la durata del progetto, questo valore inizierà piuttosto elevato, ma man mano che i difetti vengono rilevati e corretti, verranno aggiunte nuove righe di codice per risolvere problemi che non facevano parte delle stime originali e le righe di codice rimosse per eliminare la duplicazione e migliorare l'efficienza mostreranno che LOC / h indica cose diverse dalla produttività.
- Quando il codice viene scritto velocemente, sciatto, gonfio e senza alcun tentativo di refactoring, l'efficienza apparente sarà al massimo. La morale qui sarà che devi stare attento a ciò che misuri.
- Per uno sviluppatore particolare, se questa settimana aggiunge o tocca una quantità elevata di codice, la settimana successiva potrebbe esserci un debito tecnico da pagare in termini di revisione, test, debug e rilavorazione del codice.
- Alcuni sviluppatori lavoreranno a un tasso di output più costante rispetto ad altri. Si può scoprire che trascorrono la maggior parte del tempo a ottenere buone storie utente, si girano molto rapidamente e fanno test unitari corrispondenti, quindi si girano e fanno rapidamente codice incentrato solo sulle storie utente. Il take away qui è che gli sviluppatori metodici avranno probabilmente una rapida svolta, scriveranno codice compatto e avranno una bassa rielaborazione perché comprendono molto bene il problema e la soluzione prima di iniziare a scrivere codice. Sembra ragionevole che codificheranno meno perché codificano solo dopo averlo riflettuto, anziché prima e dopo.
- Quando il codice viene valutato per la sua densità di difetto, si scoprirà che non è uniforme. Alcuni codici spiegheranno la maggior parte dei problemi e dei difetti. Sarà un candidato per la riscrittura. Quando ciò accade, diventerà il codice più costoso perché in virtù del suo elevato grado di rielaborazione. Avrà le righe lorde più alte di conteggi di codice (aggiunte, cancellate, modificate, come potrebbe essere riportato da uno strumento come CVS o SVN), ma le righe nette più basse di codice all'ora investite. Questo può finire per essere una combinazione del codice o implementando il problema più complesso o la soluzione più complicata.
Indipendentemente da come si sviluppa il dibattito sulla produttività del programmatore in righe di codice, scoprirai che hai bisogno di più risorse umane di quelle che puoi permetterti e che il sistema non sarà mai completato in tempo. I tuoi veri strumenti non sono metriche. Usano una metodologia superiore, i migliori sviluppatori che puoi assumere o addestrare e il controllo di portata e rischio (probabilmente con metodi Agile).