Questo dipende dal progetto. In media (ancora non molto accurata) un nuovo progetto andrà da 0 a 10.000 (dipende soprattutto se sei nella fase di architettura o di costruzione iniziale) mentre un progetto molto vecchio sarà ovunque da negativo (attraverso l'ottimizzazione, il refactoring) a 0 (cercando di frugare e trovare cosa sta succedendo per evitare di rompere qualcosa quando si va a fare il cambiamento) a forse qualche centinaio (aggiungendo una nuova caratteristica dopo un sacco di frugare in giro per garantire che niente si rompa aggiungendola.)
I lavori di programmazione sono notoriamente difficili da mettere misure standardizzate di qualsiasi tipo (anche se la notazione big-O fa un po' di assistenza in questo sforzo da un punto di vista puramente tecnico delle prestazioni del codice per l'hardware disponibile) poiché si sta cercando di quantificare qualcosa che sta cercando di quantificare qualcosa in modo astratto - chiedendo "quante linee di buon codice sarebbero ragionevoli?" si sta essenzialmente chiedendo di costruire un sistema completo di Turing per descrivere un altro sistema, per ogni possibile scenario in cui viene chiesto.
Le persone con molta esperienza nello sviluppo di software saranno tipicamente in grado di centrare la stima di un progetto entro il 20% se fanno una discreta quantità di ricerche in anticipo e conoscono a fondo tutti gli aspetti dei sistemi coinvolti, ma questo di solito includerà anche un fattore di aggiustamento considerevole, perché l'unica cosa che l'esperienza insegna veramente a questo proposito è assumere che si sta sottostimando (su migliaia, Non ho ancora incontrato uno sviluppatore che non abbia sovrastimato la sua capacità di pompare codice - tipicamente perché tutti assumono l'intero progetto in uno stato di "flusso" mentre stimano, dagli sviluppatori ai clienti, ma arrivare a quello stato mentale tende a coinvolgere una parte considerevole di tempo e dipende da molti fattori ambientali.)
Come esempio estremo di questo: Una volta ho lavorato per un appaltatore che scriveva software aziendale quando stavo iniziando nell'industria, dopo pochi mesi avevo quello che pensavo fosse una comprensione decente di quanto tempo un progetto simile avrebbe richiesto. L'ho stimato, supponendo che sarebbe andato più o meno come il precedente (erano quasi identici, infatti era la versione 2 del progetto precedente che veniva riscritta da zero per facilitare nuove funzionalità). Tutto stava andando bene nella fase di architettura, poi un tempio indù ha affittato l'unità accanto e ogni 10-30 minuti per qualche minuto alla volta, ogni giorno, c'era qualcuno che suonava una campana per le mucche, c'era una discussione su quanto fosse fastidiosa la campana per le mucche, c'era una discussione della direzione su una nuova sede in cui trasferirsi, c'erano discussioni collaterali sulle discussioni della direzione che chiedevano alle persone input su nuove sedi e planimetrie, ecc. Passa un mese e praticamente nessun progresso è stato fatto, al punto che ho dovuto iniziare a lavorare da casa perché non ero in grado di concentrarmi per più di 10 minuti alla volta senza un'interruzione, ero in un misto di panico pensando che stavo per essere licenziato e scioccato che nessuno ne avesse parlato. Un altro mese (questa volta di lavoro produttivo) con pochi aggiornamenti visibili al cliente e hanno deciso di iniziare con lo scope creep, probabilmente assumendo che non ci fosse nulla di importante da cambiare - portando a buttare via enormi segmenti di codice esistenti, rivedendone altri, aggiungendone di nuovi all'architettura, ecc. Due mesi e mezzo dopo ho completato il progetto (per lo più da casa, venendo solo per giorni con riunioni) e ho chiesto come il mio capo non stesse impazzendo per il fatto che il progetto fosse così in ritardo - è venuto fuori che la sua decennale esperienza nel software gli ha insegnato a moltiplicare le stime date dagli sviluppatori per 4.
Oltre un decennio di esperienza nel settore dopo e ho imparato la morale di questa storia: ci sarà sempre un campanaccio. Non puoi stimare basandoti sul tuo picco, né puoi supporre che non ci saranno ricerche, pianificazioni, incontri, ecc. coinvolti in un progetto che sottraggono tempo al tempo speso a scrivere codice. A sua volta, misurare il codice in base al numero di linee scritte è un po' come cercare di commerciare in azioni sulla base di informazioni puramente tecniche: potrebbe funzionare, finché non succede un evento qualsiasi e tutti i vostri indicatori tecnici non significano nulla.