Kita Tidak Istimewa (2021)

• Perubahan kebutuhan dan ketidakpastian, pekerjaan berulang, serta solusi sementara yang sering dianggap sebagai ciri khas software juga umum dalam rekayasa tradisional; kedua ranah ini memiliki lebih banyak kesamaan daripada perbedaan
• Pembagian bahwa rekayasa tradisional adalah Waterfall dan software adalah Agile terlalu menyederhanakan. Pembuatan fisik memang lebih banyak memakai desain di awal karena biaya iterasinya besar, tetapi bidang terowongan, teknik sipil, dan elektronik juga memanfaatkan pengembangan bertahap dan adaptasi di lapangan
• Rekayasa tradisional juga menghadapi masalah yang membalikkan rencana, seperti pemasok bangkrut, perubahan peralatan manufaktur, atau karakteristik tanah yang tak terduga, sehingga sulit mengatakan bahwa hanya software yang secara khusus tidak dapat diprediksi
• Perbedaan sebenarnya terletak pada konsistensi tinggi dan perubahan cepat pada software, serta batasan yang relatif fleksibel. Produk fisik harus menerima variasi material dan keausan, batasan keras seperti kekuatan dan ukuran, serta perubahan yang sulit dibatalkan
• Perbaikan cepat memudahkan eksperimen dan verifikasi, tetapi juga bisa menekan orang untuk mengakali cacat fisik dengan kode. Setiap bidang rekayasa bisa belajar dari cara bidang lain merancang, memverifikasi, dan mengotomasi

---

Argumen defensif bahwa software itu istimewa

• Reservoir minyak bukan balon yang penuh minyak, melainkan struktur batuan berpori, sehingga sulit menentukan apakah kehilangan tekanan mendadak disebabkan oleh rongga lokal atau kebocoran yang menembus ke laut
  • Kulit hazelnut disuntikkan ke rongga kecil untuk mengisinya perlahan, menyeimbangkan tekanan, dan menguji apakah rongga itu berada di dalam struktur
  • Contoh bahwa perusahaan minyak di Norwegia adalah pembeli terbesar kulit hazelnut menunjukkan bahwa rekayasa tradisional pun bergantung pada material tak terduga dan respons di lapangan
• Saat membandingkan software dengan rekayasa tradisional, orang sering menilai software lebih rendah daripada rekayasa karena perbedaan lisensi atau ketelitian, sekaligus menjadikan software sebagai bidang khusus yang tidak bisa dipahami dalam kerangka rekayasa umum
• Argumen bahwa kebutuhan berubah luar biasa cepat sehingga perencanaan di awal dan metode rekayasa tidak perlu diterapkan berfungsi sebagai mekanisme defensif
  • Gerakan NoEstimates berusaha menghapus estimasi itu sendiri dengan alasan estimasi software sulit, berbeda dari rekayasa tradisional
• Namun sebagian besar masalah yang dianggap menyakitkan dalam software juga ada di bidang rekayasa lain, dan para insinyur yang pernah mengalami keduanya melihat hakikat kedua pekerjaan itu dekat

Lima perbedaan yang sering disebut

• Jika seluruh rekayasa tradisional diperlakukan sebagai satu ranah atau disamakan dengan teknik sipil, perbedaan antar-subbidangnya hilang
• Hal-hal yang sering disebut sebagai perbedaan umum antara software dan rekayasa tradisional adalah sebagai berikut
  • Rekayasa tradisional cocok dengan Waterfall, software cocok dengan Agile
  • Rekayasa tradisional dapat diprediksi, sedangkan software sulit diprediksi
  • Rekayasa terutama soal manufaktur dan kode adalah desain, sehingga “kode adalah desain”
  • Rekayasa tradisional lebih ketat daripada rekayasa software
  • Software bergerak jauh lebih cepat daripada rekayasa tradisional
• Sebagian memang memiliki perbedaan nyata, tetapi kebanyakan salah atau konteks inti yang diperlukan untuk menilainya tidak ada

Pembagian sederhana antara Waterfall dan Agile

