Büyük şirketlerde yetenekli mühendisler neden kötü kod yazar?

• Büyük teknoloji şirketlerinde kısa görev süreleri ve sık organizasyonel yeniden yapılanmalar nedeniyle birçok mühendis, alışık olmadığı kod tabanlarında çalışıyor
• Kod değişikliklerinin önemli bir kısmı, işe girişinin ilk 6 ayındaki ‘acemi’ düzeyindeki mühendisler tarafından yapılıyor
• Bazı deneyimli ‘old-hand’ mühendisler kaliteyi telafi etse de, aşırı iş yükü ve gayriresmî sorumluluklar nedeniyle bunların da sınırları var
• Şirketler, uzmanlıktan ziyade iş gücü hareketliliğini ve görünürlüğü (legibility) önceliklendiriyor; bu da kasıtlı bir kalite düşüşü pahasına yapılıyor
• Sonuç olarak, mühendislerin bireysel yetkinliğinden bağımsız olarak yabancı bir sistemde hızlı teslimat odaklı çalıştıran yapısal sorun, kötü kodun temel nedeni

---

Büyük şirketlerde kötü kodun ortaya çıkardığı yapı

• Büyük teknoloji şirketleri yüksek maaşlarla yetenekli mühendisler işe alıyor, ancak görev süresi çoğu zaman yalnızca 1-2 yıl oluyor
  • Hisse bazlı ödüllerin (share grant) 4 yıl sonunda tamamen hak edilmesi ve sonrasında maaşın yarıya düşmesi gibi bir yapı var
  • Yıllık ek hisse yenilemeleri (refresh) olsa da bunlar garanti edilmediğinden, mühendisler iş değiştirmeyi seçebiliyor
• İç transferler de hesaba katıldığında, aynı kod tabanında 3 yıldan uzun süre kalmak nadir
  • Yeniden yapılanmalar (re-org) her yıl, hatta daha sık gerçekleşebiliyor
• Buna karşılık kod tabanları çoğu zaman 10 yıldan fazla yaşıyor; dolayısıyla mühendislerin büyük bölümü yeni bir sistemi hâlâ ‘öğrenme’ aşamasında
  • Sonuç olarak kod değişikliklerinin önemli bir kısmı işe girişinin ilk 6 ayındaki acemiler tarafından yapılıyor

‘Old-hand’lerin rolü ve sınırları

• Bazı mühendisler belirli bir sistemde uzun süre kalarak derin uzmanlık geliştiriyor
  • Bunlar kod incelemesi yoluyla sorunları erken fark edebiliyor
• Ancak bu yapı gayriresmî ve kurumsallaşmış değil
  • Şirketlerin uzun vadeli uzmanlığı korumaya ilgisi az ve deneyimli kişileri başka takımlara taşıdıkları da oluyor
• Deneyimli kişiler sürekli aşırı iş yükü altında
  • Her değişikliği bizzat incelemeye zaman yetmiyor
  • Kendi iş çıktıları azalırsa bunun tersine aleyhlerine sonuç doğurma riski var

Ortalama düzeyde üretken bir mühendisin gerçeği

• Büyük şirketlerde ortalama düzeyde üretken bir mühendis genelde şu özelliklere sahip
  • İşe alım çıtasını geçecek kadar yetenekli, ancak yeni bir kod tabanına veya dile alışık değil
  • Aynı anda birden çok projenin çakışan teslim tarihlerini yetiştirmeye çalışıyor
• Sonuç olarak, kaliteden çok takvimin belirleyici olduğu bir ortamda elinden gelenin en iyisini yapıyor
  • Örnek: Acemi bir mühendis, yabancı olduğu bir koddaki hatayı geçici bir çözüme bağlar; deneyimli biri de kısaca gözden geçirip yayına alır
  • Yıllar sonra o kod yeniden ortaya çıktığında, “neden böyle bir kod yazılmış?” sorusu doğar

Şirketlerin bu yapıyı sürdürmesinin nedeni

