In che modo la burocrazia degli uffici influisce sulla qualità del codice [chiuso]


22

Sono interessato a storie in cui la burocrazia degli uffici ha avuto un effetto diretto sul risultato finale della qualità del codice .

Ad esempio, un amico mi ha appena detto che nel suo precedente posto di lavoro il sistema di controllo della versione era così ingombrante che ai programmatori non era permesso creare nuovi "moduli" (directory root nell'albero dei sorgenti) senza chiedere i permessi agli dei VCS. Il risultato è stato che i programmatori non erano disposti a superare la fase burocratica aggiuntiva e invece di strutturare correttamente i loro servizi hanno finito per accumulare funzionalità non correlate sui moduli esistenti anche quando la funzionalità era solo lontanamente correlata alla definizione corrente del modulo o al nome del modulo era in passato. (per non parlare di rinominare un modulo ...)

Sono interessato a storie simili di ufficio, operativo o qualsiasi altra burocrazia che alla fine, forse, ha influenzato involontariamente la qualità del software


Questa è una domanda molto molto interessante ...

1
Dang it. So di avere delle belle storie per questo, ma è il tipo di cosa a cui cerco di non pensare. :)
George Marian,

1
@Ran ottieni +1 punto mischia per questa domanda;)
Eran Harel,

Questa domanda è intrinsecamente negativa e invita a risposte distruttive / critiche. Potresti forse ottenere risposte costruttive su come questi problemi sono stati superati: soluzione tecnica, soluzione umana, pensiero laterale, ecc.?
JBR Wilkinson,

1
@JBRWilkinson Cosa c'è di sbagliato nel condividere il dolore e divertirsi mentre ci provi? Aiuta gli altri esseri umani, forse aiuterà anche i programmatori ...
Ha funzionato il

Risposte:


6

Sono interessato a storie in cui la burocrazia degli uffici ha avuto un effetto diretto sul risultato finale della qualità del codice.

Non penso che la burocrazia abbia così tanto effetto sulla qualità del codice come fanno le dinamiche personali e la politica dell'ufficio. La burocrazia ha a che fare con il processo. Quando un processo esistente viene eseguito in modo improprio (o sfruttato negativamente ... vedere più avanti), ha il potenziale di influenzare negativamente la capacità di consegna o reagire a cambiamenti improvvisi. Una mancanza di processo, tuttavia, avrà un certo e significativo impatto sulla qualità del codice. O per essere più precisi, un processo che non regola la qualità del codice (interpretato anche come mancanza di un processo di qualità del codice) influisce sulla qualità del codice.

Cioè, non è la burocrazia stessa, ma i buchi specifici, legati alla QA nella burocrazia, che influenzano la qualità del codice quando sfruttati (accidentalmente o in modo nefasto).

Le dinamiche personali e la politica dell'ufficio, tuttavia, sono molto più un colpevole del cattivo codice, tuttavia. Le dinamiche personali comportano innanzitutto la mancanza di etica professionale. Non compro davvero l'argomento secondo cui le persone scrivono codice errato perché non conoscono meglio o non sono state adeguatamente addestrate . Ho visto persone senza diplomi CS scrivere codice decente. È uno stato d'animo e una questione personale di essere organizzato e meticoloso.

La politica dell'ufficio gioca un ruolo ancora più terribile. I capi che spingono non pensano, solo codificano il mantra (anche se ci sono momenti in cui dobbiamo solo programmare e spedire e pulire i corpi in seguito); gli sviluppatori che insistono nel fornire quello che pensano sia il codice perfetto anche se ottenere qualcosa dalla porta ora è essenziale; revisori del codice che sono un buco **; guerre cubicolo e simili. Queste cose esacerbano dinamiche personali problematiche. La combinazione di entrambi penetra attraverso eventuali crepe nel processo (la burocrazia) o la loro mancanza, causando una rottura della garanzia della qualità del codice.

Il buco nella burocrazia potrebbe essere risolto se esiste una cultura delle revisioni post-morten e del miglioramento continuo. Tuttavia, dinamiche personali negative e politiche distruttive degli uffici impediscono che si verifichino tali correzioni sul processo, perpetuando così i problemi esistenti (compresi quelli relativi alla qualità del codice).

La burocrazia da sola raramente è la causa di cattiva qualità del codice. Direi che la qualità del codice e la burocrazia sono entrambe influenzate negativamente dalle dinamiche personali negative e dalla politica dell'ufficio.


non esattamente il tipo di risposta divertente che mi aspettavo, ma sicuramente pensierosa, quindi segnerò come "accetta" anche se sarò felice di vedere altre storie volare dentro.
svolto il

1

Ho smesso di lavorare su alcuni moduli particolari nel Progetto perché il revisore del codice era un Smart A $$


1

In un recente progetto, le persone di qualità avevano molti requisiti per quanto riguarda i test unitari formali (tracciabilità, regole di codifica, revisioni formali, ...). I programmatori non scrivono più unit test, ma eseguono solo il debug del loro codice. Questa è la stessa attività appena rinominata, porta agli stessi risultati tecnici, ma senza problemi amministrativi.


5
I test unitari sono pezzi di codice eseguiti automaticamente per rilevare errori di codifica. Sono "liberi" di funzionare. Gli umani che impiegano molto tempo a eseguire il debug costano $ $ per persona all'ora. Se lascia un solo sviluppatore, la capacità di debug del team si riduce ma i test unitari sarebbero comunque altrettanto buoni.
JBR Wilkinson,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.