• Menurut narasi yang dikenal luas, Winston Royce menciptakan Waterfall pada 1970 dengan meniru proses konstruksi, dan metode yang rentan terhadap perubahan kebutuhan ini digantikan oleh Agile Manifesto pada 2001
• Waterfall sebenarnya tidak sekaku atau seumum persepsi saat ini
  • Pada 1970–1980-an, developer memakai berbagai model bertahap seperti rencana sementara, Spiral Model, dan V Model
  • Agile lebih mirip hasil alami dari arus saat itu daripada revolusi yang terputus dari masa lalu
• Memang benar rekayasa tradisional memakai lebih banyak desain di awal dan waktu pengujian terpisah, tetapi itu berasal dari ekonomi biaya iterasi, bukan kekakuan Waterfall
  • Semakin banyak waktu dan biaya yang diperlukan untuk iterasi, semakin masuk akal merencanakan satu pekerjaan lebih lama
  • Jika papan sirkuit tidak bekerja sejak awal, papan itu harus dikirim kembali ke pabrik, yang bisa menambah biaya ribuan pound dan jadwal 2 minggu
• Batas antara desain dan implementasi juga tidak jelas
  • Model skala kecil milik insinyur sipil atau model tanah liat ukuran penuh yang dibuat insinyur otomotif untuk menguji estetika dan aerodinamika bisa dilihat sebagai desain sekaligus implementasi
• Industri lain juga memiliki cara kerja yang mirip Agile
  • New Austrian Tunneling Method bergantung pada pengembangan iteratif dan improvisasi di lapangan
  • Handbook of Industrial Engineering menekankan kolaborasi lintas departemen dan umpan balik pelanggan yang cepat
  • Teknik sipil pun, begitu konstruksi dimulai, bergeser ke komunikasi terbuka dan adaptasi untuk menangani masalah di lapangan

Rekayasa tradisional juga sulit diprediksi

• Jika hanya melihat jembatan atau produk yang sudah jadi, mudah melewatkan friksi, pembengkakan biaya, dan keterlambatan yang terjadi dalam prosesnya
  • Peristiwa seperti dinding yang dibangun meleset 1 inci atau pemasok utama bangkrut saja bisa mengguncang rencana
• Software tampak seperti mengalami pergantian framework atau bahasa dominan setiap 1–2 tahun, tetapi rekayasa tradisional juga mengalami perubahan alat dan lingkungan produksi
  • Jika foundry semikonduktor memperkenalkan peralatan manufaktur baru, rencana desain chip pun berubah
  • Meski tidak secepat library, itu bukan berarti tidak ada perubahan
• Hal-hal seperti kedaulatan wilayah berubah selama konstruksi, prosedur yang sudah teruji tiba-tiba gagal secara permanen, atau fakta baru ditemukan di tahap akhir pengembangan juga bisa terjadi
• Jika setelah memulai pekerjaan fondasi jembatan ditemukan bahwa tanah tertentu membeku berbeda dari perkiraan dan mencair berlebihan saat gempa, proyek harus dimulai ulang dari desain
• Gagasan bahwa hanya software yang secara khusus tidak dapat diprediksi muncul karena tidak melihat proses kerja nyata di bidang rekayasa lain

Klaim “kode adalah desain”

• “Kode adalah desain” adalah reaksi balik terhadap gagasan bahwa kita cukup membuat model sempurna dengan UML lalu menghasilkan kode secara otomatis
• Nick Coghlan, core developer CPython dan mantan insinyur integrasi sistem Boeing, melihat ini sebagai perbedaan mendasar antara software dan pekerjaan sebelumnya
  • Ia mengoordinasikan beberapa tim sistem independen seperti pesawat, kontrol lalu lintas udara, dan susunan antena agar membuat antarmuka yang kompatibel
• Bagi insinyur semikonduktor, seluruh proses dari skematik pertama CPU hingga chip final yang keluar dari foundry adalah desain, dan manufaktur bisa menjadi tahap yang relatif mudah: menyerahkan desain dan menerima chip
• Jika ada cacat pada chip atau produk mesin yang sudah jadi, desain harus diubah, sehingga desain dan pembuatan tidak terpisah
  • “Fettling” dalam teknik mesin adalah pekerjaan menyesuaikan desain dengan ketidaksempurnaan kecil dalam proses pembuatan
  • Pembuatan mengubah desain, dan desain yang berubah kembali mengubah pembuatan, menciptakan siklus
