Tidak Ada Anjing yang Disakiti dalam Pembuatan Aplikasi Ini

• Pada 2016, fitur unggah foto berbasis lokasi di aplikasi mobile React Native gagal hanya pada Android beta, sementara masalahnya tidak bisa direproduksi di Android lokal maupun iOS, dan ditelusuri selama seminggu
• Android beta tidak memberi umpan balik kesalahan meskipun unggah gambar gagal, dan setiap kali build baru diunggah ke Play Store dibutuhkan sekitar 1 jam, sehingga verifikasi hipotesis berjalan lambat
• Dibandingkan dengan contoh di bidang embedded, perangkat keras, kimia, dan kedokteran hewan, terlihat bahwa debugging perangkat lunak jauh lebih cepat dan memiliki observabilitas yang lebih tinggi
• Penyebab sebenarnya adalah perbedaan satu karakter pada tipe MIME gambar: ditulis "jpg", padahal meskipun ekstensi filenya .jpg, tipe MIME-nya harus "jpeg"
• Lingkungan pengembangan yang memungkinkan penggunaan log, observasi real-time, debugger, dan eksperimen berulang dengan murah adalah sebuah keistimewaan besar jika dibandingkan dengan loop umpan balik di profesi lain

---

Unggah foto yang gagal hanya di Android beta

• Fitur geolocated photos di aplikasi mobile React Native tampak seperti sudah siap dirilis pada hari Senin, tetapi setelah distribusi Android beta, gambar tidak bisa diunggah
• Pengujian Android lokal dan iOS beta berjalan normal, sehingga penyebab kegagalan tidak langsung terlihat
• Bahkan setelah mengunggah ulang versi dengan penanganan error yang ditingkatkan, kegagalan unggah tetap terjadi tanpa umpan balik
• Mengunggah versi iterasi baru ke Play Store membutuhkan sekitar 1 jam, dan sambil menyiapkan hipotesis berikutnya harus menunggu build selesai didistribusikan

Loop umpan balik yang lebih panjang di profesi lain

• Seorang engineer embedded mengalami situasi ketika pembaruan firmware yang didistribusikan ke perangkat jarak jauh membuat node tidak lagi merespons
  • Untuk mengetahui penyebabnya, perangkat harus ditarik kembali dan dianalisis
  • Dalam beberapa kasus, perlu berbulan-bulan untuk mengetahui apa yang salah
• Seorang hardware engineer melihat bahwa perangkat keras baru yang didistribusikan ke lokasi jauh baru bisa menunjukkan cacat desain setelah melewati beberapa musim
  • Perangkat lama dikirim lewat pos untuk kemudian perbaikannya diterapkan pada produk generasi berikutnya
  • Ada kasus ketika ventilasi ditambahkan untuk mengurangi panas, tetapi lubangnya cukup besar hingga tawon bisa membuat sarang, sehingga menjadi bug yang lebih buruk
  • Pengujian laboratorium memang mungkin dilakukan, tetapi verifikasi akhir pada akhirnya tetap terjadi di lapangan

Cara menerima kegagalan

• Sang CEO mengenang masa ketika ia menjadi kimiawan yang menyiapkan disertasi doktoral, melakukan eksperimen dengan dana penelitian besar untuk bahan kimia mahal, tetapi beberapa minggu kemudian hasilnya tampak gagal karena kesalahan eksperimen
• Ia tidak bisa mengetahui apa yang salah, dan juga tidak bisa menjawab pertanyaan tentang apa yang akan dilakukan berbeda agar kesalahan yang sama tidak terulang
• Meski begitu, ia tetap mendapatkan dana penelitian kedua, dan pengalaman ini menjadi contoh kepemimpinan yang penuh empati yang membantu orang bangkit lagi setelah gagal

Kasus kedokteran hewan yang menunjukkan risiko lebih tinggi

