- Dalam proses perombakan sistem berkas Multics di Honeywell Cambridge, André Bensoussan menangani subsistem inti bernama VTOC manager dan mengerjakannya dari perancangan hingga pengujian
- Modul ini harus memindahkan informasi deskripsi berkas antara disk dan memori serta mengelola buffer pool dan ruang disk, sehingga pada dasarnya lebih mirip pengelola memori virtual kecil
- André tidak langsung menulis kode di depan terminal; ia menyempurnakan diagram dan kode dengan pensil sambil berupaya membuat rancangan yang simetris yang tetap memuat informasi status
- Setelah naskah akhir dimasukkan, masalah yang muncul pada kompilasi pertama hanya 3 salah ketik, dan eksekusi setelah di-bind ke sistem juga berhasil pada percobaan pertama
- Bug yang ditemukan setelah itu hanya satu, karena Tom Van Vleck salah memberi tahu urutan pemanggilan prosedur penanganan kesalahan, sehingga tingkat kematangan program itu sendiri sangat tinggi
Pengerjaan Multics VTOC manager
- André Bensoussan bekerja di sistem operasi Multics di Honeywell Cambridge bersama Tom Van Vleck
- Perubahan besar pada sistem berkas memerlukan subsistem bernama VTOC manager
- Memindahkan informasi deskripsi berkas antara disk dan memori
- Mengelola buffer pool memori bersama
- Mengelola ruang disk untuk informasi berkas
- Karena peran ini, VTOC manager harus bekerja seperti pengelola memori virtual kecil
- André menangani perancangan, implementasi, dan pengujian modul ini
Program yang diselesaikan dengan pensil
- André mula-mula duduk di meja dan menggambar banyak diagram
- Ia ingin bentuk yang enak dilihat dan simetris, sambil tetap memuat seluruh informasi status
- Orang-orang di sekitarnya sampai khawatir penulisan kode terlambat karena jadwal
- Pengodean pun dilakukan bukan di terminal, melainkan dengan pensil
- Ia menolak bantuan pengetikan
- Ia menulis ulang sebagian, menyalin, menghapus, dan merevisi hingga menghasilkan naskah akhir
- Setelah seluruh naskah pensil terakhir dimasukkan ke terminal, kompilasi pertama gagal, tetapi setelah memperbaiki 3 salah ketik, kompilasi berhasil
- Setelah di-bind ke sistem dan dijalankan, modul itu bekerja pada percobaan pertama, dan sesudahnya VTOC manager terus bekerja dengan sempurna
- Satu-satunya bug yang ditemukan terjadi karena Tom Van Vleck, saat ditanya André, memberi tahu urutan pemanggilan prosedur penanganan kesalahan berdasarkan perkiraan tanpa memastikannya
- Saat jalur kesalahan itu pertama kali benar-benar dilalui, sistem mengalami crash
- Selain itu, tidak ada masalah pada program
1 komentar
Pendapat di Hacker News
Menurut saya, alasan utama ia bisa melakukannya adalah karena requirement-nya didefinisikan dengan sangat jelas
Salah satu alasan besar mengapa software sekarang banyak bug dan lambat adalah karena tidak ada yang benar-benar tahu apa yang sedang dibuat, atau kalaupun tahu, hal itu terus berubah karena “agile”
Beri developer API yang jelas dan kriteria yang terdefinisi dengan baik, maka sebagian besar akan menulis kode yang bekerja dengan sangat baik
Requirement bukanlah soal menaruh daftar dan tiket di papan Kanban, melainkan benar-benar mempelajari domain dari hal yang akan dibuat
Kita memang bisa membuat sesuatu di bidang yang tidak kita pahami, tetapi hasilnya mudah menjadi sampah; dan itu tidak masalah jika proses menulis sampah tersebut diperlakukan sebagai draf untuk mempelajari masalah domain dan kemungkinan solusinya
Tidak ada jalan pintas menuju kualitas
Jika Anda stakeholder, orang yang membuat aplikasi harus bisa mengakses Anda, dan Anda harus memastikan mereka memahami domainnya. Itu bisa dilakukan tanpa terus-menerus mengganggu mereka
Waspadalah terhadap pembual yang hanya menebar buzzword
Jika Anda desainer atau programmer, pastikan stakeholder dan pakar domain aktif dan terlibat. Jika tidak, menggali requirement dan pemahaman akan terasa sesulit mencabut gigi
Beberapa stakeholder bahkan mungkin tidak ingin masalahnya diselesaikan, mungkin sebenarnya menginginkan arah yang sama sekali berbeda, atau tersinggung karena alasan politik. Tidak ada yang lebih menenggelamkan proyek daripada stakeholder yang malas atau tidak peduli
Stakeholder tidak tahu apa yang mereka inginkan, tetapi tetap meminta fitur tambahan atau perubahan besar yang terasa acak
Banyak exception handling menjadi diperlukan karena tool ini dipaksa melakukan hal-hal yang seharusnya tidak dilakukan
Desainer sering membuat desain yang bertabrakan dengan fungsi yang dibutuhkan, cara kerja sistem yang ada, dan permintaan stakeholder; sementara tim yang mengembangkan bagian-bagian sistem membuatnya dalam silo tanpa komunikasi yang baik
Proses “agile” yang dirancang buruk mencoba mendorong semuanya masuk ke periode tertentu berdasarkan estimasi poin yang meragukan
Pada akhirnya, masalah-masalah ini membuat sistem tidak bekerja sebagaimana dimaksud atau menjadi tumpukan bug
Jika requirement jelas dan tidak berubah, anggota proyek berkomunikasi dengan baik, dan kita bisa mengendalikan proses sepenuhnya, semuanya akan berjalan baik. Kasus di artikel asli juga tampak seperti itu
Saya kebanyakan bekerja di perusahaan besar, dan 90–99% pekerjaan yang masuk termasuk kasus rata-rata
Namun ada tak terhitung kasus khusus seperti unicorn yang muncul sekali dalam 3 tahun, kira-kira saat gerhana bulan dan gerhana matahari terjadi bersamaan dan para penyihir melantunkan mantra di hutan
Karena kasus-kasus seperti ini harus diimplementasikan dalam kode alih-alih ditangani manual, bug pun muncul, dan kode yang harus ditinjau serta dipelihara menjadi jauh lebih banyak
Jangan mulai bahas maintenance. Itu bagian yang menyakitkan
Requirement selalu berubah. Itu seperti kekuatan alam, dan tidak ada dunia tempat semua orang sejak awal tahu apa yang akan dibuat, menerima API yang sudah dispesifikasikan sepenuhnya, lalu masuk gua dan tinggal mengimplementasikannya
Kenyataannya tidak pernah berjalan seperti itu, dan jika kondisi seperti itu yang dibutuhkan, software engineering bukan pekerjaan yang tepat
Kalau tidak ada pengguna, software saya pasti sempurna ;)
Saya pernah bekerja dengan seseorang yang membelot dari Uni Soviet. Ia mengatakan alasan programmer Soviet sangat hebat adalah karena akses ke komputer sangat terbatas
Jika harus memprogram dengan pensil dan kertas, Anda akan ingin programnya berjalan pada eksekusi pertama
Kebetulan, saat itu kami bekerja di Honeywell
Jadi apakah ini metode pendidikan yang baik, atau filter yang baik untuk menyaring orang yang kurang termotivasi?
Di kampus kami tidak bisa memakai komputer saat kelas, jadi kami terbiasa memprogram bahkan men-debug di atas kertas
Setelah sampai rumah, saya mengetikkannya dan menjalankannya, penasaran apakah saya bisa mereproduksi anekdot Multics yang pernah saya baca
Kompilasi pertama gagal, tetapi setelah memperbaiki satu nama variabel, semuanya berjalan sempurna
Selama beberapa tahun, saya ingat listing cetak jauh lebih baik daripada terminal dalam loop edit→compile→output. Sulit untuk melihat, berpindah, dan memperbaiki kode secara efisien
Hal itu akhirnya membaik ketika editor visual yang lebih baik, terminal yang lebih besar, serta compile dan eksekusi yang lebih cepat muncul
Sebagai analogi, ini mirip senjata api awal. Transisi dari busur panjang menjadi tidak efisien karena bubuk mesiu basah, mekanisme flintlock yang tidak stabil, dan cara semua hal harus dimasukkan ke laras
Ada komentar bagus dari akun jrd259 yang pernah bekerja dengan André di thread HN sebelumnya tentang tulisan ini: https://news.ycombinator.com/item?id=18415231
Isinya terkait betapa pentingnya meja yang luas dan ruang kerja pribadi tanpa notifikasi
Aku teringat dua kali dalam hidupku ketika aku memprogram di atas kertas
Yang pertama sekitar umur 10–12 tahun. Aku pergi ke rumah kakek-nenekku, yang tidak punya komputer maupun smartphone, tetapi ada mesin tik mekanis yang bisa berganti mencetak warna hitam dan merah dengan sebuah sakelar
Saat itu hobi utamaku adalah Turbo Pascal, jadi aku menulis program Pascal dengan mesin tik untuk nanti kumasukkan ke PC dan jalankan setelah pulang ke rumah
Karena aku berada di rumah kakek-nenek selama seminggu, aku punya cukup waktu untuk memikirkannya, men-debug dengan tangan, dan mengetik ulang bagian yang salah
Yang kedua berkaitan dengan bahasa pemrograman esoterik yang kubuat, Ziim(https://esolangs.org/wiki/Ziim), dan fungsi penjumlahan biner di halaman itu
Fungsi itu sangat besar, rumit, dan punya bug. Karena sudah kucoba jalankan di interpreter, aku tahu ada bug, tetapi tidak tahu bagian mana yang bermasalah atau bagaimana memperbaikinya
Kebetulan aku harus naik bus jarak jauh sekitar 6 jam, dan itu kesempatan sempurna untuk debugging
Aku menyalin fungsi penjumlahan Ziim dengan pensil ke kertas kotak-kotak, lalu menjalankannya langkah demi langkah secara manual di bus. Aku berhasil menemukan dan memperbaiki bug-nya, dan harus mengatur ulang seluruh tata letak fungsi itu
Sepertinya pelajarannya adalah bahwa dengan sengaja membatasi kemampuan untuk melakukan sesuatu dengan cara mudah, terkadang itu bisa menghasilkan kode yang dipikirkan dengan matang
Meski begitu, biasanya aku tidak bekerja seperti ini. Aku juga langsung menulis snippet kasar lalu mengulanginya, atau menjalankannya baris demi baris dengan debugger. Mungkin aku perlu memikirkannya lagi
Namun jika semuanya dikerjakan di atas kertas, pada akhirnya itu tidak jauh berbeda dari mengerjakannya langsung di komputer. Kita akan menuliskan semuanya, lalu kehilangan abstraksi dan kehati-hatian itu
Saat aku mulai, itu sudah menjelang akhir era “komputer besar”
Dulu, “programmer” biasanya lebih mirip petugas entri data, dan sering kali perempuan
Orang-orang yang menulis software menuliskan program di atas kertas, di kantor yang penuh asap rokok
Waktu komputasi mahal dan langka. Jika ada bug saat berjalan, tidak ada kesempatan memperbaikinya sampai bisa menjadwalkan lagi waktu entri data dan waktu eksekusi CPU
Jadi itu mendorong pendekatan ukur dua kali, potong sekali
Sebagian besar software saat itu cukup sederhana dibandingkan dengan hal-hal yang kini kita anggap wajar, sehingga pendekatan itu lebih mudah dilakukan. Selain itu, input/output software sangat terbatas, istilah UI bahkan belum ada, dan menghubungkan periferal adalah urusan besar
Sekarang, saat menulis software, kita sering melakukannya dengan gaya “lempar ke dinding dan lihat apa yang menempel”. Lebih mudah menulis kode setengah jadi dan men-debug-nya di IDE
Pengembangan software-ku cenderung iteratif, dan aku pernah menulis tentangnya di sini: https://littlegreenviper.com/miscellany/evolutionary-design-...
Aku ingat pernah harus menulis kernel sistem operasi sederhana untuk tugas kuliah
Aku belum begitu paham C dan juga tidak tahu lebih dari teori tentang apa yang dilakukan kernel, tetapi harus menulis beberapa ratus baris kode C untuk manajemen tugas
Kupikir kalau program ini tidak berjalan, hampir tidak ada cara untuk men-debug-nya karena ini kode paralel, dan bug akan muncul sebagai race condition yang tidak jelas
Aku menalar keseluruhan sistem, lalu selama beberapa hari menulis banyak fungsi kecil dan independen dengan sangat banyak pertimbangan
Lalu aku mengompilasi dan menjalankannya, dan setelah memperbaiki error kompilasi “kurang titik koma” yang tentu saja muncul, program itu berjalan pada percobaan pertama
Setiap kali ada pencapaian mengesankan yang diunggah, komentar-komentar umumnya mencari-cari cela. Kuharap itu dihentikan
Mereka bukan orang yang merancang manajer memori virtual untuk sistem operasi baru, melainkan hanya roda gigi dalam mesin yang mengubah kueri SQL menjadi HTML untuk menampilkan iklan kepada anak-anak dan orang tua
Tidak heran mereka menjadi sinis dan pahit
Sebenarnya tidak. Diskusi memang seharusnya seperti itu
Sampai batas tertentu itu benar, tetapi pertanyaan yang lebih baik untuk mengarahkannya secara positif adalah ini: bagaimana kita bisa mencapai kondisi yang memungkinkan pencapaian serupa dalam lingkungan perusahaan masa kini?
Setiap kali melihat reaksi seperti ini, umumnya memang begitu. Saringan moderasi oleh pengguna hanya butuh sedikit waktu untuk mengangkat komentar yang lebih baik ke atas
Kalau orang ini menghadapi tantangan yang kualami, dia pasti langsung menyerah begitu saja
Saat itu perangkat lunak jauh lebih kecil.
Sekarang, begitu ukurannya sedikit saja lebih besar dari program mainan, sebagian besar proyek sudah berukuran megabita, dan mustahil “menuliskannya” sebagai satu berkas tunggal.
Ini lebih besar dan lebih kompleks daripada kebanyakan hal yang dikerjakan orang saat ini. Banyak pekerjaan saat ini lebih mirip kode perekat yang dilebih-lebihkan untuk merangkai hal-hal seperti CRUD/REST.
Mungkin lebih kecil daripada jumlah baris kode seluruh proyek, tetapi lebih besar daripada unit yang biasanya ditangani orang. Selain itu, ini pun hanya sebagian dari kode sistem operasi secara keseluruhan.
Ini adalah keseluruhan “pengelola yang mengelola informasi deskripsi berkas”. Ia harus memindahkan informasi berkas antara disk dan memori, mengelola pool buffer memori bersama, serta mengelola ruang disk untuk informasi tersebut.
Coba minta sebagian besar programmer sekarang untuk menulis sesuatu dengan persyaratan dan semantik yang sama, hari ini, dalam bahasa pilihan mereka sendiri.
Kebanyakan akan tersesat bahkan sejak tahap membayangkannya. Apalagi menuliskannya di kertas, memasukkannya, lalu membuatnya berjalan.
Sebagian kecil di antaranya adalah URL komponen elektronik, tetapi hampir 90% hanyalah teks bahasa Inggris. Lalu 10% lagi adalah kutipan dari tulisan orang lain, halaman web, application note pabrikan, buku, dan sebagainya.
Ini satu berkas tunggal, dan mungkin akan tetap menjadi satu berkas tunggal sepanjang sisa tahun ini, bahkan seterusnya. Jika berlanjut dengan laju yang sama, ukurannya akan menjadi 12 megabita. Itu sama sekali bukan hal yang mustahil.
Jika tertarik, Anda bisa menjalankan git clone http://canonical.org/~kragen/sw/leatherdrink.git
Saat ini saya sudah meng-commit toolchain avr, jadi ukurannya hampir 200 megabita, dan ada juga hal-hal seperti foto, video, serta skematik.
Kalau itu bahasa pemrograman, pertambahan byte per bulannya akan lebih kecil, tetapi mungkin selisihnya sekitar lima kali lipat.
Kode yang ditulis André Bensoussan ada di sini: https://multicians.org/vtoc_man.html
Saat duduk di meja untuk mulai bekerja dan hendak menyelesaikan hal yang enggan saya lakukan, tentu saja pikiran saya melayang dan ingin mengecek berita di reddit atau HN.
Saya membuka HN, dan judul pertama yang muncul adalah ini.
“Kamu bisa melakukannya”
Itu memberi motivasi.
PS: Tentu saja saya juga membaca artikelnya :)
“Bagaimana André melakukan ini tanpa alat apa pun selain pensil?”
Saat saya masuk SMA pada usia 14 tahun, di kelas pemrograman kami menulis sebagian besar kode di kertas.
Saya anak miskin dari negara miskin, dan selain tidak punya PC di rumah, beberapa “komputer” di lab komputer sekolah pun hanyalah klon ZX Spectrum yang tidak bisa menjalankan bahasa pemrograman yang kami pakai saat itu, yaitu Turbo Pascal.