• Cakupan desain itu sendiri juga tidak jelas
  • Ikhtisar arsitektur, spesifikasi formal, dan gambar detail semuanya adalah desain pada tingkat yang berbeda
  • Dalam proyek kompleks seperti rencana desain jembatan, ada detail berulang pada banyak lapisan
• Karakteristik bahwa konstruksi memakan paling banyak waktu dan biaya berlaku untuk sebagian teknik sipil yang berpusat pada jembatan dan bangunan, dan tidak bisa digeneralisasi sebagai wajah seluruh rekayasa tradisional
• Teknik sipil pun mencakup berbagai bidang yang diperlukan untuk pembangunan kota, sehingga tidak terbatas pada jembatan dan bangunan

Kesalahpahaman tentang ketelitian

• Pembagian bahwa rekayasa tradisional bernalar hati-hati dari prinsip pertama, sedangkan software bergantung pada copy-paste, tidak mencerminkan pekerjaan sebenarnya
• Ketelitian software yang tampak relatif rendah bukan hanya masalah budaya, melainkan bisa berupa kompromi yang rasional berdasarkan sifat materialnya yang mudah diimplementasikan dan diuji
  • Cara termudah untuk memeriksa asumsi sering kali adalah mengimplementasikannya langsung lalu menjalankannya
  • Mengumpulkan informasi empiris dengan cepat juga merupakan bentuk verifikasi yang ketat
• Asumsi bahwa produk rekayasa tradisional lebih konsisten dan sistematis daripada software juga tidak tepat
  • Dalam pelestarian catatan dan verifikasi menyeluruh, software justru kadang lebih unggul
  • Banyak kasus informasi inti dalam rekayasa tradisional tersimpan di file Excel atau lemari arsip lama hingga menjadi usang atau rusak
  • Banyak insinyur rekayasa tradisional juga ingin menerapkan automated testing yang dianggap wajar dalam software
• Dalam struktur fisik pun, solusi sementara seperti menambahkan bracket terus digunakan bila diperlukan

Perbedaan nyata 1: konsistensi

• Karena software disintesis sepenuhnya dari logika dan tidak aus seperti pegas, software jauh lebih konsisten daripada hasil rekayasa lain
  • Jika sebuah fungsi sort hanya mengurutkan 95% daftar angka yang bukan input abnormal, sulit menganggapnya sebagai perilaku normal
• Pada material dan komponen fisik, variasi dari nilai teoretis pada dasarnya selalu ada
  • Resistor tersedia dari 1Ω hingga ratusan juta Ω, dan gelang warna menunjukkan nilai resistansi teoretis
  • Gelang hijau, biru, merah berarti 5.600Ω, tetapi jika ada gelang toleransi emas, nilai sebenarnya bisa berbeda hingga 5%
  • Dari 100 resistor yang sama, sebagian bisa bernilai 5.320Ω dan sebagian 5.880Ω, sehingga masing-masing harus diukur
  • Jika keausan dan perubahan suhu ikut dipertimbangkan, variasinya menjadi lebih kompleks
• Semua material fisik memiliki masalah serupa, dan produsen sekrup Fastenal juga memperingatkan agar sekrup baja tahan karat tidak digunakan pada pelat aluminium

Perbedaan nyata 2: kecepatan perubahan

• Software bisa diubah jauh lebih cepat daripada sistem rekayasa lain
  • Dalam rekayasa tradisional, setelah spesifikasi dibagikan, kita harus menunggu pembuatan dan pemasangan di pabrik atau bengkel mesin, lalu pengujian selama berminggu-minggu
  • Sebagian perubahan engineering memiliki biaya yang jelas, misalnya 5.000 dolar keluar dari anggaran setiap kali perubahan dilakukan
  • Setelah kode diubah, seluruh tes bisa dijalankan dalam hitungan detik
• Di antara bidang non-software, teknik kimia menunjukkan kecepatan yang paling mendekati, tetapi peralihan dalam satuan menit pun masih sulit dibayangkan
• Alasan bidang rekayasa lain semakin banyak memakai software untuk alat desain dan simulasi juga karena ide bisa diprototipekan dengan cepat sebelum implementasi
• Kemampuan berubah cepat juga punya sisi negatif
  • Jika masalah pada perangkat elektronik atau mekanis tidak terselesaikan sepenuhnya, tekanan akan terpusat pada insinyur software untuk melengkapinya dengan workaround kode
