“Seorang programmer yang baik dapat 10 kali lebih produktif daripada yang biasa-biasa saja” [ditutup]

Saya telah membaca sebuah wawancara dengan seorang programmer yang hebat (bukan dalam bahasa Inggris) dan di dalamnya ia berkata bahwa "seorang programmer yang hebat bisa 10 kali lebih baik daripada yang biasa-biasa saja" memberikan alasan mengapa programmer yang baik dibayar dengan sangat baik dan mengapa perusahaan pemrograman memberikan banyak fasilitas untuk karyawan mereka. Idenya adalah bahwa ada permintaan yang sangat besar untuk programmer yang baik, karena alasan di atas dan itulah sebabnya perusahaan membayar sangat banyak untuk mendapatkannya.

Apakah Anda setuju dengan pernyataan ini? Apakah Anda tahu fakta objektif yang dapat mendukungnya?

Sunting: Pertanyaannya tidak ada hubungannya dengan pengalaman; jika Anda berbicara tentang seorang programmer hebat dengan pengalaman 1 tahun maka ia harus 10 kali lebih produktif daripada programmer biasa-biasa saja dengan pengalaman 1 tahun. Saya setuju bahwa dari pengalaman tertentu bertahun-tahun dan seterusnya, hal-hal mulai menghilang tetapi itu bukan tujuan dari pertanyaan.

Tinjauan dan analisis penelitian yang cukup menyeluruh tentang perbedaan produktivitas disediakan dalam dua artikel yang ditulis oleh Steve McConnell :

• Variasi Produktivitas Diantara Pengembang dan Tim Perangkat Lunak: Asal Usul "10x"

• Asal-usul 10X - Bagaimana Valid adalah Penelitian yang Mendasari?

Artikel pertama ( Variasi produktivitas ... ) menyatakan:

... Studi asli yang menemukan variasi besar dalam produktivitas pemrograman individu dilakukan pada akhir 1960-an oleh Sackman, Erikson, dan Grant (1968). Mereka mempelajari programmer profesional dengan pengalaman rata-rata 7 tahun dan menemukan bahwa rasio waktu pengkodean awal antara programmer terbaik dan terburuk adalah sekitar 20 banding 1; rasio waktu debug lebih dari 25 banding 1; dari ukuran program 5 hingga 1; dan kecepatan eksekusi program sekitar 10 hingga 1. Mereka tidak menemukan hubungan antara jumlah pengalaman programmer dan kualitas kode atau produktivitas.

Pemeriksaan terperinci dari temuan Sackman, Erickson, dan Grant menunjukkan beberapa kelemahan dalam metodologi mereka ... Namun, bahkan setelah memperhitungkan kekurangannya, data mereka masih menunjukkan perbedaan lebih dari 10 kali lipat antara programmer terbaik dan terburuk.

Pada tahun-tahun sejak penelitian awal, temuan umum bahwa "Ada perbedaan urutan-besarnya antara programmer" telah dikonfirmasi oleh banyak studi lain dari programmer profesional (Curtis 1981, Mills 1983, DeMarco dan Lister 1985, Curtis et al. 1986 , Kartu 1987, Boehm dan Papaccio 1988, Valett dan McGarry 1989, Boehm et al 2000) ...

^{Artikel ini juga memiliki catatan menarik:}

^{Tingkat variasi ini tidak unik untuk perangkat lunak. Sebuah studi oleh Norm Augustine menemukan bahwa dalam berbagai profesi - penulisan, sepak bola, penemuan, pekerjaan polisi, dan pekerjaan lain - 20 persen orang menghasilkan sekitar 50 persen output, apakah outputnya touchdown, paten , kasus yang diselesaikan, atau perangkat lunak (Augustine 1979).}

Artikel kedua ( ... Bagaimana Valid adalah Penelitian yang Mendasari? ) Telah ditulis terutama untuk membahas tinjauan kritis yang pertama oleh Laurent Bossavit :

• kritik asli dalam bahasa Prancis: Cerita Rakyat ou fait scientifique, komentar les différencier
• Terjemahan bahasa Inggris: Fakta dan cerita rakyat dalam rekayasa perangkat lunak .

