Joel on Software   Pojok Software Joel

Artikel-artikel "Joel on Software" lain dalam bahasa Indonesia

Artikel-artikel "Joel on Software" lain dalam bahasa Inggris

Email pengarang (hanya dalam bahasa Inggris)

Pernah mendengar SEMA? Itu adalah sebuah sistem yang cukup memadai untuk mengukur seberapa bagus sebuah tim software. Tapi tunggu! Jangan mengikuti link tersebut! Anda akan membutuhkan waktu enam tahun untuk memahaminya. Jadi saya memperkenalkan versi saya sendiri, serangkaian test sederhana, yang tidak ilmiah, untuk mengetahui kualitas tim software. Tetapi hal terbaik adalah itu hanya membutuhkan waktu 3 menit. Waktu yang dapat Anda hemat cukup bagi Anda untuk pergi ke sekolah kedokteran.

Hal yang menarik dari The Joel Test adalah Anda bisa dengan cepat menjawab ya atau tidak untuk masing-masing pertanyaan. Anda tidak perlu bersusah payah menghitung berapa jumlah baris code per hari atau berapa rata-rata jumlah bug per inflection point. Berikan nilai 1 untuk setiap jawabah “ya”. Yang pasti, The Joel Test tidak ditujukan bagi Anda yang ingin memastikan software untuk reaktor nuklir Anda aman.

Skor 12 adalah sempurna, 11 masih bisa ditoleransi, tetapi 10 kebawah menunjukkan Anda mempunyai masalah yang serius. Kenyataannya adalah kebanyakan perusahaan software hanya mendapat skor 2 atau 3, dan mereka betul-betul membutuhkan pertolongan karena perusahaan seperti Microsoft selalu mempertahankan skor 12 sepanjang waktu.

Memang betul, apa yang disebutkan diatas bukan menjadi faktor yang menjamin sukses atau gagal. Jika Anda mempunyai sebuah tim software yang luar biasa bagus mengerjakan suatu produk yang tidak diinginkan orang, bagaimanapun, tidak akan ada yang menginginkan itu. Sebaliknya, bisa jadi ada sebuah tim “koboi” yang tidak melakukan satupun dari yang disebutkan diatas tetapi tetap mengerjakan software yang merubah dunia. Tetapi yang ingin ditekankan, jika Anda mengerjakan 12 hal diatas dengan benar, Anda akan mempunyai sebuah tim yang disiplin dan konsisten.

1. Apakah Anda menggunakan source control?
Saya sudah menggunakan paket source control komersial, dan saya juga sudah menggunakan CVS, yang gratis, dan saya ingin memberitahu bahwa CVS sudah cukup bagus. Jika Anda tidak mempunyai source control, Anda akan kesulitan mengatur bagaimana programmer bisa bekerja bersama. Programmer tidak bisa mengatahui apa yang dikerjakan orang lain. Kesalahan sangat mudah terjadi. Hal terbaik dari sistem source control ialah bahwa source code tidak tertinggal di hard drive masing-masing programmer -- Saya tidak pernah mendengar kalau ada proyek yang menggunakan source control kehilangan sejumlah besar code.

2. Bisakah Anda membuat build dalam satu langkah?
Maksud saya begini: berapa banyak langkah yang harus dilakukan untuk membuat sebuah build yang siap kirim dari status source terakhir sebelumnya? Tim yang bagus mempunyai sebuah script yang akan melakukan semua pengecekan dari awal, mem-build setiap baris code, membuat EXE untuk berbagai versi, bahasa, dan kombinasi #ifdef, membuat paket instalasi yang siap dipindahkan ke media CDROM. Demikian juga layout-nya, download file di website dan sebagainya.

Kalau prosesnya lebih dari satu langkah, itu awal dari kesalahan. Dan semakin mendekati saat pengiriman, Anda akan sangat sibuk memperbaiki bug “terakhir”, membuat final EXE dan seterusnya. Jika Anda memerlukan 20 langkah untuk meng-compile code, membuat build instalasi, dan seterusnya., Anda akan menjadi gila dan sangat mungkin membuat sebuah kesalahan yang konyol.

Untuk alasan tersebut, perusahaan tempat saya bekerja terakhir mengganti WISE dengan InstallShield: kami menuntut proses instalasi bisa berjalan melalui sebuah script, secara otomatis, lewat tengah malam, menggunakan NT scheduler, WISE tidak bisa memenuhi kebutuhan itu sehingga kami terpaksa membuangnya. (Orang-orang di WISE mencoba meyakinkan saya bahwa versi terakhir mereka akan bisa mendukung apa yang saya inginkan)