• Ketergantungan seperti ini bisa berujung fatal
  • Pada 2019, dua kecelakaan Boeing 737 MAX menewaskan lebih dari 300 orang
  • Investigasi menunjuk bug pada MCAS, sistem kontrol penerbangan otomatis, sebagai penyebab
  • Alih-alih memperbaiki masalah karakteristik aerodinamis pesawat yang terlambat ditemukan lewat desain fisik, Boeing menambahkan MCAS

Perbedaan nyata 3: batasan dan perubahan yang tak bisa dibatalkan

• Produk rekayasa tradisional memiliki batas fisik yang wajib dipatuhi, seperti berat, kekuatan, resistansi, dan suhu
  • Dalam desain chip, margin waktu yang setara dengan sepersekian nanodetik pun bisa dinegosiasikan dengan tim lain
• Software juga memiliki batasan seperti kapasitas memori, respons sensor dalam 10 siklus, dan batas pemanggilan API
• Namun batasan software sering kali berupa soft constraint: semakin dilampaui, keadaan memburuk, sehingga batasnya bisa sedikit disesuaikan demi kecepatan pengembangan atau algoritme yang sederhana
• Batasan rekayasa tradisional sering kali berupa hard constraint: jika dilampaui, produk tidak berfungsi
  • Kotak yang sedikit terlalu lebar saja tidak bisa melewati pintu
• Dalam kasus screw conveyor yang akan dipasang di fasilitas pengeboran minyak ternyata beberapa inci lebih tinggi daripada ruangan, peralatan tidak bisa diperkecil dan langit-langit tidak bisa dinaikkan karena ada empat lantai di atasnya
  • Mereka membuat lubang di langit-langit untuk memasukkan peralatan, lalu memasang kotak di sekitar lubang agar orang di lantai atas tidak tersandung
  • Perubahan ini tetap permanen pada struktur fasilitas dan harus terus diperhitungkan dalam semua perubahan berikutnya
• Insinyur software bisa membatalkan solusi sementara, tetapi solusi sementara fisik dalam rekayasa tradisional cenderung menjadi struktur permanen

Berbeda, tetapi tidak istimewa

• Software memiliki masalah keamanan yang khas, tetapi setiap bidang punya tantangan tersendiri: teknik sipil punya cuaca, teknik kimia punya karakteristik kimia
• Semua bidang rekayasa menghargai pemikiran abstrak di awal, pekerjaan yang tertata, dan solusi sementara yang tepat, sekaligus menghadapi kebutuhan yang berubah dan hal-hal tak diketahui
• Setiap bidang cukup terisolasi satu sama lain; sebagaimana insinyur software tidak mengenal teknik mesin, insinyur teknik kimia pun sulit mengetahui pekerjaan nyata di bidang rekayasa lain
• Karena software tidak istimewa, kita bisa belajar cara memperbaiki diri dari bidang rekayasa lain, dan rekayasa tradisional pun bisa belajar dari software dalam hal pencatatan, verifikasi, dan otomasi
• Tulisan lanjutan Apa yang bisa diajarkan rekayasa kepada kita dan apa yang bisa dipelajarinya dari kita membahas pelajaran konkret yang bisa dipertukarkan kedua pihak

[GN⁺]

Komentar di Lobste.rs

