[teknologia] Re: Jam waker, Test Driven Development, dan Bug Tracking Software
On 9/25/05, Pakcik [EMAIL PROTECTED] wrote: lanjutan tentang test driven dan bug tracking software: Pas sebelum punya jam waker, mau bangun jam berapa juga bisa. Jam 4 pagi bisa, jam 3 pagi bisa. Badan juga biasa2 aja. Trus beli jam waker. Set misalnya jam 4 pagi. Hari pertama bangun. Tapi makin lama makin bermasalah. Ketika jamnya bunyi, setengah sadar kita matikan jamnya. Mulai telat bangun. Badan juga mulai gak enak. Apa sebenarnya yang terjadi? CONTROL yg sebelumnya kita yg punya, sekarang kita lepaskan dan kasih ke jam waker. Jam waker sekarang yang pegang CONTROL. Badan juga jadi gak enak, karna kita emang belum siap bangun, tapi jam waker maksa bangun. Apa iya memang selalu begitu? Weker atau alarm sering saya aktifkan untuk keperluan sedia payung sebelum hujan, persiapan sebelum musibah telat bangun datang. Pada banyak peristiwa saya malah terbangun sebelum jam weker berbunyi, yang barangkali mengindikasikan rencana bangun tersebut masih tersimpan di penjadwal bioritmik tubuh. Kita masih memerlukan alarm, alat pengendali, untuk sebuah manajemen yang lebih rapi. Sama seperti weker raksasa yang dipasang di barak tentara tentu tidak dimaksudkan bahwa para serdadu kehilangan kontrol atas diri mereka, melainkan karena ada sebuah pekerjaan manajemen (mengelola ribuan serdadu). Jika si serdadu seorang diri atau sekelompok kecil dilepas bergerilya di hutan, tentu dia/mereka tidak boleh mengandalkan weker raksasa itu. Dia/mereka harus menyadari hakekat disiplin, setidaknya atas waktu tersebut. Pemrogram yang bekerja semata-mata projek agar beres, mungkin juga menghasilkan program bagus dengan bantuan alat-alat yang kian cerdas. Pemrogram sejati? Tentu tidak puas dan dia berusaha mencari alasannya. Kedua kelompok tersebut adalah keniscayaan; masing-masing menjalankan preferensinya. -- amal
[teknologia] Re: Jam waker, Test Driven Development, dan Bug Tracking Software
On 9/25/05, Ikhlasul Amal [EMAIL PROTECTED] wrote: Apa iya memang selalu begitu?Weker atau alarm sering saya aktifkan untuk keperluan sedia payung sebelum hujan, persiapan sebelum musibah telat bangun datang. Padabanyak peristiwa saya malah terbangun sebelum jam weker berbunyi, yangbarangkali mengindikasikan rencana bangun tersebut masih tersimpan di penjadwal bioritmik tubuh. Gak selalulah. Dan ini juga subyektif kok, gak ada fakta. Mungkin ada juga tipe orang yang gak bisa bangun tepat waktu tanpa jam weker dari awalnya, gak tau. Teman satu kamarku biasanya pake jam weker. Guess what? Siapa yang bangun? Aku yang biasanya bangun karna jam weker dia bunyi. Jadi bisa aja mungkin pake tools, tapi pura2 gak tau kita pake tools, hehe .. tapi ini susah, karna ini unconscious. Ini ada buku bagus untuk belajar tentang conscious dan unconscious. http://www.amazon.com/exec/obidos/ASIN/0201379376/ref=sib_rdr_dp/103-9115917-0469448?%5Fencoding=UTF8no=283155me=ATVPDKIKX0DERst=books Trus sejak ada address book di handphone, skrg bisa ingat nomer telpon gak? kalau aku nomer telpon sendiri juga gak ingat, tapi mungkin ini gak terlalu penting untuk di control. Kalau mau fakta, bisa ke polisi lalu lintas. Di Jepang itu kalau ke polisi lalu lintas ada datanya. Semakin lalu lintas di control dengan rambu2 yang strict, tingkat kecelakaan semakin meningkat. Tapi kalau dibandingkan dgn Indonesia, di rata2kan, tingkat kecelakaan di Indonesia jauh lebih tinggi. Jadi secara rata2, tetap aja yang managed well lebih bagus. Tapi untuk kasus programmer, siapa yg butuh rata2? Kalau ada yg prefer rata2, tool2 yang take control itu mungkin perlu dipakai. -- Pakcik
[teknologia] Re: Jam waker, Test Driven Development, dan Bug Tracking Software
Pemrogram yang bekerja semata-mata projek agar beres, mungkin juga menghasilkan program bagus dengan bantuan alat-alat yang kian cerdas. Pemrogram sejati? Tentu tidak puas dan dia berusaha mencari alasannya. Kedua kelompok tersebut adalah keniscayaan; masing-masing menjalankan preferensinya. pramuka sejati, eeh programer sejati/world-class selalu: -menuliskan comment di tiap blok codenya maksud dari code tersebut apa -mengikuti style guide -membuat API yang bagus -memikirkan code security dari awal -memikiran Optimization dari awal. -di tiap bug report verification,selalu menulis dengan sangat detail alasan kenapa bugs bisa sampai terjadi -punya sw design docs yg detail. -minimum spaghetti code -menggunakan segala macam tools karena sadar kemampuan manusia limited. -seperti kata quote diatas gak pernah cepat puas dan selalu mikirin enhancement. Anyway sedikit comments,inovasi sering muncul dari programer atau group of programer yang gak pernah puas dan punya habit untuk invent sesuatu. Di valley, programer2 seperti ini yang biasanya kemudian grouping dan kemudian start startup company untuk bikin produk yang challenge produk dari persh yang sudah exist sebelumnya(biasanya malah ex-pershnya sendiri). Kalau dianalisa,di tiap2 sektor IT selalu ada produk A vs B,padahal 5 atau 10 tahun yang lalu cuman ada si A saja. Sekarang B muncul sebagai kompetisi karena dulunya dimulai dari programer2 sejati yg ndak pernah puas ... Carlos
[teknologia] Re: Jam waker, Test Driven Development, dan Bug Tracking Software
Pakcik wrote: lanjutan tentang test driven dan bug tracking software: Pas sebelum punya jam waker, mau bangun jam berapa juga bisa. Jam 4 pagi bisa, jam 3 pagi bisa. Badan juga biasa2 aja. Trus beli jam waker. Set misalnya jam 4 pagi. Hari pertama bangun. Tapi makin lama makin bermasalah. Ketika jamnya bunyi, setengah sadar kita matikan jamnya. Mulai telat bangun. Badan juga mulai gak enak. Apa sebenarnya yang terjadi? CONTROL yg sebelumnya kita yg punya, sekarang kita lepaskan dan kasih ke jam waker. Jam waker sekarang yang pegang CONTROL. Badan juga jadi gak enak, karna kita emang belum siap bangun, tapi jam waker maksa bangun. Kita kehilangan CONTROL dan badan jadi gak enak, jadi jangan beli jam waker. :) sorry buat penjual jam waker. hehe Apa hubungannya sama test driven development dan bug tracking software? Pertama tulis testnya, tulis codenya, abis itu refactor. Kalau lewat semua test list, berarti OK. Lanjutkan cycle itu. Trus di bug tracking software, kumpulkan semua bug2 yang ada. Kalau semua bug solved, berarti OK. Apa yang terjadi? CONTROL pelan2 di serah terimakan ke tool2 ini. Tool2 ini yang akan menentukan apakah software kita OK apa NGGAK OK. Kalau lewat semua test, berarti OK. Kalau semua bug solved, berarti OK. Mirip jam waker, jam waker yang berkuasa menentukan kita udah boleh bangun apa nggak. Udah kehilangan CONTROL, penyakit lain muncul. Mulai tulis test seadanya, bug juga yang penting ilang dari list. Nggak perlu ngerti kenapa itu ilang. You just started bug development cycle. Ini sih bukan masalah pakai tools atau tidak. Ini masalah karakter dari developer dan penegakan disiplin. Untuk membangun aplikasi skala besar dari pengalaman saya sangat dibutuhkan karakter developer yang tekun dan teliti. Karena pembuatan aplikasi kalau sudah skalanya besar (lebih dari 6 bulan) maka developernya umumnya akan terkena penyakit bosan. Nah karakter dasar dari si developer itu akan menentukan apakah dia akan bertekun atau dia akan menyerah pada rasa bosan nya dan menghasilkan karya asal-asalan. Cara produktif mengatasi rasa bosan ini ada beberapa: 1. Kurangi waktu untuk develop aplikasi dan luangkan waktu belajar teknologi dan tools baru. Ini memang tidak bagus dari segi produktivitas tapi daripada developernya menghasilkan karya buruk maka lebih baik dia investasi waktu untuk sesuatu yang besar kemungkinan akan menghasilkan peningkatan produktivitas di masa yang akan datang. 2. Rotasikan developer ke pekerjaan lain dalam team: membangun dokumentasi, membuat unit test, dll. Kalau bug tracking software dipakai untuk nyimpan list bug2 dari code yang ditulis pihak lain, ok. Seperti kasus ListView yg di tulis Ariya. Kalau bug tracking dipakai untuk alat komunikasi, ok. issue tracking, ok. Tapi bukan untuk nyimpan bug2 dari code yang kita tulis sendiri. Kalau ada sesuatu yang aneh dengan code yang kita tulis, asumsi pertama adalah masalah di API yg ditulis pihak lain, bukan di code kita. Ini masalah dengan Google, Java, dan tool2 itu. Tapi terkadang ada sesuatu yang gak perlu kita CONTROL. Misalnya nomer telepon. Kita gak perlu harus ingat semua nomer telpon kan? Nomer HP sendiri juga aku gak ingat. :) Buat kasus2 ini menurutku gak apa2 pake tool. Tapi buat playboy kabel nomer telpon itu sangat penting. Jadi jangan mengandalkan tool kalau kasusnya begini. hehe :) Gimana caranya untuk tetap punya CONTROL ini? yang masih kepikir itu adalah gontok2an. Tulis dokument detail. Keep using your own code (reusable). Trus pake kertas dan pensil. Coba nulis program di kertas, jangan pake computer, tanpa reference (GOOGLE), akan kelihatan seberapa besar kita dikendalikan sama computer dan google. Enaknya pake kertas, kalau lagi mobile, gak perlu sok sibuk bawa2 laptop. Gak perlu cari2 internet. You control it yourself. Tools tidak bisa memecahkan masalah karakter dan manajemen. Kendali adalah masalah manajemen dan bukan masalah tools. Pakai low-tech, pakai high-tech tidak ada gunanya kalau masalahnya adalah masalah orangnya. Karena itu pembuatan aplikasi skala besar yang paling berat adalah masalah orang dan manajemen bukan teknologi dan tools. Buku menarik yang pernah saya baca mengenai hal ini adalah Peopleware Tom DeMarco Timothy Lister dan Agile Software Development Alistair Cockburn.
