Yazılım Mühendisliğinde Yanlış Ölçüler: Çaba mi, Değer mi?

Yazılım mühendisliği, yaratıcılık ve problem çözme üzerine kurulu bir disiplin olmasına rağmen, uzun yıllardır “verimlilik tiyatrosu” ile boğuşmaktadır. Endüstri, her birkaç yılda bir, o dönemde modaya uygun olan yeni bir çıktıya odaklanmakta ve bu da genellikle kolayca sayılabilen bir şey olmaktadır. Ancak, bunu yaparak, gerçekten neler başarmaya çalıştığımızı görmemiz engellenmektedir. Bu pattern sıkça tekrarlanmaktadır: Kolayca sayılabilen bir şeyi seçmek ve ardından gerçekten neler başarmaya çalıştığımızı unutmak. Bu durum, zaman içinde pek çok farklı biçimde kendini göstermiş, her seferinde geliştirme ekiplerinin asıl hedeflerinden sapmasına ve sadece belirli bir metriği “maksimize etmeye” odaklanmasına neden olmuştur. Aslında, yazılım geliştirmenin gerçek değeri, oluşturulan ürünün kullanıcıya sağladığı fayda ve iş hedeflerine ulaşmadaki rolüyle ölçülmelidir, nicel çıktılarla değil.

Verimlilik Tiyatrosu

1990’larda bir yazılım mühendisi olarak yetişirken, bazı şirketlerin mühendislerini her bir satır kod için ödemeye başladığını hatırlıyorum. Bu, belki de verimlilik tiyatrosunun en kötü örneği olup, olumsuz teşviklere, verimsiz süreçlere ve genel olarak kötü mühendisliğe yol açmıştır. Geliştiriciler, karşılaştıkları problemlerin gerektirdiğinden çok daha fazla kod yazmak için ödüllendirilmiş ve bu da bakımı neredeyse imkansız olan şişkin ve kırılgan kod tabanlarına yol açmıştır. Hedef – güvenilir yazılım oluşturmak ve gerçek kullanıcı sorunlarını çözmek – üretimi teşvik etme arzusunun altında kalmıştır. Bu yaklaşım, sadece kod satırlarının sayısına odaklanarak, kodun kalitesi, okunabilirliği, yeniden kullanılabilirliği ve hatasızlığı gibi kritik unsurları tamamen göz ardı etmiştir. Tüm bu gelişmeler gösteriyor ki, geliştiriciler daha fazla kod yazmak için karmaşık ve gereksiz soyutlamalar yaratmış, bu da sistemin genel performansını düşürmüş ve hata ayıklama süreçlerini uzatmıştır. Bu tür bir “verimlilik tiyatrosu”, uzun vadede şirketlere ciddi maliyetler getirmiş, ürün kalitesini düşürmüş ve geliştirici motivasyonunu olumsuz etkilemiştir.

Benzer şekilde, bazı şirketler, geliştiricilerin masada geçirdiği süreyi, kod commit sayısını veya tamamlanan özellik sayısını birincil verimlilik ölçütü olarak kullanma hatasına düşmüştür. Bu metrikler, yüzeysel olarak “üretkenlik” izlenimi verse de, genellikle yüzeysel bir çaba göstergesidir ve gerçek iş değeriyle doğrudan ilişkili değildir. Örneğin, çok sayıda commit yapmak, kod kalitesizliğini veya sürekli hata düzeltmelerini gizleyebilirken, uzun çalışma saatleri de verimsiz süreçlerin veya tükenmişliğin bir işareti olabilir. Bu durum, geliştiricileri, gerçek sonuçlar elde etmek yerine, bu metrikleri manipüle etmeye yönlendirerek sistemin bütünlüğünü ve güvenilirliğini tehlikeye atmıştır.

Agile ve Hikaye Puanları

