56 Laws of Software Engineering: Referensi Praktis untuk Developer

Situs baru Laws of Software Engineering oleh Dr. Milan Milanovic telah mengumpulkan 56 prinsip dan pola yang membentuk sistem software, tim, dan keputusan engineering. Menurut situs resminya, koleksi ini mendapatkan lebih dari 1.100 upvote di Hacker News dan terus berkembang sebagai referensi komunitas yang digunakan oleh engineer dari berbagai level.

Website ini mengorganisir hukum-hukum software engineering ke dalam kategori yang praktis: Architecture, Teams, Planning, Quality, Scale, Design, dan Decisions. Bukan sekadar daftar, setiap hukum dilengkapi dengan penjelasan kontekstual, contoh nyata dari industri, dan implikasi untuk praktik sehari-hari. Milanovic merilis konten ini di bawah lisensi Creative Commons, menjadikannya accessible tanpa barrier lisensi untuk komunitas global termasuk Indonesia.

Hukum-Hukum Fundamental yang Wajib Diketahui

Beberapa hukum yang paling sering direferensikan dalam komunitas developer dan memiliki dampak langsung pada arsitektur serta manajemen proyek:

• Conway's Law: Organisasi merancang sistem yang mencerminkan struktur komunikasi mereka sendiri. Ini menjelaskan mengapa microservices sering gagal ketika struktur tim tidak mengikuti batasan domain. Banyak startup yang mengadopsi arsitektur microservices karena tren, padahal organisasi mereka masih beroperasi dalam silo monolitik. Hasilnya adalah distributed monolith yang memiliki kompleksitas distributed tanpa benefit autonomy.

• Hyrum's Law: Dengan cukup banyak pengguna API, semua perilaku yang teramati dari sistem akan menjadi dependensi seseorang. Ini adalah alasan mengapa breaking changes harus dikelola dengan extreme caution. Bahkan bug yang tidak didokumentasikan bisa menjadi contract implisit yang diandalkan oleh ribuan sistem downstream.

• Brooks's Law: Menambahkan manpower ke proyek yang terlambat justru membuatnya semakin terlambat. Hukum klasik dari Fred Brooks yang masih relevan di era remote engineering. Onboarding engineer baru membutuhkan waktu dan bandwidth dari engineer existing, yang justru memperlambat delivery dalam short-term meskipun mungkin membantu long-term.

• Gall's Law: Sistem kompleks yang berfungsi selalu berevolusi dari sistem sederhana yang berfungsi. Anda tidak bisa membangun sistem kompleks dari nol dalam satu iterasi. Ini adalah argument kuat untuk MVP dan iterative delivery, bukan big bang redesign.

• CAP Theorem: Sistem terdistribusi hanya bisa menjamin dua dari tiga: consistency, availability, partition tolerance. Hukum ini menjadi fondasi desain arsitektur modern. Banyak engineer yang tergoda untuk mengorbankan partition tolerance, padahal dalam praktiknya network partition adalah hal yang pasti terjadi.

• Tesler's Law (Conservation of Complexity): Setiap aplikasi memiliki jumlah kompleksitas inheren yang tidak bisa dihilangkan, hanya bisa dipindahkan. Misalnya, kompleksitas bisa dipindahkan dari user ke sistem, atau dari developer ke platform. Keputusan di mana menempatkan kompleksitas ini adalah inti dari product design.

• Law of Leaky Abstractions: Semua abstraksi non-trivial, sampai batas tertentu, bocor. Ini berarti engineer tidak bisa sepenuhnya mengabaikan layer di bawah abstraksi. Abstraksi yang terlalu tebal akan menyembunyikan detail kritis yang dibutuhkan untuk debugging atau optimasi.

Kategori yang Sering Diabaikan: Tim dan Psikologi

Selain hukum teknis, Milanovic juga menyoroti hukum-hukum sosial dan psikologis yang mempengaruhi software engineering. Dunbar's Number misalnya: ada batas kognitif sekitar 150 hubungan stabil yang bisa dijaga seseorang. Ini berarti tim engineering yang terlalu besar akan mengalami fragmentasi komunikasi alami. Startup yang scaling dari 20 ke 200 engineer sering mengalami culture shock karena mekanisme komunikasi yang berfungsi sebelumnya tidak lagi scalable.

