Kullanıcı Umursamaz — Ama Siz Umursamalısınız

• Kullanıcılar, kodun kendi içsel özelliklerinden çok ürünün çalışmasına önem verir; ancak kötü kodun performans, hatalar ve geliştirme hızı üzerinde doğrudan ikincil etkileri vardır
• “Kullanıcılar teknoloji yığınını ya da testleri umursamaz” sözü yüzeyde doğru olsa da, kod kalitesi düştükçe hata düzeltmek ve özellik eklemek daha zor ve daha yavaş hale gelir
• Köprü denetimi, sarhoş pilot ve dengesiz bina temeli benzetmelerinde olduğu gibi, kullanıcı sürecin kendisini görmese bile sonuç güvenlik ve güvenilirliği etkiler
• AirBnB, OpenAI ve Meta gibi şirketler pazar hakimiyeti, devasa VC desteği ve şüpheli yasallık sayesinde bu sorunları zorlayarak geçebilir; ancak her şirket böyle bir konumda değildir
• Yazılım başarısı; satış, teknoloji yığını, kullanıcı deneyimi ve benzersiz tanımlayıcılar dahil birçok farklı ilgi alanı ve bakış açısının birlikte işlemesinin sonucudur

---

Tekrarlanan klişeler ve sınırları

• Yazılım sektöründe şu tür sözler durmadan tekrarlanır: “Müşteri testleri umursamaz, sadece ürünün çalışmasını umursar”, “Kullanıcılar teknoloji yığınını umursamaz”, “Mühendislik zarafeti pazar değeriyle aynı şey değildir”, “Kullanıcılar bunu yapay zekanın mı insanın mı yazdığını ya da hangi framework'ün kullanıldığını umursamaz, sadece ürünün çalışmasını umursar”
• Bu sözlerin hepsi aynı temanın varyasyonlarıdır: “Müşteri bunu umursamaz”; yapı olarak da ayık gerçekçiliği anlatan bir pragmatizm gibi sunulurlar
• Aynı mantık başka alanlara uygulandığında sorunun yüzeyselliği ortaya çıkar
  • Yol kullanıcıları köprünün son denetimini umursamaz, sadece arabayı taşımasını umursar denmesi gibi
  • Yolcular pilotun içkili olup olmadığını umursamaz, sadece uçağın zamanında varmasını umursar denmesi gibi
  • Ofis çalışanları yüksek binanın temelinin sağlamlığını umursamaz, sadece para kazanmayı umursar denmesi gibi
• Bu benzetmeler yüzeyde doğru görünse de, açık ikincil etkileri göz ardı eder
• Müşterinin bilgisayar kodunun içsel nitelikleriyle ilgilenmemesi doğrudur; ancak kod kalitesi performansı, hata olup olmadığını, hata düzeltme süresini ve yeni özellik ekleme süresini etkiler
• Kod ne kadar kötüyse bu sorunları çözmek o kadar zor ve yavaş olur
• AirBnB, OpenAI ve Meta gibi şirketlerin muazzam pazar hakimiyeti, devasa VC desteği ve şüpheli yasallık sayesinde bu kaygıları zorlayarak geçebildiği belirtiliyor
• Sonuç olarak, böyle şirketlerden biri değilseniz aynı şekilde sorunların üstünü örtmek zordur

‘Halk bilgeliği’nin kalıcılığı ve yazılımın çoklu ilgi alanları

• Halk bilgeliğinin kalıcılığı

  • Yalnızca birincil etkilerin önemli olduğu fikri, yazılım dünyasında son derece popüler bir halk inancı olarak varlığını sürdürür
  • İnsanlar iyi yapamadıkları şeyleri küçümseme ya da değersizleştirme eğilimindedir
  • İyi kod üretme becerisinin kendilerinde eksik olduğunu fark ettiklerinde, yalnızca iyi kodun önemsiz olduğunu değil, iyi kod yazabilen insanların bizzat sorun olduğunu düşünmeye daha yatkın olurlar
  • Böyle bir bakış açısında, müşterinin umursamadığı şeyler yüzünden yayını engelleyen kişiler sorunluymuş gibi görülür
  • Bu tutum, kişinin kendi zayıflıklarından kaçınmasına ve sorumluluğu başkalarına dışsallaştırmasına yarayan bir ego savunma mekanizması olarak işler

