Artık genelde işlerimizi AI ajanlarıyla yapıyor olsak da AI ajanlarını da bir göz olarak görebiliriz ve bu kanun gene de anlamlı olabilir.

Kritik bir hata içeren karmaşık bir algoritma yazdığınızı düşünün. Kod kendi yerelinizde ve sınırlı test senaryolarınızda sorunsuz çalışıyor. Siz gözden kaçırıyorsunuz, hatta yanınızdaki iş arkadaşınız da hızlıca onay verip geçiyor. Ancak bu kod üretim ortamına (production) çıkıp binlerce farklı senaryoyla karşılaştığında veya geniş bir ekip tarafından incelendiğinde, daha önce aklınıza bile gelmeyen bir uç durum (edge case) bir başkasının dikkatini çekiyor ve büyük bir kriz büyümeden çözülüyor.

Açık kaynak dünyasının ve Linux işletim sisteminin kurucusu Linus Torvalds’ın çalışma felsefesinden ilham alan ve Eric S. Raymond tarafından 1999 tarihli The Cathedral and the Bazaar (Katedral ve Pazar) kitabında formüle edilen Linus’s Law (Linus Kanunu), yazılım kalitesini artırmanın ve karmaşık hataları çözmenin en etkili yolunun kitlesel gözlem olduğunu savunur.

İlkenin orijinal ifadesi şöyledir:

Given enough eyeballs, all bugs are shallow.

Türkçesiyle:

Yeterince göz (farklı bakış açısı) olduğu sürece, tüm hatalar yüzeyseldir (kolayca bulunabilir ve çözülebilir).

İlkenin felsefesi son derece berraktır: Bir hatanın ne kadar karmaşık veya görünmez olduğu, ona kaç kişinin baktığıyla doğrudan ilişkilidir. Bir kişinin günlerce uğraşıp bulamadığı karanlık bir yazılım açığı, konuya tamamen farklı bir perspektifle, farklı bir tecrübeyle yaklaşan bir başkası için saniyeler içinde görünür hale gelebilir.

1. Katedral vs. Pazar (The Cathedral and the Bazaar)

Raymond, yazılım geliştirme modellerini ikiye ayırır:

• Katedral Modeli: Kodun, kapalı kapılar ardında, yalnızca elit ve sınırlı bir uzman grubu tarafından (adeta bir katedral inşa eder gibi) geliştirildiği hiyerarşik yapı. Bu modelde test süreçleri ve hata ayıklama sınırlı bir ekibin omuzlarındadır. Hataların tespiti yavaş ve maliyetlidir.
• Pazar Modeli: Herkesin katkı sunabildiği, kodun herkese açık olduğu ve kolektif bir zekayla (coşkulu bir pazar yeri gibi) geliştirildiği açık kaynak dünyası. Linus’un Linux’u geliştirirken kullandığı bu yöntem, binlerce bağımsız gözün sürekli kodu denetlemesini sağlar. Birinin göremediğini diğeri görür ve hatalar hızla ayıklanır.

2. Modern Yazılım Ekiplerinde Linus Kanunu

Bugün her şirketin açık kaynaklı devasa bir topluluğu olmayabilir; ancak Linus Kanunu’nu kendi kapalı ekiplerimizde hayata geçirmenin çok güçlü yolları vardır:

• PR (Pull Request) ve Kod İncelemesi (Code Review) Ritüelleri: Kodun ana dala (main branch) birleşmeden önce ekipteki diğer mühendisler tarafından incelenmesi, Linus Kanunu’nun en doğrudan mikro uygulamasıdır. Kod incelemelerini sadece “onaylama prosedürü” olarak görmeyip, farklı deneyim seviyelerindeki insanların bakmasını sağlamak hataları canlıya çıkmadan yakalar.
• Pair Programming: İki geliştiricinin aynı bilgisayar/kod üzerinde birlikte çalışması. Biri kodu yazarken (driver), diğerinin anlık olarak tasarımı ve olası hataları gözlemlemesi (navigator) hataların daha klavyeden dökülürken elenmesini sağlar.
• Ekip İçi “Bug Bash” (Toplu Hata Avı) Etkinlikleri: Büyük bir sürüm öncesinde tüm ekibin (geliştiriciler, test uzmanları, ürün yöneticileri, tasarımcılar) aynı anda sistemi kırıp hata bulmaya çalışması. Farklı disiplinlerden gelen insanların sisteme bakışı, geliştiricilerin asla aklına gelmeyecek kullanım hatalarını ortaya çıkarır.
• Güvenlik İçin “Bug Bounty” (Ödül Avcılığı) Programları: Sistemlerinizin güvenliğini sadece kendi iç siber güvenlik ekibinize bırakmak yerine, dışarıdaki bağımsız araştırmacıların gözlerine açmak.

Bu Gücü Doğru Kullanmanın Sınırları

Linus Kanunu muazzam bir savunma aracıdır; fakat “yeterince göz” kavramını yanlış anlamak yeni sorunlar doğurabilir:

• Sorumluluk Dağılması (Bystander Effect): Bir PR’a veya koda çok fazla kişiyi inceleyici (reviewer) olarak eklediğinizde, herkes “nasılsa başkası inceler” diyerek kodu detaylı okumadan onaylayabilir. Gözlerin sayısını artırırken, her gözün sorumluluğunu ve odağını netleştirmek gerekir.
• Nitelikli Gözlerin Önemi: Sayıdan ziyade, bakış açılarının çeşitliliği önemlidir. Koda sadece aynı yaklaşıma sahip 10 kişinin bakması yerine; bir güvenlik uzmanının, bir performans mühendisinin ve bir iş mantığı (domain) uzmanının bakması çok daha derinlikli hataları ortaya çıkarır.
• Kodun Okunabilirliği Ön Koşuldur: Başkalarının koda bakıp hata bulabilmesi için, kodun okunabilir, sade ve anlaşılır olması gerekir. Anlaşılmaz, karmaşık kodlar gözleri yorar ve hataların gizlenmesine (Leaky Abstractions) yol açar.

Sonuç

Yazılım geliştirmede kusursuz olmak imkansızdır; her geliştirici hata yapar ve kendi yazdığı koda karşı körleşir (confirmation bias).

Linus Kanunu bize, en karmaşık ve korkutucu görünen hataların bile aslında aşılmaz olmadığını, sadece daha fazla ve farklı gözlerin dikkatine ihtiyaç duyduğunu hatırlatır. Kodumuzu kapalı kapılar ardında saklamak yerine, onu ekibimizin ve topluluğumuzun gözleri önüne ne kadar cesurca serersek, o kadar dayanıklı, güvenli ve kaliteli sistemler inşa edebiliriz.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?
• Brooks’s Law: Geciken Bir Projeye İnsan Eklemek Neden Onu Daha da Geciktirir?
• Dunbar’s Number: Ekipler Neden 150 Kişiden Sonra Yabancılaşır?
• Ninety-Ninety Rule: Projeler Neden “%90 Bitti” Aşamasında Takılıp Kalır?
• Hofstadter’s Law: Bir İş Neden Her Zaman Beklediğinizden Uzun Sürer?
• Broken Windows Theory: Küçük İhmaller Kod Tabanını Nasıl Harabeye Çevirir?

Kaynaklar

• Linus’s Law — Laws of Software Engineering (https://lawsofsoftwareengineering.com/laws/linuss-law/)
• Eric S. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O’Reilly, 1999)

Gecikmelerin ve öngörülemeyen pürüzlerin takvimleri nasıl sarkıttığını Planlama (Planning) kategorisindeki Doksan-Doksan ve Hofstadter kanunlarında detaylıca inceledik. Serinin bu bölümünde yönümüzü Quality (Kalite) kategorisine çeviriyoruz. Bu teoriyi ilk olarak işletmeci bir arkadaşımdan duymuştum ve beni çok etkilemişti. Şimdi bu teorinin yazılım ekosistemindeki yansımasını göreceğiz.

Geliştiriciler olarak her gün verdiğimiz küçük, önemsiz görünen kararların zamanla tüm bir kod tabanının kaderini nasıl belirlediğini masaya yatırıyoruz.