• Büyük şirketler üretkenlikten çok iç görünürlüğe (legibility) önem veriyor
  • Kimin ne yaptığını net görebildikleri ve insanları istedikleri an yeniden konumlandırabildikleri yapıları tercih ediyorlar
• Bu, uzmanlık ve kod kalitesini feda eden bilinçli bir tercih
  • Uzmanlık kaybını göze alıp, sorun çıktığında insan kaynağını hızla yeniden dağıtabilecek esnekliği koruyorlar
• Özellikle AI gibi yeni alanlara hızlı bir pivot yapmanın önemli hâle geldiği bir dönemde bu strateji şirketler lehine işliyor
• Ancak böyle bir ortamda yabancı sistemlerde aceleyle çalışan mühendislerin artması kaçınılmaz

Mühendisin bireysel sınırları ve ‘saf/saf olmayan’ mühendislik

• Tek tek mühendislerin bu yapıyı değiştirecek gücü yok
  • 2025 itibarıyla güç merkezi mühendislerden yönetime kaymış durumda
  • Bireyin yapabileceği en iyi şey, belirli bir alanda bir ‘old-hand’ olup asgari kaliteyi korumak
• Ancak aşırı müdahil olmak, tersine yetersiz performans değerlendirmesi (PIP) alma riskini doğurabiliyor
• Metin, ‘saf (pure)’ ve ‘saf olmayan (impure)’ mühendislik ayrımını ortaya koyuyor
  • Saf mühendislik: bağımsız teknik projeler (ör. programlama dili geliştirme) odaklı
  • Saf olmayan mühendislik: yabancı sistemlerde takvim odaklı çalışılan gerçek dünya ortamı
• Büyük şirket mühendislerinin çoğu saf olmayan mühendislik içinde yer alıyor ve bu durumda kötü kod kaçınılmaz bir yan ürün hâline geliyor
  • Sistem yeterince çalışıyorsa proje başarılı sayılıyor

Sonuç: yapısal neden olarak ‘yabancı kod tabanı’

• Büyük şirketler mühendisleri serbestçe yer değiştirebilme yetkisine sahip ve bu, uzmanlık kaybını kabullenmiş bir şirket tercihi
• Kötü kodun sorumlusu bireyler değil, organizasyon yapısı ve insan kaynağı kullanım biçimi
• Tüm mühendislerin yetkinliğini iki katına çıkarsanız bile, alışık olunmayan kod tabanlarında hata yapma sorunu sürecek
• Temel neden, “mühendislerin büyük bölümünün işlerinin çoğunu alışık olmadıkları kod üzerinde yapmak zorunda olduğu yapı”
• Kötü kod örneklerini göstermek iyileştirmeye yardımcı olabilir; ancak suçlanması gereken mühendisler değil sistemdir

[sonnet]

Deneyimime göre CS, özellikle de PLT temeli sağlam olanlar, sonunda hangi ortamda olursa olsun görece daha iyi kod yazar.

Çok büyük bir bilgi birikimi olmasa bile en temel ilkeleri anlayan biri, zamanı bol ve alışık olduğu bir kod tabanında çalışıyorsa kendine göre belli bir kod kalitesi ortaya koyar. n kez refactoring yaparsanız, kodu yapay zeka yazsa bile sonunda az çok düzgün görünür.

Bir kaynak kodun başında ne kadar uzun süre durursa dursun, 20 yıllık deneyimi olduğunu söyleyip spagetti kod üretmekten başka bir şey yapamayan, neden öyle yapılmaması gerektiğini de bilmeyen çok insan var.

Mükemmel bir ortamda sonsuz zaman ve bütçe verilemeyecekse, bunun pek de büyük anlamı olmayan boş bir söylem gibi geldiğini düşünüyorum. Hangi dönemde, hangi meslekte olursa olsun bu hep aynı değil mi?

Aynı sistem içinde daha iyi kod yazmaksa açıkça mühendisin yeteneğidir.

[sonnet]

Sistemin iyi kalite sunabilmesi için rahat payı olan ve esnek biçimde tasarlanmış olması elbette iyi olur. Ve kuşkusuz, örgüt mühendisliği ile geliştirme metodolojilerinin bugüne kıyasla daha az gelişmiş olduğu dönemlerle karşılaştırıldığında, ortalama olarak durum böyledir.