3. Apakah Anda membuat build harian?

Ketika Anda menggunakan source control, kadang seorang programmer tanpa sengaja melakukan sesuatu dan merusak build. Sebagai contoh, mereka telah menambahkan source file yang baru dan segala sesuatu ter-compile dengan baik pada mesin mereka, tetapi tanpa disadari mereka lupa menambahkan source file ke code repository. Mereka begitu saja mematikan mesin mereka dan pulang dengan happy. Tetapi orang lain mendadak tidak bisa bekerja lagi, sehingga terpaksa pulang juga, dengan perasaan tidak happy.

Merusak build adalah sedemikian buruk (juga sedemikian sering), yang harus dipastikan adalah tidak boleh ada kerusakan yang tidak diketahui. Pada tim yang besar, sebuah cara yang baik untuk memastikan kerusakan segera dibetulkan adalah dengan membuat build harian pada siang hari, misalkan, pada jam makan siang. Setiap orang harus menambahkan sebanyak mungkin checkin sebelum makan siang. Ketika mereka kembali dari makan siang, build sudah selesai dilakukan. Kalau bekerja dengan baik, bagus! Sehingga setiap orang bisa meneruskan bekerja menggunakan source versi terakhir. Seandainya build gagal, Anda memperbaiki itu, tetapi orang lain bisa tetap meneruskan kerja menggunakan source sebelumnya yang belum di-build.

Kami di tim Excel mempunyai peraturan siapa yang merusak build, sebagai “hukuman”, diharuskan menjaga proses build sampai orang lain yang merusak selanjutnya menggantikannya. Ini bisa menjadi salah satu insentif yang baik supaya tidak merusak build, juga cara yang baik untuk merotasi setiap orang agar memahami bagaimana proses build bekerja.

Bacaan artikel saya mengenai hal tersebut di Daily Builds are Your Friend.

4. Apakah Anda mempunyai bug database?
Saya tidak peduli apa yang Anda bilang. Jika Anda mengembangkan code, bahkan pada tim nomor satu, tanpa sebuah database yang me-listing semua bug yang telah ditemukan, anda hanya akan menghasilkan code yang bermutu rendah. Banyak programmer berpikir mereka bisa mengingat daftar bug di kepala mereka. Omong kosong. Saya tidak bisa mengingat lebih dari dua atau tiga bug sekaligus, dan pada keesokan paginya, atau pada saat dikejar jadwal pengiriman, mereka pasti terlupakan. Tidak bisa tidak Anda harus mencatat semua bug secara terorganisir.

Bug database bisa dibuat rumit atau sederhana. Sebuah bug database minimal harus mencakup informasi berikut :

• langkah lengkap untuk memunculkan kembali bug dimaksud

• hasil yang diharapkan (kondisi tanpa bug)

• kenyataan yang timbul

• siapa yang ditunjuk untuk menanganinya

• apakah sudah fix atau belum

Jika Anda tidak melakukan pencatatan bug dikarenakan software bug tracking yang terlalu rumit, maka buatlah sebuah tabel sederhana yang terdiri dari 5 kolom di atas dan mulailah menggunakannya.

Ingin tahu lebih banyak mengenai bug tracking, baca Painless Bug Tracking.

5. Apakah Anda memperbaiki bug sebelum menulis code baru?
Microsoft Word for Windows versi-versi awal bisa disebut proyek “maret kelabu”. Itu proyek abadi, dan meleset terus. Seluruh tim telah bekerja keterlaluan lamanya, dan proyek tersebut masih saja ditunda lagi, lagi, lagi dan mengalami tekanan yang tidak dapat dibayangkan. Ketika akhirnya produk tersebut akhirnya bisa diluncurkan, setelah mengalami keterlambatan bertahun-tahun, Microsoft mengirim keseluruhan tim ke Cancun untuk liburan.

Apa yang mereka pelajari adalah bahwa project manager sedemikian ketat memaksakan “jadwal” sehingga programmers terpaksa mengikutinya dalam proses coding, menghasilkan code yang sedemikian jeleknya karena tidak ada fase perbaikan bug dalam jadwal resminya. Tidak ada usaha untuk menekan jumlah bug. Ada cerita bahwa seorang programmer yang menulis code untuk menghitung tinggi sebaris text, sengaja menuliskan “return 12”, dan menunggu bug report kalau fungsi yang dia tuliskan tidak selalu benar. Jadwal disatu sisi adalah sebuah checklist dari fitur-fitur yang akan menjadi bug. Ada istilah yang menyebutkan sebagai “metode cacat tak terhingga”.

