Hukum-Hukum Rekayasa Perangkat Lunak

 (lawsofsoftwareengineering.com)
132 poin oleh GN⁺ 2026-04-22 | 2 komentar | Bagikan ke WhatsApp
  • Koleksi yang menghimpun 56 prinsip dan pola yang memengaruhi sistem perangkat lunak, tim, dan pengambilan keputusan di satu tempat, mencakup spektrum luas dari operasional tim hingga arsitektur, kualitas, desain, dan pengambilan keputusan
  • Hukum-hukum terkait tim seperti Hukum Conway, Hukum Brooks, dan Angka Dunbar menunjukkan bahwa struktur organisasi secara langsung memengaruhi desain sistem dan produktivitas
  • Di ranah arsitektur, dirangkum batasan dan prinsip yang wajib dipertimbangkan saat merancang sistem kompleks, seperti Hukum Hyrum, teorema CAP, dan Hukum Gall
  • Hukum-hukum terkait kualitas membahas utang teknis, piramida pengujian, Hukum Kernighan, dan kesulitan nyata dalam menjaga kualitas kode serta debugging
  • Di ranah pengambilan keputusan, dibahas efek Dunning-Kruger, kekeliruan biaya hangus, prinsip Pareto, dan bias kognitif serta tolok ukur penilaian yang mudah menjebak selama proses pengembangan

Tim (Teams)