Yeni bir projeye başladığınızda her şey pırıl pırıldır: Dosya düzeni nizami, isimlendirmeler tutarlı, test kapsama oranı %90’ın üzerindedir. Ancak aylar geçtikçe bir şeyler değişmeye başlar. Önce “acil bir işi yetiştirmek için” testleri pas geçen (failing tests) tek bir PR onaylanır. Ardından, bir dosyanın içine aceleyle “sonra düzeltilmek üzere” (// TODO: fix this hack) geçici bir yama bırakılır.

Çok değil, birkaç ay sonra o pırıl pırıl kod tabanı; kimsenin dokunmaya cesaret edemediği, yeni bir özellik eklemenin günler sürdüğü ve her yerinden hatalar fışkıran bir harabeye dönüşür.

Sosyologlar James Q. Wilson ve George L. Kelling tarafından 1982’de ortaya atılan ve yazılım dünyasına The Pragmatic Programmer (Dave Thomas & Andy Hunt) kitabı ile kazandırılan Broken Windows Theory (Kırık Camlar Teorisi), bu sinsi çürüme sürecini çok net bir toplumsal psikoloji üzerinden açıklar.

İlkenin temel önermesi şöyledir:

Bir binada tek bir kırık cam onarılmadan öylece bırakılırsa, oradan geçenler binayla kimsenin ilgilenmediğini varsayar. Çok geçmeden diğer camlar da kırılır, binaya zarar verilir ve o çevre hızla bir suç ve ihmal yuvasına dönüşür.

Yazılım mühendisliğinde de kurallar tamamen aynı şekilde işler:

Bir kod tabanında küçük hataların, kötü tasarımların veya baştan savma çözümlerin (kırık camların) öylece kalmasına izin verirseniz, tüm ekip projenin kalitesine kimsenin önem vermediğini varsayar. Sonuçta, kötü kod katlanarak yayılır ve tüm sistem çöker.

1. Kırık Camların Kod Tabanındaki İzdüşümleri

Yazılımdaki “kırık camlar” her zaman büyük mimari felaketler olmak zorunda değildir; aksine, çoğunlukla göz ardı edilen küçük detaylardır:

• Sürekli “Yoksayılan” Testler (Failing/Flaky Tests): “O test zaten hep hata veriyor, boş ver çalıştır gitsin”denilen tek bir test, ekibe testlerin aslında o kadar da önemli olmadığı mesajını verir. Bir süre sonra kimse test yazmamaya başlar.
• Geçici Yamalar ve TODO Satırları: "Şimdilik böyle kalsın, haftaya düzeltirim" diyerek commit edilen ama aylar boyunca orada çürüyen baştasavma kodlar.
• Kullanılmayan/Ölü Kodlar (Dead Code): Artık çağrılmayan ama “belki lazım olur” diye silinmeyen yüzlerce satırlık eski fonksiyonlar.
• Tarihi Geçmiş veya Eksik Dokümantasyon: Kodun ne yaptığını anlatmayan, güncelliğini yitirmiş README dosyaları ve yorum satırları.
• Kötü İsimlendirmeler ve Karmaşık Stil: Kodun okunabilirliğini azaltan, her yiğidin kendi yoğurt yiyişine göre yazdığı tutarsız kodlama stilleri.

Bu ihmallerin her biri, kod tabanında “Burada standartlar gevşek, ben de aceleyle bir şeyler yazıp geçebilirim” algısını yaratır.

2. Çürüme Nasıl Yayılır? (The Decay Effect)

İyi niyetli ve disiplinli bir yazılımcı bile, her tarafı “kırık camlarla” dolu, karmaşık bir legacy (miras) projeye girdiğinde psikolojik olarak çevreye uyum sağlar:”Bu koca dosyada zaten her yer spagetti, benim ekleyeceğim 50 satırlık geçici yama (hack) de durumu çok değiştirmez” diye düşünür.

Buna karşın, her satırı özenle yazılmış, testleri eksiksiz çalışan ve CI/CD süreçleri tıkır tıkır işleyen bir projede, hiç kimse oraya kalitesiz veya özensiz bir kod parçası bırakmaya cesaret edemez. Çünkü o “temiz” düzendeki en ufak bir uyumsuzluk (kırık cam) anında sırıtır ve göze batar.

3. “Boy Scout Rule” (İzcilik Kuralı) ile Kırık Camları Onarmak

Kırık Camlar Teorisi’yle savaşmanın en etkili yolu, yazılım dünyasında her geliştiricinin benimsemesi gereken Boy Scout Rule (İzcilik Kuralı)’dur:

Kamp yaptığın yeri, bulduğundan daha temiz bırak.

Bunu yazılıma uyarladığımızda: Bir dosyada veya modülde bir değişiklik yapıyorsanız, oradan çıkmadan önce gözünüze çarpan en az bir küçük kusuru düzeltin.

• Yanıltıcı isimlendirilmiş bir değişkeni yeniden adlandırın.
• Artık kullanılmayan eski bir kütüphane bağımlılığını silin.
• Eksik kalmış bir testi yazın ya da karmaşık bir satırı refactor edin.

Bu küçük, günlük disiplinler bir araya geldiğinde, teknik borç birikimini engeller ve kod tabanının kalitesini organik olarak yukarıda tutar.

Bu Tuzaktan Nasıl Kaçınabiliriz?

Projelerimizi kırık camlardan korumak ve kalite kültürünü ayakta tutmak için şu yaklaşımları uygulayabiliriz:

• Sıfır Tolerans Politikası (Zero Tolerance): Bozulan testleri, derleme (build) hatalarını veya linter uyarılarını asla “yarın düzeltirim” diyerek bırakmayın. Öncelikli olarak o kırık camı onarın.
• Süreçleri Otomatize Edin: Kalite standartlarını kişilerin inisiyatifine bırakmayın. Pre-commit kancaları (hooks),linter’lar, statik kod analiz araçları (SonarQube) ve CI/CD süreçleriyle “kırık camların” ana dala (main branch) sızmasını otomatik olarak engelleyin.
• Kod İncelemelerini (Code Review) Önemseyin: PR (Pull Request) süreçlerini sadece “kod çalışıyor mu” testi olarak görmeyin. Kalite, stil ve düzen standartlarından ödün vermeyen, yapıcı ama disiplinli bir review kültürü oluşturun.
• “Düzeltme” (Refactoring) Zamanı Ayırın: Ekiplere sadece yeni özellik geliştirmesi değil; mevcut teknik borçları temizlemek, eskiyen modülleri yenilemek ve kırık camları onarmak için her sprint’te makul bir zaman bütçesi tanıyın.

Sonuç

Yazılımda çürüme, büyük ve radikal kararlarla değil; her gün göz ardı edilen küçük, önemsiz ihmallerin birikmesiyle başlar.

Yürürken yanından geçtiğiniz, fark edip de düzeltmediğiniz her kötü kod parçası, o projenin yeni kalite standardı haline gelir. Bir mimar veya geliştirici olarak asli görevimiz, sadece yeni binalar inşa etmek değil; o binaların ilk kırılan camını anında onaracak disiplini ve özeni her gün gösterebilmektir.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?
• Brooks’s Law: Geciken Bir Projeye İnsan Eklemek Neden Onu Daha da Geciktirir?
• Dunbar’s Number: Ekipler Neden 150 Kişiden Sonra Yabancılaşır?
• Ninety-Ninety Rule: Projeler Neden “%90 Bitti” Aşamasında Takılıp Kalır?
• Hofstadter’s Law: Bir İş Neden Her Zaman Beklediğinizden Uzun Sürer?

Kaynaklar

• Broken Windows Theory — Laws of Software Engineering (https://lawsofsoftwareengineering.com/laws/broken-windows-theory/)
• Dave Thomas & Andy Hunt, The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 1999)

Sprint planlama toplantısında yeni bir özellik için masaya oturduğunuzu düşünün. Ekip olarak tecrübelisiniz, geçmiş hatalardan ders çıkardınız ve temkinli bir plan yapıyorsunuz:

“Bu geliştirme normal şartlarda 1 ay sürer. Ancak olası riskleri ve gecikmeleri hesaba katalım; kendimize pay bırakıp teslim süresine 6 hafta diyelim.”

Peki sürecin sonunda ne olur? Proje 6 haftada değil, tam 3 ayda zor tamamlanır.

Neden? Entegrasyon yapılacak harici API beklenenden çok daha karmaşık çıkmıştır, kilit bir mühendis hastalanmıştır veya ilk kurulan mimari yaklaşım yetersiz kalıp çöpe atılmış ve her şey baştan kodlanmıştır. Kısacası,”öngörülemeyen” durumlar projenin olağan akışı hâline gelmiştir.

Bilişsel bilimci Douglas Hofstadter, 1979 tarihli Pulitzer ödüllü başyapıtı Gödel, Escher, Bach: An Eternal Golden Braid kitabında bu kronik tahminleme paradoksunu özyinelemeli (recursive) ve sarsıcı bir kanunla formüle etmiştir.

İlkenin klasik ifadesi şöyledir:

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Türkçesiyle:

Hofstadter Yasası’nı hesaba katsanız bile, bir iş her zaman beklediğinizden daha uzun sürer.

1. Özyinelemeli Tuzak (The Recursive Trap)

Hofstadter Yasası’nın dehşeti, kendi içine dönen yapısından kaynaklanır.

Bir işe başlarken “Geçmişte benzer işler sarmıştı, bu yüzden tahmini süreyi iki katına çıkarıyorum” deseniz dahi iş yine gecikir; bu kez üç katı sürer. Çünkü insan beyni neyi bilmediğini (unknown unknowns) öngöremez.

Yazılım geliştirme, fabrika bandında standart bir üretim yapmak değildir; yaratıcı ve belirsizliklerle dolu karmaşık bir problem çözme sürecidir. Ne kadar deneyimli olursanız olun, daha önce hiç çözmediğiniz teknik pürüzlerin ne zaman ortaya çıkacağını önceden kesin bir takvime bağlayamazsınız.

2. İki Ateş Arasında: Parkinson Yasası vs. Hofstadter Yasası

Yazılım planlamalarında iki zıt kuvvet sürekli çatışır:

• Parkinson Yasası: “Bir iş, tamamlanması için kendisine ayrılan süreyi dolduracak şekilde genişler.”
• Hofstadter Yasası: “Bir iş, ne kadar pay bırakırsanız bırakın beklediğinizden uzun sürer.”

Buradaki tuzak şudur: Eğer takvimi çok gevşetip gereğinden fazla güvenlik payı (buffer) eklerseniz, Parkinson Yasası devreye girer ve ekip rehavete kapılarak zamanı tüketir. Ancak hiç pay bırakmayıp takvimi sıkıştırırsanız, bu kez Hofstadter Yasası devreye girer ve ortaya çıkan ilk teknik engelde tüm teslim planı çöker.

3. Pratik Bir Yaklaşım: Ne Kadar Süre Ayırmalıyız?

Hofstadter Yasası’nın yarattığı baskıyı yönetmek için sahada sıkça başvurulan pratik bir kural (rule of thumb) vardır:

• İş 2 dakika sürüyorsa: Hemen o an yapın ve aradan çıkarın.
• İş birkaç dakika sürüyorsa: Takvime 1 saat olarak yazın.
• İş birkaç saat sürüyorsa: Takvime 1 gün olarak yazın.

Buradaki amaç süreci gereksiz yere uzatmak değildir. Amaç, beklenmedik teknik pürüzler ve hata ayıklama süreçleri devreye girdiğinde, kodu aceleye getirmeden kaliteli bir şekilde teslim edebilecek alanı kazanmaktır.

Bu Tuzaktan Nasıl Kaçınabiliriz?

Tahmin yapmaktan tamamen vazgeçemeyiz; ancak Hofstadter Yasası ile savaşmak yerine onunla yaşamayı öğrenebiliriz:

• Tek Bir Tarih Yerine Aralık Belirleyin: Projeleri “15 Kasım’da bitecek” gibi tek ve kesin bir tarih yerine,güven aralıklarıyla (“En erken 10 Kasım, en geç 30 Kasım”) ifade edin.
• Güvenlik Paylarının (Buffer) Tüketileceğini Bilin: Takvime eklediğiniz paylar projenin erken bitmesini sağlamaz; yalnızca kaçınılmaz gecikmeler yaşandığında projenin krize girmesini engeller.
• Küçük Parçalara Bölün: Tahmin edilecek işin boyutu büyüdükçe Hofstadter Yasası’nın hata payı katlanarak artar. Görevleri birkaç günü aşmayacak küçük modüllere bölmek, bilinmeyen riskleri erkenden gün yüzüne çıkarır.

Sonuç

Yazılım dünyasında bir projenin planlanan takvimi aşması çoğu zaman ekibin yetersizliğinden veya tembelliğinden kaynaklanmaz. Mesele, karmaşık yaratıcı süreçlerde geleceği kesin çizgilerle öngörebileceğimizi sanma yanılgımızdır.

Hofstadter Yasası’nı bilmek projelerin gecikmesini sihirli bir şekilde engellemez; ancak gecikmeyi bir kaza değil,karmaşık sistemlerin doğal bir gerçeği olarak kabul edip daha olgun planlar yapmamızı sağlar.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?
• Brooks’s Law: Geciken Bir Projeye İnsan Eklemek Neden Onu Daha da Geciktirir?
• Dunbar’s Number: Ekipler Neden 150 Kişiden Sonra Yabancılaşır?
• Ninety-Ninety Rule: Projeler Neden “%90 Bitti” Aşamasında Takılıp Kalır?

Kaynaklar

• Hofstadter’s Law — Laws of Software Engineering
• Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid (1979)

Mimari ve ekipler üzerine konuştuktan sonra serinin bu bölümünde doğrudan proje yönetimi ve tahminlemenin kalbine, Planning (Planlama) kategorisine geçiyoruz.

Her yazılım ekibinin aşina olduğu bir sahne vardır:

Haftalık durum toplantısında geliştiriciye projenin ne durumda olduğu sorulur. Yanıt kendinden emindir: “Neredeyse bitti, %90'ını tamamladım. Sadece birkaç küçük pürüz kaldı.”

Aradan iki hafta geçer; proje hâlâ %90'dadır. Bir ay geçer; durum değişmez. Proje adeta bir asimptot gibi %90 seviyesine kilitlenmiş, bir türlü %100'e ulaşamamaktadır.

Bell Labs’ten Tom Cargill tarafından ortaya atılan ve Jon Bentley’in 1985 tarihli Communications of the ACM makalesinde popülerleşen Ninety-Ninety Rule (Doksan-Doksan Kuralı), bu planlama paradoksunu matematiksel bir absürtlükle ama son derece isabetli bir mizahla tanımlar.

İlkenin orjinal ifadesi şöyledir:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

Türkçesiyle:

Kodun ilk %90'ı, planlanan geliştirme süresinin ilk %90'ını tüketir. Kodun geriye kalan %10'u ise geliştirme süresinin diğer %90'ını tüketir.

Toplamın %180 etmesi bir hesap hatası değildir; yazılım projelerindeki takvim sapmalarının ve eksik tahminlemelerin gerçeğe yansımasıdır.

1. “Mutlu Yol” (Happy Path) İllüzyonu

Bir geliştirici bir özelliği kodlarken süreyi zihninde doğrusal varsayar. İlk aşamada temel iş mantığı (core logic) hızla ayağa kaldırılır. Veriler akmaya başlar, butonlar çalışır ve ekranda beklenen çıktı görünür.

İşte geliştiricinin “İşin %90'ı bitti” dediği an tam olarak burasıdır: Happy Path (Mutlu Yol) tamamlanmıştır.

Ancak bir yazılımı yalnızca “her şey yolunda gittiğinde çalışan” bir prototipten, “üretim ortamında (production) dayanıklı” bir sisteme dönüştürmek, o görünüşte küçük kalan %10'luk alanda gizlidir.

2. Geriye Kalan Görünmez %10'un Anatomisi

Yazılımın kalan %10'luk kısmı aslında şu zorlu ve zaman alıcı süreçlerin tamamıdır:

• Sınır Durumlar (Edge Cases): Beklenmedik kullanıcı girdileri, boş (null) değerler, concurrency çatışmaları ve yarış durumları (race conditions).
• Hata Yönetimi ve Dayanıklılık: Ağ kopmaları, API zaman aşımları (timeout), fallback mekanizmaları ve veri tabanı kilitlenmeleri.
• Test ve Entegrasyon: Birim testleri, uçtan uca (E2E) testler ve diğer sistemlerle uyumluluk doğrulamaları.
• Operasyonel Hazırlık: Güvenlik açıklarının taranması, loglama, metriklerin ve izleme altyapısının (observability) kurulması, CI/CD hatlarının yapılandırılması.
• Ortam Farklılıkları: “Benim yerel makinemde (localhost) çalışıyordu” sendromunun canlı ortamda çözülmesi.

Yazılımcılar kod yazarken genellikle ilk %90'lık yaratıcı kısmı tahmin eder; ancak kalan %10'luk “mühendislik temizliği” ve “üretim dayanıklılığı” süresini sistematik olarak hafife alır.

Bu Tuzaktan Nasıl Kaçınabiliriz?

Doksan-Doksan Kuralı’nın yarattığı sonsuz döngüyü kırmak için izlenebilecek temel yaklaşımlar:

• “Bitti” Tanımını (Definition of Done) Katılaştırın: Bir iş, geliştirici kodlamayı bitirdiğinde değil; testleri yazıldığında, kodu incelendiğinde (code review), dokümante edildiğinde ve dağıtıma hazır olduğunda “bitti” kabul edilmelidir.
• Dikey Dilimleme (Vertical Slicing): Projeyi tek parça dev bir blok olarak geliştirmek yerine, her biri üretim kalitesinde test edilmiş küçük fonksiyonel dilimlere bölün. Böylece görünmeyen işler projenin sonuna yığılmaz.
• Sınır Durumları Baştan Tasarlayın: Hata yönetimi ve sınır durumları kodlamanın en sonuna bırakılacak bir detay değil, mimarinin ana girdisi olmalıdır.
• Tahminlemelerde Güven Payı (Buffer) Bırakın: İlk prototipin ortaya çıkma süresini projenin bitişi sanma yanılgısını kabul edin ve test/dağıtım süreçleri için gerçekçi zaman dilimleri ayırın.

Sonuç

Yazılım geliştirme, bir duvarı tuğla tuğla örmeye benzemez. Kodun son satırlarını yazmak işin bittiği anlamına gelmez; çoğu zaman asıl mühendislik mücadelesinin yeni başladığını gösterir.

Bir projede “İşin %90'ı bitti” cümlesini duyduğunuzda yapılması gereken, rahatlamak değil; projenin en belirsiz, en zorlu ve en çok zaman alacak ikinci yarısına zihnen hazırlanmaktır.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?
• Brooks’s Law: Geciken Bir Projeye İnsan Eklemek Neden Onu Daha da Geciktirir?
• Dunbar’s Number: Ekipler Neden 150 Kişiden Sonra Yabancılaşır?

Kaynaklar

• Ninety-Ninety Rule — Laws of Software Engineering
• Tom Cargill / Jon Bentley, Programming Pearls: Bumper-Sticker Computer Science (Communications of the ACM,1985)

Şirket büyüyüp çalışan sayısı yüzleri aştığında ise kaçınılmaz bir kırılma yaşanır: Koridorda tanımadığınız yüzler belirir,şirketin genel toplantıları (all-hands) samimiyetini yitirir, departmanlar arası silolar oluşur ve gayriresmi mutabakatların yerini prosedürler ile bürokrasi alır.

Yöneticiler bu kırılmayı genellikle “şirket kültürü bozuldu” ya da “iletişim eksikliği var” diyerek açıklamaya çalışır. Oysa mesele motivasyon eksikliği değil, insan beyninin biyolojik sınırlarıdır.

1992 yılında İngiliz antropolog Robin Dunbar, primatların beyin büyüklüğü (neokorteks hacmi) ile sürdürebildikleri sosyal grup boyutları arasındaki ilişkiyi incelerken bu sınırın insanlardaki karşılığını hesapladı: Dunbar’s Number (Dunbar Sayısı).

İlkenin temel tanımı şöyledir:

Bir bireyin herkesi kişisel olarak tanıyabileceği, rollerini ve birbirleriyle ilişkilerini takip edebileceği kararlı sosyal ilişkiler ağının bilişsel üst sınırı yaklaşık 150 kişidir.

Dunbar’a göre 150 sayısı tek bir katı sınırdan ibaret değildir; insan ilişkileri iç içe geçmiş halkalar hâlinde katlanarak genişler:

• 5 Kişi (En Yüksek Güven): Çekirdek destek çemberi. Kriz anında koşulsuz güvenebileceğiniz en yakın iş arkadaşları.
• 15 Kişi (Güvenilir Çalışma Grubu): Gerçek anlamda yakın iş birliği yapılabilen sınır.
• 50 Kişi (Yakın Çalışma Çevresi): Birlikte bir “topluluk” hissini koruyabilen bir bölüm veya mühendislik kolu.
• 150 Kişi (Sosyal Ağın Üst Sınırı): Bir organizasyonda herkesin yüzünü ve rolünü hatırlayabileceğiniz azami sınır.

150 sınırının üzerine çıktığınızda elinizde artık organik bir topluluk kalmaz; birbirine yabancılaşmış bireylerden oluşan bir şirket vardır.

Yazılım Dünyasında Dunbar Sayısı Nasıl Karşımıza Çıkar?

Büyümeyi yönetebilen mühendislik organizasyonları, insan biyolojisiyle savaşmak yerine sistemlerini bu katmanlara göre tasarlayanlardır:

1. Valve Corporation: Yöneticisiz Şirket Modeli

Valve’da yönetici, hiyerarşi veya resmi bir organizasyon şeması yoktur. Mühendisler çalışacakları projeleri kendileri seçer.

Ancak bu özgürlük kuralsızlık demek değildir; Valve, Dunbar Sayısı’nı şirket politikasına dönüştürmüştür:

• Proje ekipleri 12 kişiyle sınırlandırılır.
• Bir proje ekibi 15 kişiyi geçerse ekip bölünür.
• Bir grubun boyutu 50 kişiye ulaştığında ikiye ayrılır.
• Organizasyon büyüklüğü 150 kişiyi aştığında ise mevcut binayı büyütmek yerine yepyeni bir ofis açılır.

2. Amazon: “İki Pizzalık Ekipler” (Two-Pizza Teams)

Jeff Bezos’un popülerleştirdiği “Bir ekip iki pizzayla doymuyorsa çok büyüktür” kuralı (5–10 kişi), Dunbar’ın en içteki 5–15 kişilik yüksek güven halkasını hedefler. Ekipler bu boyutta kaldığında koordinasyon toplantılarına gerek kalmadan hızlı karar alabilir.

3. Linux Çekirdeği: Alt Sistemler ve Hiyerarşi

Linux çekirdeği (kernel) projesine binlerce mühendis katkı sağlar. Ancak bu binlerce kişi merkezi tek bir kanalda iletişim kurmaz. Proje; ağ, dosya sistemi, bellek yönetimi gibi alt sistem (subsystem) e-posta gruplarına bölünmüştür. Her çekirdek bakımcı (maintainer) binlerce kişilik kitlenin tamamıyla değil, yalnızca kendi küçük grubuyla doğrudan haberleşir.

Mühendislik Liderleri İçin Çıkarımlar

Dunbar Sayısı, organizasyon büyütürken rahatsız edici ama kritik gerçekleri hatırlatır:

• 15 kişiyi aşan ekiplerde doğrudan iş birliği ve güven bağı gevşemeye başlar; toplantı yükü katlanır.
• 50 kişiyi aşan bölümlerde şirket geneli toplantılar insanları kaynaştırmaz, tek taraflı duyuru panosuna döner.
• 150 kişiyi aşan organizasyonlarda artık işlerin gayriresmi iletişimle yürümesini bekleyemezsiniz. Yazılı dokümantasyon, net API sözleşmeleri ve otonom alt gruplar kurmak zorunlu hâle gelir.

Sonuç

Bir yazılım sistemini tasarlarken nasıl sunucu belleğinin (RAM) sınırlarını bilerek mimariyi kuruyorsak, organizasyonu büyütürken de insan beyninin bilişsel sınırlarını hesaba katmak zorundayız.

150 kişiyi aşmış bir mühendislik yapısında ekipleri tek bir devasa yapıda tutmaya çalışmak, monolitik bir veritabanına sınırsız yük bindirmeye benzer.

Ölçeklenmenin yolu ekibi sonsuza kadar büyütmek değil; Dunbar’ın sınırlarına saygı duyarak sistemi küçük, bağımsız ve yüksek güvene sahip modüllere bölebilmektir.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?
• Brooks’s Law: Geciken Bir Projeye İnsan Eklemek Neden Onu Daha da Geciktirir?

Kaynaklar

• Dunbar’s Number — Laws of Software Engineering
• Robin Dunbar, Neocortex size as a constraint on group size in primates (1992)

Artık genelde projelere yeni insan eklemiyoruz, onun yerine yeni Yapay zeka ajanları ekliyoruz ama gene de teslim tarihine (deadline) bir ay kalmış bir projede işlerin planlandığı gibi gitmediğini fark ettiğimizde, yönetim toplantılarında en sık duyulan refleks şudur:

“Hemen ekibe 3–4 yazılımcı daha kaydıralım, el birliğiyle projeyi yetiştirelim.”

Gündelik hayatta bu sezgisel bir mantıktır: Bir tarlayı sürmek veya bir duvarı örmek için çalışan sayısını iki katına çıkarırsanız, iş yarı sürede biter. Ancak yazılım geliştirmede bu refleks genellikle ateşe benzin dökmekle sonuçlanır.

IBM’in OS/360 işletim sistemi projesindeki deneyimlerinden yola çıkan Fred Brooks, 1975 tarihli The Mythical Man-Month eserinde bu gerçeği yazılım dünyasının en ünlü kanunlarından biriyle ifade etmiştir.

İlkenin orijinal tanımı şöyledir:

Adding manpower to a late software project makes it later.

Türkçesiyle:

Geç kalan bir yazılım projesine insan kaynağı eklemek, projeyi daha da geciktirir.

Brooks, yazılım projelerinde “insan” ile “zaman”ın birbirinin yerine geçen değişkenler olduğu varsayımını (insan-ay / man-month kavramını) bir efsane olarak nitelendirir. Projeye sonradan dahil edilen geliştiricilerin süreci hızlandırmak yerine yavaşlatmasının arkasında üç temel neden yatar:

1. Alışma Süreci (Ramp-up Time)

Yeni katılan geliştiriciler ilk günden tam verimle kod yazamaz. Mimariyi, iş kurallarını (domain), şirket içi araçları ve kod tabanını öğrenmek zorundadırlar.

Asıl kritik nokta şudur: Yeni gelenleri eğitecek, onlara kod incelemesi (code review) yapacak ve sorularını yanıtlayacak kişiler, projenin iç dinamiklerini en iyi bilen mevcut kıdemli mühendislerdir. Dolayısıyla yeni kaynak eklemek, halihazırda gecikmiş olan çekirdek ekibin üretim hızını doğrudan aşağı çeker.

2. İletişim Yükünün Katlanarak Artması (Communication Overhead)

Yazılım geliştirme izole bir iş değildir; sürekli müzakere, hizalanma ve koordinasyon gerektirir. Bir ekipteki iletişim kanallarının sayısı doğrusal değil, kombinatoryal olarak artar.

Ekipteki kişi sayısı n olduğunda, potansiyel iletişim kanalı sayısı şu formülle hesaplanır:

n(n-1)/2

4 kişilik bir ekipte yönetilmesi gereken 6 iletişim kanalı varken,

• Ekip 8 kişiye çıktığında bu kanal sayısı 28’e,
• 12 kişiye çıktığında ise 66’ya fırlar.

Kişi sayısı arttıkça toplantı süreleri uzar, mimari mutabakatlar zorlaşır ve mesajlaşma trafiği kod yazma süresini yutmaya başlar.

3. İşin Bölünemez Doğası (Task Partitioning)

Fred Brooks’un kitabındaki meşhur analojisi meseleyi çok net özetler:

Dokuz kadının bir araya gelmesi, bir bebeğin bir ayda doğmasını sağlamaz.

Bazı işler doğası gereği sıralıdır (sequential). Bir veritabanı modeli oturmadan servis katmanı yazılamaz,API kontratı çıkmadan arayüz tamamlanamaz. Görevler birbirinden bağımsız parçalara bölünemiyorsa,ekibe eklenen fazladan kişiler birbirlerinin adımlarını beklemek zorunda kalır ve çakışmalar (merge conflicts) artar.

Geciken Bir Projede Ne Yapılmalı?

Bir proje gecikmeye başladığında insan eklemek çözüm değilse, hangi adımlar atılmalıdır?

• Kapsamı Küçültün (Scope Reduction): Teslim tarihini tutturmanın en gerçekçi yolu, özellik listesini acımasızca budamak ve yalnızca mutlak gerekli olan MVP çekirdeğine odaklanmaktır.
• Teslim Tarihini Gerçekçi Olarak Öteleyin: Zaman tahmininin hatalı olduğunu baştan kabul edip takvimi güncellemek, projeye aceleyle insan yığıp kaliteyi çökertmekten daha az maliyetlidir.
• Yeni Kaynakları Kritik Yoldan Uzak Tutun: Eğer ekibe mutlaka yeni geliştiriciler dahil edilecekse, bu kişileri doğrudan geciken ana geliştirme hattına (critical path) sokmak yerine; dokümantasyon, bağımsız testler veya ortam kurulumları gibi ana ekibin odağını bölmeyecek alanlara yönlendirin.

Sonuç

Brooks’s Law, yazılım mühendisliğinin karmaşık bir organizasyonel koordinasyon işi olduğunu hatırlatır.İnsanlar fabrika tezgahındaki makineler gibi birbirinin yerine ikame edilemez.

Bir proje geciktiğinde yapılacak en tehlikeli hamle, sırf yönetimsel bir aksiyon alıyor gibi görünmek adına ekibe kontrolsüzce yeni insanlar eklemektir. Olgun ekipler kriz anlarında ekibi büyütmeye değil, karmaşıklığı ve kapsamı küçültmeye odaklanır.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?
• Conway’s Law: Sistem Mimarisi Organizasyon Yapısını Neden Aynalar?

Kaynaklar

• Brooks’s Law — Laws of Software Engineering
• Fred Brooks, The Mythical Man-Month: Essays on Software Engineering (1975)

Bu yazıyla birlikte seride yeni bir faza geçiyoruz: Ekipler ve Organizasyonlar (Teams).

Çünkü yazılım, yalnızca sunucularda ve kod satırlarında var olmaz; onu geliştiren insanların, iletişim biçimlerinin ve kurumsal yapıların doğrudan bir sonucudur.

Yeni fazın ilk ve en etkili ilkesi, 1967 yılında bilgisayar bilimci Melvin Conway tarafından ortaya konan Conway’s Law (Conway Yasası).

İlkenin klasik ifadesi şöyledir:

Software systems reflect the communication structure of the organization that builds them.

Türkçesiyle:

Yazılım sistemleri, bunları geliştiren organizasyonun iletişim yapısını yansıtır.

Conway’in temel tezi son derece nettir: Bir yazılımın mimarisini belirleyen asıl güç teknik diyagramlar veya mimari kararlar değil; ekibin içindeki iletişim kanalları ve organizasyon şemasıdır.

1. Klasik Örnek: Dört Ekip ve Dört Aşamalı Derleyici

Melvin Conway’in makalesinde aktardığı en çarpıcı örneklerden biri bir derleyici (compiler) projesidir:

Bir sistem için derleyici geliştirmek üzere işe koyulan bir organizasyon, projeyi dört ayrı gruba böler. Sürecin sonunda ortaya çıkan derleyici tam olarak dört aşamalı (4-pass compiler) bir yapıya sahip olur.

Bunun nedeni dört aşamalı bir derleyicinin teknik olarak en iyi mimari olması değildir. Gruplar arasındaki iletişim hatları ve iş bölümü, doğrudan kodun arayüzlerine (interface) ve modül sınırlarına dönüşmüştür. Ekipler birbirleriyle nasıl konuşuyorsa, kod parçaları da tam olarak o sınırlar üzerinden haberleşecek şekilde tasarlanmıştır.

2. Katmanlı Ekipler, Katmanlı Mimariler

Günümüz yazılım dünyasında Conway Yasası’nın en yaygın tezahürü departman bazlı iş bölümünde görülür:

• Ayrı bir Arayüz (Frontend) ekibi,
• Ayrı bir Backend ekibi,
• Ayrı bir Veritabanı (DBA) ekibi.

Bu organizasyon yapısına sahip bir şirketin monolitik veya katmanlı bir mimari (3-tier architecture) üretmesi neredeyse kaçınılmazdır. Özellik geliştirmeleri ekipler arasında ticket handover yöntemiyle ilerlediği için kod tabanı da UI katmanı, servis katmanı ve veri erişim katmanı olarak birbirinden kalın duvarlarla ayrılır.

Sorun bu katmanların varlığı değil; kullanıcıya yönelik tek bir küçük özelliğin bile hayata geçmesi için üç ayrı ekibin toplantı yapmasını ve birbirini beklemesini gerektirmesidir.

3. Ters Conway Manevrası (Inverse Conway Maneuver)

Conway Yasası bize mimarinin organizasyonu takip ettiğini söyler. O halde hedeflenen mimariyi kurmanın yolu nedir?

Cevap: Ters Conway Manevrası.

Eğer bağımsız dağıtılabilen, gevşek bağlı (loosely coupled) mikroservisler veya modüller inşa etmek istiyorsanız, önce organizasyonunuzu bu şekilde yapılandırmalısınız.

Yani katmanlara göre ayrılmış ekipler yerine; içinde frontend, backend, test ve ürün sorumlusunu barındıran uçtan uca otonom ürün ekipleri (cross-functional teams) kurmanız gerekir. Ekip sınırları ile yazılımın iş alanı sınırları (Bounded Contexts) örtüştüğünde, sistem mimarisi de doğal olarak modüler ve bağımsız bir yapıya evrilir.

Sonuç

Bir yazılım mimarisini değiştirmek istediğinizde yalnızca kod bloklarını yeniden düzenlemek yetmez. Ekipler arasındaki duvarları, raporlama zincirlerini ve iletişim alışkanlıklarını değiştirmediğiniz sürece sistem eninde sonunda eski organizasyonel reflekslerine geri dönecektir.

Mimari kararlar teknik tercihlerden ibaret değildir; bir organizasyonun insan ilişkilerinin dijital dünyadaki izdüşümüdür.

İyi bir mimar, yalnızca sınıfların ve servislerin nasıl konuşacağını değil; insanların birbirleriyle nasıl iletişim kurduğunu da hesaba katmak zorundadır.

Yazılım Mühendisliğinin Kanunları — 10

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası
• Zawinski’s Law: Yazılımlar Neden Sürekli Şişer ve E-posta Okumaya Çalışır?

Kaynaklar

• Conway’s Law — Laws of Software Engineering
• Melvin E. Conway, How Do Committees Invent? (F. D. Thompson Publications, Inc., 1968)

Odaklanmış, hızlı ve tek bir amaca hizmet eden harika bir araç geliştirdiğinizi düşünün.

İlk başta her şey yolundadır: Kullanıcılar aracın hafifliğini ve sadeliğini över. Ancak zaman geçtikçe talepler gelmeye başlar:”Projeyi çalışma arkadaşımla paylaşabilsem…”, “Şuraya bir yorum alanı eklesek…”, “Değişiklik olduğunda bana bildirim/e-posta gelse…”

Bir süre sonra fark edersiniz ki o yalın araç; içinde sohbet pencereleri, bildirim merkezleri ve entegrasyonlar barındıran devasa bir iletişim platformuna dönüşmüş.

Netscape’in ilk geliştiricilerinden Jamie Zawinski (jwz) tarafından 1995 yılında ortaya atılan Zawinski’s Law (Zawinski Yasası), yazılımların bu kaçınılmaz şişme eğilimini mizahi ama son derece gerçekçi bir tespitle açıklar.

İlkenin orijinal ifadesi şöyledir:

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Türkçesiyle:

Her program, e-posta okuyabilecek seviyeye gelene kadar genişlemeye çalışır. Bu şekilde genişleyemeyen programlar, genişleyebilenlerle değiştirilir.

Zawinski bu ilkeyi ortaya attığında internetin erken dönemleriydi ve “iletişim” denince akla gelen temel protokol e-postaydı. Ancak kuralın işaret ettiği asıl dinamik; kapsam şişmesi (scope creep / feature bloat) ve yazılımların er ya da geç kullanıcılar arası iletişimi kendi içine çekme arzusudur.

1. Tarihsel Çıkış Noktası: Emacs ve Netscape

Zawinski bu kuralı gözlemlerken iki büyük örneğe dayanıyordu:

• Emacs: Başlangıçta yalnızca bir metin düzenleyici olan Emacs; zamanla içine dosya yöneticisi, oyunlar, takvim ve en sonunda e-posta/haber okuyucu (Gnus) alarak adeta kendi başına bir işletim sistemine dönüştü.
• Netscape Navigator: Sadece web sayfalarını gezinmek için tasarlanan tarayıcı, kullanıcıların tarayıcıdan çıkmadan iletişim kurma talepleri neticesinde kısa sürede Netscape Mail & News bileşenini içine alarak devasa bir internet paketine (suite) evrildi.

Zawinski’nin vurguladığı kritik detay şuydu: Bir araç ne kadar iyi olursa olsun, kullanıcılar işlerini yaparken başka bir programa geçmek (context switching) istemiyordu.

2. Modern Dünyada “E-posta Okumak” Ne Anlama Geliyor?

Bugün Zawinski Yasası’ndaki “e-posta”, genel olarak iletişim, iş birliği ve entegrasyon anlamına gelir:

• Kod editörleri (VS Code, JetBrains) artık sadece kod yazmıyor; canlı iş birliği (Live Share), entegre chat ve yapay zeka asistanları barındırıyor.
• Tasarım araçları (Figma), çizim aracı olmanın ötesine geçip sesli sohbet ve anlık mesajlaşma platformlarına dönüştü.
• Proje yönetim araçları (Notion, Trello, Jira) kendi içinde e-posta gönderen, bildirim üreten ve mesajlaşılan merkezler hâline geldi.

Modern bir yazılımın “e-posta okumaya başlaması”, onun artık tek bir işlevi yerine getiren saf bir araç olmaktan çıkıp bir çalışma ortamı olmaya soyunmasıdır.

3. Unix Felsefesi ile Pazar Gerçeğinin Çatışması

Yazılım mühendisliğinin altın kurallarından biri Unix felsefesidir: “Bir işi yap ve onu en iyi şekilde yap.”

Mühendislik açısından odaklanmış, küçük ve hafif araçlar ideal olanıdır. Ancak Zawinski Yasası, mühendislik idealleriyle pazar gerçekleri arasındaki acımasız çatışmayı hatırlatır: Genişlemeyi reddeden ve yalnızca tek bir işe odaklanan araçlar teknik olarak daha zarif kalabilir; fakat kullanıcılar genellikle “her işini tek bir pencerede çözen”, daha şişkin (bloated) araçları tercih eder. Bu yüzden genişlemeyen araçlar, genişleyenler tarafından pazarın dışına itilme riskiyle karşı karşıya kalır.

Şişkinliğin (Software Bloat) Mühendislik Bedeli

Bir yazılımın sürekli yeni iletişim ve işlev katmanları ekleyerek büyümesi bedelsiz değildir:

• Güvenlik Yüzeyinin Genişlemesi (Attack Surface): E-posta okumak veya dış dünyadan gelen mesajları/içerikleri işlemek; HTML parsing, dosya indirme ve ağ protokolleri demektir. Eklenen her yeni iletişim kanalı, sisteme yeni güvenlik açığı potansiyelleri getirir.
• Kaynak Tüketimi: Başlangıçta birkaç megabayt bellek tüketen hafif bir araç, içine tarayıcı motorları (Electron gibi), mesajlaşma kuyrukları ve arka plan işçileri eklendikçe yüzlerce megabayt RAM tüketen bir canavara dönüşür.
• Çekirdek Odak Kaybı: Ekip zamanının büyük kısmını ürünün asıl varoluş amacını geliştirmeye değil; bildirim altyapısını, sohbet protokollerini ve kullanıcı izinlerini yönetmeye harcamaya başlar.

Sonuç

Zawinski Yasası, yazılımların zaman içinde karmaşıklaşmasının ve şişmesinin kaçınılmaz bir pazar yerçekimi olduğunu gösterir.

Bir yazılım mimarı veya ürün geliştiricisi olarak görevimiz bu baskıyı tamamen görmezden gelmek değildir. Asıl hüner; kullanıcıların iletişim ve entegrasyon ihtiyaçlarını karşılarken ürünün çekirdek değerini şişkinlik (bloat) altında ezilmekten koruyabilmektir.

Her program eninde sonunda e-posta okumak isteyebilir; ancak iyi bir mühendislik vizyonu, programın ne zaman durması gerektiğini bilen sınırlara sahip olmalıdır.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı
• Law of Unintended Consequences: İstenmeyen Sonuçlar Yasası

Kaynaklar

• Zawinski’s Law — Laws of Software Engineering
• Jamie Zawinski, The Netscape Dormando Group Notes (1995)

“İstek başarısız olursa istemci hemen 3 kez daha denesin (retry mekanizması).”

Değişikliği canlıya alıyoruz. İlk birkaç gün her şey mükemmel görünüyor; geçici hatalar kullanıcıya yansımadan çözülüyor. Ancak bir gün arka plandaki veritabanı yoğunluktan dolayı hafifçe yavaşlıyor. Normalde dakikada 1.000 istek alan sistem, devreye giren agresif retry politikası yüzünden bir anda 4.000 istekle boğulmaya başlıyor.

Yavaşlayan servis toparlanmak yerine tamamen çöküyor. Kendi ellerimizle yazdığımız iyileştirme, kendi backend’imize yapılmış bir DDoS saldırısına dönüşüyor.

İşte bu senaryo, yazılım mühendisliğinde ve karmaşık sistemlerde sıklıkla karşımıza çıkan Law of Unintended Consequences (İstenmeyen Sonuçlar Yasası) ilkesinin tipik bir örneğidir.

İlke:

Whenever you change a complex system, expect surprise

Türkçesiyle özet şu şekildedir:

“Karmaşık bir sisteme yapılan herhangi bir amaçlı müdahale, her zaman öngörülmeyen ve hedeflenmemiş sonuçlar (yan etkiler) doğurur.”

Bu sonuçlar bazen beklenmedik bir fayda sağlasa da, mühendislik dünyasında genellikle iki tehlikeli biçimde ortaya çıkar:

1. Geri tepen çözümler (Perverse Results / Kobra Etkisi): Çözümün, çözmeye çalıştığı problemi daha da büyütmesi.
2. Beklenmeyen yan etkiler (Unexpected Drawbacks): Bir problemi çözerken tamamen alakasız başka bir kritik alanı bozması.

Yazılım geliştirme süreçlerinde iyi niyetle aldığımız kararların nasıl ters teptiğine ve karmaşıklığın bunu nasıl tetiklediğine yakından bakalım.

1. Performans İçin Cache Eklemek: Veritabanını Kurtarırken Belleği ve Tutarlılığı Kaybetmek

Veritabanı sorguları yavaşladığında akla gelen ilk refleks önbellekleme (caching) yapmaktır. Redis veya Memcached ekleyerek sorgu sürelerini mikrosaniyelere düşürmeyi hedefleriz.

Ancak cache eklemek, sisteminize yeni bir durum (state) ve bağımlılık katmanı ekler:

• Cache Invalidation: Veritabanındaki veri güncellendiğinde cache’teki veriyi temizlemek yazılımın en zor problemlerinden birine dönüşür. Kullanıcılar güncellenmemiş (stale) veriler görmeye başlar.
• Thundering Herd (Cache Stampede): Popüler bir verinin cache süresi (TTL) dolduğu anda, gelen binlerce istek aynı milisaniyede veritabanına hücum eder ve normalde çalışacak olan veritabanını bir anda kilitler.

Performansı artırmak amacıyla atılan basit bir adım, dağıtık veri tutarlılığı ve bellek yönetimi krizini beraberinde getirir.

2. Yerel Optimizasyonların Küresel Bedeli: İndeksler ve Kilitler (Locks)

Karmaşık sistemlerde bir noktayı optimize etmek, genellikle başka bir noktaya gizli bir yük bindirir:

• Sorgu Optimizasyonu vs. Yazma Maliyeti: Yavaş çalışan bir SELECT sorgusunu hızlandırmak için tabloya yeni indeksler ekleyebilirsiniz. Okuma performansı anında düzelir. Ancak her yeni indeks; INSERT, UPDATE ve DELETEişlemlerinde diske ekstra yazma, replikasyon gecikmesi ve veritabanı kilitlenme sürelerinde artış demektir.
• Race Condition Çözümü vs. Deadlock: Çok iş parçacıklı (multithreaded) bir yapıda yarış durumunu engellemek için kod bloklarına kilit (mutex/lock) koyabilirsiniz. Hatalı veri yazımını engellersiniz, ancak kilit süreleri uzadığında sistem genelinde thread starvation veya deadlock (kilitlenme) yaşanabilir.

Bir katmandaki iyileştirme, görünmez bağlarla bağlı olduğu diğer katmanda performans darboğazına dönüşür.

3. İkinci Dereceden Düşünme (Second-Order Thinking)

Karmaşık sistemlerde doğrusal düşünce tarzı iflas eder:

• Birinci Dereceden Düşünme (First-Order): “X problemi var, Y çözümünü uygularsam X çözülür.”
• İkinci Dereceden Düşünme (Second-Order): “Y çözümünü uygularsam X çözülecek. Peki ya sonra ne olacak? Bu çözüm diğer servisleri, ağ trafiğini, kullanıcı davranışlarını ve veri tutarlılığını nasıl etkileyecek?”

Sistem mühendisliğinde olgunluk, yalnızca problemi anlık olarak çözmek değil; çözümün sistemin geri kalanında tetikleyeceği zincirleme reaksiyonları öngörebilmektir.

Bu Tuzaktan Nasıl Kaçınabiliriz?

İstenmeyen sonuçları sıfıra indirmek karmaşık sistemlerde imkansızdır; ancak etkilerini sınırlandırmak mümkündür:

• Geri Alınabilirlik (Reversibility): Mimari kararları iki yönlü kapılar (two-way doors) gibi tasarlayın. Bir değişiklik beklenmeyen bir etki yarattığında sistemi dakikalar içinde eski hâline döndürebilecek esneklikte (Feature Flags, Canary Deployment) olun.
• Defansif Tasarım: İstemcilere retry mekanizması ekliyorsanız, araya mutlaka rastgele bekleme süresi koyan Exponential Backoff ve Jitter ekleyin. Servislerin önüne aşırı yüklenmeyi engelleyecek Rate Limiter ve Circuit Breaker yerleştirin.
• Gözlemlenebilirlik (Observability): Yalnızca hedeflenen metriği değil, komşu sistemlerin durumunu da izleyin.Örneğin sorgu sürelerini düşürmek için cache eklediğinizde veritabanı CPU kullanımını, bellek doluluğunu ve cache miss oranlarını eş zamanlı takip edin.

Sonuç

Yazılım sistemleri izole edilmiş kod parçalarından ibaret değildir; birbiriyle sürekli etkileşim hâlinde olan dinamik ekosistemlerdir.

Bir mimar veya mühendis olarak masaya oturup bir bileşeni değiştirdiğimizde kendimize sormamız gereken soru yalnızca “Bu kod çalışıyor mu?” olmamalıdır. Asıl kritik soru şudur:

“Bu çözüm, sistemin hangi görünmez dengesini bozacak?”

İyi bir yazılım tasarımı, yalnızca planlanan hedefe ulaşan tasarım değil; planlanmamış etkileri yönetecek kadar esnek ve dayanıklı olan tasarımdır.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?
• Fallacies of Distributed Computing: Dağıtık Sistemlerin 8 Büyük Yanılgısı

Kaynaklar

• Law of Unintended Consequences — Laws of Software Engineering
• Robert K. Merton, The Unanticipated Consequences of Purposive Social Action (1936)

Monolitik bir uygulamada bir fonksiyonu çağırdığınızda sonuç oldukça basittir: İşlem ya anında gerçekleşir ya da bir hata fırlatılır. Her şey aynı bellek alanında, aynı işlemcinin kontrolü altındadır.

Peki ya uygulamanızı mikroservislere böler ve o fonksiyonu başka bir sunucuya taşırsanız ne olur?

Birçok geliştirici için ilk varsayım şudur: “Sadece bir HTTP isteği atacağım, aynı veriyi alıp işime devam edeceğim.”

Oysa işin içine ağ (network) girdiğinde, yazılım geliştirmenin kuralları tamamen değişir. Lokal ortamınızda (localhost) kusursuz çalışan kodunuz, üretim ortamındaki (production) gerçek bir ağa çıktığında hiç beklemediğiniz şekillerde kırılmaya başlar.

1990'ların ortalarında Sun Microsystems mühendisleri (özellikle L. Peter Deutsch ve James Gosling), geliştiricilerin dağıtık sistemler tasarlarken düştükleri temel yanılgıları bir liste hâline getirdiler. Bugün bu liste, Fallacies of Distributed Computing (Dağıtık Hesaplamanın Yanılgıları) olarak bilinir.

İlkenin temel önermesi şudur:

Geliştiriciler, dağıtık bir sistem tasarlarken ağın kusursuz olduğunu varsayarak 8 temel yanılgıya düşerler. Bu varsayımların hepsi yanlıştır ve eninde sonunda sistemin çökmesine neden olur.

Bu 8 yanılgı sadece tarihi bir belge değildir; bulut bilişim ve mikroservis mimarilerinin dünyayı yönettiği günümüzde her zamankinden daha geçerlidir. Gelin bu 8 yanılgıyı yakından inceleyelim.

1. Ağ güvenilirdir (The network is reliable)

Lokal bir metot çağrısı neredeyse hiçbir zaman “yarı yolda” kaybolmaz. Ancak ağ üzerinden gönderilen bir istek; kopan bir kablo, bozulan bir switch, çöken bir yönlendirici (router) veya anlık bir yoğunluk nedeniyle hedefine ulaşamayabilir. Daha da kötüsü, istek hedefe ulaşır, işlem başarıyla yapılır ancak yanıt size dönerken ağ kopabilir.

Eğer ağın hep çalışacağını varsayarsanız, uygulamanız sonsuza kadar yanıt bekleyebilir. Bu yüzden dağıtık sistemlerde Timeout (zaman aşımı) ve Retry (yeniden deneme) mekanizmaları bir seçenek değil, zorunluluktur. İşlemlerin tekrarlanması durumunda verinin bozulmaması için API’lerinizi Idempotent (tekrarlanabilir) tasarlamanız gerekir.

2. Gecikme sıfırdır (Latency is zero)

Bellek içi (in-memory) bir fonksiyonu çağırmak mikrosaniyeler sürer. Oysa aynı işlemi ağ üzerinden başka bir veri merkezindeki servise yaptırmak milisaniyeler, hatta saniyeler alabilir.

Siparişleri listelerken, her siparişin kullanıcı bilgisini almak için User servisine tek tek HTTP isteği attığınızı düşünün. Lokal veritabanında milisaniyeler sürecek bu işlem, ağ üzerindeki gecikmelerin üst üste binmesiyle uygulamanızı tamamen felç edebilir. Dağıtık sistemlerde ağ üzerinden yapılan çağrı sayısını (network round-trip) minimize etmek ve verileri toplu (batch) getirmek şarttır.

3. Bant genişliği sonsuzdur (Bandwidth is infinite)

Videoların 4K, internetin gigabit hızlarında olduğu bir çağda bant genişliğini dert etmemek kolaydır. Ancak binlerce mikroservisin sürekli birbirine devasa JSON’lar fırlattığı bir arka plan sisteminde, bant genişliği hızla tükenebilir.

İhtiyacınız olmayan tüm veri tabanı kolonlarını ağ üzerinden diğer servise gönderiyorsanız, bir süre sonra ağ donanımlarınızın sınırlarına takılırsınız. Yalnızca ihtiyaç duyulan veriyi ileten GraphQL gibi teknolojiler veya gRPC gibi sıkıştırılmış ikili (binary) protokoller bu yanılgıyı aşmak için doğmuştur.

4. Ağ güvenlidir (The network is secure)

Lokal ağınızda sunucuların birbiriyle şifresiz (HTTP) konuşması size güvenli gelebilir. Ancak günümüzde sistemler bulut üzerinde, farklı bölgelere yayılmış (multi-region) ve internete daha açık haldedir.

Ağı güvenli varsayıp servisler arası iletişimi kimlik doğrulamasız (authentication olmadan) yapmak, “Sıfır Güven” (Zero Trust) felsefesine tamamen aykırıdır. Ağ üzerindeki her paketin dinlenebileceğini (sniffing) veya değiştirilebileceğini varsayarak TLS/mTLS (karşılıklı şifreleme) kullanmak zorunludur.

5. Topoloji değişmez (Topology doesn’t change)

Bugün veritabanınız IP’si sabit olan 1. rack’takı sunucuda çalışıyor olabilir. Yarın bulut sağlayıcınız o sunucuyu kapatıp başka bir IP’den yeniden başlatabilir. Konteyner mimarilerinde (Kubernetes) pod’ların IP adresleri dakikalar içinde değişir.

Topolojinin sabit olduğunu varsayıp kodun içine IP adreslerini (hardcode) gömerseniz sisteminiz ilk güncellemede çöker. Bu yüzden DNS, Load Balancer ve Service Discovery (servis keşfi) gibi mekanizmaları kullanılır. Böylece servisler fiziksel IP’lere değil, mantıksal isimlere güvenir.

6. Tek bir sistem yöneticisi vardır (There is one administrator)

Küçük bir uygulamada sunucuyu yöneten, veritabanına bakan ve kodu yazan kişi aynı olabilir. Ancak dağıtık bir sistemde farklı servisler, farklı şirketler (SaaS ürünleri) veya farklı ekipler tarafından yönetilir.

Veritabanı ekibi sizden habersiz bir tabloyu güncellediğinde veya ödeme entegratörü API versiyonunu değiştirdiğinde sisteminiz çökebilir. Mimarilerimizi bu dış bağımlılıkların her an kırılabileceğini (ve muhatap bulamayacağımızı) hesaplayarak tasarlamalı, sistemleri birbirine çok sıkı bağlamaktan (tight coupling) kaçınmalıyız.

7. Taşıma maliyeti sıfırdır (Transport cost is zero)

İki servis birbiriyle konuşurken veriyi JSON’a çevirmek (Serialization), ağdan göndermek ve karşı tarafta tekrar objeye dönüştürmek (Deserialization) zorundadır. Bu işlem CPU döngüleri, bellek (RAM) ve zaman harcar.

Ayrıca bulut dünyasında taşıma maliyeti kelimenin tam anlamıyla “paradır”. AWS, Azure veya Google Cloud üzerinde farklı bölgeler (regions) veya hatta aynı bölgedeki farklı erişilebilirlik alanları (availability zones) arasında gigabaytlarca veri transfer ettiğinizde, ay sonunda devasa ağ faturalarıyla karşılaşırsınız.

8. Ağ homojendir (The network is homogeneous)

Ağdaki tüm cihazların, sunucuların, router’ların ve işletim sistemlerinin aynı standartlarda çalıştığını varsaymaktır. Oysa ağın bir ucu en son model bir bulut sunucusuyken, diğer ucu 3G ile bağlanan eski bir cep telefonu, bir IoT cihazı veya farklı bir iletişim protokolü kullanan eski bir legacy (miras) sistem olabilir. Paket boyutları (MTU), iletim hızları ve bağlantı kaliteleri sürekli değişkenlik gösterir.

Sonuç: Hata İçin Tasarlamak (Design for Failure)

Fallacies of Distributed Computing bize çok net bir mesaj verir: Dağıtık sistemlerde hata bir ihtimal değil, bir kesinliktir.

Mikroservislere geçmek, kodunuzu parçalara ayırmak kadar basit değildir. Ağı mimarinin merkezine koymak ve şu soruları sormak gerekir:

• Ağ koparsa sistem nasıl ayakta kalacak?
• İstek yavaşlarsa veya kaybolursa sistem sonsuza kadar bekleyecek mi?
• Servisler birbirini kilitlerse bu hatayı nasıl izole edeceğiz (Circuit Breaker)?

İyi bir mimari, ağın kusursuz olduğuna inanan değil; ağın her an çökebileceğini kabul edip ona göre önlem alan mimaridir.

Serinin önceki yazıları:

• Gall’s Law: Karmaşık Sistemler Neden Basit Başlamalı?
• Hyrum’s Law: API’nizin Dokümante Edilmemiş Sözleşmeleri
• The Law of Leaky Abstractions: Soyutlamalar Her Şeyi Gizleyemez
• Tesler’s Law: Karmaşıklık Yok Olmaz, Yer Değiştirir
• CAP Theorem: Dağıtık Sistemlerde Neden Her Şeye Sahip Olamayız?
• Second-System Effect: İkinci Sistemi Tasarlarken Neden Aşırıya Kaçarız?

Kaynaklar

• Fallacies of Distributed Computing — Laws of Software Engineering
• Arnon Rotem-Gal-Oz, Fallacies of Distributed Computing Explained