• Seorang teman dokter hewan menangani anjing tua yang sakit dan menyarankan pemiliknya melakukan X-ray, tetapi ditolak karena biaya
• Tanpa X-ray, hal terbaik yang bisa dilakukan adalah meraba perut anjing dari luar, dan teraba benda besar
• Yang diangkat melalui operasi adalah tongkol jagung, tetapi tanpa X-ray tidak ada kepastian apakah itu memang seluruh sumber masalahnya
• Keesokan harinya anjing itu mati, dan tidak seperti masalah peluncuran aplikasi mobile, kegagalan di profesi lain benar-benar bisa menyangkut hidup dan mati

Bug satu karakter dan keistimewaan alat debugging

• Pada Jumat pagi terlihat ada ketidaksesuaian antara dokumentasi Android dan codebase, dan penyebab masalah selama seminggu ternyata hanya satu karakter
• Tipe MIME gambar disetel ke "jpg", padahal seharusnya "jpeg", sementara file disimpan sebagai .jpg
• Developer perangkat lunak bisa melihat jauh ke dalam proses yang kompleks, memantau perilaku secara real-time, menulis log, serta menghentikan eksekusi dengan debugger untuk memeriksanya
• Kemampuan ini murah dan cepat, dan eksperimen bisa diulang berkali-kali dalam sehari hanya dengan beberapa klik
• Perangkat lunak juga bisa sama penting dan berdampaknya seperti profesi lain, tetapi developer bekerja dalam lingkungan yang layak disyukuri karena memiliki alat debugging yang ada sekarang

[GN⁺]

Pendapat Hacker News

• Ini hampir seperti fabel yang menunjukkan bagaimana rekayasa perangkat lunak berbeda dari profesi lain—kalau bercanda, dari profesi yang “nyata”
  Saya juga suka versi yang lebih pendek dan jenaka: seorang insinyur perangkat lunak, insinyur perangkat keras, dan kepala departemen sedang dalam perjalanan ke rapat di Swiss ketika rem mobil mereka rusak di jalan pegunungan yang curam; mobil menabrak pagar pembatas saat meluncur turun dan secara ajaib berhenti
  Kepala departemen mengusulkan mengadakan rapat untuk menetapkan visi, misi, dan tujuan, lalu memecahkan masalah inti lewat perbaikan berkelanjutan; insinyur perangkat keras mengusulkan membongkar rem dengan pisau Swiss Army dan memperbaikinya
  Insinyur perangkat lunak berkata, “Sebelum melakukan apa pun, mari dorong mobilnya kembali ke atas dan lihat apakah bisa direproduksi lagi”

  • Kelebihan besar rekayasa perangkat lunak adalah ia berurusan dengan abstraksi. Ini mirip membangun kastel di atas awan, sehingga bahkan fondasinya pun bisa dibentuk ulang seluruhnya
    Pada saat yang sama, kekurangan besar rekayasa perangkat lunak juga adalah ia berurusan dengan abstraksi. Bahkan fondasinya pun ikut bergerak
    http://thecodelesscode.com/case/154
  • Apakah pelajaran dari cerita ini cuma bahwa insinyur perangkat keras yang benar?
  • Itu insinyur mesin
  • Bagaimana kalau saat menekan “jalankan ulang”, mobil secara ajaib muncul lagi di atas bukit dan kejadian yang sama terulang, lalu pada saat rem rusak waktu bisa dihentikan dan semua komponen mobil bisa dibongkar untuk melihat persis bagian mana yang bermasalah secara real-time, slow motion, dan reverse playback?
    Punya kemampuan seperti itu tidak berarti insinyur perangkat lunak itu konyol atau tidak realistis
    Rekayasa di ruang digital memberi kemampuan debugging yang nyaris ajaib di bidang fisik. Kalau ingin membuat 10 barang yang sama dan mengujinya dengan 10 cara, secara harfiah cukup CTRL+C, CTRL+V. Saya ingin melihat mekanik melakukan itu
  • Yang tidak berfungsi hanya rem, mesinnya baik-baik saja. Kenapa harus repot-repot mendorong mobil ke atas bukit?
  • Saya akan menutup semua jendela dan me-restart

