- Yazılım mühendisliği kültüründe karmaşık sistemler kuran kişiler daha çok takdir görüyor; basit çözümü seçenler ise çoğu zaman hak ettiği değeri görmüyor
- Terfi değerlendirmeleri, mülakatlar ve tasarım incelemelerinde karmaşıklık sık sık “etki” ile karıştırılıyor; bu da gereksiz soyutlamalar ve ölçeklenebilirlik katmanları ekleme eğilimini güçlendiriyor
- Basit uygulamalar “görünmez başarı” olarak kalırken, karmaşık yapılar gösterişli anlatılar ve dokümantasyonla terfi dosyalarını doldurmayı kolaylaştırıyor
- Gerçek ustalık daha fazla araç kullanmakta değil, karmaşıklığı ne zaman dışarıda bırakmak gerektiğini bilme muhakemeti ve özgüveninde yatıyor
- Hem mühendisler hem de liderler sadeliği görünür kılmalı ve bunu resmen tanıyan değerlendirme/ödüllendirme sistemleri kurmalı
Sadelik vs karmaşıklık: terfi anlatısındaki asimetri
- Aynı ekipteki iki mühendisin örneği: Engineer A, 50 satırlık sade bir kodla birkaç günde özelliği yayına alıyor; Engineer B ise yeni bir soyutlama katmanı, pub/sub sistemi ve yapılandırma çerçevesi ekleyerek işi 3 haftada tamamlıyor
- Engineer B’nin işi terfi paketinde “ölçeklenebilir olay tabanlı mimari tasarımı, yeniden kullanılabilir soyutlama katmanı eklenmesi, yapılandırma çerçevesi kurulması” olarak anlatılabiliyor
- Engineer A’nin işi ise sadece “özellik X’in uygulanması” diye üç kelimeyle ifade ediliyor
- Oysa gerçekte daha iyi iş buydu; ama basit görünecek şekilde yapıldığı için görünmez katkı haline geldi
- “Kaçınılan karmaşıklık” ile kimse terfi almıyor — karmaşıklığın akıllıca görünmesinin nedeni, değerlendirme sisteminin onu ödüllendirecek şekilde kurulmuş olması
Mülakatlarda ve tasarım incelemelerinde karmaşıklığı güçlendiren yapı
- Sistem tasarımı mülakatlarında basit bir çözüm (tek veritabanı, sezgisel API, cache katmanı) önerdiğinizde mülakatçı “Peki ya on milyon kullanıcı gelirse?” diye yükleniyor
- Servisler, kuyruklar ve sharding eklendikçe mülakatçının daha memnun olduğunu görüyorsunuz
- Adayın çıkardığı ders: “Basit cevap yeterli değildi”
- Mülakatçının bunu yapmasının makul nedenleri olabilir (baskı altında düşünme yetisini, dağıtık sistem bilgisini ölçmek gibi), ama adaya geçen mesaj şudur: “Karmaşıklık etkileyicidir”
- Tasarım incelemelerinde de “future-proof olmamız gerekmiyor mu?” sorusu, gereksiz katmanlar ve soyutlamalar eklemeye yol açan aynı kalıbı tekrar tekrar üretiyor
- Sorun bunu gerektirdiği için değil, toplantı odası bunu beklediği için ekleniyor
- Birkaç satırlık kod tekrarını önlemek için kurulan bir soyutlama, çoğu zaman anlamayı ve bakımı daha zor hale getiriyor
- Kod daha “profesyonel” görünse de kullanıcı özelliğe daha hızlı kavuşmuyor; sonraki mühendis de değişiklik yapmadan önce yarım gününü soyutlamayı anlamaya harcıyor
Uygun karmaşıklık vs gereksiz karmaşıklık (Unearned Complexity)
- Sorun karmaşıklığın kendisi değil — milyonlarca işlemi işlemek için dağıtık sistemler gerekir; 10 ekip aynı ürünü geliştiriyorsa servis sınırları gerekir
- Sorun gereksiz karmaşıklık: “Veritabanı sınırına ulaştık, o yüzden sharding gerekiyor” ile “3 yıl sonra sınıra ulaşabiliriz, o yüzden şimdi sharding yapalım” arasındaki fark
- Bunu anlayan mühendisin kodu ve mimarisi “tabii ki böyle” hissi verir; ne sihirli görünür ne aşırı zeki, ne de anlamadığınız için sizi aptal hissettirir
- Senior seviyeye giden gerçek yol, daha fazla araç ve desen öğrenmek değil; onları ne zaman kullanmamanız gerektiğini bilmektir — karmaşıklık eklemek herkesin yapabileceği bir şeydir, ama onu çıkarmak deneyim ve özgüven ister
Mühendisler için uygulanabilir adımlar
- Sadeliği görünür kılmanız gerekir — çünkü yapılan iş kendi adına konuşmaz ve değerlendirme sistemi de bunu duyacak şekilde tasarlanmamıştır
- “Özellik X’i uyguladım” demek yerine, “Olay tabanlı mimari ve özel soyutlama katmanını da içeren üç yaklaşımı değerlendirdikten sonra, basit uygulamanın hem mevcut hem öngörülen gereksinimleri karşıladığına karar verdim; 2 günde yayına aldım ve 6 ay boyunca sorunsuz çalıştı” diye anlatın
- Bir şeyi yapmamaya karar vermek de bir karardır ve önemli bir karardır — buna uygun şekilde dokümante edilmelidir
- Tasarım incelemesinde “future-proof olmamız gerekmiyor mu?” sorusuna sadece boyun eğmeyin; “Bunu sonra eklemek şu kadar sürer, şimdi eklemenin maliyeti şu kadar olur, beklemek daha iyi” diye ortaya koyun
- Bu bir karşı çıkış değil, konuyu değerlendirdiğinizi gösterme biçimidir
- Yöneticinizle doğrudan konuşup “İşimi dokümante etme biçiminin sadece kodu değil, aldığım kararları da yansıtmasını istiyorum” deyin — böylece yöneticiye de sizi savunabileceği bir dil vermiş olursunuz
- Tüm bunlara rağmen yalnızca en karmaşık sistemi kuranları terfi ettiren bir ekipteyseniz, bu da faydalı bir bilgidir — bazı organizasyonlar sadeliğe gerçekten değer verir, bazıları ise bunu sadece söyleyip tersini ödüllendirir
Mühendislik liderleri için uygulanabilir adımlar
- Teşvikleri belirlemek liderlerin sorumluluğudur — çoğu terfi kriteri karmaşıklığı ödüllendirecek şekilde tasarlanmıştır ve “etki” genellikle inşa edilen şeyin ölçeği ve kapsamıyla ölçülür
- Sadece yapılanı değil, kaçınılanı da değerlendirmeye katmak gerekir
- Tasarım incelemelerinde “Ölçeklenebilirliği düşündünüz mü?” demek yerine, “Yayına alınabilecek en basit sürüm nedir ve daha karmaşık bir şeye ihtiyaç olduğunu gösterecek somut sinyaller nelerdir?” diye sorun
- Bu tek soru oyunu değiştirir: varsayılanı sadelik yapar, karmaşıklığa ise ispat yükü bindirir
- Terfi görüşmelerinde etkileyici sistemlerin listesiyle dolu paketlere karşı “Bunların hepsi gerçekten gerekli miydi? pub/sub sistemi gerçekten gerekli miydi, yoksa sadece dosyada iyi görünsün diye mi vardı?” diye sormak gerekir
- Ekip üyesi temiz ve basit bir çözümü yayına aldığında, onun anlatısını kurmasına yardım etmelisiniz — “farklı yaklaşımları değerlendirip sorunu çözen en basit olanı seçti” ifadesinin ikna edici bir terfi örneği olabilmesi için liderin buna gerçekten öyle davranması gerekir
- Ekip kanalında alenen kimi kutladığınıza dikkat edin — sadece büyük ve karmaşık projeleri överseniz insanlar da buna göre optimize olur
- Kod silen mühendisi, “henüz gerek yok” deyip haklı çıkan mühendisi de takdir etmelisiniz
10 yorum
özgeçmiş odaklı tasarım...
Bu yazıda yer alan önerilerin anlamsız olduğunu düşünmüyorum, ama "büyük tasarım"ı yenmek için fazla güçsüz kaldıklarını düşünüyorum. Çünkü onu açıklamak aşırı derecede kolay :(
Hacker News görüşleri
Bir mülakat sorusunda iki kişinin bir elektronik tabloyu e-postayla birbirine gönderdiği bir senaryo verilmişti
Ben Google Sheets'e taşırım diye cevap verdim, ama mülakatçının sanırım benim doğrudan bir araç tasarlamamı istediği anlaşılıyordu
O zaman da garip gelmişti, şimdi bile bundan hangi dersi çıkarmam gerektiğini tam bilmiyorum
İyi bir cevabı kabul edip ardından “bu, teknik tasarım değerlendirmesi için kurgusal bir durum; şimdi yeni bir sistem tasarlayalım” diye yönlendirmeleri gerekirdi
Aday bu varsayımı kabul etmezse, bu da ayrıca bir sinyal olarak değerlendirilebilir
Ben olsam “Mevcut çözüm olmadığını varsayıp sıfırdan mı tasarlayalım?” diye sorardım
Bu, mülakatçının yalnızca duymak istediği cevabı beklediği algoritma tartışmasının sistem tasarımı versiyonu gibi
Aslında doğru karar buydu, ama Patrick Collison bizzat arayıp “Mülakatı geçemedin ama neyin amaçlandığını anlıyor musun?” diye sormuş
Sonunda tekrar mülakata girip geçmişti
Bu, mülakatın amacını anlamanın önemli olduğunu gösteren bir anekdottu
Büyük bir feribot şirketi gemi konumlarını ve personel atamalarını Google Sheets ile yönetiyormuş; arkadaşım “bu, büyük bir şirketin yapacağı iş değil” dedi
Ama ben, halihazırda doğrulanmış araçlarla sorunu çözmüş olmalarını harika buldum
Bu sayede şirket içi geliştirme ekibi ya da pahalı dış kaynak olmadan da operasyon mümkün
Bu, kibirimi derine gömmeme neden olan bir deneyimdi
Karşı tarafın tam olarak hangi noktanın uymadığını açıklamasını sağladıktan sonra teknik tasarıma geçmek gerekir
Sheets kullanamamanın çeşitli nedenleri olabilir — özellik kısıtları, Çin içinden erişim kısıtlaması, şirket politikası, ağ sorunları vb.
Müşteri zaten bu nedenlerden dolayı özel bir çözüm istiyor olabilir
Yani geliştiricinin görevi sadece “Google Sheets kullanın” demek değil, müşterinin bağlamını anlamaktır
Yapay zeka kodlama araçları sorunu daha da incelikli biçimde kötüleştiriyor
Artık karmaşık mimarileri 5 dakikada üretebiliyorsunuz, ama bakım maliyeti aynı kalıyor
Sonuç olarak daha gösterişli yapılar hızla ortaya çıkıyor ve terfi için yazılan dokümanlar da çabucak tamamlanıyor
Ama gerçekte kimse o kodu tam olarak anlamıyor
Gerçek sadelik ölçütü “sonraki kişinin bunu soru sormadan anlayabilmesi” iken, yapay zeka üretimi kod bu sınavı tam olarak geçemiyor
Şimdi bu sadece daha da kötüleşecek
Bu yüzden kariyer tercihlerimde kurumun kodu anlama kültürünün ne kadar güçlü olduğuna bakıyorum
Kimsenin sistemi bilmediği bir durumu bir daha yaşamak istemiyorum
Amaç problem çözmekse, ister yapay zekayla yapılmış araç olsun ister satın alınmış bir araç, sonuçta sorunu çözmesi gerekir
Ancak hazır ürünler uymuyorsa, eninde sonunda doğrudan üretilmiş özel çözümler artacaktır
Fakat kimse onları anlamazsa, sıradaki kişi yeniden yapacaktır
Yine de kullanıcıyla üreticinin birbirine yaklaşması açısından bu bir iyileşme olabilir
Örneğin
AGENTS.mdiçinde “KISS”, “YAGNI” gibi yönergeleri açıkça yazmak faydalı olurSorun şu ki “sonraki kişi” sonunda 6 ay sonraki kendim oluyor
Yapay zeka da context window sınırları nedeniyle aynı problemi yaşıyor
Pek çok geliştirici sadece popüler stack'lerin peşinden gidiyor ve operasyon kolaylığını hesaba katmıyor
Yapay zeka da “bu aşırı tasarım” demez
Kubernetes ve ElasticSearch istiyorsanız, aynen kurar geçer
Hem FAANG hem de startup deneyimi yaşamış biri olarak, karmaşıklık ile sadelik arasındaki dengenin kilit olduğunu düşünüyorum
Büyük şirketlerde geçici bir hack binlerce kişinin üretkenliğine zarar verebilir,
startup'larda ise aşırı altyapı şirketi batırabilir
Gerçekten usta mühendis, bu iki durumu ayırt edebilen ve deneyimiyle uygun trade-off'u seçebilen kişidir
Amazon'da çalıştığım dönemde (2005~2008), şirket kültürünün simgesi olan iki ödül vardı
“Just Do It” ödülü inisiyatif alarak problem çözmeyi, “Door Desk” ödülü ise tasarruf ve sadeliği simgeliyordu
Hatta işe yaramayan bir televizyonu ortadan kaldıran bir çalışanın ödül aldığı ve ödül olarak o televizyonun verildiği bir anekdot vardır
Metafor olarak sadelik, pratikte biraz muğlaktı
Sadelik savunulacaksa bunu iş dünyasının diliyle ifade etmek gerekir
“Olaylar %80 azaldı”, “maliyet %40 düştü”, “performans %33 arttı” gibi
Sadelik tek başına ödüllendirilmez ama onun sonuçları çok takdir edilir
Ben refactoring'i bir maliyet modeline çevirip KPI'ları ölçtüm ve MTTR'ı %60 azalttım
Takdir görmek için bu tür sayıları doğrudan göstermek gerekiyor
Yönetici olarak ben basit kodu tercih ederdim
Ama bunun nedeni ekibin deneyimli kişilerden oluşmasıydı
Daha az deneyimli ekiplerde The Parable of The Toaster gibi şeyler yaşanır
Yaş aldıkça karmaşıklığa direnç göstermeye başlıyorsunuz
Ama liderlik bunu çoğu zaman “anlamadığı için karşı çıkıyor” diye yanlış yorumluyor
En uzun ömürlü projeler, basit ve değiştirilmesi kolay olanlardı
Yapay zeka araçları bu yaklaşımı daha da kolaylaştırıyor — bileşenleri bağımsız örnek projelerde deneyip, doğrulanmış kodu asıl projeye entegre ediyorsunuz
İç ağ ortamında olduğumuz için yapay zekayı doğrudan bağlamıyoruz, ama bu yöntem çok faydalı
Bu yüzden ben “karmaşık olanı da yapabiliriz ama önce basit sürümle başlayalım” diye öneriyorum
Çoğu zaman o basit sürüm sonunda yıllarca çalışan production kodu oluyor
Basit bir çözümü hızla ortaya koyan geliştirici, kalan zamanda birkaç özellik daha geliştirebilir
Buna karşılık karmaşık çözüme takılan biri tek bir özelliğe haftalarını harcar
Sonuçta üretkenlik metriklerinde basit yaklaşım daha cazip görünür
Ben de kariyerimi “büyük fikirler”den çok istikrarlı biçimde sonuç üreten biri olarak kurdum
Şirketimizdeki mülakatlardan biri kamu kütüphanesi sistemi tasarımı sorusu
Önce küçük bir kasaba kütüphanesi ölçeğinde başlıyor, sonra ülke geneline genişleyen bir senaryoya dönüşüyor
En iyi cevap “en büyük ölçekte bile orta seviye bir sunucu ve Postgres yeterli olur” şeklindeydi
Gerçekte 10 ile 10.000 arasında büyük fark olmayabilir ama deneyimsiz mülakatçılar çoğu zaman sadece prompt'u okuyor
Sonrasında aşırı altyapı ve özgeçmiş odaklı geliştirme sorunu büyüttü
Bence yapay zeka nihayetinde kullanıcının yetkinliğini büyüten bir araç
Yetkin geliştirici için üretkenliği artırır, ama deneyimsiz biri için karmaşayı hızla çoğaltan bir araç olur
Aksine gereksiz wrapper fonksiyonları ve tip dönüşümleri ekleme eğiliminde
Yapay zeka bana daha çok “koda bir şeyler ekleyen taraf” gibi geliyor
Yine de derinliği olmayan “vibe coding”in artması endişe verici
Benim karşılaştığım mülakatçılar da karmaşıklığı tercih ediyordu.
Sadeliğin olumlu değerlendirilmesini beklediğim bile yok. Gerçek şu ki, ortalığı karmaşıklaştırıp sonra çıkardığı sorunu toparladığı için terfi alanlar bile var.
Hizmet için tasarım değil, yetenekleri abartmak için yapılan aşırı mühendislik her yerde.
Değerlendiren kişinin konuya hakim olması gerektiğini düşünüyorum.
Açıklamaları da yeterince dinlemesi gerektiği de doğru.
Bunu değerlendirebilecek biri yukarıdaysa her şey yolunda, ama en başta bu olmadığı için, böyle şeyler hak ettiği şekilde değerlendirilemiyor ve bu yüzden de böyle insanlar yukarı çıkamıyor...
Bu bir kısır döngü...
Şirket açısından bakınca, dengeli bir mühendis olarak başarılı olup yukarı çıkmak, iyi mühendislik/engineering principle'ların da korunabilmesi için gerekli gibi görünüyor.
Çoğu gerçeklik, işi basitçe işlev uygulama düzeyinde yapabilenlerle ölçeklenebilir şekilde tasarlayıp trade-off'ları da iyi yönetebilenler arasındaki fark değil mi?
Karmaşık şekilde çalışmış olsanız bile buna sonuçta özellik X’in uygulanması denebilir.
Buradaki fark, bunu değerlendiren kişiye hangi şekilde ifade ettiğinizde yatıyor.