Com'è lavorare in un grande team di programmazione?

Mi sono sempre sentito fortunato a lavorare in un piccolo team di programmazione. Penso che il massimo con cui ho lavorato siano 11 programmatori. Com'è lavorare su un progetto con centinaia di sviluppatori? Migliaia? Cosa scala e cosa no?

EDIT: Grazie per tutte le risposte! Sembra che ci siano pochissimi aspetti positivi:

• possibile lavorare su basi di codice mega-grandi
• migliore sviluppo della carriera interna
• protezione dei dipendenti contro la gestione abusiva (questo è più -ve su piccolo che + ve su grande)

C'è qualche altro vantaggio per le grandi squadre?

Trovo le scale della burocrazia davvero bene.

A parte questo, non molto. I grandi progetti hanno grandi team perché non c'è altro modo, non perché è più efficiente (per sviluppatore). Paghi un costo non appena aggiungi una seconda persona al mix in termini di inefficienza (ad es. Trasferimento di conoscenza e comunicazione).

Il più grande progetto a cui ho lavorato ha avuto circa 70 sviluppi in 5 diversi siti. Anche il cambio di una riga ha richiesto un minimo di un giorno, anche se in parte a causa del fatto che la costruzione ha richiesto oltre 45 minuti su un collegamento di rete da Zurigo a Londra e l'avvio dell'app ha richiesto altri 45 minuti. Il check-in ha richiesto circa 5 minuti per file. Non sto scherzando. Gli sviluppatori di Londra potrebbero farlo in una frazione del tempo.

Ad ogni modo, quello che tendi a trovare è che su grandi progetti avrai un sacco di membri del team con cui non interagisci così tanto. È più simile a una raccolta vagamente affiliata di mini progetti. Una volta ho letto che lo sviluppo di Microsoft tendeva a suddividere i progetti in team di 5-7 sviluppatori, anche per progetti di grandi dimensioni come Microsoft Office.

Parte della differenza è anche la differenza tra piccole e grandi aziende: quelle più grandi tendono ad avere più processi, più regole, meno flessibilità e così via. Ma questo non è affatto garantito.

