Hukum-Hukum Rekayasa Perangkat Lunak

 (lawsofsoftwareengineering.com)
18 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Kumpulan prinsip dan hukum yang berulang kali muncul di seluruh pengembangan perangkat lunak, dikelompokkan ke dalam kategori tim, perencanaan, arsitektur, kualitas, skalabilitas, desain, dan pengambilan keputusan, serta dirangkum dengan fokus pada definisi satu baris
  • Pada kategori tim dan perencanaan, Conway's Law, Brooks's Law, Goodhart's Law, Hofstadter's Law, dan lainnya merangkum pola berulang dalam operasional pengembangan seperti struktur organisasi, penambahan personel, keterlambatan jadwal, dan distorsi metrik target
  • Pada kategori arsitektur dan kualitas, Hyrum's Law, CAP Theorem, Technical Debt, Testing Pyramid, dan lainnya mencakup ketergantungan API, batasan sistem terdistribusi, pemeliharaan kualitas kode, dan prinsip penyusunan pengujian
  • Pada kategori desain dan pengambilan keputusan, YAGNI, DRY, KISS, SOLID Principles, Occam's Razor, Confirmation Bias, dan lainnya mencakup standar untuk kesederhanaan, penghapusan duplikasi, kemudahan pemeliharaan, dan menghindari kesalahan penilaian
  • Karena hanya menyajikan kalimat inti tanpa penjelasan rinci atau contoh, daftar ini berfungsi sebagai rujukan cepat untuk meninjau berbagai konsep rekayasa perangkat lunak dan menggunakannya sebagai bahasa bersama

Ikhtisar

  • Kumpulan prinsip dan hukum yang berulang kali muncul pada sistem perangkat lunak, tim, perencanaan, kualitas, skalabilitas, desain, dan pengambilan keputusan, dikelompokkan per kategori
  • Setiap entri dirangkum dalam satu kalimat inti bersama nama hukumnya, tanpa penjelasan rinci atau contoh tambahan
  • Daftar tautan dan penanda kategori di bagian atas lebih dekat berfungsi sebagai indeks daripada penjelasan isi sebenarnya, dan inti kontennya terbatas pada kalimat definisi masing-masing hukum itu sendiri

Tim

  • Conway's Law

    • Organisasi merancang sistem yang mencerminkan struktur komunikasi mereka sendiri

  • Brooks's Law

    • Menambahkan personel ke proyek perangkat lunak yang terlambat justru membuat proyek semakin terlambat

  • Dunbar's Number

    • Ada batas kognitif sekitar 150 orang untuk jumlah hubungan stabil yang dapat dipertahankan seseorang

  • The Ringelmann Effect

    • Semakin besar ukuran kelompok, semakin terjadi penurunan produktivitas individu

  • Price's Law

    • Sejumlah orang sebesar akar kuadrat dari total peserta mengerjakan 50% dari pekerjaan

  • Putt's Law

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

  • Peter Principle

    • Dalam organisasi hierarkis, setiap karyawan cenderung dipromosikan hingga mencapai tingkat ketidakmampuannya

  • Bus Factor

    • Menunjukkan jumlah minimum anggota tim yang jika hilang akan membuat proyek mengalami kesulitan serius

  • Dilbert Principle

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

Perencanaan

  • Premature Optimization

    • Optimisasi prematur adalah akar dari segala kejahatan

  • Parkinson's Law

    • Pekerjaan akan mengembang untuk mengisi seluruh waktu yang tersedia untuk menyelesaikannya

  • The Ninety-Ninety Rule

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

  • Hofstadter's Law

    • Semuanya selalu memakan waktu lebih lama dari perkiraan, bahkan jika sudah memperhitungkan Hofstadter's Law

  • Goodhart's Law

    • Saat sebuah ukuran menjadi target, ukurannya tidak lagi berfungsi sebagai ukuran yang baik

  • Gilb's Law

    • Segala sesuatu yang perlu dikuantifikasi dapat diukur dengan suatu cara yang lebih baik daripada tidak diukur sama sekali

