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)

Saat The Joel Test pertama kali muncul, salah satu bagian yang paling sering dikomentari oleh pembaca adalah penulisan specs. Nampaknya specs seperti flossing: setiap orang tahu bahwa mereka harus menulis specs, tapi tidak ada yang melakukan.

Kenapa orang tidak mau menulis specs? Orang menyatakan bahwa hal ini karena mereka menghemat waktu dengan melewati fase penulisan specs. Mereka berlaku seolah-olah penulisan spec merupakan suatu kemewahan yang diperuntukan bagi teknisi pesawat luar angkasa NASA, atau orang yang bekerja untuk perusahaan asuransi raksasa dan sudah mapan. Omong kosong. Pertama, kegagalan penulisan spec merupakan resiko tunggal yang terbesar dan tidak perlu yang anda ambil dalam suatu proyek software. Hal ini sama bodohnya seperti merencanakan melewati gurun Mojave hanya membawa pakaian di punggung anda, dan berharap bisa "terbang". Programer dan teknisi software yang menyelami kode tanpa penulisan spec cenderung berpikir bahwa mereka adalah penembak yang hebat, menembak dari bawah pinggangnya. Mereka bukan seperti itu. Mereka sangat tidak produktif. Mereka menulis kode yang buruk dan menghasilkan software yang jelek, dan mereka mencelakakan proyek mereka dengan mengambil resiko besar yang sama sekali tidak perlu.

Saya percaya bahwa pada proyek yang sulit mana pun (lebih dari 1 minggu coding atau lebih dari 1 programmer), jika anda tidak memiliki spec, anda akan selalu menghabiskan lebih banyak waktu dan menghasilkan kualitas kode yang lebih rendah. Ini penjelasannya.

Fungsi yang terpenting dari sebuah spec adalah untuk mendesain program tersebut. Bahkan jika anda sendiri yang menulis kode, dan anda menulis spec semata-mata untuk keuntungan diri anda sendiri, langkah penulisan spec -- menggambarkan bagaimana program akan bekerja secara detail -- akan memaksa anda untuk benar-benar mendesain program tersebut.

Mari kita mengunjungi dua programer khayalan di dua perusahaan. Speedy, di Hasty Bananas Software, tidak pernah menulis specs. "Specs? Kami tidak memerlukan specs!" Pada saat yang sama, Mr.Rogers, dari The Well-Tempered Software Company, menolak untuk menulis kode sampai spec sudah lengkap ditulis. Ini hanya merupakan dua dari banyak teman khayalan saya.

Speedy dan Mr. Rogers mempunyai satu kesamaan: mereka berdua bertanggung jawab atas kompatibilitas ke belakang untuk versi 2.0 produk mereka masing-masing.

Speedy memutuskan bahwa cara terbaik untuk menyediakan kompatibilitas ke belakang adalah dengan menulis sebuah pengubah yang hanya mengubah file versi 1.0 ke file versi 2.0. Dia mulai bekerja. Ketik, ketik, ketik. Klik di sini, klik di sana. Hard disk berputar. Debu berterbangan. Setelah hampir 2 minggu, dia telah memiliki sebuah pengubah yang beralasan. Namun customer Speedy tidak senang. Kodenya Speedy akan memaksa mereka untuk meng-upgrade semua orang di perusahaan tersebut ke versi terbaru. Pelanggan terbesar Speedy, Nanner Splits Unlimited, menolak untuk membeli software terbaru itu. Nanner Splits ingin mengetahui bahwa versi 2.0 akan tetap bisa bekerja pada file versi 1.0 tanpa mengubah mereka. Speedy memutuskan untuk menulis sebuah pengubah balik dan menghubungkannya ke dalam fungsi "simpan". Akan menjadi sedikit kacau, karena saat anda menggunakan fitur versi 2.0, akan kelihatan bekerja, sampai saat anda menyimpan file tersebut ke format 1.0. Anda akan diberitahukan bahwa fitur yang anda gunakan setengah jam yang lalu tidak dapat dipakai pada format file yang lama. Kemudian pengubah balik tersebut memakan waktu dua minggu lagi untuk ditulis, dan hal itu tidak berfungsi dengan bagus. Waktu yang terpakai: 4 minggu.