• Saya setuju dengan banyak bagian tulisan ini, tetapi terlalu optimistis terhadap ketelitian dalam rekayasa perangkat lunak. Bahkan sekarang, pengujian otomatis—terutama pengujian yang kokoh di beberapa lapisan—belum tentu menjadi bagian wajar dari proses pengembangan; ada yang menganggap developer sendiri sebagai satu-satunya pos pemeriksaan, atau organisasi memperlakukan prosedur sebagai hambatan lalu menghapusnya.
  Industri ini menciptakan ulang roda setiap beberapa tahun tanpa mensistematisasi praktik terbaik yang sudah terbukti. Hal-hal yang distandardisasi pun umumnya hanya berupa kosakata bersama yang longgar, dengan makna yang sangat berbeda antarperusahaan; contoh utamanya adalah “agile” atau “testing”. Banyak developer menganggap testing hanya sebatas unit test, sebagian memasukkan component dan integration test, tetapi di beberapa perusahaan, setelah hanya melewati itu saja, perangkat lunak langsung dideploy ke lingkungan produksi.
  Seperti komentar yang pernah saya tulis, dalam organisasi yang sehat, code review seharusnya menjadi salah satu dari beberapa prosedur yang bertanggung jawab atas kualitas, bukan gerbang tunggal yang menentukan deployment ke produksi. Di banyak tim dan perusahaan, proses quality assurance setelah code merge pada dasarnya sudah menghilang.
  Ini bukan soal mengencerkan tanggung jawab, melainkan menanamkan kualitas ke dalam proses sejak sebelum kode ditulis. Dibutuhkan sesi Three Amigos, tempat berbagai peran membahas spesifikasi dan kebutuhan; test-driven development; analisis statis yang terintegrasi ke IDE dan setiap tahap pemeriksaan; serta spesialis quality assurance dan otomasi pengujian yang terpisah dari developer.
  Dalam teknik sipil, satu orang tidak menjadi perancang jembatan, pelaksana konstruksi, sekaligus satu-satunya penanggung jawab. Ada banyak tahap, seperti perhitungan dan penyusunan dokumen, pemeriksaan ulang, persetujuan pemerintah, audit dan inspeksi selama konstruksi; bahkan rumah tinggal pun melalui gambar desain, persetujuan, izin, dan inspeksi. Bencana rekayasa pun sering kali merupakan kegagalan seluruh proses yang tidak tertahan di berbagai tahap.
  Jika ingin membandingkan pengembangan perangkat lunak dengan teknik sipil, kita juga harus mengakui bahwa tingkat prosedurnya sama sekali tidak setara. Sering kali, paling banter ia lebih mirip pengembang perumahan yang membangun rumah termurah sambil mengakali persyaratan hukum.

  • Di bidang rekayasa nyata pun, testing dilakukan jauh lebih sedikit daripada yang dibayangkan, dan neraka integrasi juga sangat menyakitkan.
  • Akan baik jika industri perangkat lunak lebih mementingkan kualitas, tetapi kedua bidang ini berbeda sejak dari biaya kegagalan. Jika perhitungan jembatan salah, orang bisa meninggal dan sulit diperbaiki tanpa membangun jembatan baru; sementara cacat perangkat lunak, meski dalam kasus luar biasa bisa menimbulkan korban jiwa, umumnya dapat diperbaiki.
    Karena itu, pada perangkat lunak umum—bukan bidang seperti perangkat lunak pengendali MRI—titik kompromi antara biaya testing/verifikasi dan efeknya niscaya berbeda dari teknik sipil.

• Ketiga tulisan itu bagus, jadi saya sarankan untuk dibaca. Diskusi-diskusi sebelumnya juga bisa dilihat bersama:
  https://lobste.rs/s/fv8swh/crossover_project (pengumuman proyek)
  https://lobste.rs/s/lmvroa/are_we_really_engineers (diskusi ulang)
  https://lobste.rs/s/8j8sdc/are_we_really_engineers (diskusi ulang lainnya)
  Ceramah ini dari Glenn Vanderburg juga sangat relevan.

• Perbedaan terbesar antara pengembangan perangkat lunak dan rekayasa tradisional adalah gesekan saat melakukan perubahan. Perangkat lunak relatif murah untuk diubah dan fleksibel, sehingga membuka kemungkinan yang benar-benar baru.
  Rekayasa tradisional pun, semakin banyak simulasi yang dibuat, dapat memperluas kemungkinan perubahan agar mirip dengan perangkat lunak, dalam batas-batas fisika dan kimia.
  Pernyataan “untuk fungsi pengurutan, kita tidak mengharapkan ia mengurutkan daftar angka yang tidak patologis hanya dengan probabilitas 95%” kini benar-benar berlaku untuk kode yang dihasilkan LLM. Sebagian besar berfungsi, tetapi tidak selalu.

• Saya penasaran mengapa ~hwayne menonaktifkan akunnya.

  • Menurut postingan di Bluesky dan konfirmasi ulang beberapa hari lalu, alasannya adalah istirahat kesehatan mental akibat media sosial.