Agile sedang membunuh inovasi perangkat lunak

• Di konferensi Black Hat, pendiri Signal, Moxie Marlinspike, berpendapat bahwa inovasi perangkat lunak telah menghilang selama 20 tahun terakhir karena pengembangan agile
• Ia menunjukkan bahwa para pengembang terjebak dalam "lapisan abstraksi kotak hitam" dan kehilangan kebebasan yang dibutuhkan untuk berinovasi
• "Siapa pun yang mengelola organisasi engineering kemungkinan memiliki filosofi manajemen yang merupakan subkonsep dari agile, turunan dari agile, berada dalam ranah agile, atau setidaknya terkait dengannya dalam satu atau lain cara"
  • Alih-alih bergerak dari bawah ke atas, dengan cara pengembang menggabungkan keahlian engineering dan visi untuk melihat kemampuan baru dari teknologi yang ada,
    ia berargumen bahwa tim Agile menjadi tersiloisasi (terisolasi) secara individual, bekerja terpisah satu sama lain, dan tidak bisa mengetahui apa yang sedang dikerjakan tim lain
• Selain itu, dalam sesi penutup, pendiri dan CEO Thistle Technologies, Window Snyder, menambahkan bahwa tim kotak hitam semacam ini juga cenderung kurang memiliki visibilitas terhadap prinsip kerja produk mereka sendiri
  • Snyder juga berpendapat bahwa mahasiswa yang belajar pemrograman tidak mempelajari cara berinteraksi dengan bahasa tingkat rendah atau kode mesin, melainkan hanya bahasa tingkat tinggi yang mempermudah pengembangan aplikasi, sehingga engineer tidak memiliki konteks yang dibutuhkan untuk memahami bagaimana potongan-potongan puzzle masuk ke dalam keseluruhan yang lebih besar dan saling terhubung

Peneliti keamanan memegang kunci inovasi

• Marlinspike juga mengatakan bahwa selama beberapa dekade terakhir, software engineering terus diabstraksikan agar lebih cepat, lebih fleksibel, dan terus melaju, sementara para peneliti keamanan justru berusaha melihat melampaui abstraksi itu
  • "Keamanan adalah proses melihat ke dalam hal-hal yang abstrak untuk memahami bagaimana sesuatu benar-benar bekerja, apa yang ada di bawahnya, dan kadang-kadang memahaminya lebih baik daripada orang yang pertama kali membuatnya"
• Karena itu, ia berpendapat bahwa peneliti keamanan memegang kunci untuk mendorong inovasi baru
• Ia juga membuat analogi bahwa memahami perangkat lunak seperti memahami sihir, dan para profesional keamanan adalah "orang-orang yang duduk di perpustakaan dan mempelajari sihir"

Opini GN⁺

• Ini adalah komentar Marlinspike yang tajam dan penuh wawasan, yang menyoroti masalah mendasar dalam agile
• Saya sepakat bahwa karena terlalu terobsesi pada abstraksi dan kecepatan pengembangan, para pengembang makin lama makin tidak memahami konsep-konsep dasar
• Bagian yang menyoroti peran peneliti keamanan sangat mengesankan. Karena keamanan adalah pekerjaan menggali realitas yang tersembunyi di balik abstraksi, hal ini bisa menjadi pendorong inovasi
• Dalam arti tertentu, ini menyampaikan pesan bahwa software engineer perlu mengejar pemahaman yang lebih mendalam
• Tentu saja agile juga memiliki kelebihan, jadi pendekatan yang seimbang akan diperlukan. Kita perlu mencari cara untuk tetap mempertahankan kelincahan dan fleksibilitas agile sambil memperkuat fondasi dasar
• Untuk itu, perbaikan perlu dimulai dari kurikulum pendidikan pengembang. Pendidikan mata pelajaran dasar seperti bahasa tingkat rendah dan arsitektur komputer perlu diperkuat, bukan hanya bahasa tingkat tinggi

[jeokrang]

Sepertinya mereka salah mengira masalah dari para manajer yang salah memahami Agile sebagai masalah Agile itu sendiri.

[yangeok]

Seiring arus zaman, karena mempelajari pengetahuan tingkat rendah tidak menghasilkan ROI, rasanya kita jadi berhenti hanya pada mempelajari pengetahuan tingkat tinggi saja.

[andrewchaa]

Mengapa repot-repot menyalahkan Agile yang tidak ada sangkut pautnya ...

[lordang]

Penjelasannya membingungkan karena mencampur konsep north-south dan east-west.
Rasanya, soal tidak tahu tim lain mengerjakan apa itu lebih merupakan masalah struktur organisasi cross-functional daripada Agile itu sendiri.

Kalau soal tidak terlalu paham low level, dari isinya malah terdengar seperti, "kalau begitu memang ada kecenderungan juga jadi kurang paham low level."

Meski soal tidak tahu tim lain mengerjakan apa mungkin masih ada sedikit kaitannya dengan Agile, saya benar-benar tidak paham apa hubungannya tidak paham low level dengan Agile wkwkwk

[lordang]

Kalau mau diperdebatkan, sepertinya yang lebih mendekati adalah karena open source sudah tersebar luas, jadi tidak perlu membuat semuanya sendiri, tidak perlu reinventing wheel, dan untuk sisi low level tinggal ambil dan pakai saja, sehingga orang justru tidak merasa perlu belajar.

Kalau mau mencoba memahami pernyataan itu, mungkin bisa dimengerti sebagai: karena agile orang hanya fokus membuat cepat jadi tidak belajar low level. Tapi bukankah yang lebih tepat adalah karena memang tidak diperlukan, jadi tidak dipelajari?

