The Mythical Man-Month, 50 tahun kemudian

Papan tulis itu punya delapan nama. Delapan engineer, ditambahkan dalam dua sprint, karena kami ketinggalan dan product manager sudah menghitung: delapan kepala bekerja paralel akan menutup ketertinggalan itu. Akulah yang menyetujuinya. Aku berdiri di depan ruangan dan berkata ya, ini akan membantu, kita bisa onboard mereka dengan cepat.

Tiga minggu kemudian ada enam belas orang di daily standup. Meeting itu tumbuh dari lima belas menit menjadi empat puluh. Dua engineer baru telah memperkenalkan race condition yang halus yang tidak ada yang menangkap selama sembilan hari. Salah satu engineer lama secara diam-diam mulai bekerja malam untuk menjelaskan ulang arsitektur kepada pendatang baru, yang berarti dia tidak lagi membangun. Kami ship tiga minggu lebih lambat dari sebelum aku menambahkan delapan orang itu.

Waktu itu, aku tidak tahu bahwa Fred Brooks sudah menggambarkan hasil ini di tahun 1975. Bahwa tragikomedi ini punya nama. Bahwa seseorang sudah menulis bukunya.

Hukum Brooks, dan mengapa masih terasa perih

The Mythical Man-Month diterbitkan tahun 1975, diambil dari pengalaman Fred Brooks memimpin pengembangan OS/360 di IBM. Ini bukan buku yang panjang. Dan bukan pula buku yang lembut.

Observasi sentralnya — yang kemudian dinamai Hukum Brooks (Brooks’s Law) — sederhana: menambah tenaga kerja ke proyek software yang sudah terlambat akan membuatnya semakin terlambat. Alasannya itulah yang penting. Setiap orang baru yang kamu tambahkan ke team tidak hanya menambah kapasitas. Mereka menambah jalur komunikasi. Dua engineer punya satu saluran di antara mereka. Lima punya sepuluh. Lima belas punya seratus lima. Jumlah saluran tumbuh sebagai n(n−1)/2, dan setiap saluran membutuhkan perhatian, sinkronisasi, dan perbaikan saat rusak.

Brooks tidak bilang team besar tidak bisa membangun software. Dia bilang bahwa software terbuat dari komunikasi, dan komunikasi tidak skala secara linear dengan jumlah orang. Melatih engineer baru, onboarding mereka ke codebase, menangkap kesalahan yang mereka buat saat masih menemukan ritme — biaya itu jatuh ke orang-orang yang sudah ada di sana. Orang-orang yang sudah ketinggalan.

Aku punya delapan orang dengan velocity. Aku menambahkan delapan lagi dan mendapatkan enam belas orang dengan communication overhead yang memakan velocity yang coba aku jaga.

Ini bukan failure mode yang halus. Sudah tertulis. Sudah tertulis selama lima puluh tahun.

Second-system syndrome, dan rewrite yang akan memperbaiki segalanya

Ada satu bab di The Mythical Man-Month yang berjudul “The Second-System Effect.” Brooks menggambarkan polanya: seorang engineer membangun sistem pertama di bawah tekanan, dengan batasan, membuat potongan pragmatis. Berhasil. Mereka kini berpengalaman. Mereka tahu persis apa yang akan mereka lakukan secara berbeda. Diberi kesempatan membangun versi kedua — tanpa batasan, dengan pengetahuan yang susah payah diperoleh — mereka over-engineer secara spektakuler.

Sistem kedua selalu yang paling berbahaya. Itulah yang di dalamnya pengalaman menjadi kesombongan dan keanggunan arsitektur mendesak tanggal ship.

Aku melihat ini di setiap organisasi tempat aku bekerja. Tidak selalu rewrite penuh — kadang hanya satu komponen. Modul pembayaran yang “harus dibangun ulang dari nol.” Authentication service yang sistem sebelumnya salah tangani, jadi kali ini kita akan membangunnya dengan benar, dengan full extensibility, mendukung setiap OAuth provider yang bisa kamu sebut, diabstraksikan sedemikian rupa sehingga menambahkan provider baru membutuhkan tiga implementasi interface dan sebuah factory method. Ship-nya butuh delapan bulan. Melayani satu provider.

Brooks memberi nama ini. Di tahun 1975. Dan itu tidak berhenti terjadi.

”No Silver Bullet” — esai yang bertahan lebih baik dari bukunya