• Biz toplumun içindeyiz

  • Ciddi yazılım çalışması, farklı ilgi alanları ve farklı bakış açılarının bir karışımıdır
  • Teknik satıştan teknoloji yığınına, kullanıcı deneyiminden benzersiz tanımlayıcılara kadar birçok unsur yazılım çabasının parçasıdır
  • Bütün bu unsurlar başarıya ya da başarısızlığa katkıda bulunur

[GN⁺]

Lobste.rs görüşleri

• Bu tür cümleler hem iletiliş biçimi hem de okunuş biçimi açısından iyi de kötü de olabilir
  Örneğin “Müşteri testlerle hiç ilgilenmez. Ürünün çalışıp çalışmadığıyla ilgilenir” sözü, “bug’lı şeyi yayına alın” değil, belirli bir test ideolojisinden çok ürünün gerçekten çalışmasına odaklanın anlamında okunabilir
  Testler, kodu çalışır hale getirmenin araçlarından yalnızca biridir; bu yüzden test kapsamı yüksek olup hepsi geçse bile ürün çalışmıyorsa bu başarısızlıktır, testler dışında başka yollarla ürünü iyi çalıştırabiliyorsanız bu da kabul edilebilir, biçimsel dogmaları izlemeden bug’ları iyi yakalayabiliyorsanız bu da sorun değildir şeklinde yorumlanabilir
  Ayrıca kullanıcı ve işletme açısından bakıldığında, “ürün/özelliğin hiç var olmaması” da bir bug olabilir; bu yüzden mevcut bug’ları düzeltmekle yeni özellik çıkarmak her zaman tertemiz biçimde ayrılmaz
  Yine de pratikte bu tür sözlerin gerçekten “köşe dön ve çöp çıkar” anlamında kullanıldığına da tanık oldum

  • “Kullanıcı ve işletme açısından ürün/özelliğin hiç var olmaması da bir bug’dır” noktasına dair, yazar olarak açıkça ele alamadığım bir taraf var
    Berbat programlamanın aylar ölçeğinde bile “pratik” olduğu fikrini tamamen reddediyorum
    Tasarımı kötü ve testleri yetersiz bir kod tabanında yeni özellik geliştirmek yavaş ve pahalıdır
  • “Birim testi ne kadar çoksa o kadar iyi” diye düşünen ya da darboğaz bile olmayan kodu günlerce optimize eden çok sayıda mühendis var; böyle durumlarda yukarıdaki yorumlar oldukça yerinde
    Geliştiriciler zamanlarını değerin oluştuğu yere harcayıp harcamadıklarının farkında olmalı; yönetimin de neden böyle işlerin yapıldığını anlaması ideal olur
    Anlayış eksikliği ile yanlış teşvik yapısı birleşince sonuçta yine “köşe dön ve çöp çıkar” noktasına varılıyor