[bbulbum]

Saya juga merasa bahwa Agile cenderung mengabaikan pilihan yang membuat kita melihat masalah dari sudut pandang yang lebih luas dan menjaga keberlanjutan dalam jangka panjang, dan dari sisi perangkat lunak pun akhirnya membuat kita hanya fokus menyelesaikan masalah yang ada di depan mata.
Tentu, sekadar membuat sesuatu berjalan apa pun caranya bukanlah Agile, tetapi tampaknya memang ada kecenderungan untuk mengambil pilihan yang sangat menitikberatkan pada kecepatan, dan saya rasa hal ini bisa menjadi faktor yang membuat upaya mengejar pemahaman yang mendalam menjadi lebih sulit.

[savvykang]

Saya tidak mengerti mengapa orang mencoba mencari penyebab masalah tidak adanya kewenangan pengambilan keputusan di organisasi engineering pada agile.

[galadbran]

Situasi ketika tidak tahu apa yang sedang dikerjakan tim lain itu apa hubungannya dengan agile... ;;;

Tapi, nama Window Snyder memang sangat unik ya...

[xguru]

Saya ingin melihat video aslinya, tetapi sepertinya belum ada. Mungkin tidak lama lagi akan diunggah ke YouTube resmi
https://www.youtube.com/@BlackHatOfficialYT/

[GN⁺]

Opini Hacker News

• Struktur perusahaan modern adalah akar masalahnya

  • Ada teori manajemen modern yang menyatakan bahwa tanggung jawab dan pengambilan keputusan harus naik mengikuti hierarki perusahaan
  • Karyawan level bawah dianggap paling sedikit tahu tentang produk
  • Namun kenyataannya, karyawan di lapangan justru punya informasi paling banyak
  • Jika rekayasa perangkat lunak dijadikan proses lini perakitan, inovasi akan berhenti
  • Hierarki manajemen yang sepenuhnya setara bukan jawabannya, tetapi dibutuhkan cara agar karyawan di lapangan tidak dilumpuhkan
  • Buku <i>Reinventing Organisations</i> menjelaskan struktur perusahaan yang inovatif

• Ide-ide bagus dari agile telah diserap ke dalam rekayasa perangkat lunak secara umum

  • Programmer agile dianggap mengikuti stand-up meeting yang kaku, papan Kanban, dan sebagainya
  • Saya tidak berpikir agile menyebabkan pemecahan pengetahuan dan penurunan keterampilan dalam rekayasa perangkat lunak
  • Ini adalah masalah yang muncul karena kecenderungan menuju produksi massal
  • Fenomena serupa juga muncul di perusahaan mobil atau pabrik furnitur

• Keluhan tentang agile, scrum, dan OKR

  • Semuanya menjanjikan akan mendorong kebebasan dan tanggung jawab ke karyawan level bawah, tetapi pada praktiknya justru tersentralisasi
  • Saya ingin mencoba menerapkan OKR secara terbalik
  • Semua karyawan harus mendefinisikan hasil utama di wilayah mereka sendiri, dan manajer harus menetapkan arah tim berdasarkan itu
  • Dibutuhkan pendekatan bottom-up, bukan top-down
  • Perekrutan harus baik, pelatihan harus baik, dan karyawan harus dipercaya

• Pengalaman dalam rapat grooming backlog

  • Harus mengestimasi perbaikan bug pada kode yang tidak familiar
  • Karena sulit mengestimasi, saya hanya menyebut angka secara kasar
  • Agile dijalankan dengan cara yang mirip di tiga tempat

• Teori tentang masalah agile

  • Membagi pekerjaan menjadi bagian-bagian kecil memang bermanfaat, tetapi pemrograman membutuhkan kreativitas
  • Banyak informasi hilang dalam proses pemecahan pekerjaan
  • Developer harus menemukan solusi kreatif, tetapi tidak mendapatkan informasi yang diperlukan
  • Dibutuhkan developer yang berpengalaman atau diagram desain dan dokumentasi yang lebih baik

• Penurunan kualitas perangkat lunak

  • Perangkat lunak memburuk selama beberapa dekade terakhir
  • Kita memakai mesin yang lebih kuat, tetapi responsnya lebih lambat
  • Ini mungkin berkaitan dengan bangkitnya agile

• Engineer harus dibuat "memiliki" sebagian kode

  • Itulah masa ketika perangkat lunak tim berada pada kondisi terbaiknya

• Pengalaman menghindari rapat stand-up harian

  • Retrospektif dan pemecahan pekerjaan yang terus-menerus tidak efisien
  • Itu hanya bermanfaat bagi manajer nonteknis

• Masalah organisasi besar

  • Developer tidak lagi memimpin
  • Visi, produk, UX, dan manajemen proyek ditentukan dari atas
  • Developer bekerja menggunakan teknologi cloud
  • Mereka tidak bisa memahami gambaran besarnya atau memberi usulan penting

• Pendapat bahwa "keajaiban" dalam pengembangan perangkat lunak harus dikembalikan

  • Terlihat bahwa penulis sudah lebih dari 20 tahun berada di industri ini
  • Jika menghabiskan waktu dengan programmer muda, keajaiban itu masih ada
  • Keluhan serupa juga ada 20 tahun lalu, tetapi saat itu pekerjaan tetap terasa menyenangkan

[savvykang]

> Ada teori manajemen modern bahwa tanggung jawab dan pengambilan keputusan harus naik mengikuti hierarki perusahaan

Bukankah ini justru ciri organisasi yang birokratis?