Dalam artikel kedua, di bagian A Deeper Dive Ke dalam Penelitian yang Mendukung "10x" McConnell memeriksa kembali secara lebih rinci referensi yang digunakan dalam artikel pertama dan menyimpulkan:

... Ketika saya meninjau kembali kutipan-kutipan ini sekali lagi dalam menulis artikel ini, saya menyimpulkan lagi bahwa mereka mendukung temuan umum bahwa terdapat 10x perbedaan produktivitas di antara programmer. Studi telah secara kolektif melibatkan ratusan programmer profesional di seluruh spektrum kegiatan pemrograman.

... badan penelitian yang mendukung klaim 10x sama kuatnya dengan penelitian apa pun yang telah dilakukan dalam rekayasa perangkat lunak. Studi yang mendukung klaim 10x secara tunggal tidak tunduk pada batasan metodologis yang dijelaskan pada Gambar 1, karena mereka mempelajari variabilitas individu itu sendiri (yaitu, hanya sisi kiri gambar). Bossavit tidak mengutip bahkan satu studi - cacat atau sebaliknya - yang bertentangan dengan klaim 10x, dan saya belum melihat studi seperti itu juga. Fakta bahwa tidak ada penelitian yang menghasilkan temuan yang bertentangan dengan klaim 10x bahkan memberikan kepercayaan lebih pada klaim 10x. Ketika saya mempertimbangkan jumlah studi yang telah dilakukan, secara agregat saya menemukan penelitian tidak hanya sugestif, tetapi konklusif - yang jarang terjadi dalam penelitian rekayasa perangkat lunak.

Demi kelengkapan, daftar referensi yang digunakan dalam variasi Produktivitas ... juga dikutip di bawah ini:

Referensi

Augustine, NR 1979. "Hukum Agustinus dan Program Pengembangan Sistem Utama." Tinjauan Manajemen Sistem Pertahanan: 50-76.

Boehm, Barry W., dan Philip N. Papaccio. 1988. "Memahami dan Mengontrol Biaya Perangkat Lunak." Transaksi IEEE pada Rekayasa Perangkat Lunak SE-14, no. 10 (Oktober): 1462-77.

Boehm, Barry, et al, 2000. Estimasi Biaya Perangkat Lunak dengan Cocomo II, Boston, Mass .: Addison Wesley, 2000.

Boehm, Barry W., TE Gray, dan T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." Transaksi IEEE pada Rekayasa Perangkat Lunak SE-10, no. 3 (Mei): 290-303. Juga di Jones 1986b.

Card, David N. 1987. "Program Evaluasi Teknologi Perangkat Lunak." Teknologi Informasi dan Perangkat Lunak 29, no. 6 (Juli / Agustus): 291-300.

Curtis, Bill. 1981. "Membuktikan Variabilitas Programmer." Prosiding IEEE 69, no. 7: 846.

Curtis, Bill, dkk. 1986. "Psikologi Perangkat Lunak: Perlunya Program Antar-disiplin." Prosiding IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, dan Timothy Lister. 1985. "Kinerja Programmer dan Efek dari Tempat Kerja." Prosiding Konferensi Internasional ke-8 tentang Rekayasa Perangkat Lunak. Washington, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Proyek dan Tim Produktif, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Produktivitas Perangkat Lunak. Boston, Mass .: Little, Brown.

Sackman, H., WJ Erikson, dan EE Grant. 1968. "Studi Eksperimental Eksperimental Membandingkan Kinerja Pemrograman Online dan Offline." Komunikasi ACM 11, no. 1 (Januari): 3-11.

Valett, J., dan FE McGarry. 1989. "Ringkasan Pengalaman Pengukuran Perangkat Lunak di Laboratorium Rekayasa Perangkat Lunak." Jurnal Sistem dan Perangkat Lunak 9, no. 2 (Februari): 137-48.

Weinberg, Gerald M., dan Edward L. Schulman. 1974. "Tujuan dan Kinerja dalam Pemrograman Komputer." Faktor Manusia 16, no. 1 (Februari): 70-77.