Price's Law menyatakan bahwa akar kuadrat dari total peserta melakukan 50% pekerjaan. Dalam tim 100 engineer, 10 orang melakukan setengah dari seluruh output. Ini bukan argumen untuk meritokrasi berlebihan, tapi pengingat bahwa distribusi kontribusi dalam tim tidak pernah merata. Manajer yang tidak memahami ini akan frustrasi mencoba membuat semua orang produktif secara merata, yang pada dasarnya melawan hukum alam.

Ringelmann Effect menunjukkan bahwa produktivitas individu menurun seiring bertambahnya ukuran grup. Ini adalah fenomena yang terdokumentasi baik dalam psikologi sosial dan punya implikasi langsung untuk standup meeting, code review, dan proses decision-making. Tim yang terlalu besar sering kali lebih lambat bukan karena koordinasi, tapi karena motivasi individu menurun secara alami.

Bus Factor adalah minimum jumlah anggota tim yang kehilangan akan membuat proyek dalam masalah serius. Ini adalah metrik sederhana yang sering diabaikan. Tim dengan bus factor 1 memiliki risiko ekstrem yang tidak perlu ada. Knowledge sharing dan documentation adalah investasi murah untuk mengurangi risiko ini.

Relevansi di Era AI dan Agentic Coding

Di era dimana AI agent mulai menulis kode, hukum-hukum ini justru semakin relevan. Leaky Abstractions menjadi lebih berbahaya ketika engineer tidak lagi memahami fondasi kode yang mereka maintain. Jika AI menghasilkan 1000 baris kode yang berfungsi, tapi engineer tidak memahami mekanisme internal, maka debugging menjadi mimpi buruk ketika abstraction bocor.

Technical Debt terakumulasi lebih cepat karena volume kode yang dihasilkan AI jauh melampaui kapasitas review manusia. Hukum Broken Windows Theory menyatakan bahwa jendela rusak yang tidak diperbaiki akan mengundang lebih banyak vandalisme. Dalam konteks AI, kode berkualitas rendah yang dihasilkan agent dan diterima tanpa review akan mengundang lebih banyak kode berkualitas rendah.

Postel's Law : be conservative in what you do, be liberal in what you accept from others. Ini menjadi semakin penting ketika sistem berinteraksi dengan output AI yang bisa tidak deterministik. Sistem yang robust harus bisa menangani edge cases yang mungkin tidak terduga, sementara tetap menghasilkan output yang konsisten dan predictable.

Aplikasi Praktis untuk Developer Indonesia

Bagi developer Indonesia, koleksi ini adalah checklist mental yang berguna untuk setiap desain arsitektur, rekrutmen tim, atau evaluasi proyek. Situs ini juga menyediakan versi buku dan poster untuk referensi offline. Banyak tim startup Indonesia yang terburu-buru scaling tanpa memperhatikan fondasi teknis. Referensi seperti Laws of Software Engineering ini bisa menjadi rem yang dibutuhkan untuk memastikan fondasi tidak retak sebelum masa pertumbuhan tiba.

Beberapa hukum yang paling relevan untuk konteks Indonesia adalah Goodhart's Law : when a measure becomes a target, it ceases to be a good measure. Banyak organisasi Indonesia yang mengukur produktivitas engineering berdasarkan jumlah commit atau lines of code. Goodhart's Law memperingatkan bahwa metrik yang dijadikan target akan kehilangan nilai prediktifnya karena orang akan gaming the metric.

Dr. Milanovic juga menyertakan Hofstadter's Law : it always takes longer than you expect, even when you take into account Hofstadter's Law. Ini adalah pengingat humbling untuk setiap estimasi proyek. Dalam konteks Indonesia, di mana requirement sering berubah dan stakeholder involvement tidak konsisten, Hofstadter's Law adalah realitas yang harus diakui, bukan dihindari.