Ancak benim gözüme, mühendis olarak egosu şişkin ama organizasyonun bir üyesi olarak sorumluluk duygusu yetersiz birinin, bütün bunların kendi suçu değil de yönetimin hatası olduğunu söyleyerek mazeret üretmesi gibi görünüyor.

İnşaat mühendisleri, endüstriyel tasarımcılar ve animatörlerin teslim tarihi yok da, yalnızca yaratıcılık ve kaliteye göre değerlendirilip verimlilik baskısı görmüyorlar mı; teslim tarihi olan tek meslek programcılık mı?

[wahihi]

Ne kadar da saçma sapan şeyler var burada.. kötü kod iyi kod diye konuşmak juniorların gevezeliği; asıl daha önemli olan, o sektöre uygun yazılım tasarımını iyi yapan bir senior var mı, yok mu?

[sonnet]

Burada paylaşılan yazılar, yerel SI pazarında OCP’nin bile göz ardı edildiği bazı bakış açıları ya da deneyimlerden biraz farklı bir ortamı yansıtıyor olabilir.

Her neyse, Linus Torvalds da junior değil...

[GN⁺]

Hacker News görüşü

• Bu kişinin yazılarını birkaç kez okudum ve her seferinde geriye bir tür rahatsızlık hissi kalıyordu.
  Sanırım artık nedenini biliyorum. Yazının analizi kendi içinde mantıklı ama temelinde bir tür nihilizm yatıyor gibi.
  Muhtemelen bir zamanlar idealistti ama kötü deneyimler yüzünden artık “bir şeye inanmanın boşuna olduğunu” açıklamaya çalışan biri.
  Bu yüzden aklıma şu sorular geliyor — büyük şirketler neden böyle davranmak zorunda, kötü kod neden mühendislere bu kadar yük oluyor, o duygu gerçekten yanlış mı, yoksa bunun nedeni içinde yaşadığımız ekonomik yapı mı, ya da devasa güçlere boyun eğmek olgunluk mu?

  • Kötü kod neden bu kadar rahatsız ediyor?
    Çünkü ben onun sonuçlarından sorumluyum.
    Başkasının yazdığı berbat kodu düzeltmeye çalışırken takvim kayıyor ve bunun yüzünden yıl sonu değerlendirmem düşüyor.
    Bana “neden bu kadar uzun sürdü” diye soruyorlar ama bunun nedeni, sorunları bulmak için çöp yığını içinde debelenmek zorunda kalmam.
    Yıllarca bunu yönetime anlatmaya çalıştım ama sonunda bu iş Sisifos’un emeği gibi hissettirdi.
  • Mühendislerin kötü koddan nefret etmesinin nedeni zanaatkârlık ruhu.
    Bir mimarın özensiz bir bina gördüğünde sıkılması, bir yönetmenin kötü yapılmış bir film karşısında rahatsız olması gibi, iyi mühendis de işi olabildiğince düzgün yapmaya çalışır.
    Bence olgunluk güçsüzlüğe boyun eğmek değil, mümkün olduğunca mücadele etmektir.
    İlginç olan şu ki, yazarı nihilist diye nitelendiriyoruz ama “dünya kontrol edilemez” düşüncesinin kendisi zaten nihilist bir bakış.
  • Mühendislerle iş tarafı ‘kötü kod’ ölçütünü farklı tanımlıyor.
    Eskiden ben de mükemmel olmayan her şeyi kötü kod sayardım ama farklı şirketlerde çalıştıkça bakış açım değişti.
    Artık iş hedeflerini karşılıyor ve asgari kalite eşiğini geçiyorsa yeterli görüyorum.
    Sonuçta çoğu kodun zaten geliştirilebilecek bir yanı vardır.
  • Bu blogu ilk gördüğümde “demek ki bunu yaşayan sadece ben değilmişim” diye rahatlamıştım.
    Staff+ mühendisliğinin sert gerçeğini olduğu gibi anlattığı için bağ kurdum.
    “Şirketin istediğini yap, doğru olmasa bile” iddiası alaycı gelebilir ama şirketin dişlileri arasında öğütülmekten iyidir diye düşünüyorum.
  • Bence yazarı fazla yorumluyorsunuz.
    O sadece sizin ideallerinize inanmıyor; bu onu otomatik olarak nihilist yapmaz.