1. Hukum Conway (Conway's Law)

Organisasi merancang sistem yang mencerminkan struktur komunikasinya sendiri

  • Arsitektur perangkat lunak secara alami cenderung mengikuti struktur komunikasi organisasi yang membuatnya
  • Jika tim terbagi menjadi 3, sistem juga cenderung terbagi menjadi 3 modul besar
  • Ada juga "strategi Conway terbalik" (Inverse Conway Maneuver), yaitu pendekatan menata ulang struktur tim terlebih dahulu agar sesuai dengan arsitektur yang diinginkan
  • Saat mengadopsi microservices, menyelaraskan batas tim dan batas layanan adalah langkah yang efektif

2. Hukum Brooks (Brooks's Law)

Menambahkan tenaga kerja ke proyek perangkat lunak yang terlambat justru membuatnya semakin terlambat

  • Saat personel baru bergabung, anggota tim yang sudah ada menghabiskan waktu untuk pelatihan dan koordinasi, sehingga produktivitas total sementara menurun
  • Ketika jumlah anggota tim bertambah, jalur komunikasi meningkat secara eksponensial (untuk n orang menjadi n(n-1)/2)
  • Diformulasikan oleh Frederick Brooks dalam buku tahun 1975 The Mythical Man-Month berdasarkan pengalamannya di proyek IBM OS/360
  • Dapat dijelaskan secara kuantitatif dengan Hukum Little (L = λ × W): saat personel ditambah, WIP (pekerjaan yang sedang berlangsung) meningkat, tetapi throughput stagnan sehingga lead time justru bertambah
  • Solusinya bukan menambah orang, melainkan menyesuaikan cakupan atau mengubah jadwal

3. Angka Dunbar (Dunbar's Number)

Batas kognitif hubungan yang dapat dipertahankan seseorang secara stabil adalah sekitar 150 orang

  • Angka yang diturunkan Robin Dunbar dari korelasi antara ukuran otak primata dan ukuran kelompok sosial
  • Struktur hierarki sosial Dunbar: ~5 orang (hubungan dekat), ~15 orang (kolaborator tepercaya), ~50 orang (hubungan kerja dekat), ~150 orang (koneksi sosial stabil)
  • Jika organisasi engineering melebihi 150 orang, komunikasi informal mencapai batasnya sehingga diperlukan hierarki dan proses formal
  • "Two-Pizza Team" Amazon (5~10 orang) mencerminkan bahwa bahkan dalam lingkup 150 orang, kolaborasi nyata terjadi dalam unit yang lebih kecil

4. Efek Ringelmann (The Ringelmann Effect)

Semakin besar ukuran grup, semakin menurun produktivitas individu

  • Fenomena "kemalasan sosial" (social loafing), di mana kontribusi tiap individu menurun seiring bertambahnya anggota grup
  • Dalam tim perangkat lunak, ketika ukuran tim membesar, rasa tanggung jawab individu memudar dan biaya koordinasi meningkat
  • Menjelaskan mengapa tim kecil menghasilkan output per orang yang lebih tinggi

5. Hukum Price (Price's Law)

Sejumlah orang yang setara dengan akar kuadrat dari total peserta melakukan 50% dari seluruh pekerjaan

  • Dalam organisasi beranggotakan 100 orang, sekitar 10 orang menangani separuh dari seluruh pekerjaan
  • Semakin besar organisasi, semakin kuat ketergantungan pada sejumlah kecil orang berkinerja tinggi
  • Menjelaskan mengapa produktivitas tidak meningkat secara linear saat tim diperbesar

6. Hukum Putt (Putt's Law)

Orang yang memahami teknologi tidak mengelola, dan orang yang mengelola tidak memahami teknologi

  • Ungkapan satir tentang kesenjangan antara peran manajerial dan keahlian teknis dalam organisasi teknologi
  • Saat merancang struktur kepemimpinan teknis, kesenjangan ini perlu disadari dan dilengkapi mekanisme kompensasi

7. Prinsip Peter (Peter Principle)

Dalam organisasi, semua karyawan cenderung dipromosikan hingga mencapai tingkat ketidakmampuannya sendiri

  • Pola ketika seseorang yang kompeten di peran tertentu dipromosikan lalu menjadi tidak kompeten di peran barunya
  • Mencerminkan kenyataan bahwa developer hebat belum tentu menjadi manajer yang baik
  • Menunjukkan perlunya sistem dual ladder yang memisahkan jalur IC (Individual Contributor) dan jalur manajemen

8. Bus Factor

Jumlah minimum anggota tim yang jika keluar dapat membuat proyek menghadapi risiko serius

  • Jika Bus Factor bernilai 1, berarti ada single point of failure
  • Penting untuk meningkatkan Bus Factor melalui berbagi pengetahuan, pair programming, dan dokumentasi
  • Code review dan cross-training adalah cara praktis untuk memperbaiki Bus Factor

9. Prinsip Dilbert (Dilbert Principle)

Perusahaan cenderung mempromosikan karyawan yang tidak kompeten ke posisi manajerial untuk membatasi dampak kerugiannya

  • Pengamatan satir yang diajukan Scott Adams, sebagai variasi dari Prinsip Peter
  • Fenomena organisasi yang paradoksal, di mana posisi manajerial dianggap sebagai tempat yang menimbulkan paling sedikit kerugian terhadap kerja praktik
Iklan

Perencanaan (Planning)

10. Optimisasi prematur / Prinsip optimisasi Knuth (Premature Optimization)

Optimisasi prematur adalah akar dari segala kejahatan

  • Diajukan Donald Knuth dalam makalah tahun 1974: "dalam sekitar 97% kasus, efisiensi kecil seharusnya diabaikan"
  • Karena sekitar 20% kode menghabiskan 80% waktu eksekusi, mengoptimalkan 80% kode sisanya adalah pemborosan
  • Urutan yang benar: buat agar berjalan terlebih dahulu → buat agar benar → lalu buat cepat jika memang perlu
  • Karena kode yang dioptimalkan menjadi lebih kompleks, optimisasi sebaiknya dilakukan setelah memeriksa bottleneck yang nyata lewat profiling

11. Hukum Parkinson (Parkinson's Law)

Pekerjaan akan meluas hingga memenuhi seluruh waktu yang diberikan

  • Jika deadline-nya 2 minggu maka pekerjaan akan melebar selama 2 minggu, jika 4 minggu maka selama 4 minggu
  • Menjelaskan mengapa penetapan milestone yang singkat dan jelas penting dalam proyek perangkat lunak
  • Agile berbasis sprint adalah respons praktis terhadap hukum ini

12. Aturan 90-90 (The Ninety-Ninety Rule)

90% pertama dari kode menghabiskan 90% waktu pengembangan, dan 10% sisanya menghabiskan 90% waktu lainnya

  • Memperingatkan bahwa 10% terakhir proyek perangkat lunak—edge case, polishing, dan perbaikan bug—memakan waktu jauh lebih lama dari perkiraan
  • Ucapan "hampir selesai" dalam kenyataannya bisa jadi baru berada di titik setengah dari keseluruhan jadwal

13. Hukum Hofstadter (Hofstadter's Law)

Selalu memakan waktu lebih lama dari perkiraan, bahkan jika Hukum Hofstadter sudah diperhitungkan

  • Hukum dengan struktur referensi-diri rekursif yang menggambarkan kesulitan mendasar dalam mengestimasi jadwal perangkat lunak
  • Kenyataan bahwa meski buffer ditambahkan, jadwal tetap terlampaui
  • Diperkenalkan Douglas Hofstadter dalam buku tahun 1979 Gödel, Escher, Bach

14. Hukum Goodhart (Goodhart's Law)

Ketika sebuah metrik menjadi target, ia tidak lagi menjadi metrik yang baik

  • Contoh yang representatif adalah ketika code coverage dijadikan KPI sehingga memicu lahirnya pengujian yang tidak bermakna
  • Jika produktivitas diukur dengan jumlah baris kode (LOC), maka akan dihasilkan kode yang bertele-tele dan tidak perlu
  • Fokus harus pada pencapaian nilai yang esensial, bukan pada optimisasi metrik

15. Hukum Gilb (Gilb's Law)

Untuk hal yang perlu dikuantifikasi, mengukurnya dengan cara apa pun lebih baik daripada tidak mengukurnya sama sekali

  • Walaupun pengukuran sempurna tidak mungkin, pengukuran kasar tetap selalu lebih berguna daripada tidak ada pengukuran
  • Berlaku juga untuk hal-hal yang sulit dikuantifikasi seperti kualitas perangkat lunak dan kepuasan pengguna

Arsitektur (Architecture)

16. Hukum Hyrum (Hyrum's Law)

Jika pengguna API cukup banyak, seseorang akan bergantung pada setiap perilaku sistem yang dapat diamati

  • Bukan hanya spesifikasi API resmi, tetapi juga perilaku tidak resmi seperti timing, format pesan error, urutan pengurutan menjadi objek ketergantungan
  • Contoh Microsoft Windows yang mempertahankan perilaku versi lama demi kompatibilitas aplikasi pihak ketiga yang bergantung pada perilaku dan bug yang tidak terdokumentasi di masa lalu
  • Diamati oleh Hyrum Wright dari Google berdasarkan pengalaman mengubah library internal Google sekitar 2011–2012
  • Rekannya, Titus Winters, memberi nama "Hyrum's Law" (Software Engineering at Google)
  • Kontrak yang sesungguhnya bukan API resmi, melainkan seluruh perilaku nyata yang dapat diamati

17. Hukum Gall (Gall's Law)

Sistem kompleks yang berfungsi pasti merupakan hasil evolusi dari sistem sederhana yang berfungsi

  • Jika sistem kompleks dirancang sejak awal, ada terlalu banyak variabel tak dikenal yang belum tervalidasi sehingga kemungkinan gagalnya tinggi
  • Landasan teoretis bagi pendekatan MVP (Minimum Viable Product)
  • Contoh Facebook yang dimulai pada 2004 sebagai sistem profil sederhana untuk mahasiswa Harvard lalu berkembang secara bertahap
  • Bahkan saat beralih ke microservices, memulai dari monolit lalu memisahkannya secara bertahap lebih menguntungkan
  • Diajukan oleh John Gall dalam buku Systemantics pada 1975 (menjadi cult classic setelah ditolak 30 penerbit)

18. Hukum Abstraksi yang Bocor (The Law of Leaky Abstractions)

Setiap abstraksi yang non-trivial akan mengalami kebocoran sampai tingkat tertentu

  • ORM menyembunyikan SQL, tetapi ketika muncul masalah performa, situasi umum yang terjadi adalah tetap harus memeriksa query yang dihasilkan
  • Garbage collection di Java/Python juga merupakan abstraksi, tetapi perilaku internal seperti jeda GC memengaruhi performa
  • Pelajarannya bukan bahwa abstraksi itu buruk, melainkan bahwa kita harus bersiap saat abstraksi itu rusak
  • Diperkenalkan Joel Spolsky dalam posting blog tahun 2002 bersama contoh seperti TCP dan virtual memory
  • Juga terkait konteksnya dengan pernyataan George Box: "semua model itu salah, tetapi sebagian berguna"

19. Hukum Tesler / Hukum Pelestarian Kompleksitas (Tesler's Law)

Setiap aplikasi memiliki kompleksitas bawaan yang tidak dapat dihilangkan; kompleksitas itu hanya bisa dipindahkan, bukan dihapus

Iklan
  • Pertanyaan intinya: siapa yang akan menanggung kompleksitas itu (pengguna vs sistem)
  • Calendly menyerap kompleksitas penjadwalan ke dalam sistem, sedangkan email thread membebankannya kepada pengguna
  • Desain yang baik memindahkan kompleksitas dari pengalaman pengguna ke dalam sistem internal
  • Diformulasikan Larry Tesler pada 1980-an saat mengerjakan Apple Lisa dan GUI awal

20. Teorema CAP (CAP Theorem)

Sistem terdistribusi hanya dapat menjamin dua dari tiga hal: konsistensi (C), ketersediaan (A), dan toleransi partisi (P)

  • Partisi jaringan tidak dapat dihindari di dunia nyata, sehingga pilihan praktisnya adalah konsistensi vs ketersediaan
  • Sistem CP (misalnya: MongoDB): saat partisi terjadi, penulisan diblokir untuk menjaga sinkronisasi semua replika
  • Sistem AP (misalnya: Cassandra, DNS): tetap merespons permintaan selama partisi, dengan mengizinkan ketidakkonsistenan sementara antar replika
  • Diajukan Eric Brewer pada 2000 dalam konteks web service, lalu dibuktikan secara formal oleh Gilbert & Lynch pada 2002

21. Efek Sistem Kedua (Second-System Effect)

Setelah sistem kecil yang sukses, sering muncul kecenderungan membuat sistem lanjutan yang gemuk dan terlalu dirancang

  • Karena percaya diri setelah sukses dengan sistem pertama, pola yang muncul adalah menuangkan semua ide ke dalam sistem kedua
  • Penyebab utamanya adalah feature creep dan over-generalization
  • Diidentifikasi oleh Frederick Brooks dalam The Mythical Man-Month

22. Kekeliruan dalam Komputasi Terdistribusi (Fallacies of Distributed Computing)

Delapan asumsi keliru yang sering dimiliki orang ketika pertama kali merancang sistem terdistribusi

  • 8 kekeliruan: (1) jaringan dapat diandalkan, (2) latensi adalah 0, (3) bandwidth tidak terbatas, (4) jaringan aman, (5) topologi tidak berubah, (6) hanya ada satu administrator, (7) biaya transport adalah 0, (8) jaringan itu homogen
  • Jika desain dibangun di atas asumsi ini, maka di production akan muncul gangguan dan masalah performa yang tidak terduga

23. Hukum Konsekuensi yang Tidak Diinginkan (Law of Unintended Consequences)

Saat sistem kompleks diubah, hasil yang tidak terduga harus diantisipasi

  • Mengubah satu komponen dalam sistem dapat menimbulkan efek samping di tempat yang tidak terduga
  • Prinsip yang mendukung perlunya chaos engineering dan testing yang komprehensif

24. Hukum Zawinski (Zawinski's Law)

Setiap program akan berusaha berkembang sampai bisa membaca email

  • Menyindir fenomena pembengkakan fitur (feature bloat), ketika software yang sukses ingin terus menambahkan makin banyak fitur
  • Diamati oleh Jamie Zawinski (pengembang awal Netscape)
  • Peringatan terhadap kecenderungan alat sederhana yang seiring waktu ingin berubah menjadi platform serbabisa

Kualitas (Quality)

25. Aturan Boy Scout (The Boy Scout Rule)

Tinggalkan kode dalam kondisi yang lebih baik daripada saat kamu menemukannya

  • Yang penting bukan refactoring besar-besaran, melainkan perbaikan yang berkelanjutan dan bertahap
  • Mempraktikkan perbaikan kecil setiap kali, seperti memperbaiki nama fungsi yang membingungkan, menghapus kode duplikat, atau menambahkan test yang hilang
  • Diterapkan ke pengembangan perangkat lunak oleh Robert C. Martin (Uncle Bob) dalam Clean Code (2008)
  • Prinsip para engineer Google: "If you touch it, you own it" — jika kamu mengubah kode, kamu juga mengambil tanggung jawab atas kualitasnya
  • Menerapkan aturan ini membantu mencegah efek jendela pecah (Broken Windows) dan akumulasi utang teknis

26. Hukum Murphy (Murphy's Law)

Apa pun yang bisa salah pasti akan salah

  • Menjadi dasar bagi defensive programming, exception handling, dan desain yang siap menghadapi kegagalan
  • Dalam software, kita perlu merancang error handling dan fallback dengan sikap bahwa "error yang mungkin terjadi pasti akan terjadi"

27. Hukum Postel / Prinsip Robustness (Postel's Law)

Bersikap konservatif dalam apa yang kamu lakukan, dan bersikap longgar terhadap apa yang kamu terima dari orang lain

  • Dalam desain API, prinsipnya adalah output harus ketat mengikuti spesifikasi, sedangkan input menerima beragam format secara fleksibel
  • Prinsip robustness yang dirumuskan Jon Postel saat merancang protokol TCP/IP
  • Pedoman praktis untuk meningkatkan interoperabilitas antarsistem

28. Teori Jendela Pecah (Broken Windows Theory)

Jangan membiarkan desain buruk, keputusan yang salah, atau kode berkualitas rendah dibiarkan begitu saja

  • Jika satu "jendela pecah" (kode buruk) dibiarkan, itu akan memicu penurunan kualitas tambahan
  • Jika komentar TODO, dead code, dan warning yang belum terselesaikan menumpuk di codebase, kode baru pun cenderung ditulis dengan standar yang rendah
  • Budaya memperbaiki masalah kecil segera setelah ditemukan itu penting
Iklan

29. Utang Teknis (Technical Debt)

Semua faktor yang memperlambat kecepatan pengembangan perangkat lunak

  • Ward Cunningham pertama kali menggunakan metafora finansial ini pada OOPSLA 1992: mengambil jalan pintas dalam kode berarti meminjam waktu dari masa depan
  • Pokok (biaya perbaikan) + bunga (penurunan produktivitas berkelanjutan akibat kode yang berantakan)
  • Utang teknis yang disengaja kadang rasional (timing peluncuran ke pasar, prototyping), tetapi rencana pelunasan tetap wajib
  • Contoh khasnya adalah melewatkan automated testing: rilis berhasil, tetapi setiap perubahan berikutnya memunculkan bug tak terduga
  • Cara mengatasinya: refactoring, menambahkan test yang hilang, memperbaiki desain

30. Hukum Linus (Linus's Law)

Dengan jumlah peninjau yang cukup banyak, semua bug akan mudah ditemukan

  • Prinsip inti pengembangan open source: banyak pasang mata yang meninjau kode akan membuat bug menjadi masalah sepele
  • Dinamai oleh Eric Raymond dalam The Cathedral and the Bazaar dari nama Linus Torvalds
  • Mendukung pentingnya budaya code review

31. Hukum Kernighan (Kernighan's Law)

Debugging dua kali lebih sulit daripada menulis kode itu sejak awal

  • Karena itu, jika Anda menulis kode secerdas mungkin, Anda tidak akan cukup cerdas saat harus melakukan debugging
  • Ini alasan mengapa kita harus menulis kode sederhana dengan keterbacaan tinggi
  • Diajukan oleh Brian Kernighan dalam The Elements of Programming Style

32. Piramida Pengujian (Testing Pyramid)

Sebuah proyek sebaiknya memiliki banyak unit test yang cepat, sedikit integration test, dan hanya segelintir UI test

  • Unit test (bagian bawah): cepat, berbiaya rendah, ditulis paling banyak
  • Integration test (bagian tengah): memverifikasi interaksi antar komponen
  • UI/E2E test (bagian atas): lambat dan mudah rusak, jadi harus diminimalkan
  • Model strategi pengujian yang diperkenalkan Mike Cohn dalam Succeeding with Agile

33. Paradoks Pestisida (Pesticide Paradox)

Jika pengujian yang sama dijalankan berulang kali, efektivitasnya akan menurun seiring waktu

  • Karena bug yang bisa ditangkap oleh pengujian yang ada pada dasarnya sudah tertangkap, test case baru harus terus ditambahkan
  • Meninjau dan memperbarui set pengujian secara berkala adalah hal yang wajib

34. Hukum Evolusi Perangkat Lunak Lehman (Lehman's Laws of Software Evolution)

Perangkat lunak yang mencerminkan dunia nyata harus berevolusi, dan evolusi itu memiliki batasan yang dapat diprediksi

  • Perangkat lunak tipe E (yang mencerminkan dunia nyata) tak terelakkan harus terus berubah agar tetap bisa digunakan
  • Setiap perubahan meningkatkan kompleksitas, dan jika tidak dikelola secara aktif, kualitas akan menurun

35. Hukum Sturgeon (Sturgeon's Law)

90% dari segala sesuatu itu tidak berguna

  • Diajukan oleh Theodore Sturgeon sebagai tanggapan terhadap kritik sastra fiksi ilmiah
  • Berlaku juga pada perangkat lunak: dari sebagian besar kode, alat, dan framework, hanya sedikit yang benar-benar hebat
  • Perlu menjaga standar kualitas yang tinggi dan fokus pada 10% yang bernilai

Skala (Scale)

36. Hukum Amdahl (Amdahl's Law)

Peningkatan kecepatan dari paralelisasi dibatasi oleh proporsi pekerjaan yang tidak dapat diparalelkan

  • Jika 5% program bersifat sekuensial, berapa pun banyaknya prosesor yang ditambahkan, peningkatan kecepatan maksimum teoritis hanya 20x
  • Menyadari batas paralelisasi dan mengurangi bottleneck sekuensial lebih efektif
  • Diajukan oleh Gene Amdahl pada 1967

37. Hukum Gustafson (Gustafson's Law)

Dengan memperbesar ukuran masalah, peningkatan kecepatan yang signifikan dapat dicapai dalam pemrosesan paralel

  • Sudut pandang pelengkap terhadap Hukum Amdahl: pada masalah yang dapat diskalakan, bukan masalah tetap, penambahan prosesor efektif
  • Dalam pemrosesan big data, simulasi ilmiah, dan sebagainya, lebih banyak resource memungkinkan kita menyelesaikan masalah yang lebih besar

38. Hukum Metcalfe (Metcalfe's Law)

Nilai sebuah jaringan sebanding dengan kuadrat jumlah penggunanya

Iklan
  • Jika pengguna berjumlah 10, nilainya menjadi 100 unit; jika 100, menjadi 10.000 unit
  • Dasar teoretis dari efek jaringan pada social network, messenger, marketplace, dan lain-lain
  • Diajukan oleh Robert Metcalfe untuk menjelaskan nilai teknologi Ethernet

Desain (Design)

39. Prinsip DRY (Don't Repeat Yourself)

Setiap pengetahuan harus memiliki satu representasi yang tunggal, jelas, dan otoritatif

  • Mencakup bukan hanya duplikasi kode, tetapi juga duplikasi pengetahuan, logika, dan data
  • Duplikasi menyebabkan bug dan inkonsistensi karena perubahan mengharuskan perbaikan di banyak tempat sekaligus
  • Diformalkan oleh Andy Hunt dan Dave Thomas dalam The Pragmatic Programmer

40. Prinsip KISS (Keep It Simple, Stupid)

Desain dan sistem harus sesederhana mungkin

  • Kompleksitas meningkatkan biaya pemahaman, pemeliharaan, dan debugging
  • Solusi yang sederhana dalam kebanyakan kasus lebih efektif dan juga memiliki kemungkinan cacat yang lebih rendah
  • Berasal dari prinsip desain yang diajukan Angkatan Laut AS pada 1960-an

41. Prinsip SOLID (SOLID Principles)

Lima panduan inti untuk meningkatkan desain perangkat lunak

  • S — Single Responsibility Principle: kelas hanya berubah karena satu alasan
  • O — Open-Closed Principle: harus terbuka untuk ekstensi dan tertutup untuk modifikasi
  • L — Liskov Substitution Principle: subtype harus dapat menggantikan supertype
  • I — Interface Segregation Principle: klien tidak boleh bergantung pada interface yang tidak digunakannya
  • D — Dependency Inversion Principle: modul tingkat tinggi tidak bergantung pada modul tingkat rendah, melainkan pada abstraksi
  • Diformalkan oleh Robert C. Martin, dan singkatan SOLID dinamai oleh Michael Feathers

42. Hukum Demeter (Law of Demeter)

Objek seharusnya hanya berinteraksi dengan teman langsungnya, dan menghindari komunikasi langsung dengan objek asing

  • Prinsip yang menyatakan bahwa pemanggilan berantai seperti a.getB().getC().doSomething() harus dihindari
  • Menurunkan coupling dan memperkuat enkapsulasi, sehingga mengurangi cakupan dampak perubahan
  • Juga disebut "prinsip pengetahuan minimum"

43. Prinsip Least Astonishment (Principle of Least Astonishment)

Perangkat lunak dan interface harus berperilaku dengan cara yang paling sedikit mengejutkan pengguna dan developer lain

  • Fungsi, API, dan UI harus memiliki perilaku yang dapat diprediksi dari nama dan konvensinya
  • Jika fungsi delete() ternyata hanya melakukan arsip, itu menimbulkan kejutan → cacat desain
  • Perilaku yang tidak intuitif menyebabkan bug dan kesalahan pengguna

44. YAGNI (You Aren't Gonna Need It)

Jangan menambahkan fitur sebelum benar-benar dibutuhkan

  • Prinsip inti Extreme Programming (XP) yang diajukan Ron Jeffries pada akhir 1990-an
  • Jika menulis kode karena "mungkin akan dibutuhkan di masa depan", itu menimbulkan overengineering dan beban pemeliharaan
  • YAGNI hanya bisa dipraktikkan jika ada kepercayaan diri pada refactoring (test coverage yang baik, CI)
  • Jika saat ini hanya perlu ekspor JSON, cukup implementasikan JSON; XML/YAML dan lainnya ditambahkan saat benar-benar diminta

Pengambilan Keputusan (Decisions)

45. Efek Dunning-Kruger (Dunning-Kruger Effect)

Semakin sedikit yang diketahui seseorang tentang sesuatu, semakin besar kecenderungannya untuk merasa percaya diri

  • Fenomena ketika developer pemula meremehkan tingkat kesulitan sistem yang kompleks, atau justru pakar lebih rendah hati terhadap pengetahuannya sendiri
  • Penting untuk meningkatkan akurasi kesadaran diri melalui code review, mentoring, dan pembelajaran berkelanjutan

46. Pisau Cukur Hanlon (Hanlon's Razor)

Jangan menganggap sebagai niat jahat sesuatu yang dapat dijelaskan dengan cukup oleh kebodohan atau kecerobohan

  • Sebelum menafsirkan kode buruk atau keputusan salah rekan kerja sebagai sabotase yang disengaja, pertimbangkan dulu ketidaktahuan, kesalahan, atau kekurangan waktu
  • Menjadi dasar kepercayaan dan komunikasi yang konstruktif dalam tim

47. Pisau Cukur Occam (Occam's Razor)

Penjelasan yang paling sederhana sering kali adalah yang paling tepat

Iklan
  • Saat debugging, periksa dulu kemungkinan yang paling sederhana sebelum mencari penyebab yang kompleks
  • Dalam desain arsitektur juga, utamakan solusi sederhana sebelum menambahkan lapisan abstraksi yang tidak perlu

48. Kekeliruan Biaya Hangus (Sunk Cost Fallacy)

Fenomena ketika seseorang terus mempertahankan pilihan yang merugikan hanya karena sudah menginvestasikan waktu atau energi

  • Bahkan jika fitur yang dikembangkan selama 6 bulan ternyata menuju arah yang salah, ada kecenderungan tidak bisa melepaskannya karena waktu yang sudah diinvestasikan
  • Keputusan yang benar harus didasarkan pada nilai masa depan, bukan investasi masa lalu

49. Peta Bukanlah Wilayah (The Map Is Not the Territory)

Representasi (model) atas realitas tidak sama dengan realitas itu sendiri

  • Diagram UML, dokumen arsitektur, model data, dan sebagainya hanyalah aproksimasi realitas
  • Jangan terlalu percaya pada model; amati perilaku sistem yang sebenarnya dan perbarui model tersebut

50. Bias Konfirmasi (Confirmation Bias)

Kecenderungan untuk lebih menyukai informasi yang mendukung keyakinan atau ide yang sudah ada

  • Jebakan ketika seseorang hanya mengumpulkan informasi yang menguntungkan tech stack atau keputusan desain yang telah dipilihnya
  • Secara aktif mencari bukti yang berlawanan dan menerima beragam sudut pandang adalah kunci pengambilan keputusan yang seimbang

51. Hype Cycle dan Hukum Amara (The Hype Cycle & Amara's Law)

Ada kecenderungan untuk melebih-lebihkan dampak jangka pendek teknologi, dan meremehkan pengaruh jangka panjangnya

  • Hype Cycle dari Gartner: pemicu teknologi → puncak ekspektasi yang berlebihan → lembah kekecewaan → lereng pencerahan → dataran produktivitas
  • Saat mengadopsi teknologi baru (blockchain, AI, dll.), jangan terbawa euforia jangka pendek; nilai kepraktisan jangka panjangnya

52. Efek Lindy (The Lindy Effect)

Semakin lama sesuatu telah digunakan, semakin besar kemungkinan ia akan terus digunakan di masa depan

  • Teknologi yang telah digunakan selama puluhan tahun seperti UNIX, SQL, dan bahasa C kemungkinan besar akan terus bertahan lama
  • Menjadi dasar teoretis saat memilih teknologi yang sudah teruji dibanding framework baru
  • Dipopulerkan oleh Nassim Nicholas Taleb dalam Antifragile

53. Berpikir Berdasarkan Prinsip Pertama (First Principles Thinking)

Cara berpikir yang memecah masalah kompleks menjadi elemen-elemen paling dasar lalu membangunnya kembali dari sana

  • Menghilangkan praktik dan asumsi yang sudah ada, lalu menurunkan solusi dengan berangkat dari kebenaran mendasar
  • Terkenal lewat contoh penerapannya oleh Elon Musk untuk menekan biaya roket SpaceX
  • Dalam merancang sistem kompleks, waspadai pola pikir "karena dari dulu memang begitu"

54. Berpikir Terbalik (Inversion)

Metode menyelesaikan masalah dengan mengasumsikan hasil yang berlawanan lalu menalar secara terbalik

  • Alih-alih "bagaimana cara berhasil", pikirkan dulu "bagaimana cara gagal" untuk mengidentifikasi faktor risiko
  • Menjadi dasar teoretis bagi analisis mode kegagalan (Failure Mode Analysis) dan pre-mortem
  • Model mental yang sering digunakan oleh Charlie Munger

55. Prinsip Pareto / Aturan 80/20 (Pareto Principle)

80% masalah berasal dari 20% penyebab

  • Ada kecenderungan 80% dari seluruh bug terkonsentrasi pada 20% kode
  • Memusatkan sumber daya pada 20% yang paling berdampak adalah strategi alokasi sumber daya yang efisien
  • Berasal dari prinsip yang diamati Vilfredo Pareto dari distribusi kepemilikan tanah di Italia

56. Hukum Cunningham (Cunningham's Law)

Cara terbaik untuk mendapatkan jawaban yang benar di internet bukanlah dengan mengajukan pertanyaan, melainkan dengan memposting jawaban yang salah

  • Orang lebih aktif berpartisipasi untuk mengoreksi informasi yang salah daripada menjawab pertanyaan
  • Merupakan hukum yang diambil dari nama Ward Cunningham (penemu Wiki), tetapi sebenarnya nama tersebut diberikan oleh Steven McGeady
  • Wawasan yang dapat dimanfaatkan untuk dokumentasi atau berbagi pengetahuan di komunitas open source

Bacaan terkait

2 komentar

 
GN⁺ 2026-04-22
Komentar Hacker News

  • Saya sangat tidak suka dengan ungkapan "optimisasi prematur adalah akar dari segala kejahatan". Kalimat itu lahir dari konteks tahun 1974, jadi asumsi dasarnya berbeda dengan sekarang. Dulu optimisasi lebih dekat ke assembly dan hitungan siklus, tetapi sekarang performa terutama merupakan masalah pemilihan arsitektur, jadi harus dipikirkan sejak awal. Nasihat untuk menangkap bug performa seperti O(n²) yang tidak disengaja lewat profiling masih tetap valid, tetapi setelah biaya abstraksi menjadi bottleneck, sistem sering justru ditambahi cache dan paralelisme lalu menjadi lebih rumit dan lebih lambat. Menurut saya sekarang, optimisasi yang terlambat sama buruknya dengan optimisasi prematur, bahkan mungkin lebih buruk

    • Menurut saya ini salah satu kalimat yang paling sering disalahpahami dalam pemrograman. Kalau membaca teks asli Donald Knuth, intinya adalah jangan menghabiskan tenaga pada peningkatan performa yang tidak perlu tanpa pengukuran, tetapi situasi 10% yang memang kritis terhadap performa adalah pengecualian. Namun saya sering melihat ini diterima sebagai doktrin aneh bahwa "jangan mengukur apa pun"
    • Menurut saya optimisasi prematur yang benar-benar buruk adalah ketika orang terobsesi pada perbedaan kecil yang tidak penting. Misalnya di Java, saya sering memakai ConcurrentHashMap karena nanti bisa saja masuk ke konteks multithread, dan dalam kebanyakan situasi perbedaan performanya tidak besar. Tetapi karena "HashMap lebih cepat", PR jadi tertahan dan debat tak berujung pun terjadi. Daripada itu, menurut saya lebih tepat fokus pada hal-hal yang benar-benar terasa bedanya, seperti 40 pemanggilan PostgreSQL yang blocking atau request web yang tidak perlu. Namun, menurut saya optimisasi dini di level algoritme sepenuhnya masuk akal
    • Saya suka bercanda bahwa alih-alih "optimisasi prematur", saya hanya melakukan optimisasi yang matang. Memikirkan cara penggunaan, pola akses data, dan kebutuhan performa sebelum menumpuk framework adalah pendekatan yang sangat matang. Kebanyakan kasus memang tidak perlu sampai menghitung siklus, tetapi keputusan seperti apakah ini bulk load atau pemrosesan satuan, apakah perlu mempertimbangkan konkurensi atau distribusi, akan sangat berpengaruh bila dipikirkan di awal. Kubu yang bilang performa bisa dipikirkan nanti sering kali justru buntu saat fase perbaikan
    • Tahun lalu saya menghabiskan 6 bulan untuk membongkar lapisan abstraksi yang menambah 40ms pada setiap request. Profiling menemukan hot path-nya, tetapi itu tidak bisa diselesaikan tanpa penulisan ulang. Pihak yang berkata "nanti saja dioptimalkan" sering tidak benar-benar menekankan bahwa nanti itu bisa jadi tidak pernah datang
    • Menurut saya dengan tool modern, kita bisa membuat desain yang dapat diskalakan dengan relatif mudah. Jadi saya memahami optimisasi prematur sebagai tindakan mengikis bagian yang sebenarnya sudah cukup baik, bukan berarti kita boleh menulis kode berantakan sejak awal

  • Saya merasa sayang Curly's Law tidak masuk. Sebuah variabel seharusnya hanya punya satu makna, dan tidak boleh menyimpan nilai dari domain berbeda tergantung situasi atau menjalankan dua peran sekaligus. Analogi supaya tidak menjadi sesuatu yang "sekaligus semir lantai dan topping dessert" rasanya pas sekali

    • Saya ingin bercanda bahwa analogi "semir lantai sekaligus topping dessert" itu mungkin bukan hukum yang benar-benar universal. Dari pengalaman pernah kerja bersih-bersih dekat restoran, saya merasa pasti ada cukup banyak orang yang akan mencoba makan semir lantai sebagai topping kalau dibilang itu bisa bikin mabuk
    • Saya tidak tahu prinsip ini dari namanya, tetapi saya pernah mempelajarinya lewat pengalaman. Misalnya kalau ada aturan bahwa jika x tidak 0 maka y dibuat 0, maka kalau ingin tahu apakah x itu 0, jangan melihat y sebagai sinyal tidak langsung. Lebih buruk lagi, jangan mendaur ulang y untuk kegunaan lain hanya karena nilainya tersisa
    • Saya jadi teringat bahwa Shellac memang pernah dipakai sekaligus sebagai semir lantai dan bahan tambahan makanan. Sekarang memang ada pengganti yang lebih baik, tetapi dulu ini dipakai terutama untuk permen, dan setahu saya sampai sekarang masih dipakai sebagai perekat alat musik tiup
    • Saya cukup menyukai absl::StatusOr yang dipakai di Google
    • Saya biasanya menyebut situasi seperti ini dengan nama POSIWID

  • Saya merasa kalau semua "hukum" perangkat lunak seperti ini dikumpulkan jadi satu, kontradiksi internal di antara mereka terlalu banyak, sehingga pada akhirnya jadi mudah memilih satu kalimat yang membenarkan argumen kita sendiri. Yang benar-benar sulit adalah tahu kapan sebuah hukum harus dilanggar, dan mengapa itu dilanggar

    • Menurut saya benturan antara Postel's Law dan Hyrum's Law adalah contoh yang mewakili. Kalau input diterima terlalu longgar, seseorang akan bergantung pada setiap perilaku API yang bisa diamati, dan begitu nanti diubah menjadi lebih ketat, itu menjadi breaking change meskipun tidak pernah didokumentasikan. Jadi kesimpulan saya adalah: bersikap ketat pada batas internal yang saya kendalikan, dan longgar hanya pada batas eksternal saat saya tidak bisa memaksa klien melakukan upgrade. Tetapi dalam praktiknya, memisahkan kedua batas itu justru yang paling sulit
    • Saya sering memakai DRY sebagai contoh utama kontradiksi seperti ini. Saya terlalu sering melihat orang berusaha menghindari dua fungsi yang mirip, lalu malah melambungkan kompleksitas konseptual sampai ke langit
    • Sebagai SWE yang sudah bekerja cukup lama, sampai sekarang saya masih mendapat manfaat besar hanya dari KISS dan YAGNI. Saya merasa banyak bagian dari software engineering itu sebenarnya overengineering, dan jujur menurut saya situs ini juga begitu. Di bidang rekayasa lain, biaya material dan tenaga kerja terlihat jelas, jadi pemborosan seperti ini tidak akan bertahan lama
    • Saya juga merasa Leadership Principles di Amazon mirip seperti itu. Secara umum itu panduan yang masuk akal, tetapi dalam perdebatan nyata sering berubah menjadi pertarungan soal siapa yang bisa mempersenjatai prinsip yang tampak paling meyakinkan untuk ditempelkan pada argumennya sendiri. Saya juga berpikir itu belum tentu sepenuhnya buruk
    • Daripada perang hukum IT yang formal, saya lebih suka alternatif seperti CUPID dari Dan North. Sebagai atribut untuk joyful coding, ini terasa lebih praktis daripada SOLID

  • Sebagai lelucon tentang hukum software engineering edisi 2026, saya ingin bilang semua website akan dibuat dengan vibe coding memakai Claude Opus. Hasilnya, warna latarnya akan jadi krem ala Anthropic, font dan ketebalannya akan dicampur berlebihan seperti pemula desain yang baru belajar tipografi, UI kartu akan membanjir, dan pola seperti garis tepi berwarna membulat hanya di satu sisi kartu akan terus berulang

    • Saya ingin langsung melewati situs itu, karena besar kemungkinan orang yang melakukan vibe coding pada situsnya juga melakukan vibe coding pada bukunya. Selain itu, setelah saya cek riwayat coding orang ini, isinya kebanyakan cheat sheet dan roadmap, jadi saya hampir tidak punya kepercayaan pada isi bukunya juga
    • Saya juga memperkirakan domainnya pasti berbentuk judul panjang persisnya lalu .com

  • Saya pikir Boyd's Law of Iteration juga layak masuk. Maksudnya, saat menangani kompleksitas, iterasi yang cepat sering memberi hasil lebih baik daripada analisis yang mendalam, dan kalau diingat bahwa Boyd adalah orang yang membuat OODA loop, itu jadi makin mengesankan

    • Saya sangat suka hukum ini dan berharap lebih banyak orang memahaminya. Pihak manajemen atau bisnis menginginkan perencanaan di muka, tetapi dalam perangkat lunak kita tidak bisa memprediksi semua masalah sejak awal. Daripada mengurung diri sendiri dengan merancang struktur kaku dari awal, menurut saya lebih efektif menyelesaikan masalah lewat refactoring di atas arsitektur yang fleksibel
    • Secara umum saya menganggap pengembangan iteratif lebih baik daripada pengembangan yang terlalu hati-hati. Contoh tongkat kendali pesawat tempur juga sangat halus dan bagus. Ini mengingatkan saya pada proyek menyiksa saat kuliah ketika waktu build mencapai 10 menit sekali. Kami seharusnya mengganti implementasi nyata dengan komponen mock yang sudah disediakan, tetapi saya baru mengetahuinya terlambat dan akhirnya tidak selesai sebelum tenggat. Sejak itu saya selalu lebih dulu mencari cara untuk mengurangi waktu build
    • Saya merasa kalau Boyd's Law didorong terlalu ekstrem, ini bisa mengarah ke bentuk seperti sprint 1 minggu atau bahkan lebih pendek

  • Saya merasa di antara komentar yang dihapus ada meta-law terbaik untuk tulisan ini. Isinya kurang lebih, "semua hukum software engineering langsung disalahpahami dan diterapkan tanpa kritik dengan cara yang akan membuat penulis aslinya ngeri", dan melihat perilaku LLM yang kehilangan konteks utama, saya jadi makin paham kenapa begitu. Pada akhirnya memang ada batas dalam memampatkan puluhan tahun kebijaksanaan dan pengalaman menjadi kutipan satu baris

  • Kalau seluruh "situs daftar hukum software engineering" ini mau dibuat dengan vibe coding, saya ingin bertanya hukum apa yang dilanggar sampai mereka tidak sekalian saja membuat halaman Wikipedia

    • Menurut saya usulan "buat saja halaman Wikipedia" juga terdengar agak aneh. Wikipedia tahun 2026 terasa seperti tempat di mana membuat halaman baru nyaris mustahil kecuali Anda benar-benar pakar mendalam dari lingkungan budaya Wikipedia. Para mastah wiki bilang siapa pun bisa membuatnya asal mengikuti 137 pedoman, tetapi dalam kenyataan ada sinisme bahwa halaman Anda mudah saja dihapus admin
    • Saya ingin menamai hukum itu Slop's Law. Jika sesuatu bisa dibuat asal-asalan, pada akhirnya itu memang akan dibuat asal-asalan
    • Saya ingin merangkum Sturgeon's Law versi 2026 sebagai "99% dari semua hal adalah crap atau slop"

  • Saya merasa hal-hal seperti ini seharusnya menjadi pengetahuan dasar sampai layak dijadikan syarat kerja. Rasanya seperti sesuatu yang perlu diketahui semua orang

  • Walau bukan hukum khusus perangkat lunak, saya biasanya mengajarkan Chesterton's Fence paling awal kepada intern dan pegawai baru

    • Menurut saya Law of Unintended Consequences yang ada di daftar juga menjelaskan fenomena yang sama. Meski begitu, secara pribadi saya lebih suka kisah pagar daripada hukum itu
    • Saya menjadikan prinsip ini salah satu prinsip inti saya, dan kalau diringkas dalam satu kalimat, ini adalah berpikir lalu bertindak

  • Saya merasa Hukum Pelestarian Kompleksitas dari Tesler memberi wawasan langsung hanya dari kalimatnya. Maksudnya, setiap aplikasi memiliki kompleksitas bawaan yang tidak bisa dihapus, hanya bisa dipindahkan. Tetapi ketika masuk ke penjelasannya, ini terasa menyusut menjadi nasihat biasa agar jangan terlalu menyiksa pengguna, sehingga saya jadi sedikit kurang tertarik. Pengguna pada akhirnya tetap harus memegang tingkat kompleksitas yang memang diperlukan, dan kalau dikurangi secara membabi buta, hasilnya mudah menjadi mainan yang tidak fleksibel. Karena itu, saat refactoring saya merasa lebih berguna untuk mengingat bahwa ketika satu bagian disederhanakan, bagian lain bisa menjadi lebih rumit
 
choam2426 2026-04-27

Kalau pakai vibe coding memang terasa bagus untuk sementara, tapi pada akhirnya sepertinya akan berbalik jadi konsekuensi yang harus ditanggung...