Sekarang, Mr. Rogers di perusahaan Well-Tempered Software (disingkat: "WellTemperSoft") merupakan tipe seorang kutu buku yang rapi yang menolak menulis kode sampai dia memiliki sebuah spec. Dia menghabiskan waktu 20 menit merancang fitur kompatibilitas ke belakang seperti yang dilakukan oleh Speedy, dan menghasilkan sebuah spec yang kurang lebih berbunyi:

• Saat membuka file yang dibuat dengan versi yang lebih tua, file tersebut dikonversikan ke format baru.

Spec ini ditunjukan ke pelanggan, yang mengatakan "tunggu sebentar! Kami tidak mau semuanya berpindah sekaligus!" Lalu Mr. Rogers berpikir lagi, dan mengubah spec menjadi:

• Saat membuka sebuah file yang dibuat oleh produk versi yang lebih tua, file dikonversikan ke format baru di memory. Saat menyimpan file ini, pemakai diberikan pilihan untuk mengubah kembali.

Dua puluh menit yang lain telah lewat.

Atasan Mr. Rogers, seorang yang mencintai OOP, melihat hal ini dan berpikir ada sesuatu yang kurang. Dia menyarankan arsitektur yang berbeda.

• Kode ini akan di pecah dengan menggunakan 2 antarmuka: V1 dan V2.  V1 mengandung semua fitur di versi satu, dan V2, yang diturunkan dari V1, menambahkan semua fitur baru. Sekarang V1::Simpan dapat mengatasi kompatibilitas ke belakang sementara V2::Simpan dapat digunakan untuk menyimpan semua fitur baru. Jika anda membuka sebuah file V1 dan mencoba menggunakan fungsi V2, program akan langsung memperingati anda, dan anda harus mengubah file tersebut atau melupakan fungsi baru itu.

Dua puluh menit lagi.

Mr. Rogers menggerutu. Refactoring ini akan memakan waktu 3 minggu, bukannya 2 minggu yang merupakan estimasi awal dia! Namun hal ini menyelesaikan semua masalah pelanggan, dengan cara yang elegan, jadi dia jalan terus dan kerjakan.

Total waktu yang berlalu untuk Mr. Rogers: 3 minggu dan 1 jam. Waktu yang dipakai Speedy: 4 minggu, tapi kodenya Speedy tidak sebagus punya Rogers.

Pesan dari cerita ini adalah dengan sebuah contoh sederhana, anda dapat membuktikan apapun. Oops. Bukan, bukan itu maksud saya. Pesan cerita ini adalah saat anda mendisain produk anda dengan bahasa manusia, hanya akan memakan waktu beberapa menit untuk memikirkan beberapa kemungkinan, revisi, dan memperbaiki disain anda. Tidak ada yang akan tersinggung saat anda menghapus satu paragraph dari word processor. Namun saat anda mendisain produk anda dalam sebuah bahasa pemrograman, akan memakan waktu berminggu-minggu untuk melakukan iterasi disain. Yang terburuk adalah, seseorang yang baru saja menghabiskan 2 minggu menulis kode akan merasa terikat dengan kode tersebut, tidak perduli sesalah apapun. Tidak ada yang bisa dikatakan oleh atasan Speedy atau pelanggan yang dapat meyakinkan dia untuk membuang kode pengubahnya yang indah, meskipun hal itu tidak mewakili arsitektur yang terbaik. Sebagai hasilnya, produk akhir akan cenderung berkompromi antara disain awal yang salah dan disain yang ideal. Ini adalah "disain terbaik yang bisa kita dapatkan, dari semua kode yang telah kami tulis dan kami tidak mau membuangnya". Tidak akan sebagus "Disain terbaik yang bisa kami dapatkan, titik".

Jadi itu adalah alasan terbesar pertama untuk menulis sebuah spec. Alasan terbesar kedua adalah untuk menghemat waktu komunikasi. Saat anda menulis sebuah spec, anda hanya perlu mengkomunikasikan bagaimana program ini harus bekerja sekali. Setiap orang di dalam tim tinggal membaca spec ini. Orang QA membaca ini sehingga mereka tahu bagaimana program ini seharusnya bekerja dan mereka tahu apa yang harus dicoba. Orang marketing menggunakan ini untuk menulis white paper yang gamblang untuk ditampilkan di web site tentang produk yang belum juga dibuat. Orang pengembang bisnis salah membaca hal ini dan menghasilkan fantasi yang aneh tentang bagaimana produk ini dapat mengobati kebotakan dan lainnya, namun hal ini bisa mengundang investor, jadi boleh juga. Pengembang membaca hal ini sehingga mereka tahu kode apa yang harus ditulis. Pelanggan membaca hal ini untuk memastikan pengembang membangun sebuah produk yang akan mereka bayar. Penulis teknis membaca hal ini dan menulis sebuah manual yang bagus ( yang akan hilang atau dibuang, namun ini adalah cerita yang lain). Manager membaca hal ini sehingga mereka bisa kelihatannya mengetahui apa yang terjadi pada rapat managemen. Dan seterusnya.

