Di quanto codice dovrei essere responsabile?

L'unica misura concreta per uno sviluppatore dipendente è il numero di ore trascorse a programmare e correggere bug e il denaro che ti viene pagato. Se rimani a notte fonda 6 giorni a settimana per 50.000 $ l'anno, allora hai un problema. Indipendentemente dal numero di righe di codice di cui il tuo capo desidera essere responsabile, non gestirai più di quanto tu possa fare, tenendo ovviamente conto di una certa qualità del codice. Sviluppare codice di scarsa qualità senza test di unità è un buon modo per gestire molto più codice, ma la società dovrà pagare il prezzo di un grande debito tecnico .

Negli piccoli sviluppatori di aziende tendono a essere responsabili di molto più codice rispetto a large corp. Il fattore da 3 a 10 a cui ti riferisci sembra realistico per me.

Ho conosciuto un team di tre persone che gestiva una base di codice di 1,5 milioni di linee e non ci stava affogando. La misurazione importante non è la quantità di codice di cui sei responsabile, ma piuttosto la quantità di codice che devi modificare in un determinato intervallo 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 cammini sotto un autobus? Le piccole aziende di solito non fanno valutazioni del rischio in questo modo, ma ciò significa che il continuo successo dell'azienda è lasciato al caso.

la dimensione base del codice / il numero di sviluppatori non è correlata al carico di lavoro. Se hai un enorme codice di codice stabile, la metrica sarà alta. Se hai ancora una piccola base di codice in fase di sviluppo, quella metrica sarà bassa. le variazioni delle linee per unità di tempo per sviluppatore sono più legate al carico di lavoro. Ma anche così, ho passato giorni a rintracciare bug sottili la cui soluzione era una linea ...

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

Nel caso in cui uno sviluppatore descrittore stia tentando di rispettare le scadenze a causa di un'enorme quantità di supporto da un'area in cui altri sviluppatori lavorano. È una struttura di gestione molto inefficiente.

Inoltre ti suggerisco di allontanarti dalla misurazione del carico di lavoro in linee di codice. Le ore di lavoro sono l'unica metrica sensibile a cui riesco a pensare

Measuring programming progress by lines of code is like measuring aircraft building progress by weight - Bill Gates

NB. Non sto dicendo lo stesso che sto dicendo in modo equo. Vale anche la pena notare che è bene specializzarsi su alcuni aspetti della base di codice, che avviene naturalmente. È solo un problema se nessun altro lavora mai su quel codice.

For example, if Facebook had 2 programmers, they would obviously be overworked - but HOW would you reach that conclusion? That's the type of the question I was going for.

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

1. Quante ore stai lavorando?
2. Quante ore dovresti lavorare?
3. Sono rispettate le scadenze?

Quindi segui questa logica:

• Se 1 > 2, hai bisogno di più persone o di scadenze meno aggressive.
• Se 1 < 2, hai bisogno di meno persone o più iniziative.
• Se le scadenze non vengono soddisfatte 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 ha due difetti evidenti.

• Le persone non sono uguali.
• Ci sono modi per rendere le persone più produttive (aggiornare il loro computer o qualcosa del genere).

Ma ti viene l'idea.