• Saya benar-benar lelah dengan keluhan bahwa insinyur perangkat lunak bukan “insinyur sungguhan”, dan bahwa semuanya akan beres kalau kita mengadakan lebih banyak rapat desain besar di awal serta perencanaan yang luar biasa banyak
  Bidang rekayasa lain bekerja seperti itu bukan karena mereka jauh lebih profesional daripada kita, atau karena cara itu lebih baik, melainkan karena bagi mereka hanya itu satu-satunya cara. Setelah hotel selesai dibangun, mereka tidak akan sadar plafonnya harus dinaikkan 6 inci lalu merobohkan semuanya dan membangunnya ulang
  Kalau mereka bisa menjalankan ceilingHeight += 6, menekan “Rebuild”, lalu hotel dibangun ulang sementara unit test otomatis juga memeriksa aksesibilitas dan total biayanya 2,82 dolar, tentu mereka juga akan melakukannya
  Kita harus membuang rasa inferioritas. Kita melakukan rekayasa dengan alat yang bahkan tak bisa diimpikan oleh insinyur sipil dan mesin di dunia nyata, dan wajar saja prosesnya menjadi sangat berbeda
  Tentu ada kalanya kita tidak menerapkan proses yang cukup pada suatu masalah. Tapi kalau Anda mengira itu masalah yang hanya ada pada pemrograman, saya ingin meresepkan beberapa jam menonton https://www.imdb.com/title/tt4788946/

  • Sepertinya Anda melewatkan poin utamanya. Perencanaan awal atau rapat bukanlah esensinya; itu adalah konsekuensi dari standar sebelumnya. Rekayasa adalah memecahkan masalah praktis secara ilmiah, dengan keselamatan, keterulangan, dan pemahaman prinsip solusi yang tidak bisa ditawar; pemecah masalahnya harus memenuhi kualifikasi sebagai insinyur dalam etika dan ketelitian ilmiah, dan karena kualifikasi itu ia memikul tanggung jawab yang tidak bisa dielakkan ketika solusi yang disetujuinya gagal
    Ini bukan soal merasa lebih unggul; jika salah satu dari empat kriteria itu hilang, Anda tidak sedang melakukan rekayasa. Dari pengalaman saya, sebagian besar pengembangan perangkat lunak tidak memiliki keempatnya. Itu tidak selalu buruk, tetapi sebagian besar pengembangan perangkat lunak bukan rekayasa
    Sama sekali bukan berarti rekayasa lebih unggul daripada pengembangan
  • Sangat setuju. Media yang berbeda masing-masing punya proses dan teknik yang dioptimalkan untuknya
    Ini seperti perbedaan antara memahat tanah liat dan memahat marmer. Kalau salah di tanah liat, Anda bisa segera membentuknya ulang, tetapi kalau Anda memahat bagian yang tidak boleh hilang dari marmer, Anda harus memesan blok marmer baru
    Membawa cara memahat marmer ke dunia tanah liat hanya akan menjadikan Anda pematung tanah liat yang buruk, atau setidaknya sangat tidak efisien
    Tidak banyak gunanya juga memperdebatkan mana yang lebih bernilai, patung tanah liat atau marmer. Keduanya punya tempat masing-masing dalam masyarakat
  • Sedikit menyimpang, tetapi salah satu alasan 3D printing bagus adalah karena ia memberi pengalaman yang paling mendekati ceilingHeight += 6 di dunia nyata
    Hari ini saya memodelkan dan mencetak sebuah benda, lalu menyadari satu bagiannya akan lebih baik jika sekitar 1 mm lebih tebal. 30 detik kemudian, versi 2 sudah menuju printer
    Benar-benar hebat. Saya sulit menunggu sampai hal seperti ini menjadi sepopuler printer kertas
  • Orang-orang yang mengira rekayasa perangkat lunak bukan rekayasa sungguhan mungkin akan terkejut mengetahui bahwa sebagian besar rekayasa “sungguhan” hanyalah memasukkan angka ke perangkat lunak
  • Kalau melihat pesawat dan jet yang dirancang sebelum CAD, desain rekayasa pun bisa cukup banyak diperbaiki di lapangan. Semuanya dibuat pas dengan pengetahuan tertanam di kepala orang yang membuat dan memperbaikinya
    https://www.youtube.com/watch?v=NPVT2lvMvOk