Arsitektur

  • Hyrum's Law

    • Jika pengguna API menjadi cukup banyak, maka setiap perilaku yang dapat diamati dari sistem akan menjadi sesuatu yang diandalkan oleh seseorang

  • Gall's Law

    • Sistem kompleks yang berfungsi, tanpa pengecualian, berevolusi dari sistem sederhana yang sebelumnya berfungsi

  • The Law of Leaky Abstractions

    • Setiap abstraksi yang tidak sepele pasti mengalami kebocoran sampai tingkat tertentu

  • Tesler's Law

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

  • CAP Theorem

    • Sistem terdistribusi hanya dapat menjamin dua dari konsistensi, ketersediaan, dan toleransi partisi

  • Second-System Effect

    • Setelah sistem kecil yang sukses, sering kali muncul pengganti yang dirancang berlebihan dan membengkak

  • Fallacies of Distributed Computing

    • Ada delapan asumsi keliru yang sering dibuat perancang sistem terdistribusi baru

  • Law of Unintended Consequences

    • Jika mengubah sistem yang kompleks, kita harus mengharapkan hasil yang tidak terduga

  • Zawinski's Law

    • Setiap program cenderung berkembang sampai bisa membaca email

Kualitas

  • The Boy Scout Rule

    • Kode harus ditinggalkan dalam kondisi yang lebih baik daripada saat ditemukan

  • Murphy's Law / Sod's Law

    • Apa pun yang bisa salah pada akhirnya akan salah

  • Postel's Law

    • Bersikaplah konservatif dalam apa yang Anda lakukan, dan toleran dalam apa yang Anda terima dari orang lain

  • Broken Windows Theory

    • Desain buruk, keputusan keliru, dan kode yang buruk tidak boleh dibiarkan seperti jendela yang pecah

  • Technical Debt

    • Technical Debt adalah segala sesuatu yang memperlambat kecepatan pengembangan perangkat lunak

  • Linus's Law

    • Dengan cukup banyak mata, semua bug menjadi dangkal

  • Kernighan's Law

    • Debugging dua kali lebih sulit daripada menulis kode sejak awal

  • Testing Pyramid

    • Proyek seharusnya memiliki banyak unit test yang cepat, lebih sedikit tes integrasi, dan hanya sedikit tes UI

  • Pesticide Paradox

    • Semakin lama tes yang sama dijalankan berulang, semakin berkurang efektivitasnya seiring waktu

  • Lehman's Laws of Software Evolution

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

  • Sturgeon's Law

    • 90% dari segala sesuatu itu buruk

Skalabilitas

  • Amdahl's Law

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

  • Gustafson's Law

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

  • Metcalfe's Law

    • Nilai sebuah jaringan sebanding dengan kuadrat jumlah penggunanya

Desain

  • YAGNI

    • Jangan menambahkan fitur sebelum fitur itu benar-benar dibutuhkan

  • DRY

    • Setiap potongan pengetahuan harus memiliki satu representasi otoritatif yang tidak ambigu

  • KISS

    • Desain dan sistem harus sesederhana mungkin

  • SOLID Principles

    • Terdiri dari lima pedoman utama untuk meningkatkan kemudahan pemeliharaan dan skalabilitas kode

  • Law of Demeter

    • Objek seharusnya hanya berinteraksi dengan teman langsungnya, bukan dengan pihak yang asing

  • Principle of Least Astonishment

    • Perangkat lunak dan antarmuka harus berperilaku dengan cara yang paling tidak mengejutkan pengguna dan pengembang lain

Pengambilan Keputusan

  • Dunning-Kruger Effect

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

  • Hanlon's Razor

    • Jangan mengaitkan sesuatu pada niat jahat jika hal itu bisa dijelaskan secara memadai oleh ketidaktahuan atau kecerobohan

  • Occam's Razor

    • Penjelasan yang paling sederhana sering kali adalah yang paling akurat

  • Sunk Cost Fallacy

    • Kekeliruan untuk terus bertahan pada pilihan hanya karena waktu atau energi sudah terlanjur diinvestasikan, meski pergi justru akan lebih membantu

  • The Map Is Not the Territory

    • Representasi atas realitas bukanlah realitas itu sendiri

  • Confirmation Bias

    • Ada kecenderungan untuk lebih menyukai informasi yang mendukung keyakinan atau ide yang sudah ada

  • The Hype Cycle & Amara's Law

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

  • The Lindy Effect

    • Sesuatu yang telah digunakan lebih lama lebih mungkin untuk terus digunakan di masa depan

  • First Principles Thinking

    • Cara berpikir dengan memecah masalah kompleks menjadi blok paling dasar lalu menyusunnya kembali

  • Inversion

    • Cara memecahkan masalah dengan mempertimbangkan hasil kebalikan dan menelusurinya dari arah sebaliknya

  • Pareto Principle

    • 80% masalah berasal dari 20% penyebab

  • Cunningham's Law

    • Cara terbaik mendapatkan jawaban yang benar di internet bukanlah dengan bertanya, melainkan dengan memposting jawaban yang salah

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
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