Krisis Perangkat Lunak

Krisis Perangkat Lunak

• Apa itu krisis perangkat lunak?

  • Istilah "krisis perangkat lunak" pertama kali digunakan pada Konferensi Rekayasa Perangkat Lunak NATO pertama pada tahun 1968
  • Konferensi-konferensi ini merupakan salah satu upaya awal untuk mendefinisikan dan menata praktik pemrograman
  • Konferensi Rekayasa Perangkat Lunak NATO terakhir diadakan pada periode yang sama dengan peluncuran Apollo 11 pada tahun 1969

• Penyebab krisis perangkat lunak

  • Peraih Turing Award 1972, Edsger Dijkstra, menjelaskan penyebab krisis perangkat lunak sebagai meningkatnya kompleksitas dan kecepatan perangkat keras
  • "Semakin kuat mesin, semakin besar pula masalah pemrograman" - Edsger Dijkstra

• Krisis perangkat lunak saat ini

  • Saat ini, krisis perangkat lunak tidak lagi banyak dibicarakan
  • Orang menganggap masalahnya telah terpecahkan berkat pengembangan bahasa baru dan metode pengorganisasian baru
  • Namun, ini mungkin berasal dari rasa kalah dan penerimaan, bukan dari kenyamanan yang sesungguhnya

• Masalah abstraksi

  • Berbagai upaya telah dilakukan untuk mengatasi krisis perangkat lunak, tetapi sebagian besar mencoba menyelesaikannya melalui "abstraksi"
  • Abstraksi memberikan tingkat kemandirian tertentu dengan mengorbankan performa
  • Setelah komersialisasi komputer pribadi, abstraksi menjadi cara berpikir yang mendasar

• Kesenjangan antara pengembang dan pengguna

  • Krisis perangkat lunak tidak hanya memengaruhi orang yang membuat perangkat lunak, tetapi juga orang yang menggunakannya
  • Pengguna hampir tidak memiliki kendali selain atas apa yang disediakan oleh pembuatnya
  • Alan Perlis: "Jika Anda punya ide bagus, Anda harus siap untuk bertanggung jawab"

• Ketiadaan tanggung jawab

  • Pembuat perangkat lunak terbebas dari tanggung jawab atas alat yang mereka buat
  • Seiring berjalannya komersialisasi, kecenderungan ini makin menguat
  • Abstraksi digunakan sebagai alat untuk menghindari pemikiran yang sulit

• Solusi

  • Solusi untuk krisis perangkat lunak bukanlah kembali ke platform yang lebih terbatas, melainkan membatasi jumlah lapisan abstraksi dan menuntut pelestarian informasi
  • Model pemrograman, antarmuka pengguna, dan perangkat keras dasar harus dangkal dan dapat dikomposisikan
  • Pengguna alat harus diberdayakan

• Pergerakan saat ini

  • Ada gerakan seperti Handmade, Permacomputing, dan retro computing untuk meningkatkan kesadaran terhadap krisis perangkat lunak
  • Gerakan kontra-budaya ini merupakan sinyal yang sehat dan menunjukkan bahwa keadaan bisa membaik

Ringkasan GN⁺

• Krisis perangkat lunak adalah masalah yang muncul akibat meningkatnya kompleksitas dan kecepatan perangkat keras
• Saat ini, masalah tersebut dicoba diatasi melalui abstraksi, tetapi itu harus dibayar dengan performa
• Pembuat perangkat lunak terbebas dari tanggung jawab atas alat yang mereka buat, dan hal ini diperkuat oleh komersialisasi
• Solusinya adalah membatasi jumlah lapisan abstraksi dan menuntut pelestarian informasi
• Gerakan seperti Handmade dan Permacomputing meningkatkan kesadaran terhadap krisis perangkat lunak

[GN⁺]

Pendapat Hacker News

• Pendapat penulis

  • Menentang bukan abstraksi itu sendiri, melainkan penerapannya yang tanpa batas
  • Tidak mengajukan kembalinya platform yang lebih terbatas sebagai solusi
  • Tidak berpendapat bahwa pengguna harus menjadi "lebih teknis"
  • Untuk memahami krisis perangkat lunak, perlu memahami kurva "kemahiran platform" dan "siklus pertumbuhan/rilis"
  • Tulisan ini bukan clickbait, melainkan cerminan situasi sebagai seorang pengembang
  • Ingin menawarkan sebagian dari solusi dan sedang merencanakan tulisan lanjutan

• Krisis perangkat lunak

  • Mencakup masalah seperti anggaran proyek yang membengkak, jadwal yang molor, perangkat lunak yang tidak efisien, kualitas rendah, tidak memenuhi kebutuhan, sulit dipelihara, hingga perangkat lunak yang tidak pernah dikirimkan
  • Perangkat lunak yang berhasil diabaikan, sementara kegagalan dan cacatlah yang mendapat perhatian
  • Sebuah komputer melewati ratusan lapisan abstraksi sebelum sampai ke desktop, dan ini terjadi miliaran kali setiap hari di seluruh dunia

• Pengembangan perangkat lunak dan kepemimpinan

  • Kepemimpinan di perusahaan otomotif menekankan pengetahuan teknis, tetapi dalam pengembangan perangkat lunak agile, kompetensi teknis berhenti di lapisan bawah
  • Pengembang perangkat lunak bekerja per tiket tanpa pertimbangan filosofis, dan tidak dipromosikan ke peran kepemimpinan
  • Kesadaran terhadap krisis perangkat lunak kemungkinan besar terbatas pada aktivitas hobi

• Kebutuhan akan abstraksi

  • Abstraksi adalah alat yang esensial, dan yang menjadi masalah adalah abstraksi yang buruk atau jumlah abstraksi yang terlalu banyak
  • Pengembangan perangkat lunak kini menjadi lebih mudah dan dokumentasinya juga lebih baik

• Alat dan informasi

  • Jika mengetahui alat yang tepat, pengembangan perangkat lunak menjadi sangat mudah
  • Alat yang diketahui kebanyakan orang umumnya tidak bagus, dan ada pengaruh modal yang besar
  • Sebagai contoh, pernah dibuat video membangun aplikasi marketplace yang kompleks dalam lingkungan serverless hanya dalam 3 jam, tetapi penontonnya sedikit

• GUI dan komposabilitas

  • Saat menggunakan alat UNIX, kita mendapatkan pengalaman yang dangkal tetapi dapat dikombinasikan
  • GUI tidak saling berkomunikasi dan tidak dapat dikomposisikan
  • Sedang bereksperimen dengan alat yang menggabungkan GUI dan pipeline shell

• Pentingnya perangkat lunak

  • Sebagian besar perangkat lunak tidak bersifat kritis fatal, sehingga kualitas yang rendah pun sering tidak menjadi masalah besar
  • Sebagian besar pengembang perangkat lunak bekerja tanpa motivasi seperti yang ada di Silicon Valley

• Modularitas dan abstraksi

  • Sistem kompleks seperti internet dipertahankan melalui abstraksi berlapis
  • Alat perangkat lunak telah banyak membaik sejak tahun 70-an
  • Misalnya, dengan menggunakan copilot di VSCode, seluruh API dapat dilengkapi otomatis

• Krisis manajemen proyek

  • Yang ada bukan krisis perangkat lunak, melainkan krisis manajemen proyek
  • Ada kesenjangan antara pihak yang merencanakan dan pihak yang mengeksekusi
  • Komersialisasi pengembangan perangkat lunak memungkinkan orang dari berbagai tingkat kemampuan untuk ikut terlibat
  • Ini mirip dengan industri makanan, dan kita tidak menyebutnya sebagai krisis restoran