2000’lerde Agile’in yükselişi, görev kompleksitesini, çabayı ve riski diğer işlere相对 olarak tahmin etmek için soyut bir yol olan hikaye puanlarını getirdi. “Bu ne kadar sürecek?” sorusunu cevaplamak yerine, hikaye puanları “Bu, daha önce yaptıklarımıza göre ne kadar büyüktür?” sorusunu cevaplamak üzere tasarlanmıştı. Bu yaklaşım teoride iyi görünse de, bazı geliştirme ekipleri sisteme oyun oynayarak tahminleri şişirerek, çözümleri överengineer ederek ve ürettiği işin gerçekten değer yaratıp yaratmadığını göz ardı ederek uygulamaya koydu. Yine, metric hedef haline geldi ve asıl hedef – önemli sonuçlar elde etmek – ikincil hale geldi. Hikaye puanlarının arkasındaki orijinal felsefe, geliştirme ekibinin bir öğeyi tamamlamak için gereken çaba, karmaşıklık ve belirsizlik hakkında ortak bir anlayışa varmasını sağlamaktı. Bu, takım üyeleri arasında tartışmayı teşvik ederek, potansiyel engelleri erken aşamada belirlemeye ve daha gerçekçi planlamalar yapmaya yardımcı olmaktı. Ancak, birçok durumda, hikaye puanları bir “hız metriği” olarak yanlış yorumlandı ve ekiplerin veya bireylerin performansını karşılaştırmak için kullanıldı. Bu durum, geliştiriciler üzerinde puanları yüksek tutma veya daha fazla puan “tamamlama” baskısı yaratarak, gerçekçi olmayan tahminlere ve gereksiz karmaşıklıkta çözümlere yol açtı.

Örneğin, bir geliştirici, basit bir görevi bile yüksek puanlarla etiketleyerek sprint hızını artırmaya çalışabilir veya daha karmaşık bir çözüm geliştirerek “daha fazla puan” kazanma eğilimine girebilir. Bu, nihayetinde, bakım maliyetlerini artıran, gereksiz özelliklerle şişirilmiş ürünlere ve gerçek müşteri ihtiyaçlarından uzaklaşan bir geliştirme sürecine neden oldu. Takımlar, puanları tamamlamaya odaklanırken, kullanıcı geri bildirimlerini veya ürünün piyasadaki etkisini göz ardı etmeye başladı. Agile metodolojisinin temel prensiplerinden olan “çalışan yazılım en iyi ilerleme ölçütüdür” ilkesi, yerini “yüksek sprint hızı en iyi ilerleme ölçütüdür” yanılgısına bıraktı. Bu, sadece kısa vadeli başarı yanılsamaları yaratmakla kalmadı, aynı zamanda uzun vadede ürün kalitesi ve iş değeri üzerinde olumsuz etkiler bıraktı.

Tokenmaxxing: Yeni Bir Yanlış Ölçü

Şu anda, geliştiricilerin ve ekiplerin mümkün olduğunca çok AI model tokenını tüketmeye çalıştığı “tokenmaxxing” trendi, ham tüketimi çıktı için eşdeğer olarak tedavi etmektedir. Bunu, yazılım mühendisliği dünyasına giren son yanlış verimlilik metrici olarak görüyorum. Tokenmaxxing, “satır kodları” veya şişirilmiş “hikaye puanları”nı benchmark olarak kullanmak kadar anlamsız olan başka bir boş metricdir. Tokenmaxxing, aşağıdaki davranışların bir sonucu olarak ortaya çıkmaktadır:

• Prompt flooding: Büyük kod tabanları, belgeler ve bağlamın her bir promta doldurulması, modelin gerçekten ihtiyaç duyduğu bağlamda harcama yapılması. Bu davranış, genellikle “ne kadar çok bilgi verirsem o kadar iyi sonuç alırım” yanılgısından kaynaklanır. Ancak, AI modellerinin bağlam penceresi sınırlıdır ve gereksiz veya alakasız bilgilerle doldurulduğunda, modelin asıl odaklanması gereken önemli detayları gözden kaçırmasına neden olabilir. Ayrıca, her token bir maliyete sahip olduğu için, prompt flooding gereksiz yere faturaları artırır ve modelin işleme süresini uzatır. Etkili bir prompt mühendisliği yaklaşımı, modelin spesifik görevi için en alakalı ve özlü bilgiyi sağlamayı gerektirir.
• Agent swarms: Koordineli veya tutarlı olup olmamalarına bakılmaksızın, çoklu AI ajanlarının paralel olarak çalıştırılması ve kod çıkışını maksimize edilmesi. Bu durum, “ne kadar çok AI ajanı çalıştırırsam o kadar hızlı ilerlerim” düşüncesiyle ortaya çıkar. Gerçekte ise, ajanslar arasında koordinasyon eksikliği, çakışan veya redundant işlere yol açabilir. Örneğin, birden fazla ajan aynı görevi farklı yaklaşımlarla çözmeye çalışırken, kaynakları boşa harcayabilir ve geliştiricinin hangi çıktının en uygun olduğuna karar vermesini zorlaştırabilir. Akıllı ajan kullanımı, belirli, iyi tanımlanmış ve paralel olarak yürütülebilecek görevler için tasarlanmalı, gereksiz yere ajan enflasyonu yaratılmamalıdır.
• Background loops: AI oturumlarının veya ajanlarının arka planda sürekli olarak çalıştırılması ve üretimin rõ ràng sahibi veya nedenleri olmadan token harcama yapılması. Bu, “her ihtimale karşı sürekli açık kalsın” veya “belki bir şeyler üretir” gibi düşüncelerle tetiklenebilir. Ancak, sürekli çalışan AI ajanları, aktif olarak kullanılmadıklarında bile token tüketmeye devam ederler. Bu durum, beklenmedik ve yüksek maliyetlere yol açabilir, özellikle de bu ajanların ürettiği çıktıların kim tarafından denetleneceği veya ne için kullanılacağı belli değilse. Bir AI aracının veya oturumunun her zaman belirli bir amaç ve ölçülebilir bir hedefle çalıştırılması esastır; aksi takdirde, bu sadece bir kaynak israfına dönüşür.