Untuk memperbaiki masalah ini, Microsoft mengadopsi yang disebut “metode tanpa cacat”. Banyak programmer merasa tidak biasa karena kedengarannya seperti manajemen berpikir mereka bisa meniadakan bug sama sekali. Sebenarnya, istilah “tanpa cacat” berarti pada setiap waktu yang diberikan, prioritas tertinggi adalah meng-eliminasi bug sebelum menulis code baru. Saya akan menjelaskan mengapa.

Pada umumnya, semakin lama Anda menunda memperbaiki bug, maka akan semakin besar pengorbanan (dalam hal waktu dan uang) yang diperlukan untuk memperbaikinya.

Contoh, jika Anda hanya salah ketik sesuatu atau syntax error yang dikenali oleh compiler, perbaikan bisa dilakukan dengan sangat mudah.

Ketika muncul sebuah bug dalam code Anda ketika pertama kali dijalankan, Anda bisa memperbaikinya hampir tidak memerlukan waktu karena semua code masih segar dalam ingatan Anda.

Jika Anda menemukan bug dalam code yang ditulis beberapa hari yang lalu, akan memerlukan beberapa waktu untuk menelusuri. Tapi ketika Anda membaca ulang code yang Anda tulis, Anda akan mengingat semuanya dan bug bisa diperbaiki dalam waktu yang singkat.

Tetapi jika Anda menemukan bug dalam code yang sudah ditulis beberapa bulan yang lalu, mungkin Anda sudah lupa banyak hal mengenai code itu, dengan demikian semakin sulit juga untuk memperbaikinya. Pada saat Anda harus memperbaiki kesalahan code orang lain, pada waktu yang sama mungkin mereka sedang liburan di Aruba, pada saat seperti ini, memperbaiki bug seperti menggali ilmu pengetahuan baru. Lambat, mengikuti metode tertentu, dan Anda tidak akan pernah tahu kapan selesai.

Dan jika Anda menemukan bug pada code yang sudah dirilis, Anda mungkin akan memerlukan pengorbanan yang luar biasa untuk memperbaikinya.

Itulah alasan mengapa harus segera memperbaiki bug: karena memerlukan waktu yang lebih sedikit. Alasan lain adalah kenyataan bahwa lebih mudah memprediksi waktu yang diperlukan untuk menuliskan code baru daripada memperbaiki bug. Contoh, jika saya meminta Anda untuk memprediksi waktu yang diperlukan untuk menuliskan code yang fungsinya mensortir daftar, Anda bisa memberikan perkiraan yang lumayan mendekati. Tetapi jika saya meminta Anda untuk memprediksi waktu yang dibutuhkan untuk memperbaiki bug dimana code Anda tidak berjalan sebagaimana mestinya di mesin yang terinstall Internet Explorer 5.5, Anda bahkan tidak bisa menebak karena Anda (secara definitif) tidak mengetahui apa yang menyebabkan bug tersebut. Bisa jadi Anda menghabiskan waktu 3 hari untuk menelusurinya, atau hanya 2 menit.

Berarti jika pekerjaan yang Anda jadwalkan masih mengandung banyak bug yang harus dibereskan, jadwal Anda sulit dipercaya. Tetapi jika Anda telah memperbaiki semua bug yang sudah dikenal, selanjutnya hanya menulis code baru, jadwal Anda akan lebih akurat.

Hal positif lain mengupayakan aplikasi tanpa bug adalah Anda bisa merespons lebih cepat terhadap situasi kompetisi. Beberapa programmer bertanggung jawab atas hal ini supaya Anda selalu mempunyai produk yang siap dikirim setiap saat. Katakan suatu waktu kompetitor Anda memperkenalkan fitur baru yang dahsyat yang bisa mencuri pelanggan Anda, dengan cepat pula Anda bisa menambahkan fitur itu dan segera diluncurkan, tanpa harus berkutat dengan sejumlah bug.

6. Apakah Anda mempunyai jadwal yang terkini?
Apa yang membuat kita harus mempunyai jadwal? Jika code Anda penting bagi orang bisnis, ada banyak alasan mengapa orang bisnis perlu tahu kapan suatu code diselesaikan. Programmers biasanya ogah-ogahan membuat jadwal. "Itu akan tersedia kalau (proyeknya) sudah selesai!" begitu mereka beralasan kepada orang bisnis.

