12 dilema etika yang menggerogoti pengembang saat ini

Dunia teknologi selalu lama berkuasa dan kurang memikirkan konsekuensi dari kekuatan ini. Jika bisa dibangun, akan selalu ada seseorang yang akan membangunnya tanpa memikirkan cara yang lebih aman dan waras untuk melakukannya, apalagi apakah teknologi itu harus dibangun terlebih dahulu. Perangkat lunak tersebut ditulis. Siapa yang peduli di mana dan bagaimana penggunaannya? Itu tugas seseorang di kantor pojok.

Lebih meresahkan: Sementara kursus etika telah menjadi pokok gelar teknik dunia fisik, mereka tetap menjadi anomali yang menyesatkan dalam pedagogi ilmu komputer. Namun karena perangkat lunak mengambil alih lebih banyak kehidupan kita, konsekuensi etis dari keputusan yang dibuat oleh pemrogram hanya menjadi lebih besar. Sekarang kode kita ada di lemari es, termostat, alarm asap, dan banyak lagi, gerakan yang salah, kurangnya pandangan ke depan, atau pengambilan keputusan yang benar-benar meragukan dapat menghantui umat manusia ke mana pun ia pergi.

[Apa yang masuk dan apa yang keluar dalam pengembang aplikasi: 15 tren pemrograman populer - dan 15 menjadi dingin. | Tunjukkan seberapa banyak Anda benar-benar tahu tentang pengembangan dengan mengikuti tes IQ Pemrograman kami, putaran 3 dan kuis bahasa pemrograman "Halo, dunia" kami. | Bekerja lebih cerdas, bukan lebih keras - unduh Panduan Bertahan Hidup Pengembang dari untuk semua tip dan tren yang perlu diketahui pemrogram. | Ikuti terus berita pengembang terbaru dengan buletin Dunia Pengembang. ]

Berikut ini adalah beberapa masalah etika yang dihadapi developer setiap hari - baik mereka menyadarinya atau tidak. Tidak ada jawaban yang mudah, dalam beberapa hal karena sifat pekerjaan itu sangat abstrak. Lebih buruk lagi, bisnis telah menjadi sangat terkait erat dengan teknologi komputer sehingga sulit untuk menyeimbangkan kebutuhan dan motivasi semua pihak yang berinvestasi dalam mencoba mencegah fitur kasus bisnis saat ini menjadi mimpi buruk Orwellian besok.

Triknya adalah dengan memikirkan masa lalu zeitgeist saat ini dan mengantisipasi setiap pemanfaatan masa depan dari apa yang Anda bangun. Cukup sederhana, ya? Pertimbangkan ini bukan sebagai buku panduan untuk membuat keputusan Anda dan lebih sebagai titik awal untuk jenis perenungan etis yang harus kita lakukan sebagai bagian sehari-hari dari pekerjaan kita.

Dilema etika No. 1: File log - apa yang harus disimpan dan bagaimana menanganinya

Pemrogram seperti tikus pak. Mereka menyimpan catatan segalanya, seringkali karena itu satu-satunya cara untuk men-debug sistem. Tetapi file log juga melacak semua yang dilakukan pengguna, dan di tangan yang salah, mereka dapat mengungkap fakta yang ingin dirahasiakan oleh pengguna.

Banyak bisnis dibangun dengan melindungi file log secara aktif. Beberapa layanan pencadangan jarak jauh bahkan menjanjikan untuk menyimpan salinan tambahan di lokasi geografis yang berbeda. Tidak setiap bisnis menginginkan ketekunan seperti itu. Snapchat, misalnya, membangun mereknya dengan melakukan pekerjaan yang sangat buruk dalam mencadangkan data, tetapi penggunanya tertarik oleh kebebasan sistem yang pelupa.

Keberadaan file log saja menimbulkan beberapa pertanyaan etis. Apakah mereka cukup terlindungi? Siapa yang punya akses? Ketika kami mengatakan kami menghancurkan file, apakah mereka benar-benar dihancurkan?

Intinya adalah memastikan informasi apa yang layak disimpan, mengingat risiko melakukannya, etis atau sebaliknya. Di sini, masa depan memperumit persamaan. Pada 1960-an, merokok dianut secara luas. Tidak ada yang akan berpikir dua kali untuk melacak kebiasaan merokok orang. Saat ini, bagaimanapun, pengetahuan tentang aktivitas merokok seseorang dapat digunakan untuk menaikkan tarif asuransi kesehatan atau bahkan menolak pertanggungan.