• Sepanjang karier, sudah beberapa kali semua orang buntu karena ada sesuatu yang error tetapi benar-benar diam. Tidak ada output error, tidak ada apa pun
  Dalam banyak kasus seperti itu, penyebabnya adalah pustaka pihak ketiga tingkat rendah yang melakukan catch (e) {}. Kasus pertama yang saya alami di awal menjadi pelajaran bagus, dan sekarang saya tidak pernah mengabaikan error begitu saja. Minimal saya mencatatnya di log
  Perangkat lunak yang dibuat sekarang bisa saja digunakan 5 tahun lagi di lingkungan yang sama sekali tidak pernah dibayangkan

  • “Fungsi ini terlalu jelas bagi semua anggota tim, jadi tidak perlu komentar”
    30 tahun kemudian:
    /* X systems I modul body I 14.09.1990 */
void xxvcda(int *addr, int sizeof)
  • Benar sekali. Di kode yang sedang saya lihat, seorang penulis sebelumnya yang sempat lewat sebentar menelan exception dari pustaka bawah, lalu sebagai gantinya melempar exception yang sama sekali tidak berguna
    Ia bahkan tidak tahu fitur bahasa untuk menaikkan exception baru dari exception sebelumnya agar konteks stack trace tetap terjaga. Lucu juga. Setidaknya ini bukan kode pekerjaan utama saya, meski pekerjaan utama juga punya kelucuannya sendiri
  • Baru-baru ini saya mengalami hal serupa dengan DRF dan JWT. Karena masalah timing yang sporadis, JWT menjadi tidak valid dan saya tidak bisa login
    DRF menelan error validasi dan hanya mengembalikan error umum, jadi tidak ada petunjuk sama sekali; akhirnya saya harus turun sendiri dan menambahkan logging untuk mencari tahu apa yang terjadi

