Minggu lalu, saya menghabiskan banyak waktu untuk menghapus kode mati dari basis kode kami. Saya suka menghapus kode. Bagi saya, sedikit sekali hal yang memberikan kesenangan yang sama dengan mengatur berbagai hal dalam kode. Ya, saya sangat menyukainya sehingga saya bingung oleh para insinyur yang meninggalkan kode yang tidak perlu dalam aplikasi. Tetapi pada akhir pekan saya mendengar seseorang berbicara tentang percobaan Milgram "Submission to authority" ( mereka juga menulis tentang hal itu di hub) - dan saya tidak bisa membantu tetapi menarik paralel antara orang yang mengejutkan manusia lain dan insinyur yang meninggalkan bug dan kode buruk yang diketahui.
Jika Anda tidak terbiasa dengan percobaan Stanley Milgram, maka itu terdiri dari kenyataan bahwa Eksperimen (orang yang memiliki otoritas) memerintahkan Guru (objek penelitian) untuk mengalahkan Siswa dalam serangkaian pelepasan arus yang meningkat, yang berada di ruangan lain. Ilustrasi Wikipedia:

E - eksperimen, T - guru, L - pelajar
Inti dari percobaan ini adalah untuk mempelajari reaksi orang terhadap perintah yang bertentangan dengan prinsip-prinsip moral mereka. Sebelum percobaan, diyakini bahwa sebagian besar subjek akan menghentikan percobaan segera setelah mereka menyadari bahwa mereka menyakiti Pelajar. Namun, selama percobaan ternyata jumlah subjek yang mencolok mencapai debit maksimum 450 volt.
Dalam set pertama percobaan Milgram, 65 persen dari peserta (26 dari 40 orang) menggunakan nilai maksimum yang mungkin dari 450 volt, meskipun itu tidak menyenangkan bagi mereka untuk melakukan ini; pada titik waktu tertentu, setiap peserta berhenti dan meragukan eksperimen; beberapa peserta ingin berhenti dan mengembalikan uang yang mereka bayarkan untuk partisipasi. Selama percobaan, peserta mengalami berbagai tingkat kegembiraan dan stres. Mereka berkeringat, gemetar, tergagap, menggigit bibir, mengerang, merogoh kukunya ke kulit, beberapa tertawa gugup.
Ketika kita belajar tentang hasil seperti itu, kita ingin percaya bahwa kita tidak akan pernah melakukan itu. Kami ingin percaya bahwa "hanya mematuhi perintah" adalah cacat manusia yang tidak kita miliki. Tetapi percobaan seperti percobaan Milgram menunjukkan bahwa keyakinan seperti itu paling optimis, dan sepenuhnya salah.
Dan sekarang kita tahu bagaimana orang bereaksi terhadap otoritas, ketika rasa sakit fisik dipertaruhkan, mari kita lihat bagaimana programmer bereaksi terhadap otoritas ketika datang ke hal-hal yang lebih abstrak, seperti frustrasi dan ketidaknyamanan. Mari kita ambil diagram percobaan Milham dan desain ulang untuk mencerminkan tim pengembangan:

Jika kita melihat tim pengembangan seperti yang ditunjukkan dalam ilustrasi, tidak mengherankan mengapa kita para insinyur meninggalkan kode yang buruk dan meninggalkan bug yang dikenal. Mungkin pada titik tertentu orang yang berkuasa menjelaskan bahwa kita tidak punya waktu untuk memperbaiki masalah atau masalah ini tidak diprioritaskan dibandingkan dengan hal-hal lain dalam peta jalan. Atau bahwa menghapus kode mati tidak membawa nilai bagi pengguna. Sebagai hasilnya, kita membiarkan kode itu apa adanya dan melanjutkan ke tugas berikutnya, meskipun ini bertentangan dengan kompas moral kita dan konsep tentang apa yang baik dan apa yang buruk.
Dalam percobaan Milgram, subjek sering ragu-ragu dan memprotes agar tidak mengirim pelepasan lain ke seseorang di ruangan lain. Dalam kasus seperti itu, pelaku percobaan menuntut kelanjutan dari salah satu frasa yang telah ditentukan:
- “Silakan lanjutkan” (Silakan lanjutkan / Silakan lanjutkan);
- "Eksperimen mengharuskan Anda untuk melanjutkan";
- “Sangat penting bagi Anda untuk melanjutkan” (Sangat penting bagi Anda untuk melanjutkan);
- "Kamu tidak punya pilihan lain, kamu harus pergi".
Dengan menggunakan apa-apa selain kata-kata, eksperimen itu mampu memastikan bahwa 65 persen dari subjek melawan kehendak mereka mengalahkan orang lain dengan debit yang sangat menyakitkan saat ini. Saya ingin tahu kata apa yang kami gunakan dalam konteks pengembangan perangkat lunak?
- Ini bukan apa yang kita putuskan, tetapi tim produk
- Kita harus memenuhi tenggat waktu
- Tim pemasaran akan merilis siaran pers minggu depan.
- Kami menutup terlalu sedikit tiket
- Bagaimanapun, kami akan membuang kode ini
- Ini adalah solusi sementara.
- Perlu meningkatkan kinerja tim Anda
- Ini akan memengaruhi sejumlah kecil pengguna.
- Ini bukan prioritas bagi kami sekarang.
- Kami akan memperbaikinya nanti
- Inilah yang diinginkan manajemen
- Kenapa begitu lama?
- Perlu melakukannya lebih cepat.
Saya tidak menulis tentang ini untuk menyarankan solusi. Saya tidak memilikinya. Saya menulis untuk menumbuhkan - pertama-tama dalam diri saya - simpati dan pengertian . Ketika saya melihat kode yang meninggalkan perasaan bingung atau perilaku yang tidak saya mengerti, saya harus ingat bahwa tindakan tidak selalu mencerminkan niat. Saya harus ingat bahwa insinyur meninggalkan kode buruk bukan karena mereka tidak peduli - mereka meninggalkan kode buruk karena mereka tidak memiliki kebebasan untuk menertibkannya. Dan mereka meninggalkan bug bukan karena mereka tidak peduli dengan pengguna, tetapi karena mereka tidak memiliki wewenang untuk menyimpang dari peta jalan produk.