Tokenmaxxing’in altında yatan temel sorun, AI’yı bir araç olmaktan çıkarıp, kendi başına bir hedef haline getirmesidir. Oysa AI, yazılım mühendislerinin belirli sorunları daha verimli çözmelerine yardımcı olan güçlü bir yardımcı olmalıdır, token harcamalarını artırmanın kendisi bir başarı göstergesi değildir.

Doğru Soruyu Sormak

Şimdi, AI’nin yazılım geliştirmeyi yeniden şekillendirdiği sır değildir ve bu davranışlar bunun bir sonucudur. AI’ye kod tabanları sağlamak, aynı anda çoklu ajanları çalıştırmak ve hatta kod asistanlarına başvurmak bazı durumlar için faydalı olabilir. Ancak, yaptığımız değişikliklerin kontrolünü kaybettiğimizde ve bunları neden yaptığımızı unuttuğumuzda, hepimizin aynı eski problemle karşı karşıya kalmasını sağlarız: Mühendislik verimliliğini yanlış metriclerle ölçmek. Daha useful bir soru sormak, “Kaç token harcadık?” değil, “Gerçekten hangi problemi çözdük ve kime karşı?” olmalıdır. Hedefler olmadan kaynak harcamak, sadece zaman ve para kaybına yol açar. Bu yeni paradigmayı benimsemek, ekiplerin gerçek iş değerine odaklanmasını ve AI araçlarını bu değeri yaratmak için stratejik olarak kullanmasını gerektirir. Önemli olan, kullanıcılarımızın karşılaştığı zorlukları anlayıp, AI’nın yardımıyla bu zorluklara yenilikçi ve etkili çözümler sunabilmektir. Bu, sadece kod yazmakla veya token harcamakla değil, ürünün nihai etkisini ve kullanıcı memnuniyetini artırmakla ilgilidir. Doğru soruları sormak, sadece teknolojik kapasitemizi değil, aynı zamanda iş zekamızı ve kullanıcı odaklı yaklaşımımızı da ortaya koyar.

AI ve Gelecek

Evet, AI yazılım mühendislerine daha azıyla daha fazla şey yapma, hızla ilerleme ve önceden ulaşılamayan deneyimler yapma yeteneği sunuyor. Örneğin, tekrarlayan kod yazma görevlerini otomatikleştirebilir, karmaşık sistemlerde hata ayıklama süreçlerini hızlandırabilir ve hatta yeni mimari tasarımlar veya algoritmalar için fikirler üretebilir. Ancak, AI’yi verimlilik olarak yerine koymak, bunları gerçekten başarmaya çalıştığımız şeyin öneminin azalmasına yol açar. Yapay zeka, yazılım geliştirme sürecini değiştirmeye devam edecek ve bizim de bu değişime uyum sağlamamız gerekecek. Ancak, bunu yaparken, gerçekten neler başarmaya çalıştığımızı unutmamalıyız ve doğru metriclere odaklanmalıyız. Gelecekteki yazılım mühendisliği, AI’yı sadece bir araç olarak değil, stratejik bir ortak olarak gören, onun potansiyelini insan zekası ve yaratıcılığıyla birleştiren bir yaklaşımla şekillenecektir. Bu, AI’nın ürettiği çıktıyı eleştirel bir gözle değerlendirmek, onun önerilerini geliştirmek ve nihayetinde kullanıcılar için anlamlı ve sürdürülebilir çözümler üretmek anlamına gelir. AI ile işbirliği yaparak, sadece daha hızlı değil, aynı zamanda daha akıllı ve daha etkili yazılımlar geliştirebiliriz.