Kesepakatan bisnis di masa depan; peraturan pemerintah di masa depan; kebutuhan yang tak terduga dan sangat mendesak untuk aliran pendapatan baru - mungkin tidak mungkin untuk memprediksi file log yang tampaknya tidak berbahaya yang akan menjadi masalah di masa mendatang, tetapi penting untuk mempertimbangkan etika cara Anda menangani log di sepanjang jalan.

Dilema etika No. 2: Apakah - dan bagaimana - mengubah pengguna menjadi produk

Ini adalah pepatah kuno di era startup: Jika Anda tidak membayar untuk suatu layanan, Anda bukan pelanggan; Anda adalah produknya.

Di Internet, layanan "gratis" berlimpah. Faktanya, pertanyaan dari mana uang itu akan datang sering kali ditunda, ditunda. Kami baru saja membangun kehebatannya, mengawasi metrik adopsi, dan mengira orang lain akan menangani pekerjaan kotor untuk menjaga agar lampu server tetap menyala. Kasus terburuk, selalu ada iklan.

Pengembang harus terbuka tentang siapa yang akan mendukung pekerjaan mereka dan dari mana uang itu akan datang. Setiap perubahan harus dikomunikasikan kepada pengguna dengan cara yang jelas dan tepat waktu untuk menghindari kejutan dan pukulan balik. Mengubah orang menjadi produk adalah perubahan etika yang tidak bisa dianggap enteng. Penawaran iklan yang teduh, jaringan iklan yang teduh - kami harus berhati-hati dalam menangani kepercayaan implisit dari pengguna awal.

Dilema etika No. 3: Seberapa bebaskah konten yang diinginkan?

Sejumlah bisnis bergantung pada penyajian konten tanpa membayar mereka yang membuatnya. Beberapa berbalik dan menjual iklan atau bahkan mengenakan biaya untuk akses. Bisnis-bisnis ini seringkali tidak dapat bertahan dan tidak dapat memberi harga material mereka semenarik mungkin jika mereka harus menanggung bagian yang adil dari biaya pengembangan. Mereka mengembangkan rasionalisasi yang rumit tentang "berbagi" atau "penggunaan wajar" untuk menutupi keputusan yang goyah secara etis.

Pengembang harus bertanya pada diri sendiri bagaimana kode mereka akan mendukung semua orang dalam rantai makanan, dari pembuat hingga konsumen. Apakah orang yang membuat konten ingin karyanya didistribusikan dengan cara ini? Apakah mereka senang bekerja untuk eksposur atau perhatian saja? Apakah mereka diberi bagian yang adil dari pendapatan?

Tidak mempertimbangkan pertanyaan-pertanyaan ini berarti menutup mata terhadap pembajakan. Lagipula, tidak semua informasi hanya "ingin bebas".

Dilema etika No. 4: Berapa banyak perlindungan yang cukup

Beberapa orang mengatakan bahwa semuanya harus dienkripsi ganda dengan dua algoritma berbeda dan dikunci dalam hard disk yang disimpan di brankas. Sayangnya, overhead memperlambat sistem hingga merayap dan membuat pengembangan 10 kali lebih berat. Lebih buruk lagi, jika satu bit dibalik atau salah satu bagian dari algoritme salah, semua data akan hilang karena enkripsi tidak dapat dibatalkan.

Yang lain tidak mau angkat jari untuk melindungi data. Tim berikutnya dapat menambahkan enkripsi khusus nanti jika perlu, kata pengembang. Atau mereka mungkin membantah bahwa tidak ada yang sensitif tentang itu. Tim yang mengabaikan tanggung jawab ini biasanya dapat menghasilkan banyak kode lain dan membuat tumpukan fitur luar biasa yang diinginkan orang. Siapa yang peduli jika mereka aman?

Tidak ada jawaban sederhana tentang seberapa besar perlindungan yang harus diterapkan. Hanya ada tebakan. Lebih banyak selalu lebih baik - sampai data hilang atau produk tidak dikirim.

Dilema etika No. 5: Untuk memperbaiki bug atau tidak memperbaiki bug?