Saat anda tidak menulis sebuah spec, semua komunikasi ini tetap terjadi, tapi akan terjadi saat diperlukan. Orang QA akan mencoba segala macam di program ini, dan saat ada sesuatu yang aneh, mereka akan menghampiri programer dan mengusik mereka lagi-lagi untuk menanyakan pertanyaan bodoh yang lain tentang bagaimana hal ini seharusnya bekerja. Disamping hal ini merusak produktivitas programer, programer cenderung memberikan jawaban yang berhubungan dengan kode yang mereka tulis, daripada "jawaban yang betul". Jadi orang QA sebenarnya sedang menguji program terhadap program, bukan program terhadap disain, yang seharusnya, hmm, lebih berguna.

Saat anda tidak mempunyai spec, apa yang terjadi pada penulis teknis yang malang adalah yang terlucu (dengan cara yang menyedihkan). Penulis teknis sering tidak mempunyai wewenang untuk mengganggu programer. Pada banyak perusahaan, jika penulis teknis mempunyai kebiasaan menginterupsi programer untuk bertanya bagaimana sesuatu hal seharusnya bekerja, programer akan menghadap managernya dan mengeluh tentang bagaimana mereka tidak bisa bekerja karena penulis [brengsek] ini, dan minta untuk menyingkirkan mereka. Dan manager, mencoba untuk memperbaiki produktivitas, melarang penulis teknis untuk menghabiskan waktu programer yang berharga lagi. Anda selalu dapat mengetahui perusahaan seperti ini, karena help file dan manualnya tidak memberikan informasi yang lebih dari apa yang dapat diketahui dari layar. Saat anda melihat pesan di layar yang mengatakan

• Apakah anda mau mengaktifkan dukungan LRF-1914 ?

... dan anda klik "Help", sebuah topik help yang lucu namun menyedihkan muncul yang mengatakan sesuatu seperti:

• Mempersilahkan anda untuk memilih antara dukungan LRF-1914 (default) atau tanpa dukungan LRF-1914. Jika anda ingin dukungan LRF-1914, pilih "Yes" atau tekan "Y". Jika anda tidak ingin dukungan LRF-1914, pilih "No" atau tekan "N".

Hm, terima kasih. Hal ini sangat jelas bahwa penulis teknis sedang mencoba menutupi fakta bahwa mereka tidak mengetahui apa itu dukungan LRF-1914. Mereka tidak bisa bertanya ke programer, karena (a) mereka malu, atau (b) programernya di Hyderabad dan mereka di London, atau (c) mereka dilarang oleh managemen untuk menginterupsi programer, atau sejumlah penyakit perusahaan lainnya yang telalu banyak untuk disebutkan, namun masalah dasarnya terletak pada sebuah spec.

Alasan terbesar nomor tiga untuk mempunyai spec adalah tanpa memiliki spec yang detail, tidak mungkin membuat jadwal. Tidak memiliki jadwal tidak masalah jika ini merupakan PhD anda dan anda berencana menghabiskan 14 tahun pada hal itu, atau jika anda seorang programer yang bekerja di Duke Nukem berikutnya dan kami akan kirim saat kami baik dan siap. Namun untuk hampir semua jenis bisnis yang nyata, anda perlu mengetahui hal ini akan makan waktu berapa lama, karena mengembangkan sebuah produk membutuhkan uang. Anda tidak akan membeli sebuah jeans tanpa mengetahui berapa harganya, lalu bagaimana sebuah bisnis yang bertanggung jawab memutuskan apakah akan membangun sebuah produk tanpa mengetahui akan memakan waktu berapa lama, dan berapa biayanya? Lebih jauh tentang penjadwalan, baca Penjadwalan software yang mudah.

