Di quanto codice dovrei essere responsabile?

Attraverso i colleghi e le interviste di uscita, ho sentito che nella mia piccola azienda sono "responsabile" per un numero di codici compreso tra 3 e 10 volte superiore a quello di un altro lavoro. Sto cercando di cercare una sorta di metrica fuzzy che posso usare per confrontare il mio carico di lavoro con altri nel mio campo.

Per "responsabilità del codice", non intendo "Sono l'unico che conosce l'area X della base di codice" (anche se purtroppo, è spesso vero in un ambiente di avvio), ma piuttosto mi riferisco a un numero come "code_base_size / number_of_developers".

Ci sono risorse che posso usare per aiutarmi a misurare in modo più preciso il mio carico di lavoro rispetto al semplice conteggio delle righe di codice?

L'unica misura concreta per uno sviluppatore impiegato è il numero di ore trascorse a programmare e correggere bug e il denaro che vi viene pagato. Se rimani a tarda notte 6 giorni alla settimana per 50K US $ all'anno, allora hai un problema. Indipendentemente dal numero di righe di codice che il tuo capo vuole che tu sia responsabile, non gestirai più di quello che puoi fare, tenendo ovviamente conto di una certa qualità del codice. Lo sviluppo di un codice di scarsa qualità senza test unitari è un buon modo per gestire molto più codice, ma la società dovrà pagare il prezzo di un grande debito tecnico .

Nelle piccole aziende gli sviluppatori tendono ad essere responsabili di molto più codice rispetto a quelli di grandi dimensioni . Il fattore da 3 a 10 a cui ti riferisci mi sembra realistico.

Ho conosciuto un team di tre persone che gestiva un codebase di 1,5 milioni di righe e non ci stava annegando. L'importante misurazione non è la quantità di codice di cui sei responsabile, ma piuttosto la quantità di codice che devi modificare in un determinato incremento di tempo.

C'è anche l'angolo di valutazione del rischio. Se sei l'unica persona che conosce un pezzo di codice, qual è il costo opportunità che andrebbe perso se passi sotto un autobus? Le piccole aziende di solito non effettuano una valutazione del rischio del genere, ma ciò significa che il continuo successo dell'azienda è lasciato al caso.

la dimensione della base di codice / il numero di sviluppatori non è correlato al carico di lavoro. Se disponi di un'enorme base di codice stabile, tale metrica sarà elevata. Se hai ancora una piccola base di codice in fase di sviluppo, tale metrica sarà bassa. le modifiche delle linee per unità di tempo per sviluppatore sono più correlate al carico di lavoro. Ma anche allora, ho trascorso giorni a rintracciare bug sottili la cui correzione era una riga ...

Il codice dovrebbe essere di responsabilità del gruppo e non di uno sviluppatore. Il supporto dovrebbe essere delegato in modo equo ogni settimana, sembra stupido assegnarlo in altro modo. In caso contrario, ti suggerisco di parlare con la tua direzione.

Nella situazione in cui stai descrivendo uno sviluppatore, potresti avere difficoltà a rispettare le scadenze a causa di un'enorme quantità di supporto da un'area in cui gli altri sviluppatori sono al lavoro. È una struttura di gestione molto inefficiente.

Inoltre suggerisco di abbandonare la misurazione del carico di lavoro in righe di codice. Le ore uomo sono l'unica metrica ragionevole a cui riesco a pensare

Misurare i progressi della programmazione in base a righe di codice è come misurare i progressi nella costruzione di aeromobili in base al peso: Bill Gates

NB. Non sto dicendo uguale sto dicendo abbastanza. Vale anche la pena notare che va bene specializzarsi in alcuni aspetti della base di codice, ciò accade naturalmente. È solo un problema se nessun altro lavora su quel codice.

Ad esempio, se Facebook avesse 2 programmatori, sarebbero ovviamente sovraccarichi di lavoro, ma come raggiungeresti questa conclusione? Questo è il tipo di domanda che stavo facendo.

Questa non è una domanda di programmazione, è una domanda di gestione.
Ci sono alcune semplici domande a cui rispondere e non hanno nulla a che fare con il software.

1. Quante ore lavori?
2. Quante ore dovresti lavorare?
3. Le scadenze sono rispettate?

Quindi seguire questa logica:

• Se 1> 2, hai bisogno di più persone o scadenze meno aggressive.
• Se 1 <2, hai bisogno di meno persone o più iniziative.
• Se le scadenze non vengono rispettate e 1> = 2, hai bisogno di più persone.
• Se le scadenze non vengono rispettate e 1 <2, dovresti licenziare qualcuno.

Questa è una semplificazione eccessiva che presenta due evidenti difetti.

• Le persone non sono create uguali.
• Ci sono modi per aumentare la produzione delle persone (aggiornare il proprio computer o qualcosa del genere).

Ma hai avuto l'idea.