• Dürüst olmak gerekirse, böyle konuşan insanlar çoğu zaman kullanıcıyı da pek umursamayan kişiler gibi görünüyor
  Kullanıcının çalışan bir ürün almasını istiyorsanız, geliştirme sürecinin içinde bunun olasılığını artıran mekanizmalar bulunmalı; bunu zaten birkaç gün önceki yorumumda da söylemiştim
  Bu yaklaşım, kullanıcının ürün hakkında düzgün geri bildirim verecek bir yolu da olmadığı ve gerçek kullanım metriklerinin de bulunmadığı ortamlarda sık görülüyor
  Kullanıcının hemen görmediği ya da umursamadığı halde yine de etkilendiği çok sayıda başarısızlık senaryosu var
  En tipik örnek güvenliktir; verileri internetteki sızıntı listelerine düşene kadar kullanıcı “güvensiz olma” durumunu önemsemeyebilir, performans da çok daha iyi olabileceğini öğrenene kadar sorun gibi hissedilmeyebilir

  • Bu tür konuları genel bir kitleye anlatmak zor
    Herhangi bir iyileştirme sürecinde tek bir unsuru seçip onu optimize ederek iyi sonuca ulaşmak zordur, ama tartışmada ilerleme kaydetmek için çoğu zaman bunu yapmak zorunda kalırsınız
    Bu yüzden geri bildirim hattını gerçekten gözle görülen sorunun nerede olduğuna göre ayarlayarak tartışmayı düzeltmek faydalı olur
    Bu tür yazıları, yazılım projelerinin başarısını etkileyen ama birbiriyle dışlayıcıymış gibi görünen unsurları akla getirme girişimi olarak görüyorum
    Yalnızca teknik sezgisi olan insanların bildiği şeyleri söze döküp savunmanın değeri var; ancak birçok teknik kişinin görünmeyen işleri dengeleme ya da bunları etkili biçimde savunma konusunda zorlandığını düşünüyorum, ben de bu konuda hâlâ pratik yapıyorum

• İç tarafı önemsemek önemlidir ve bunun kullanıcıya da gerçekten faydası olur

• Bu bakış açısı hoşuma gidiyor
  Karşı uç olan aşırı mühendislik tarafına gitmek istemem ama “hızlı ilerle ve bir şeyleri boz” zihniyetinden de uzaklaşsak iyi olur
  Deneyimime göre bu, web geliştirme dünyasında neredeyse bir salgın gibi
  LLM’lerin mümkün kıldığı düşük kaliteli yazılım akışının, umarım kullanıcıların güvenilir yazılımı ödüllendirmesine yol açmasını isterim
  Giderek bir grug brain geliştiriciye dönüşüyorum; bunun ne kadar yaygın bir his olduğunu bilmiyorum ama “hadi bir özellik daha ekleyelim” meselesinden yoruldum
  Biz sık sık yazılım maliyetini yalnızca yayın tarihi ile ölçme hatasına düşüyoruz ve yaşam döngüsü boyunca oluşacak bakım maliyetlerini neredeyse hiç hesaba katmıyoruz
  “Zor değil, bir haftadan kısa sürer!” denirken, her yıl bakım, düzeltme, genişletme, güncelleme, entegrasyon ve dokümantasyon için harcanacak 2 ila 4 haftadan söz edilmiyor

• Ben de buna benzer bir şeyi sık söylerim
  “Son kullanıcı, yazılımın %100 test kapsamına sahip olup olmadığını ya da lbl0 gibi etiketler taşıyan dokümantasyonsuz assembly ile %100 yazılıp yazılmadığını umursamaz. Doğruluk, performans ve kullanıcı deneyimini önemser”
  Ama yazılım mühendisliği tam da bu hedeflere daha kolay ulaşmayı ve kaliteyi iyi bir seviyede tutmayı sağlar
  Sorun şu ki bu yol da cargo cult’a ve aşırı mühendisliğe kayabilir; benim de bunda kesinlikle payım var
  Yine de sonunda kullanıcıya gerçek değer sunmanız gerekir

• Boeing ve Airbus örneğinde olduğu gibi, kanıtlanabilir biçimde en iyi sonuçlar vardır
  İki şirketin uçaklarının neden bu kadar benzer göründüğü, kimin önce tasarladığı ya da kimin kimden çaldığı asıl mesele değil
  Kimse kimseden çalmadı; farklı takımlardaki dünyanın en iyi mühendisleri aynı kısıtlar altında tasarım yaptığında, bundan sapan tasarımlar tanım gereği daha düşük kalitede olur
  Pareto frontier üzerinde olmanız gerekir; aksi halde elenirsiniz
  Bizim alanda da bir yerlerde optimum bir nokta var; asıl soru, oraya ulaşacak araçlara, bütçeye ve doğru insanlara sahip olup olmadığınız ve gerçekten oraya ulaşıp ulaşmadığınızı anlayacak kadar kullanıcı bulunup bulunmadığıdır