Tetapi kejadiannya bukan begitu. Ada banyak rencana dan keputusan yang harus diambil mendahului waktu selesainya code: demo, pameran, iklan dll. Dan semua ini hanya akan berjalan dengan baik apabila mempunyai jadwal yang up to date.

Hal lain mengenai pentingnya mempunyai jadwal adalah itu akan memaksa Anda untuk memutuskan fitur apa yang harus dikerjakan, sementara fitur yang kurang penting harus ditunda dulu daripada meleset terus, keadaan mana yang disebut featuritis (mis. scope creep).

Menyusun jadwal tidak terlalu susah-susah amat. Baca artikel saya Painless Software Schedules, yang mengajarkan bagaimana membuat jadwal yang bagus dengan mudah.

7. Apakah Anda mempunyai spec?
Menuliskan spesifikasi sama seperti membersihkan gigi dengan benang: semua orang setuju kalau itu bagus, tetapi tidak ada yang mengerjakannya.

Saya tidak yakin betul mengapa hal ini terjadi, bisa jadi karena kebanyakan programmer benci menulis dokumen. Akibatnya, ketika tim programmer terbentur masalah, mereka lebih suka menuliskan solusinya dalam bentuk code, bukan dokumen. Mereka lebih suka menyelam kedalam dan menulis code daripada merumuskan spesifikasinya terlebih dahulu.

Pada tahap design, ketika Anda menemukan masalah, Anda bisa memperbaiki dengan mudah dengan hanya merubah beberapa baris tulisan. Sementara kalau sudah berbentuk code, biaya untuk memperbaiki masalah meningkat secara dramastis, baik secara emosional (orang tidak suka membuang code) dan waktu, jadi ada hambatan untuk sungguh-sungguh memperbaiki masalah. Software yang dibangun tanpa spesifikasi biasanya mempunyai design yang buruk dan jadwalnya selalu meleset tak terkendali. Hal tersebutlah kelihatannya yang terjadi di Netscape, dimana mereka mempunyai 4 versi awal yang tumbuh dengan sangat baik sampai ketika manajemen secara bodoh memutuskan membuang semua code dan memulai dari awal lagi. Lagi-lagi mereka membuat kesalahan terhadap Mozilla, mereka menciptakan monster yang sedemikian rupa tidak terkontrol sehingga setelah berahun-tahun baru sampai ketahap alpha.

Cara saya mengatasi hal tersebut adalah mengirim mereka untuk mengambil kursus menulis intensif. Solusi lain adalah mempekerjakan seorang program manager yang bertanggung jawab menulis spesifikasi. Atau Anda juga bisa menerapkan peraturan yang sederhana “tidak ada code tanpa spesifikasi”.

Pelajari mengenai menulis spesifikasi dengan membaca tulisan saya 4-part series.

8. Apakah programmer mendapat suasana kerja yang tenang?
Produkivitas akan meningkat dengan memberikan ruang yang cukup, dan tenang bagi pekerja. Buku manajemen software klasik Peopleware menjelaskan cukup banyak mengenai benefit ini.

Masalahnya, kita semua mengetahui bahwa pekerja demikian bekerja paling baik dengan masuk kedalam “flow”, atau dikenal juga dengan “sedang mood” dimana mereka bisa berkonsentrasi penuh pada pekerjaan mereka dan berbebas dari lingkungan sekitar. Mereka bisa lupa waktu dan menghasilkan yang terbaik melalui konsentrasi, yaitu dimana mereka bisa bekerja dengan produktivitas penuh. Penulis, programmer, ilmuwan, bahkan pemain basket bisa bercerita banyak mengenai apa yang disebut “sedang mood”

Kesulitannya, mencapai “mood” demikian tidak mudah. Ketika Anda mencoba mengukurnya, rata-rata dibutuhkan waktu 15 menit untuk mencapai tahap bekerja dengan produktivitas maksimum. Tetapi kadang-kadang, jika Anda sedang capek, atau sudah mengerjakan banyak pekerjaan kreatif hari itu, Anda tidak bisa mendapatkan mood itu dan sepanjang hari Anda hanya akan membaca web, atau bermain Tetris.

