Bagaimana birokrasi kantor mempengaruhi kualitas kode [ditutup]

Saya tertarik pada cerita di mana birokrasi kantor memiliki efek langsung pada hasil kualitas kode akhir .

Sebagai contoh, seorang teman baru saja memberi tahu saya bahwa di tempat kerjanya sebelumnya sistem kontrol versi sangat besar sehingga programmer tidak diperbolehkan membuat "modul" baru (direktori root di pohon sumber) tanpa meminta izin dari dewa VCS. Hasilnya adalah bahwa para programmer tidak mau melalui langkah birokrasi tambahan dan bukannya mempompisiasikan layanan mereka dengan benar, mereka akhirnya menumpuk fungsi yang tidak terkait di atas modul yang ada bahkan ketika fungsionalitas hanya terkait jarak jauh dengan definisi modul saat ini atau nama modul. adalah cara di masa lalu. (Belum lagi mengganti nama modul ...)

Saya tertarik pada cerita serupa tentang kantor, operasional, atau birokrasi lainnya yang pada akhirnya, mungkin secara tidak sengaja mempengaruhi kualitas perangkat lunak

Saya tertarik pada cerita di mana birokrasi kantor berpengaruh langsung pada hasil kualitas kode akhir.

Saya tidak berpikir birokrasi memiliki banyak pengaruh pada kualitas kode seperti dinamika pribadi dan politik kantor. Birokrasi berhubungan dengan proses. Ketika proses yang ada dilakukan dengan tidak tepat (atau dieksploitasi secara negatif ... lihat lebih lanjut di bawah), ini berpotensi memengaruhi secara negatif kemampuan pengiriman atau bereaksi terhadap perubahan mendadak. Namun, kurangnya proses akan memiliki dampak tertentu dan signifikan pada kualitas kode. Atau lebih tepatnya, proses yang tidak mengatur kualitas kode (juga ditafsirkan sebagai kurangnya proses kualitas kode) memengaruhi kualitas kode.

Artinya, bukan birokrasi itu sendiri melainkan lubang birokrasi spesifik terkait QA yang memengaruhi kualitas kode ketika dieksploitasi (baik secara tidak sengaja atau jahat).

Akan tetapi, dinamika pribadi dan politik kantor jauh lebih merupakan pelakunya dalam kode yang buruk. Dinamika pribadi melibatkan kurangnya etika profesional terlebih dahulu dan terutama. Saya tidak benar-benar membeli argumen bahwa orang menulis kode yang buruk karena mereka tidak tahu yang lebih baik atau belum dilatih dengan baik . Saya telah melihat orang tanpa gelar CS terkait menulis kode yang layak. Ini adalah keadaan pikiran dan masalah pribadi yang teratur dan cermat.

Politik kantor memainkan peran yang bahkan lebih mengerikan. Atasan yang mendorong jangan berpikir, hanya mantra kode (meskipun ada kalanya kita harus memberi kode dan mengirim serta membersihkan mayat nanti); pengembang yang bersikeras memberikan apa yang menurut mereka adalah kode yang sempurna meskipun mengeluarkan sesuatu dari pintu sekarang adalah intinya; pengulas kode yang merupakan ** lubang; perang bilik dan semacamnya. Hal-hal ini memperburuk dinamika pribadi yang bermasalah. Kombinasi keduanya merembes melalui celah apa pun dalam proses (birokrasi) atau ketiadaannya, menyebabkan kerusakan dalam jaminan kualitas kode.

Lubang dalam birokrasi dapat dipecahkan jika ada budaya ulasan post-morten dan peningkatan berkelanjutan. Namun, dinamika pribadi negatif dan politik kantor yang destruktif mencegah koreksi pada proses yang terjadi, sehingga melanggengkan masalah yang ada (termasuk yang terkait dengan kualitas kode).

Birokrasi dengan sendirinya jarang menjadi penyebab kualitas kode yang buruk. Saya sebenarnya akan mengatakan bahwa kualitas kode dan birokrasi dipengaruhi secara negatif oleh dinamika pribadi negatif dan politik kantor.

Saya berhenti mengerjakan beberapa modul tertentu di Proyek karena kode resensi adalah Smart A $$

Pada proyek baru-baru ini, orang-orang berkualitas memiliki banyak persyaratan mengenai pengujian unit formal (keterlacakan, aturan pengkodean, ulasan formal, ...). Para pembuat kode tidak lagi menulis unit test, mereka hanya men-debug kode mereka. Ini adalah tugas yang sama yang baru saja diganti namanya, mengarah ke hasil teknis yang sama, tetapi tanpa kerumitan administratif.