• Seorang teman fisikawan sering mengutip ucapan Rutherford, “semua sains adalah fisika atau mengumpulkan perangko”
  Maksud teman itu adalah, berbeda dengan matematika atau ilmu komputer, fisika punya cara untuk diverifikasi oleh realitas fisik
  Bidangnya adalah medan magnet ekstrem, dengan eksperimen seperti membuat kumparan tembaga raksasa, mengalirkan arus sampai hampir meleleh, lalu meledakkan bahan peledak di sekitar kumparan agar dalam sesaat yang sangat singkat medan magnet di pusatnya menjadi yang terkuat yang pernah dibuat manusia, setelah itu tembaga cair bersuhu ribuan derajat terpental dan seluruh perangkat hancur
  Dalam lingkungan kerja seperti itu, kesalahan atau salah hitung berarti orang bisa mati dengan sangat cepat dan mengerikan. Jadi dia tidak setuju ketika mahasiswa doktoral matematika, yang kerugian terbesarnya hanya bubuk kapur di sweter, menyebut diri mereka ilmuwan

  • Itu interpretasi yang cukup unik atas kutipan tersebut. Menurut beberapa buku, maksud ucapan itu adalah sains itu matematis dan kuantitatif, atau kalau tidak, bersifat teknis
    Dengan kata lain, entah berusaha memahami dinamika suatu objek, atau sekadar mengumpulkan fakta menarik dan memberi nama pada objek yang diminati
  • Generator kompresi fluks magnetik yang dipompa ledakan[1] itu menarik
    Untuk orang yang tertarik berkarier sebagai supervillain tapi tidak tahu harus mulai dari mana, EMP sungguhan dibuat dengan cara begitu
    [1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
  • Dulu saya penasaran kenapa Dijkstra begitu arogan, lalu saya paham setelah tahu bahwa ia mengambil jurusan fisika teoretis
  • Saya jarang melihat matematikawan menyebut diri mereka ilmuwan. Justru biasanya mereka membanggakan diri bahwa mereka bukan ilmuwan dan tidak dibatasi oleh hal-hal remeh dalam realitas
  • Sebagai fisikawan sejati, dia salah menafsirkan kutipan itu

• Setelah kejadian seperti ini, saya selalu berharap ada tindakan korektif di hulu. Kalau ada logging dan pelaporan error yang memadai, memperbaikinya tidak akan memakan waktu seminggu
  Library yang menerima tipe MIME image/jpg yang salah seharusnya melempar exception, crash, atau setidaknya mencatat log dengan jelas. Saya penasaran apakah penulis asli melaporkan bug ke library itu

  • Di bagian akhir tulisan, saya penasaran Shawn bekerja di lingkungan seperti apa sampai diagnosisnya memakan waktu selama itu
    Apakah ia punya akses untuk memastikan atau menolak apakah upload gambar benar-benar masuk ke server? Kenapa di lingkungan uji upload berhasil, tetapi di versi rilis aplikasi tidak? Apa yang berbeda pada lingkungan uji?
    Secara teori, Shawn seharusnya punya akses yang cukup untuk cukup cepat menjawab “upload berhasil, lalu kenapa tidak terlihat?”, entah dengan menjalankan server sendiri atau meminta bantuan orang yang bisa mendiagnosis mengapa upload gagal secara diam-diam
    Menurut saya, pelajaran yang jauh lebih penting daripada “tipe MIME gambar adalah jpg padahal seharusnya jpeg” adalah mengapa di pengujian berhasil tetapi di produksi tidak. Lebih penting daripada bug itu sendiri adalah kenapa lingkungan membuat bug itu sulit ditemukan
    Dalam kasus saya, sebuah aplikasi desktop mengalami malfungsi parah tetapi error tidak masuk log. Baru beberapa hari kemudian saya tahu bahwa file handle habis, dan log4net juga tidak bisa mencatat log jika tidak bisa mendapatkan file handle. Solusi untuk membatalkan satu perbaikan bug kecil memang sederhana, tetapi perbaikan sebenarnya adalah mengustomisasi log4net agar file log selalu tetap terbuka. Dengan begitu, meski aplikasi menghabiskan semua file handle, error tetap tercatat
  • Paragraf terkait dalam tulisan itu agak mengganggu saya: “Saya mengunggah ulang versi dengan penanganan error yang lebih baik, tetapi upload gambar gagal tanpa umpan balik apa pun. Biasanya kode menampilkan error dengan teks merah seperti berteriak, dan diam adalah tujuannya. Di sini, diam adalah masalahnya.”
    Diam bukanlah tujuan. Terlalu banyak developer menganggap diam sebagai tujuan, padahal tujuan sebenarnya adalah kebenaran. Kalau tidak ada error, aplikasi memang sebaiknya tenang, tetapi kalau ada error yang berdampak pada pengguna, harus ada kotak peringatan merah besar
    Menurut saya developer perlu belajar menyukai pesan error. Pesan error yang ditulis dengan baik akan cepat mengungkap penyebabnya dan menghemat banyak waktu semua orang
    Kalau developer ini belajar untuk lebih sering menampilkan pesan error ke depannya, itu hasil yang sangat baik

• Saya teringat mantan rekan kerja yang sering berkata, “kita kan tidak sedang membuat sistem pengatur lalu lintas udara.” Maksudnya, kesalahan tidak akan mempertaruhkan nyawa
  Saat itu kami sedang membuat game, tetapi ucapan itu juga berlaku untuk hampir semua aplikasi CRUD yang pernah saya tulis
  Secara terpisah, saya sering bertanya kepada para pemimpin teknologi senior lain, terutama Director, VP, dan CTO, “apa kesalahan paling mahal yang pernah Anda buat?” Kalau Anda engineer junior, ini sesuatu yang sebaiknya dicoba suatu hari nanti
  Banyak pemimpin teknologi tingkat tinggi bisa bercerita tentang kesalahan bernilai 100 ribu sampai 1 juta dolar. Saya pernah melihat orang membuang jutaan dolar dalam sebuah proyek lalu langsung dipromosikan. Penting untuk memahami kenapa hal seperti itu bisa terjadi, dan bahkan kenapa itu bisa menjadi hal yang baik

  • Saya tidak setuju. Kegagalan mungkin tidak berujung pada kematian dalam bola api, tetapi tetap bisa merugikan. Kerugian kecil pun akan terakumulasi jika skalanya besar
    Frustrasi karena game yang penuh bug bisa berujung pada aksi balas dendam di jalan atau adu teriak di dunia nyata. Ada orang yang bunuh diri karena komputer mengirim tagihan yang salah. Ada juga perusahaan yang bangkrut karena software kehilangan data berharga
    Orang pernah dibunuh gara-gara aplikasi media sosial yang tampak sepele, dan Twitter pernah dipakai untuk mengorganisir hasutan pembantaian. Ada juga orang yang menjadi korban stalking dan penyerangan karena informasi yang dibocorkan Pokemon Go
    Software punya kekuatan nyata. Kalau tidak, tidak ada alasan untuk menulis software
  • Sikap “kita kan tidak sedang membuat sistem pengatur lalu lintas udara” juga membuat saya tidak nyaman
    Saya pernah membuat software yang bisa menghilangkan data berharga, dan sekarang saya membuat software yang jika rusak bisa menyebabkan banjir
    Kita seharusnya punya sedikit lebih banyak rasa bangga terhadap pekerjaan sendiri

• Sebagai software engineer, saya cukup menikmati debugging. Karena debugging membuat saya memakai keterampilan dan cara berpikir yang berbeda dari saat membuat desain dan mengimplementasikannya
  Tentu saja bukan berarti debugging tidak membuat stres. Saat mengembangkan software untuk switch telepon AT&T 5ESS, kami punya demo, dan di lab pengujian hanya ada satu saluran telepon yang disetel untuk fitur kami
  Berapa kali pun dicoba, software-nya tidak berjalan, dan saya stres sambil memeriksa semua hal yang mungkin, tetap yakin bahwa software-nya benar. Akhirnya saya meminta teknisi lab memeriksa salurannya, dan ternyata satu-satunya saluran yang disetel itu entah bagaimana terlepas. Masalah hardware bodoh

  • Saya juga sama. Terutama pada sistem yang kompleks, saya selalu menikmati tantangan debugging
  • Debugging itu menyenangkan kalau ada tool-nya, tetapi tidak enak kalau akibat pilihan yang diambil semuanya terlalu jauh, baik secara kiasan maupun harfiah
    Debugging sistem terdistribusi di cloud secara eksponensial lebih buruk daripada ketika semua service bisa dijalankan secara lokal, dan sistem terdistribusi lokal itu pun jauh lebih buruk daripada ketika masalah bisa di-debug di dalam satu program
    Debugger sungguhan juga membuat debugging jauh lebih baik. Saya tidak pernah memahami orang yang hanya bersikeras memakai salah satu antara debugging printf dan debugger sungguhan. Padahal memakai keduanya memberi keuntungan besar. Fitur tracing yang bagus juga, kalau tersedia, jauh lebih baik daripada debugging printf, jadi layak ditekankan di sini
    Pada masa-masa awal pemrograman, saya menempelkan banyak emosi yang tidak perlu pada keadaan tidak tahu kenapa sesuatu terjadi, tetapi lambat laun saya menerima loop “sebentar, kenapa begini? saya tidak tahu… oh, tunggu… wah, alasan kenapa ini tidak jalan ternyata benar-benar masuk akal!”, dan juga menginternalisasi bahwa rasanya menyenangkan kalau sudah sampai akhir
    Sekarang, keadaan tidak tahu itu sendiri hanya bisa dirusak oleh ekspektasi dan tindakan orang lain. Seiring waktu, saya belajar bahwa pilihan bahasa, pilihan arsitektur, dan sebagainya harus dikelola dengan sangat tegas agar proses ini mudah dan cepat
    Pada titik karier saya sekarang, jauh lebih mudah meyakinkan sejak awal bahwa AWS Lambda adalah pilihan yang buruk dari sisi performa, total biaya, kemampuan debugging, dan kecepatan pengembangan, daripada nanti meyakinkan orang bahwa memang ada alasan masuk akal kenapa “memperbaiki satu masalah itu makan waktu selama ini”

• Saya tertawa di bagian terakhir. Baru kemarin, saya menyelesaikan masalah yang selama 3 tahun mengganggu perusahaan, dan penyebabnya bagi kami adalah huruf A
  Selama 3 tahun terakhir, seseorang melakukan perbaikan manual dengan memasukkan dan mengeluarkan data, dan itu menjadi bagian dari pekerjaannya. Ia bahkan memasang jadwal berulang di kalender untuk pembersihan rutin. Jutaan pelanggan bergantung pada satu orang ini agar paket data yang benar diterapkan pada saluran ponsel mereka
  Bisa dibayangkan kekacauan apa yang terjadi kalau ia lupa atau pergi cuti
  Pada akhirnya penyebabnya adalah if $line->status == STATUS_ACTIVE, dan yang satu Active, yang lain active. Tidak ada anjing yang terluka, tetapi selama bertahun-tahun uang yang tak terhitung jumlahnya lenyap

  • Kalau ini perkara hukum, leluconnya akan begini: “Apa yang sudah kamu lakukan? Kamu baru saja menyelesaikan perkara yang membiayai seluruh keluargaku masuk sekolah hukum!”
    Orang malang itu tidak lagi menjadi sosok yang tak tergantikan. Setengah bercanda. Software memang membuat pekerjaan lebih efisien, tetapi saya juga cenderung memperhatikan motivasi manusia
  • Saya pernah melihat kasus rumit ketika karakter tak terlihat seperti spasi atau line break menimbulkan kerusakan
    Saya terutama sangat menderita saat mengisi field HL7 di Mac. Sepertinya karakter ’ yang diketik dari keyboard Mac tidak kompatibel dengan semua versi HL7, atau tidak cocok dengan tujuan tempat HL7 itu diteruskan
    Ini ingatan lama, tetapi perbedaan kata seperti o’clock dan o′clock membuat distribusi laporan radiologi rusak. Masalah itu berlangsung bertahun-tahun sebelum tertangkap
    HN menampilkan ’ berbeda dari yang saya ketik, tetapi tetap karakter yang sama. Cukup lucu, karena setengah masalahnya adalah perbedaannya tidak terlihat saat debugging
  • Apakah STATUS_ACTIVE didefinisikan keliru di sebagian kode?
    Selalu ada risiko seseorang “dengan baik hati” memperbaiki typo referer pada HttpHeader::REFERRER menjadi referrer. Tetapi typo itu sudah dibekukan dalam standar HTTP, jadi kalau dilakukan software akan rusak total. Itu tanggung jawab Phillip Hallam-Baker pada era CERN

• Anekdot sarang tawon itu terasa sangat dekat
  Pemilik gedung kantor kami memasang antarmuka layar sentuh di luar gedung agar orang bisa menelepon masing-masing front desk dan dibukakan pintu. Itu dilakukan karena tidak ada resepsionis yang bisa melihat pintu
  Perangkat itu bertahan 6 bulan sebelum mulai mengalami malfungsi parah. Penyebabnya adalah antarmuka tersebut, yang pada dasarnya tablet Android hitam besar, dipasang di sisi timur gedung
  Begitu pertengahan musim semi tiba, perangkat itu mendapat cukup banyak sinar matahari setiap hari hingga overheat, dan sebagian elektronik sentuh serta hardware layarnya rusak
  Dalam jenis software yang saya buat, saya tidak perlu khawatir soal beban panas

  • Saya jadi teringat kisah sinar matahari menghentikan kereta. Menurut Southeastern, layanan di Lewisham, London tenggara, tertunda karena sudut ‘matahari musim dingin yang rendah’
    Perusahaan kereta itu menulis di Twitter bahwa “terjadi kemacetan parah pada layanan yang melewati Lewisham akibat masalah keberangkatan yang disebabkan oleh sinar matahari yang kuat”
    Mereka juga mengatakan matahari musim dingin yang rendah menyinari monitor keberangkatan sehingga masinis tidak bisa melihatnya

• Pesan “akhirnya terpecahkan. Penyebabnya huruf ‘E’” itu lucu
  Bug yang paling sederhana dan kecil sering kali justru paling sulit ditemukan. Pagi ini pun saya menghabiskan satu atau dua jam mencari off-by-one error
  Penyebabnya adalah satu index + 1 yang lupa diubah saat refactoring

  • Seperti yang sering dikatakan, ada dua masalah sulit dalam ilmu komputer: invalidasi cache, penamaan, dan off-by-one error