Seorang programmer yang benar-benar mengerikan dapat memiliki produktivitas di bawah nol (bug yang mereka perkenalkan membutuhkan waktu lebih lama untuk diperbaiki daripada yang diperlukan untuk melakukan semua pekerjaan mereka untuk mereka).

Dan seorang programmer yang benar-benar hebat dapat melakukan hal-hal yang tidak akan pernah dapat dicapai oleh programmer miskin dan rata-rata , terlepas dari berapa banyak waktu yang Anda berikan kepada mereka.

Jadi untuk alasan ini, sulit untuk berbicara tentang "10x sebagai produktif" atau "100x sebagai produktif".

Yang perlu diingat, bahwa sebagian besar pengusaha pemrogram tidak membutuhkan mereka untuk melakukan tugas-tugas sulit yang tidak bisa dikelola oleh pemrogram rata-rata. Sebagian besar kode yang ditulis adalah situs web, lini aplikasi bisnis, aplikasi intranet, dll. Sebagian besar tidak terlalu sulit. Programmer yang produktif di lingkungan itu adalah orang yang paling baik dalam memahami dan mengimplementasikan kebutuhan pengguna, bukan orang yang dapat menulis kode paling pintar.

Memang, sebagian besar pengusaha pemrogram akan lebih baik dengan programmer yang baik daripada yang hebat, karena yang hebat hanya akan bosan dan pergi. Harus menemukan kecocokan yang baik antara programmer dan pekerjaan.

Fakta dan Kekeliruan status Rekayasa Perangkat Lunak (Fakta 2, tersedia dalam pratinjau amazon):

Programmer terbaik hingga 28 kali lebih baik daripada programmer terburuk, menurut penelitian "perbedaan individu". Mengingat bahwa gaji mereka tidak pernah sepadan, mereka adalah tawaran terbesar di bidang perangkat lunak.

(lihat daftar sumber di sana untuk penelitian)

Tentu saja, jika Anda membandingkan produktivitas non-programmer (atau programmer yang sangat buruk) dengan yang baik (dalam hal pengalaman dan pengetahuan), perbedaannya bisa sangat besar ( n/0 == infinityuntuk setiap positif n), tetapi tidak adil atau perbandingan yang masuk akal.

Gaji Anda mungkin tergantung pada beberapa faktor (dalam urutan acak):

• Teknologi yang digunakan
• Negara / negara tempat Anda bekerja
• Kekayaan perusahaan
• Jenis bisnis perusahaan
• Jumlah pengembang di perusahaan
• Berapa lama Anda bekerja di perusahaan
• Kantor politik

bersama dengan pribadi Anda ...

• produktifitas
• pengetahuan dan pengalaman
• keterlibatan dalam bisnis perusahaan (untuk pemula)
• keterampilan negosiasi
• daya tarik dan keterampilan seksual, lol (well, kecerdasan itu seksi)

Jawaban saya adalah "ya, tapi hati-hati bagaimana Anda menggunakan metrik itu".

Seorang programmer yang, harus kita katakan, berfungsi secara optimal, adalah orang yang menciptakan fungsionalitas dan menyebabkan lebih sedikit kesalahan yang perlu diperbaiki daripada yang kinerjanya lebih rendah. Saya tidak akan merasa sulit untuk percaya bahwa orang-orang ini dapat tampil di 10X produktifitas orang lain, terutama ketika Anda mempertimbangkan bahwa satu pilihan baik atau buruk yang dibuat dalam satu jam dapat dengan mudah memiliki 10 jam dampak, dan programmer membuat banyak pilihan seperti itu kebanyakan hari.

Tapi...

Anda harus berhati-hati dalam mengukur hal ini. Saya benar-benar tidak percaya sebagian besar pengukuran pada produktivitas karena saya telah melihat kasus tanpa akhir di mana hampir setiap metrik yang dikenal gagal untuk mempertimbangkan sesuatu yang saya anggap penting untuk produktivitas tim. Jadi saya umumnya membenci angka sulit seperti itu untuk "produktivitas". Inilah beberapa contoh:

• Lines of code (LOC) - metrik yang umumnya dibenci, karena programmer yang ceroboh dapat menghasilkan banyak baris kode yang mengerikan, verbose, tidak efisien, sulit untuk di-debug sementara programmer yang baik menciptakan beberapa baris kode yang elegan, mudah diperbaiki, jarang patah kode lebih banyak waktu, tetapi yang secara keseluruhan merupakan pilihan yang lebih baik.
• Bug yang dihasilkan dan / atau waktu untuk diperbaiki - semua orang akan menghasilkan beberapa bug, dan seringkali bug yang paling mahal dihasilkan oleh serangkaian keputusan buruk yang mana pembuat masalah hanya merupakan yang terakhir dalam efek domino. Selain itu, debugger hebat Anda tidak selalu merupakan desainer hebat Anda - Anda membutuhkan keduanya.
• Dengan hampir semua metrik, ada pengembang hebat yang begitu menyebalkan dalam tim, sehingga 1 pengembang "super produktif" akan mengusir 10 pengembang yang pada dasarnya baik dan saya jarang melihat seseorang yang dapat melakukan semuanya dengan baik, jadi kita perlu lebih dari 1 orang di proyek.
• Tidak ada cara untuk dengan mudah memperhitungkan orang-orang hebat yang melihat masalah datang sebelum mereka serius dan menghadangnya, terutama ketika masalahnya adalah kesenjangan dalam suatu proses - CM rusak, bangunan tidak efisien, celah dalam pengujian, cacat keamanan - ini sering terlihat seperti buang-buang waktu sampai Anda menyadari bahwa mereka menyelamatkan Anda dari bencana - tidak ada cara untuk mengukurnya.
• Juga, ada orang-orang yang saya anggap perlu pada tim dengan ukuran tertentu yang saya sebut "pembangun kohesi" - jarang menjadi puncak produktivitas mutlak, mereka biasanya masih di atas 20% dan mereka melakukan pekerjaan yang tak ternilai untuk membantu meningkatkan orang-orang baru, menghubungkan titik-titik dan memastikan bahwa pertanyaan yang tepat ditanyakan dan orang-orang yang tepat disimpan dalam lingkaran, mereka menulis (tanpa diminta!) bagian penting dari dokumentasi yang dirujuk oleh semua orang karena bukan hanya dokumen yang tepat, tetapi itu disatukan dengan cara yang benar. Jika Anda ingin 10 orang bekerja pada efisiensi puncak, Anda benar-benar membutuhkan salah satu dari orang-orang ini dan Anda tidak akan mendapatkannya jika Anda menempatkan 10 pengembang super di sebuah ruangan.

Banyak sistem pengukuran telah mencoba untuk memperhitungkan faktor-faktor ini, tetapi saya belum melihat bahwa ada satu yang memperhitungkan semua masalah ini, jadi saya tidak pernah terlalu terkesan dengan faktor-faktor seperti "pengembang yang baik 10x lebih produktif daripada yang biasa-biasa saja "karena saya harus bertanya-tanya apakah metrik benar-benar menjelaskan semua pekerjaan yang perlu masuk ke produk berkelanjutan yang sukses atau tim sukses yang berkembang.

Jadi peringatan besar saya adalah - apa yang akan Anda lakukan dengan metrik ini? Saya akan menggunakan sesuatu seperti ini untuk menyadari bahwa alat dan bakat yang tepat dapat menyebabkan perbedaan besar dalam bagaimana pekerjaan dilakukan tetapi jika Anda mencoba untuk mengoptimalkan ke tim di mana setiap individu menghasilkan 10X output "khas", Anda pasti akan kasus frustrasi. Lebih baik adalah menemukan cara untuk membuat tim Anda melakukan 2-3X apa yang mereka lakukan sebelumnya dengan bekerja bersama dengan lebih baik.

Dalam bukunya The Leprechauns of Software Engineering , Laurent Bossavit menjelaskan meneliti 10x klaim produktivitas. Dia menemukan bahwa tidak ada nomor suara di belakangnya - klaim telah berubah dari spekulasi menjadi "fakta yang mapan" oleh permainan telepon yang berturut-turut lebih konkret dalam kutipan. Posting blog yang terdiri dari bab tentang klaim 10x, dan termasuk kutipan dan misquotes yang relevan, adalah fakta dan cerita rakyat dalam rekayasa perangkat lunak .