Kesulitan lain adalah ternyata begitu mudahnya keluar dari mood. Suara berisik, dering telepon, keluar makan siang, menyetir 5 menit ke Starbucks untuk membeli kopi, dan interupsi dari rekan kerja --- terutama interupsi dari rekan kerja – semuanya bisa membawa Anda keluar dari mood. Jika seorang rekan kerja menanyakan sebuah pertanyaan, 1 menit interupsi, Anda perlu waktu sampai setengah jam lagi untuk produktif kembali, produktivitas Anda sangat payah. Apalagi jika Anda berada di ruangan yang berisik, dimana disekitarnya orang pemasaran berteriak ditelepon, pekerja diinterupsi berkali-kali, tidak akan bisa mood kembali.

Bagi programmer, jelas-jelas hal tersebut cukup berat. Produkivitas tergantung kepada kemampuan mengingat sekian banyak detil bersamaan. Gangguan apa saja bisa menyebabkan detil tersebut rusak. Ketika meneruskan kerja, Anda tidak bisa mengingat semua detil (seperti nama variabel lokal yang Anda pakai, atau sedang memikirkan algoritma pencarian) dan Anda harus pelan-pelan mengingat-ingat kembali, secara bertahap sampai kembali ke kecepatan sebelumnya.

Aljabar sederhananya, jika kita menginterupsi seoarng programmer, bahkan hanya 1 menit saja, sebenarnya kita membuang 15 menit produktivitas. Sebagai contoh, tempatkan dua orang programmer, Jeff dan Mutt dalam partisi terbuka bersebelah-sebelahan. Mutt tidak bisa mengingat versi Unicode dari strcpy function. Dia bisa mencarinya sendiri, yang memerlukan waktu 30 detik, atau dia bisa bertanya ke Jeff, yang memerlukan waktu 15 detik. Karena dia duduk bersebelahan dengan Jeff, dia bertanya ke Jeff. Jeff terganggu dan kehilangan 15 menit produktivitas untuk menyelamatkan Mutt 15 detik.

Sekarang pindahkan mereka ke ruangan kantor yang terpisah dengan dinding dan pintu. Sekarang ketika Mutt tidak bisa mengingat nama variabel fungsi tadi, dia bisa mencari sendiri yang akan memakan waktu 30 detik. Atau dia juga bisa bertanya kepada Jeff, tetapi butuh waktu 45 detik termasuk berdiri selama itu. Jadi Mutt memutuskan mencari sendiri. Mutt kehilangan 30 detik produktivitas, tetapi menyelamatkan 15 menit untuk Jeff. Ahhh!

9. Apakah Anda menggunakan tools terbaik?
Menulis code dalam bahasa yang terkompilasi adalah hal terakhir yang tidak bisa dilakukan secara instan menggunakan komputer rumah. Jika proses kompilasi menghabiskan waktu lebih dari beberapa detik, mendapatkan komputer tercepat keluaran terakhir akan menyelamatkan waktu Anda. Jika kompilasi mencapai 15 detik, programmer akan merasa bosan menunggu dan mungkin merasa akan lebih baik membaca The Onion, yang akan menghabiskan berjam-jam waktu produktif.

Men-debug kode GUI dengan satu monitor akan sangat menyulitkan kalau tidak disebut tidak mungkin. Jika Anda mengerjakan GUI, menggunakaan dua monitor akan membuat pekerjaan jauh lebih mudah.

Kebanyakan programmer sekali waktu harus meng-edit bitmap icon untuk toolbar, dan kebanyakan tidak mempunyai editor bitmap yang bagus. Microsoft Paint bukan aplikasi nyaman untuk tujuan itu, tetapi kebanyakan programmer terpaksa harus menggunakannya.

Pada pekerjaan saya yang terakhir, system administrator mengirimi saya peringatan kalau saya menggunakan lebih dari 220 megabyte ruang harddrive di server. Merujuk pada harga harddrive saat ini, biaya untuk ruang sebesar itu mungkin lebih murah dari kertas toilet yang saya pakai. Menghabiskan waktu 10 menit untuk membersihkan directory saya justru penghamburan produktivitas.

Tim development yang jagoan tidak menghambat programmernya. Sedikit saja frustasi yang disebabkan perangkat yang kurang powerful akan menyebabkan programmer menggerutu dan tidak senang. Programmer demikian adalah programmer yang tidak produktif.

Untuk mengatasi hal ini... programmer perlu disuap dengan produk muktahir keluaran terakhir. Ini cara jauh lebih murah supaya mereka benar-benar bekerja untuk Anda daripada membayar gaji yang kompetitif !