Tahun 1986, Brooks menerbitkan esai berjudul “No Silver Bullet — Essence and Accidents of Software Engineering”. Esai ini dimasukkan ke edisi Silver Anniversary dari The Mythical Man-Month tahun 1995 sebagai “No Silver Bullet — Refired,” dengan respons lanjutan terhadap para kritikusnya. Menurutku esai ini bisa dibilang lebih penting dari buku aslinya.

Argumennya: pengembangan software punya dua jenis kesulitan. Accidental complexity — gesekan yang diperkenalkan oleh tools, bahasa, lingkungan kita — dan essential complexity — kesulitan yang tidak bisa direduksi dari masalah itu sendiri. Selama beberapa dekade, kita sudah banyak menyelesaikan accidental complexity. Bahasa tingkat tinggi. Garbage collection. IDE. Version control. Cloud deployment. Masing-masing menghilangkan gesekan yang tidak perlu ada.

Tapi essential complexity tidak menyerah pada tooling. Mencari tahu apa yang seharusnya dilakukan sistem, mengelola interaksi antar komponen, bernalar tentang edge case dan failure mode serta perilaku pengguna — itulah bagian yang susahnya. Dan tidak ada tool, sekuat apapun, yang menghilangkannya. Tidak ada silver bullet.

Brooks menulis sebagai respons terhadap optimisme AI. Teknologi spesifik yang dia tanggapi adalah expert systems dan automated programming tools. Lima puluh tahun kemudian, optimisme itu punya bentuk berbeda. Tapi struktur argumennya tidak berubah.

Apa yang berubah ketika salah satu anggota team kamu adalah LLM

Di sinilah aku harus jujur, bukan sekadar mengutip otoritas orang yang sudah meninggal.

Argumen communication cost Brooks mengasumsikan rekan satu team manusia. Setiap orang yang ditambahkan ke team membutuhkan waktu onboarding, butuh penjelasan, menimbulkan overhead koordinasi. Tapi LLM bukan manusia. Dia tidak perlu hadir di standup. Dia tidak salah paham arsitektur dan memperkenalkan race condition karena kebingungan. Kamu tidak perlu berulang kali menjelaskan domain kepadanya saat dia mencari ritme.

Jadi apakah menambahkan tool AI ke proyek yang terlambat adalah silver bullet?

Tidak. Tapi alasannya lebih menarik dari “Brooks bilang begitu.”

Communication cost-nya berbeda, bukan nol. Saat aku menambahkan LLM ke alur kerjaku, aku menghabiskan waktu untuk belajar mempromptnya dengan baik, belajar di mana dia berhalusinasi, belajar output mana yang bisa dipercaya dan mana yang harus diverifikasi. Biaya onboarding itu nyata. Hanya saja jauh lebih rendah dari manusia, dan tidak skala sesuai ukuran team — aku membayarnya sekali, bukan n kali.

Yang tidak bisa dilakukan LLM adalah mengurangi essential complexity. Dia bisa men-scaffold boilerplate. Dia bisa menyarankan implementasi. Dia bisa mempercepat bagian pekerjaan yang sudah bisa diselesaikan. Tapi memutuskan apa yang harus dilakukan sistem, menangkap keputusan desain yang akan menciptakan enam bulan technical debt, mengetahui trade-off mana yang worth it di sprint ini — itu masih pekerjaan manusia. AI tidak membuat bagian yang susah menjadi lebih mudah. Ia membuat bagian yang mudah menjadi lebih cepat, yang berguna, tapi itu bukan terobosan yang diimplikasikan oleh optimisme itu.

Menambahkan tool AI ke proyek yang terlambat bukan silver bullet. Ini bukan mythical man baru. Ini anggota team dengan onboarding cost yang luar biasa rendah, output tinggi untuk tugas-tugas yang terdefinisi dengan baik, dan tidak punya penilaian sama sekali. Anggaran untuk itu dengan jujur dan hasilnya sepadan. Perlakukan itu sebagai jalan pintas ke essential complexity dan kamu akan kembali ke papan tulis, menambahkan nama.

Satu hal yang sudah terasa janggal

Brooks mendedikasikan satu bab untuk model “surgical team”, dipinjam dari Harlan Mills. Idenya: satu chief programmer — sang surgeon — melakukan semua pekerjaan intelektual kritis, didukung oleh para spesialis yang tugasnya adalah melindungi mereka dari segala sesuatu yang bukan berpikir. Team kecil dan hierarkis di mana orang terbaik melakukan pekerjaan terbaik dan semua orang lain menciptakan kondisi untuk itu.