Apa yang dia temukan adalah sesuatu seperti ini: seseorang pada tahun 1968 melakukan penelitian yang membandingkan orang-orang yang memecahkan masalah debugging tertentu, dan menemukan bahwa beberapa dari mereka melakukannya 10x lebih cepat daripada yang lain. Dari sini kita dapat menyimpulkan bahwa beberapa orang 10x lebih baik dalam memecahkan masalah itu , atau kita dapat menyimpulkan bahwa beberapa orang beruntung , atau berbagai hal yang berbeda. Beberapa orang memilih untuk mengutip ini karena (ini semua parafrase) "sebuah penelitian (Sackman et al, 1968) menemukan beberapa programmer bekerja 10x lebih cepat daripada yang lain". Kemudian menjadi "penelitian telah menunjukkan bahwa programmer yang baik 10x lebih baik daripada rata-rata" maka akhirnya "sudah menjadi rahasia umum bahwa produktivitas programmer bervariasi 10x antara individu". Lalu seseorang mengumpulkan semua kutipan ini, salah mengutip satu sumber asli untuk mengatakan "banyak peneliti percaya ...".

Tentu saja, itu tidak akan menjadi permainan telepon jika hanya kebenaran pernyataan yang berubah: pengali menjadi 11 dan lebih juga.

" Pemrogram yang produktif di lingkungan itu adalah orang yang paling baik dalam memahami dan mengimplementasikan kebutuhan pengguna, bukan orang yang dapat menulis kode paling pintar. " (Dari Carson63000 jawaban)

Poin kunci itu ditambah dengan bethlakshmiPoin membuat poin besar. Seorang pengembang hebat bisa menjadi hebat dalam satu irisan realitasnya, tetapi segera hancur begitu dunia berubah. Mampu mengikuti kebutuhan bisnis jauh lebih penting daripada yang lain. Pada akhirnya, kecuali bisnis Anda adalah teknologi, bisnis itu tidak peduli dengan teknologi; mereka butuh solusi. Jadi menjadi hebat dengan pola desain tidak berarti jongkok untuk pengguna akhir yang hanya membutuhkan data dump untuk ditampilkan di halaman web. Saya telah melihat pengembang yang biasa-biasa saja mendapatkan pekerjaan dengan melayani bisnis yang mendukung mereka sementara pengembang yang hebat bosan dan berjalan pergi mencari tantangan yang tidak pernah berakhir. Bergantung pada organisasi dan proyek Anda, mungkin untuk memberi makan pengembang-pengembang yang kelaparan ini tetapi kemungkinan, akan ada titik waktu ketika Anda tidak t membutuhkan kekuatan pemrosesan sebesar itu. Pengembang ini tidak suka hanya duduk diam seperti prosesor. Mereka akan mati dan reboot di tempat lain.

Terakhir, saya akan mengatakan tidak apa-apa untuk mengetahui siapa pemain "kunci" Anda, tetapi "tim" pengembangan masih merupakan tim. Untuk mengulangi bethlakshmi, " apa yang akan Anda lakukan dengan metrik ini?"Jika Anda membutuhkan tim yang berperilaku seperti tim, saya tidak akan fokus pada metrik seperti ini. Saya akan menyadari bahwa bahkan pemain terkecil pun masih merupakan bagian penting dari tim. Bahkan pada 60% lebih sedikit dari produktivitas kunci Anda pemain, bahwa satu pemain mungkin memberi tim Anda sesuatu yang dibutuhkan. Cari tahu apa itu dan cobalah untuk melipatgandakannya. Jangan membakar pemain kunci Anda dengan menganggap ia harus memimpin tim, menemukan cara untuk melipatgandakan outputnya juga, dengan mencemari pemain lain dengan kehebatan itu. Ini membutuhkan sedikit kreativitas, bukan hanya angka. Pada akhirnya, Anda mungkin belajar bahwa apa yang membuat seorang programmer yang baik adalah bahkan bukan programmer itu, bisa juga rekan-rekannya, peluangnya di tempat kerja atau bahkan bisa jadi kamu.