Suatu kesalahan umum yang parah yaitu mengenai perdebatan tentang bagaimana sesuatu harus didisain, dan kemudian tidak pernah ada penyelesaian. Brian Valentine, pemimpin pengembang di Windows 2000, terkenal dengan motto-nya: "Buat keputusan dalam waktu kurang dari 10 menit, atau yang berikutnya gratis".

Dalam kebanyakan organisasi programing, setiap kali ada perdebatan tentang disain, tidak ada yang pernah mau mengambil sebuah keputusan, biasanya karena alasan politis. Jadi para programer hanya bekerja pada hal-hal yang tidak kontroversial. Seiring dengan lewatnya waktu, semua keputusan yang sulit ditunda sampai akhir. Hal ini yang sering menyebabkan proyek gagal. Jika anda sedang memulai sebuah perusahaan baru dengan sebuah teknologi baru dan anda menyadari bahwa perusahaan anda secara konstitusi tidak mampu membuat sebuah keputusan, anda sebaiknya menutup perusahaan itu dan mengembalikan uangnya ke investor, karena anda tidak akan menghasilkan apa pun.

Penulisan spec merupakan cara terbaik untuk menemukan semua keputusan disain yang sulit itu, yang tidak nampak jika anda tidak mempunyai sebuah spec. Bahkan untuk keputusan kecil pun dapat ditemukankan oleh spec. Sebagai contoh, jika anda sedang membangun sebuah web site dengan keanggotaan, anda semua akan setuju jika pengguna lupa password-nya, anda akan mengirimkannya ke mereka. Bagus. Tapi itu tidak cukup untuk menulis kode. Untuk menulis kode, anda perlu mengetahui kata-kata persis yang akan di-email. Pada kebanyakan perusahaan, para programer tidak dipercayai menulis kata-kata yang akan dibaca oleh user (kebanyakan kasus hal ini merupakan alasan yang bagus). Lalu serorang marketing atau orang PR atau orang jurusan bahasa nampaknya diperlukan untuk menghasilkan kata-kata untuk pesannya. "Yth Shlub, Ini password yang anda lupakan. Harap tidak ceroboh lagi lain kali". Saat anda memaksa diri anda menulis sebuah spec yang bagus dan lengkap (dan saya akan membicarakan lebih banyak lagi tentang hal ini nanti), anda menyadari semua hal ini dan akan membetulkan itu atau paling tidak ditandai dengan sebuah bendera merah yang besar.

OK. Kita sudah sependapat sekarang. Specs adalah sesuatu yang baik. Saya menduga bahwa kebanyakan orang sudah mengerti hal ini, dan tulisan saya, walaupun menghibur, tidak mengajarkan hal baru apa pun. Lalu kenapa orang tidak menulis specs? Ini bukan untuk menghemat waktu, karena memang tidak, dan saya pikir kebanyakan pemrogram tahu itu. (Pada kebanyakan organisasi, satu-satunya "specs" yang ada adalah staccato (lembar musik yang bertempo tinggi), selembar dokumen text yang ditulis oleh programer di Notepad setelah menulis kode dan setelah menjelaskan fitur tersebut ke orang yang ke tiga ratus).

Saya pikir hal ini karena banyak sekali orang yang tidak menyukai menulis. Memandangi sebuah layar kosong sangat membuat frustasi. Secara pribadi, saya mengatasi ketakutan saya untuk menulis dengan mengambil kelas saat kuliah yang mengharuskan setiap minggu menulis makalah 3-5 halaman. Menulis seperti otot. Semakin anda menulis, semakin anda akan mampu menulis. Jika anda perlu menulis specs dan anda tidak bisa, mulailah membuat jurnal, buat sebuah weblog, ambil kursus menulis kreatif, atau sekedar menulis sebuah surat kepada semua keluarga dan teman sekamar saat kuliah anda yang telah dilupakan selama 4 tahun. Segala hal yang melibatkan penempatan kata-kata di atas kertas akan memperbaiki kemampuan menulis anda. Jika anda adalah seorang manager pengembang software dan orang yang seharusnya menulis specs tidak bisa menulis, kirim mereka untuk mengikuti kursus menulis kreatif selama 2 minggu di gunung.

Jika anda tidak pernah bekerja pada perusahaan yang membuat functional specification, anda mungkin belum pernah melihatnya. Pada bagian berikutnya dari seri ini, saya akan menunjukkan ke anda sebuah contoh spec yang singkat untuk anda lihat, dan kita akan membicarakan apa yang perlu dimiliki oleh sebuah spec yang baik. Terus baca!