Tahun 1975, ini adalah proposal organisasi yang serius. Pada 2026, ini menggambarkan hampir tidak ada team software yang ada.

Pengembangan software modern bersifat kolaboratif dengan cara yang tidak bisa diakomodasi model surgical team. Desain dibagi bersama. Code review mendistribusikan pengetahuan dan menangkap kesalahan yang akan dilewatkan sang surgeon. Rotasi on-call mengasumsikan bahwa lebih dari satu orang memahami sistem apapun. Team terbaik yang pernah aku kerjakan tidak punya surgeon. Mereka punya engineer-engineer kuat yang masing-masing bisa memegang kompleksitas signifikan, ditantang oleh rekan-rekan yang sama kuatnya. Hierarki intelektual yang membuat model surgical team bekerja adalah batasan yang secara aktif dilawan oleh kebanyakan team yang sehat.

Brooks sedang meresepkan sesuatu yang nyata — konsentrasikan orang-orang terbaikmu pada masalah-masalah tersulit, lindungi mereka dari overhead. Naluri itu masih benar. Tapi metaforanya membekukan solusi ke dalam org chart yang sebagian besar industri sudah tinggalkan, dan dengan alasan yang baik.

Apa yang sebenarnya dibicarakan buku ini

Aku sudah menggambarkan The Mythical Man-Month sebagai buku manajemen proyek. Sebenarnya tidak juga.

Saran manajemen proyeknya spesifik dan kadang sudah usang. Bab organisasional adalah produk zamannya. Estimate dan heuristik mencerminkan dunia di mana “menulis sebuah modul” berarti sesuatu yang jauh lebih melelahkan dari hari ini.

Apa yang sebenarnya dibicarakan buku ini adalah ketidakmungkinan jalan pintas dalam pekerjaan yang terbuat dari komunikasi. Software itu susah bukan karena komputernya lambat atau bahasanya sulit atau toolsnya buruk. Susahnya karena ini adalah tindakan penerjemahan yang berkelanjutan — antara apa yang dibutuhkan pengguna dan apa yang dibangun engineer, antara spesifikasi dan implementasi, antara apa yang dipahami satu engineer dan apa yang dipahami rekan satu team mereka. Setiap jalan pintas yang mengabaikan biaya penerjemahan itu akan berbunga.

Brooks memenangkan ACM Turing Award tahun 1999 — bukan untuk The Mythical Man-Month tapi untuk kontribusi sebelumnya di arsitektur komputer. Dia meninggal tahun 2022 di usia 83. Komunitas manajemen proyek tidak memberinya penghargaan. Mereka memberinya sesuatu yang lebih baik: lima puluh tahun project manager membaca buku ini, mengenali kesalahan mereka sendiri di dalamnya, dan tetap membuatnya bagaimanapun.

Celah itu — antara mengetahui dan melakukan — itulah yang sebenarnya didokumentasikan buku ini.

Papan tulis, dibaca ulang

Aku kadang memikirkan papan tulis itu. Delapan nama. Ditambahkan dengan penuh keyakinan.

Kalau aku membaca buku itu sebelum meeting itu, aku tidak yakin aku akan memutuskan secara berbeda. Tekanannya nyata. Deadline-nya nyata. Matematika product manager itu menggoda — delapan engineer lagi, masalah selesai — dan akulah orang yang tugasnya adalah optimis di depan umum.

Tapi aku akan tahu, saat masuk ke ruangan itu, bahwa aku sedang membuat taruhan berisiko, bukan rencana yang masuk akal. Aku akan menghitung communication cost sebelum aku menyetujuinya. Aku akan punya kata untuk apa yang akan aku lakukan: Hukum Brooks. Dan aku akan punya lima puluh tahun bukti bahwa kata itu ada karena alasan.

Itulah yang dilakukan buku yang baik. Itu tidak menghentikanmu dari membuat kesalahan. Itu membuatmu melakukannya dengan mata terbuka, yang merupakan hal yang sama sekali berbeda.

Papan tulis itu masih ada, di ruang konferensi yang jarang aku pakai lagi. Seseorang mengecat delapan nama itu. Aku masih tahu persis di mana mereka berada.

---