Cukup sulit untuk menegosiasikan beting etis ketika melibatkan keputusan aktif, tetapi lebih sulit lagi ketika masalah dapat disingkirkan dan diberi label bug yang pada akhirnya akan diperbaiki. Seberapa keras kita harus bekerja untuk memperbaiki masalah yang entah bagaimana tergelincir ke dalam kode yang sedang berjalan? Apakah kita menjatuhkan semuanya? Bagaimana kami memutuskan apakah suatu bug cukup serius untuk diperbaiki? 

Isaac Asimov menghadapi masalah ini sejak lama ketika dia menulis hukum robotika dan memasukkan hukum yang melarang robot untuk tidak melakukan apa-apa jika manusia akan dirugikan melalui kelambanan robot. Tentu saja robotnya memiliki otak positronik yang dapat melihat semua segi dari suatu masalah secara instan dan menyelesaikannya. Pertanyaan untuk pengembang sangat rumit sehingga banyak bug diabaikan dan tidak diperbaiki karena tidak ada yang mau memikirkannya.

Bisakah perusahaan memprioritaskan daftar dengan adil? Apakah beberapa pelanggan lebih penting daripada yang lain? Bisakah seorang programmer memainkan favorit dengan memilih satu bug di atas yang lain? Ini bahkan lebih sulit untuk direnungkan ketika Anda menyadari bahwa sulit untuk mengantisipasi seberapa besar kerugian yang akan datang dari bug tertentu.

Dilema etika No. 6: Berapa banyak kode - atau kompromi - untuk mencegah penyalahgunaan

Kamera Web Apple asli hadir dengan tambahan mekanis yang cerdas, penutup fisik yang memblokir lensa saat dimatikan. Penutup dan sakelar dihubungkan bersama; tidak ada cara untuk menggunakan kamera tanpa membuka rana sendiri.

Beberapa webcam yang lebih baru datang dengan LED yang seharusnya menyala saat kamera diaktifkan. Biasanya berfungsi, tetapi siapa pun yang telah memprogram komputer tahu mungkin ada tempat dalam kode di mana kamera dan LED dapat dipisahkan. Jika itu bisa ditemukan, kamera bisa dijadikan alat mata-mata.

Tantangan bagi insinyur adalah mengantisipasi penyalahgunaan dan merancang untuk mencegahnya. Rana Apple adalah salah satu contoh yang jelas dan efektif tentang bagaimana hal itu dapat dilakukan dengan elegan. Ketika saya sedang mengerjakan sebuah buku tentang kecurangan pada SAT, saya bertemu dengan seorang peretas yang menambahkan perangkat lunak jaringan ke kalkulatornya. Setelah beberapa pertimbangan, dia memutuskan untuk hanya mendukung protokol kabel karena dia takut anak-anak akan menyelipkan kalkulator dengan Wi-Fi ke dalam ujian. Dengan hanya mendukung protokol berkabel, dia memastikan bahwa siapa pun yang diuji perlu menjalankan kabel ke mesin tetangga mereka. Dia benci melewatkan protokol nirkabel, tetapi dia merasa risiko penyalahgunaan terlalu tinggi.

Dilema etika No. 7: Seberapa jauh melindungi pelanggan dari permintaan data

Jika Anda mengumpulkan data, bisa dipastikan bahwa organisasi Anda suatu hari akan terjebak antara melayani pelanggan Anda dan melayani pemerintah. Permintaan untuk mengirimkan data ke badan hukum menjadi semakin umum, meninggalkan semakin banyak organisasi perangkat lunak dan layanan yang memikirkan sejauh mana mereka akan mengkhianati privasi pelanggan mereka di hadapan hukum. Anda dapat memeriksa permintaan ini dan bahkan menyewa pengacara Anda sendiri untuk mempertanyakan apakah permintaan tersebut benar-benar sah, tetapi kenyataannya pengadilan akan memperdebatkan legalitas lama setelah dana Anda habis.

Tidak ada solusi yang mudah. Beberapa perusahaan memilih untuk meninggalkan bisnis daripada berbohong kepada pelanggan mereka. Yang lain mencoba untuk lebih terbuka tentang permintaan, yang sering dilarang oleh pemerintah.

Dilema etika No. 8: Bagaimana menangani sifat internasional dari Internet

