Considerare un componente software complesso ed esteso; ad esempio un motore di rendering di testo multilingue, un framework IPC, uno scheduler in grado di gestire più fusi orari, un modulo pieno di complessità causato dalla necessità di rimanere retrocompatibili, ecc. Richiede molta conoscenza dei dettagli per mantenere ed estendere tale componente senza introdurre bug con ogni cambiamento di codice. Spesso è anche utile conoscere la cronologia dei bug quando si riceve una nuova segnalazione di bug. Inoltre, richiede una conoscenza approfondita del design del componente per essere in grado di mantenere la sua coerenza dopo le future estensioni, ed è bene conoscere la logica dietro le decisioni di progettazione passate. Potresti provare a documentare questo tipo di conoscenza, ma richiederebbe molto tempo e sforzi, diventerebbe rapidamente obsoleto e quindi non affidabile. Peggio ancora, tutti avrebbero ancora bisogno di tenere a mente quella documentazione scritta.
Mi sembra che per tali componenti, è meglio avere qualcuno che abbia una conoscenza approfondita, in quanto non si può conoscere a fondo e tenere il passo con il codice prodotto da un intero gruppo di persone senza una comunicazione eccessiva e l'apprendimento in testa . Mi chiedo se la pratica della proprietà del codice collettivo consenta a tali esperti, come mi sembra che richiederebbe alcuni tipo di "proprietà del codice debole". E se no: come può avere successo senza una quantità enorme di lavoro duplicato?