Tuttavia, può essere utile per lo sviluppo della carriera. In una piccola azienda qualcuno deve partire o morire prima che tu possa ottenere una promozione (o la società deve crescere in modo tale che il team si espanda e ti muovi verso l'alto) mentre in dipartimenti di sviluppo più grandi puoi spostarti tra i team e così via.

Inoltre a volte puoi trovare alcune persone davvero intelligenti a cui attaccarti e da cui imparare. Nelle piccole aziende essere così isolati e autosufficienti può favorire i programmatori a diventare un po '"strani", una specie di eremita.

La comunicazione è ciò che ho scoperto essere la cosa più grande che inizia a degradare con l'aumentare delle dimensioni del team. Diventa più difficile ottenere comunicazioni, e più difficile garantire che tutti siano ancora sulla stessa pagina. Lavoro indirettamente su un team di circa 75 sviluppatori, usiamo una base di codice comune, ma molti dei 75 si dividono in gruppi più piccoli per singole "attività". Per noi la comunicazione è solo un vero incubo.

Anche la gestione di gruppi più grandi è più difficile, poiché nella maggior parte degli ambienti dopo che 8-12 persone sono state coinvolte da altri membri della direzione, purtroppo questo esagera il problema di comunicazione poiché in genere crea un ambiente di tipo "silo" in cui i singoli sottoinsiemi iniziano a staccarsi dal grande gruppo e cerca di mantenere la conoscenza all'interno del loro gruppo.

All'epoca in cui realizzavo software per sistemi d'arma, avevamo GRANDI team di sviluppatori software. Dal momento che nessuna persona può avvolgere la testa attorno ai requisiti (alcuni dei quali sono stati classificati), si trattava solo di squadre e di come le squadre interagivano tra loro.

1. La gestione della configurazione - il processo di creazione notturno - era un grosso problema. A quei tempi ci voleva un grande cluster di elaborazione distribuito per ricompilare il mondo ogni notte.

2. Le autorizzazioni al lavoro - e addebitare il tuo tempo all'elemento pubblicitario corretto nel programma generale del progetto principale - è stato un grande dolore al collo. Fino a 0,1 ore. incrementi.

Ma il più grande affare era la notifica di modifica. In particolare modifiche dell'interfaccia.

Questo è stato così importante, hanno inventato questo folle processo a due strati. La maggior parte degli sforzi è consistita nell'assicurarsi che la Richiesta di notifica di modifica dell'interfaccia (non la notifica stessa, ma la richiesta di notifica) disponesse di elaborati software di supporto con un database e report e quant'altro.

Una volta che la richiesta è stata approvata, l'avviso effettivo è più o meno ovvio. Significava che si trattava davvero di un processo a un solo livello e la richiesta era effettivamente l'avviso. Ma quando stai facendo lo sviluppo a cascata, tutto deve essere pensato a lungo prima che gli sviluppatori si presentino.

Con così tante persone che lavorano in parallelo, c'era una scheda di controllo della configurazione. Tutti i vari team manager, oltre a un gruppo di persone il cui compito era semplicemente coordinare i cambiamenti.

Il mio primo "vero" lavoro di programmazione è stato quello di lavorare con un altro esercito per sviluppare sistemi di controllo del traffico aereo internazionale. È stato uno sforzo di grande successo e siamo stati considerati un ambiente di livello 5 del modello di maturità della capacità. Da allora sono stato in negozi di medie e piccole dimensioni. Quindi, qual è il posto migliore dove stare? Personalmente prenderei un negozio più piccolo su quello enorme ogni giorno. Mentre alcuni potrebbero considerare il livello 5 come il Santo Graal, per me è stato soffocante. Tutto deve essere documentato, approvato, approvato, ecc. Non fraintendetemi, ne vedo sicuramente il valore, soprattutto per i sistemi critici come il controllo del traffico aereo, ma la domanda è: come volete spendere giorno? Vuoi la libertà di poter sognare le cose e poi metterle in atto, o vuoi scrivere ai requisiti? Forse se fossi rimasto più a lungo con il sistema ATC avrei potuto salire al livello di essere in grado di progettare e sviluppare, ma anche quello richiedeva un numero X di anni, un numero Y di approvazioni, un numero Z di promozioni - tutto ben prescritto senza possibilità di deviazione. Era soffocante.

Un'ultima cosa, in generale trovo che la qualità degli sviluppatori sia molto più elevata nelle aziende più piccole semplicemente perché non possono nascondersi. Non è difficile essere mediocri in un'azienda molto grande, ma diventa dolorosamente ovvio in una piccola azienda e spesso non durano a lungo.

Ho lavorato (brevemente) in un'organizzazione con almeno centinaia di sviluppatori. Ma ovviamente (?), L'organizzazione è partizionata internamente in modo che tu come singolo dipendente non abbia un contatto diretto con tutti gli altri, sarebbe molto difficile tenere il passo.

In quel particolare posto, il software era diviso in componenti, con squadre formate attorno a componenti. Alcuni team lavoravano con un solo componente (grande), mentre molti avevano la responsabilità di un gruppo di componenti (più piccoli).

Ovviamente questo implica tutto ciò che funziona con una base di codice molto ampia; cose come la gestione della configurazione, la costruzione, l'integrazione e così via diventano importanti, grandi, cose che sono a loro volta fatte da dipartimenti dedicati specializzati. E tu li sbalordisci, per essere in grado di raccogliere tutti i risultati dei dipartimenti degli sviluppatori e di integrarli regolarmente (una volta alla settimana, dove ho lavorato) in un insieme coeso che ha funzionato.

Non ho mai lavorato per una grande squadra di programmatori , ma il risultato di un'organizzazione che aumenta di dimensioni è di solito più regole. Questa non è necessariamente sempre una brutta cosa! Oltre alle regole che rendono difficile la vita di tutti, ci sono anche più regole per proteggere i dipendenti e garantire un buon processo.

Ho visto manager di piccole organizzazioni cavarsela con cose che li avrebbero immediatamente fatti chiudere da un dipartimento delle risorse umane.

L'unica differenza che ho notato con i grandi progetti è la politica dell'ufficio. Più grandi sono i progetti, più dominante è la politica.

Il mio primo progetto fuori dalla scuola fu un paio di centinaia di sviluppatori. Come un nuovo sviluppatore arrogante e naieve da scuola ero davvero non pronti per questo. L'unica cosa che ha salvato il mio hiney (ed è l'unica cosa che ti proteggerà mai davvero) è stata la quantità di amici che ho fatto.

Questa è la lezione più grande che ho imparato da quello. Cerca di fare amicizia con tutti . Anche i cretini. In particolare, se hai la possibilità di smettere di lavorare per un minuto e avere una conversazione con qualcuno con cui non hai mai parlato prima, fallo.

Una volta ho trascorso un anno a lavorare in un team con oltre 500 persone, di cui circa 200 erano sviluppatori. Stavamo offrendo un EOA, integrando diverse soluzioni SOA diverse.

In pratica c'erano tra i 30 e i 50 team, ognuno con un numero variabile di programmatori (3 nel nostro team), ognuno con la responsabilità di un aspetto diverso del risultato complessivo.

Il team più grande su cui abbia mai lavorato era di circa 15 persone (questo era solo per 3 o 4 mesi, in un'azienda diversa). Ero il capo tecnico del team e mi sono messo al lavoro alle 7 del mattino, avrei avuto 2 ore abbastanza prima che tutti gli altri entrassero, era l'unico modo in cui potevo portare a termine i miei compiti.

Non mi piacerebbe lavorare in un team con più di 8 o 10 sviluppatori, 15 erano troppi per un singolo team (il team avrebbe potuto facilmente essere diviso in due, non purtroppo la mia chiamata), 3 o 4 sviluppatori è un bella dimensione comoda IMHO