• Sorunun kıdem süresi değil, motivasyon meselesi olduğunu düşünüyorum.
  Office Space filmindeki replik gibi, “çok çalışsan da ödül yoksa motivasyon da olmaz” gerçeğini hatırlatıyor.

  • Büyük şirketlerdeki mühendisler aslında çok motive (ben Google’da mühendisim).
    Ama yönetim iyi koddan çok sonucu önemsiyor.
    Bakım işinin değerini ölçemedikleri için o emek takdir edilmiyor.
    Sonunda terfi eden kişi, dağınık kodu üretime çıkaran kişi oluyor.
  • Sadece motivasyon yetmez.
    Ben ekibimi ve kodumu önemseyip titizlikle çalıştım ama sonunda PR sayısı gibi basit metriklerle değerlendirildim.
    Kodun zorluğu ya da ekibe katkı göz ardı edildi; önemli olan yalnızca “göze görünen sayılar”dı.
    Üstelik beni değerlendiren yönetici de birkaç ay sonra işten çıkarıldı.
    İronik biçimde, umursamaz olsaydım bunlardan bu kadar yara almazdım.

• Büyük şirketler mühendisleri yerine konabilir kaynaklar gibi görüyor.
  Bu sadece verimlilik meselesi değil, güç dengesini yönetim lehine çevirmeye yönelik bir strateji.
  Amaç, kritik projelerin belirli bir mühendis grubuna bağımlı kalmaması.

  • Sermaye, bir miktar verimlilikten vazgeçmesi gerekse bile emeğin gücünü zayıflatmak ister.
    Her çalışanın değiştirilebilir olmasını ister.
  • Ama pratikte şirketlerin deneyimli mühendisleri bilerek başka takımlara kaydırması nadirdir.
    Hatta çoğu zaman iyi mühendisleri elde tutmak için uğraşırlar.
  • Aslında mühendisler de kendi aralarında “şu kodu sadece Bob biliyor” durumundan şikâyet eder.
    Yani bu kültür yalnızca yönetimin sorunu değil.

• Kodun sözdizimi ve yapısı ders kitabı gibi olabilir ama temel yaklaşım yanlışsa bunu sık sık görürsünüz.
  Kod incelemeleri yalnızca sözdizimine odaklanıyor; iş problemi ya da karmaşıklık neredeyse hiç konuşulmuyor.
  Kısa vadede idare ediyor ama uzun vadede teknik borç patlıyor.

  • Kesinlikle katılıyorum. Veritabanı şeması gibi şeyler ilk sprintte donup kalıyor ve sonrasında asla refactor edilmiyor.
    Sonuç olarak, önemsiz kod kalitesi tartışmaları yüzünden PR’lar günlerce bekliyor.
  • Büyük şirketlerde de aynı şeyi görüyorum.
    Herkes yalnızca yüzeysel kod temizliğine takılmış durumda.
    Mantıksal doğruluğu ya da büyük resmi görmek zor; çoğu zaman reviewer da bağlamı bilmiyor.
  • İyi gereksinim toplama, dokümantasyon ve ürün tasarımı yoksa uzun ömürlü bir tasarım kurmak zordur.
    Organizasyonun bütünü bu tür geri bildirimi kaldıracak durumda değilse, sonunda ‘idare eden sistemlere’ bel bağlanır.
  • Kod incelemesinde mimari sorunlar yakalıyorsanız, aslında süreç aşamasında başarısız olmuşsunuzdur.
    Büyük tasarım kararları kod incelemesinden önce gözden geçirilmelidir.
  • Bu desen yapay zeka ile üretilmiş kodda da sık görülüyor.
    Bir bakıma uzun vadeli maliyeti otomatikleştiriyoruz.