Internet berjalan di mana-mana, menghindari banyak penghalang tradisional di perbatasan. Ini bisa menjadi penyebab sakit kepala hukum ketika pelanggan A dan B berada di negara yang berbeda. Itu hanya permulaan, karena server C dan D seringkali berada di negara yang sama sekali berbeda juga.

Ini mengarah pada masalah etika yang jelas. Eropa, misalnya, memiliki undang-undang yang ketat tentang menyimpan informasi pribadi dan memandang pelanggaran privasi sebagai kegagalan etika. Negara lain bersikeras agar perusahaan menyimpan banyak catatan tentang transaksi. Hukum siapa yang harus dipatuhi perusahaan ketika pelanggan berada di negara yang berbeda? Kapan data berada di berbagai negara? Kapan data ditransfer melintasi jalur internasional?

Menjaga setiap kemungkinan hukum bisa menjadi sangat besar, meninggalkan banyak organisasi yang pasti tergoda untuk mengubur kepala mereka di pasir.

Dilema etika No. 9: Berapa banyak yang harus diberikan kembali ke open source

Semua orang tahu bahwa open source itu gratis. Anda tidak perlu membayar apa pun dan itulah yang membuatnya begitu indah dan rumit. Tetapi tidak semua orang memikirkan masalah etika yang datang dengan menggunakan kode gratis itu. Semua paket open source datang dengan lisensi dan Anda harus mengikutinya.

Beberapa lisensi tidak membutuhkan banyak pengorbanan. Lisensi seperti Lisensi Apache atau Lisensi MIT memerlukan pengakuan dan hanya itu saja. Tetapi lisensi lain, seperti Lisensi Publik Umum GNU, meminta Anda untuk berbagi semua peningkatan Anda.

Mengurai lisensi open source dapat menghadirkan tantangan etika. Seorang manajer dari sebuah perusahaan publik besar mengatakan kepada saya, "Kami tidak mendistribusikan MySQL, jadi kami tidak berutang apa pun kepada siapa pun." Dia memasukkan klausul, yang ditulis beberapa dekade lalu, yang mengikat kewajiban lisensi dengan tindakan mendistribusikan ulang perangkat lunak. Perusahaan menggunakan MySQL untuk aplikasi Web-nya, jadi dia merasa itu bisa dilakukan tanpa memberi kembali.

Tidak ada cara sederhana untuk mengukur kewajiban etis, dan banyak programmer menyia-nyiakan banyak penekanan tombol untuk memperdebatkan apa yang mereka maksud. Namun, seluruh usaha itu akan terhenti jika orang berhenti memberi. Kabar baiknya adalah sering kali menjadi kepentingan terbaik setiap orang untuk berkontribusi karena semua orang ingin perangkat lunak tetap kompatibel dengan penggunaannya.

Dilema etika No. 10: Berapa banyak pemantauan yang benar-benar diperlukan

Mungkin atasan Anda ingin memastikan bahwa pelanggan tidak menipu perusahaan. Mungkin Anda ingin memastikan Anda dibayar untuk pekerjaan Anda. Mungkin beberapa orang menyeramkan dari pemerintah mengatakan Anda harus memasang pintu belakang untuk menangkap orang jahat. Dalam setiap kasus, argumennya dipenuhi dengan jaminan bahwa pintu belakang hanya akan digunakan, seperti kekuatan Superman, untuk mendukung kebenaran dan keadilan. Itu tidak akan digunakan untuk melawan musuh politik atau mereka yang kurang beruntung. Itu tidak akan dijual kepada rezim despotik.

Tetapi bagaimana jika orang jahat menemukan pintu yang tersembunyi dan mencari cara untuk menggunakannya sendiri? Bagaimana jika pintu belakang Anda digunakan untuk mendukung ketidakbenaran dan ketidakadilan? Kode Anda tidak dapat membuat keputusan etis sendiri. Itu tugasmu.

Dilema etika No. 11: Bagaimana kode seharusnya anti peluru

Tentu, perhitungan minimal, struktur data sederhana, dan pendekatan brute-force bekerja dengan baik di demo ketika masalahnya kecil. Pengguna mencoba kode tersebut dan berkata, "Astaga, ini bekerja dengan cepat." Beberapa bulan kemudian, ketika data yang cukup telah dimuat ke dalam sistem, kelemahan algoritma murah muncul dan kode melambat untuk di-crawl.