10. Apakah Anda mempunyai tester?
Jika tim Anda tidak mempunyai tester, paling tidak untuk dua atau tiga programmer, Anda mungkin akan menghasilkan produk yang mengandung banyak bug, atau Anda terpaksa harus memboroskan uang $100/jam kepada programmer untuk pekerjaan senilai $30/jam kalau dikerjakan tester. Mengabaikan peran tester adalah kerugian besar bagi ekonomi yang sayangnya banyak orang tidak menyadari hal itu.

Baca Top Five (Wrong) Reasons You Don't Have Testers, sebuah artikel yang saya tulis mengenai hal ini.

11. Pada saat wawancara, apakah Anda meminta kandidat baru menuliskan code?
Apakah Anda akan meng-hire seorang pesulap tanpa meminta mereka mempertontonkan beberapa tipuan sulap ? Tentu saja tidak.

Apakah Anda akan memilih perusahaan catering untuk perkawinan Anda tanpa terlebih dahulu mencicipi makanannya? Saya meragukan hal itu (kecuali itu Bibi Marge, dan dia akan membenci anda selamanya jika Anda tidak membiarkannya membuat kue chopped liver-nya yang “terkenal”).

Begitulah, setiap hari programmer di-hire berdasarkan resume mereka karena pewawancara merasa nyaman ngobrol dengan mereka. Atau mereka ditanyakan ("apa perbedaan diantara CreateDialog() and DialogBox()?") yang sebetulnya bisa dicari di dokumentasi. Anda tidak perduli kalau mereka menghapalkan ribuan pertanyaan umum mengenai programming, yang Anda perlukan mereka bisa menghasilkan code. Atau, lebih buruk lagi, mereka ditanyakan “AHA!”: jenis pertanyaan yang kelihatannya mudah kalau Anda tahu jawabannya, tetapi kalau Anda tidak mengetahui jawabannya sebelumnya, maka tidak mungkin bisa dilakukan.

Tolong, jangan seperti itu. Lakukan apapun yang Anda inginkan selama wawancara, tetapi pastikan minta kandidat menuliskan beberapa kode. (Untuk saran lebih lengkap, silakan baca tulisan saya Guerrilla Guide to Interviewing.)

12. Apakah Anda menerapkan hallway usability testing?
Hallway usability test adalah dimana Anda mencegat orang berikutnya yang melewati aula dan memaksa mereka mencoba menggunakan code yang Anda baru tulis. Jika Anda melakukan hal tersebut kepada lima orang, Anda akan belajar bahwa 95% yang disana belajar mengenai masalah usability dalam code Anda.

User interface yang bagus tidak sesulit yang anda pikirkan, dan itu sangat penting jika Anda menghendaki pelanggan Anda menyukai dan membeli produk Anda. Anda bisa membaca buku online mengenai desain UI , perkenalan penting bagi programmer.

Manfaat yang terpenting mengenai user interface adalah jika Anda menunjukkan program Anda kepada sejumlah orang (lima atau enam sudah mencukupi), Anda akan segera menyadari masalah terbesar yang dihadapi mereka. Baca artikel Jakob Nielsen's yang menjelaskan kenapa. Bahkan jika kemampuan desain UI Anda lemah, asal Anda memaksakan diri Anda melakukan hallway usability tests, yang tidak perlu mengeluarkan biaya apa-apa, UI Anda akan jauh, jauh lebih bagus.

Empat cara menggunakan The Joel Test

1. Ukur tingkat organisasi software Anda, dan beritahu saya berapa nilainya, agar saya mempunyai lebih banyak cerita gossip.

2. Jika Anda manager dari tim programming, pakai ini sebagai checklist untuk memastikan tim Anda sudah melakukan yang terbaik. Jika Anda mulai dengan rating 12, Anda bisa melepaskan programmer Anda bekerja sendiri dan full time fokus pada sisi bisnis daripada merecoki mereka.

3. Jika Anda ingin mencoba pekerjaan programming, tanyakan kepada calon majikan Anda berapa rate mereka. Jika terlalu rendah, pastikan Anda akan mempunyai cukup wewenang untuk memperbaikinya. Kalau tidak, Anda akan menjadi frustasi dan tidak produktif.

4. Jika Anda seorang investor dan sedang melakukan due diligence untuk mempertimbangkan nilai dari tim programmer, atau perusahaan software Anda sedang mempertimbangkan bergabung dengan perusahaan lain, cara pengujian ini akan memberikan perspektif yang cepat dan jitu.