• Büyük şirketler kodun kendisiyle ilgilenmez.
  Kod yalnızca şirketi çalıştıran bir araçtır.
  Sonuçta asıl önemli olan kod değil, süreçtir.
  Sistem bozulduğunda onu geri getirecek prosedürlerin olup olmadığı belirleyicidir.

• Her sektör ölçek büyüdükçe benzer ödünler verir.
  Kusursuzluk değil, ‘yeterince iyi’ kalite kâr yaratır.
  IKEA sandalyesi ile Herman Miller sandalyesi arasındaki fark gibi; mesele yalnızca farklı kısıtlar olmasıdır.
  Gerçek beceri, nerede taviz vereceğini bilmektir.
  Büyük şirket yapısı da bu tavizleri mühendislere dayatır.

• İyi bir kıdemli mühendis en baştan kötü kod yazmaz.
  Sorun kısa vadeli çıktı baskısı ve temel eksikliği.
  Review’ı atlamak ya da mimariyi yeterince düşünmemek asıl neden.

  • Ama gerçek hayatta durum o kadar dağılmış olabilir ki iyi kod yazmak fiilen mümkün olmaz.
    Şu yorumda anlatıldığı gibi, milyonlarca satırlık hack birikmiş bir kod tabanında ne kadar uğraşsanız da temiz bir yapı kuramazsınız.
    Sonunda olan şey bütün spagettiyi birden kaldırmaya çalışmak olur.
  • Sonuçta ikisi de doğru.
    Kıdemli mühendisler her zaman ‘doğru yapmak’ ile ‘hızlı bitirmek’ arasında ikilemde kalır.
  • İyi kod bağlama bağlıdır.
    Karmaşık bir kod tabanını bir gecede anlayamazsınız ve organizasyon bilgi birikimini önemsemiyorsa kalite kötüleşir.
    Yeni çalışanlara dokümantasyon ya da düzenleme işleri verip kodun yapısını öğrenmelerini sağlamak iyi olabilir.
  • Bir başka neden de geriye dönük uyumluluk zorunluluğu.
    Ne kadar çok eski hack varsa olsun, sistemi kıramayacağınız için onlara dokunamazsınız.
  • Yazdığım en kötü kodların nedeni sürekli değişen gereksinimlerdi.
    Tasarım ne kadar iyi olursa olsun, temel kumdan yapılmışsa sonunda çöker.

• Yazarın söylediği gibi ‘okunabilirlik kalitenin önüne geçiyorsa’, o zaman bütün büyük şirket projelerinde statik analiz araçları ve otomatik formatter’lar zorunlu olmalı.
  Ama pratikte durum böyle değil.
  Bu araçların benimsenmesi teknik olmayan yöneticilerin kararı oluyor ve onlar kısa vadeli maliyetten hoşlanmıyor.
  Sonunda yayın takvimi her şeyin önüne geçiyor.

  • “İkinci monitöre gerek yok” diyen yönetici tipi bu kültürün simgesi gibi.

• Bir üretim devinde danışmanlık yaparken, kodun her yerine yayılmış garip nesne modelleme kalıpları görmüştüm.
  Sebebini araştırınca, tasarımcının kastettiği kavramların (plan–kalıp–ürün) geliştirme ekibi tarafından tamamen yanlış anlaşıldığını gördük.
  Bunu düzeltmeyi önerdik ama aldığımız yanıt “artık çok geç” oldu.
  Sonuç olarak, yanlış model 10 yıldan uzun süre korunup devasa bir teknik borç üretti.

  • Hatta “umarım bu ürün yine de kimseyi öldürmez” diye şaka yapılıyordu.

• Büyük şirketlerdeki kısa ortalama çalışma süresi istatistiği yanıltıcı olabilir.
  Bunun nedeni sadece çalışan sayısındaki hızlı artış yüzünden medyanın kısa görünmesidir.
  Gerçek tabloyu görmek için aslında ayrılan çalışanlar üzerinden bakmak gerekir.

  • Aynı nedenle, kıdemli geliştirici oranı da olduğundan düşük görünür.
    Çünkü geçmişte geliştirici sayısı basitçe daha azdı.