- 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
Henüz yorum yok.