Yazılımcının verimliliğini kod satır sayısı ile ölçmek
Bir fikir sanatçısının verimliliğini nasıl ölçersiniz?
Zor bir soru.
Sanatını düşüncelerini hayata geçirerek icra eden sanatçılar için verimlilik ölçümü her zaman zor olmuştur. Yazılım sanatını icra eden yazılımcılar için de aynı durum geçerli. Söz konusu düşünceleri koda dökmek olunca yazılımcının verimini ölçmek için akla ilk gelen klasik yöntemlerden bir tanesi ürettiği koda bakarak karar vermek. Bir yazılımcı verilen zamanda ne kadar fazla kod yazarsa o kadar verimlidir. Çünkü yazılımcının ürettiği çıktı koddur. Dolayısı ile verimini ürettiği kodun miktarına bakarak ölçmek akıllıca olacaktır.
Malesef ki çoğu yazılımcı ve yönetici bu yanlış zihniyete sahip. Bu zihniyet yüzünden yazılımcılar özellikle de yöneticiler tuzağa düşerek, yazılımcının verimliliğini ürettiği kod miktarına bakarak ölçmeye çalışıyorlar ve sonunda da yazılım dünyasında yapılması en kötü stratejik hatalardan birini yapıyorlar. Öyle ki Bill Gates bile bu zihniyetin ne kadar yanlış olduğunu şu sözüyle açıklamaya çalışmış:
Programlamadaki ilerlemeyi kod satırı ile ölçmek uçak üretiminde ki ilerlemeyi ağırlık ile ölçmeye benzer. — Bill Gates
Belki kısa vade de yaptıkları hatanın farkına varmaları güç fakat uzun vade de geliştirdikleri yazılımda her kod değişikliği yapmaya çalıştıklarında, yazılımlarına yeni bir fonksiyonellik eklemeye çalıştıklarında ve teslim tarihlerinde sıklıkla aksamalar yaşadıklarında yaptıkları bu stratejik hatanın farkına çok acı bir şekilde varıyorlar. Fakat durum bu noktaya gelince malesef ki atı alan üsküdarı geçmiş oluyor.
Bildiğiniz gibi daha önce paylaştığım “Aykırı Yazılımcı” terimi ile yazılım sektöründe doğru bilinen yanlışları anlatmak için ilk adımı atmıştım. Bugünkü yazımızın konusu doğru bilinen yanlışlardan bir tanesi olan ve yöneticiler tarafından sıklıkla yapılan “Yazılımcının verimliliğini yazdığı kod satır sayısı ile ölçmek” olacak. Bu doğru gibi görünen yanlış, küçük büyük dinlemeden her firmada yapılabiliyor. Bu hatanın arkasındaki motivasyonu ve sonuçlarını daha iyi anlamak için hepimizin bildiği şirketlerden birisi olan Apple örneğini ele alacağım.
2000 satır kod
1982 yılında, Lisa yazılım ekibi büyük bir zorlama ile yazılımı gelecek 6 ay içerisinde bitirmek için sıkı bir çalışma içerisindeydiler. Yöneticilerden birkaçı teslim tarihini tutturabilmek için her yazılımcının ilerlemesini ve verimliliğini haftalık olarak yazdığı kod miktarına bakarak ölçmeye karar verdiler. Bu karara göre her yazılımcı her hafta minimum 2000 satırlık kod yazmak ve haftanın bitiş günü olan Cuma günü, o hafta içerisinde yazdıkları kod satırını bir form şeklinde doldurup ilgili yöneticite teslim etmek zorundaydılar.
Tasarım ekibinde olan Bill Atkinson, yazılımcının verimliliğini yazdığı kod satır sayısına bakarak ölçmenin çok salakça bir düşünce olduğunu düşünüyordu. Bir yazılımcı olarak amacının olabildiğince az kod yazarak efektif bir program kodlamak olduğunu; kod satır sayısı metriği sadece özensiz, şişirilmiş ve bozuk kod yazmayı teşvik ettiğini düşünüyordu. O sıralar Bill, yazılımın belli bir bölümünde optimizasyon görevi üstlenmişti. Kodu ve programı optimize edip daha performanslı hale getirebilmek için gerekli modülü yeniden yazmıştı ve bu yeniden yazma yaklaşık 2000 satır kod tasarrufu getirmişti. Bu 2000 satırlık gereksiz kodu çöpe attıktan sonra Bill yöneticilerin verdiği kararı öğrendi ve haftalık yazması gereken minimum 2000 satırlık kod ile ilgili dolduracağı form önünde duruyordu. Bir süre forma ne yazması gerektiği konusunda düşündü ve sonra forma -2000 yazdı.
Yöneticiler onun bu hareketine ne tepki verdiler bilmiyorum ama bunu takip eden birkaç hafta sonra Bill’den bu formu doldurması konusunda ısrarcı olmayı bıraktıkları söyleniyor.
Ne kadar çok kod o kadar çok sorun
Siz de tecrübeli bir yazılımcı olarak kendi tecrübelerinizi bir hatırlayın veya etrafınızdaki diğer tecrübeli yazılımcılara sorun. Her biri size kod yazmanın beraberinde büyük sorumluluklar ve yükler getirdiğini söyleyeceklerdir. Yazılan her kod test edilmek zorundadır. Uzun yıllar hizmet sağlaması için belli periyotlarda bakımı yapılması gerekir. Diğer yazılımcılar tarafından okuyup anlaşılmalıdır ve gerektiğinde debug edilip tespit edilen hatalar giderilmelidir. Dolayısı ile ne kadar çok kod, programcılar tarafından okuyup anlaşılmak için harnacak o kadar çok zaman demektir. Yeni hataların ortaya çıkma olasılığının artması ve mevcut hataların saklanacakları alanların fazlalığı demektir. Kodun bakımını yapmak istesen o kadar fazla kod parçasının hareket ettirilmesi demektir. Yapılacak değişikliklerin kod satır sayısının fazlalığından dolayı yavaşlaması, eklenecek yeni fonksiyonellikler için gereken çabanın artması ve zorlaşması demektir.
Malesef ki “Ne kadar ekmek, o kadar köfte” deyimi yazılım dünyası için geçerli değildir. Tam tersine ne kadar çok kod o kadar bela demektir. Hal böyle olunca, yazılımcının verimliliğini yazdığı kod satırı ile ölçmek çok basit ve doğruymuş gibi görünse de aslında yazılımı felekate götüren stratejik bir hatadır.
Peki bu gerçek neden bu kadar kolay bir şekilde görmezden geliniyor ve bu hatalar yapılıyor?
Çok basit. Yanlış zihniyet. Doğru bilinen yanlışların sorgulanmadan takip edilmeye devam edilmesi. Akabinde bu yanlış doğruların sonucunda elde edilen olumsuz çıktıların hata olarak değerlendirilmeyip sorunun yanlış yerlerde aranması. Yazılım yöneticilerinin gerçek olması gereken doğru yazılımcı zihniyeti taşımaması.
Bir aykırı yazılımcı olarak bu zihniyete karşıyım, aykırıyım. Daha kaç yazılım bu ve bunun benzeri kararlardan dolayı daha potansiyeline ulaşamadan çöpe atılacak. Daha kaç şirket bu ve benzeri yanlışlardan dolayı zarar edip belki de iflas edecek. Yazılım bilimini diğer iş dünyası ile karşılaştırmayı bırakmamız lazım. Diğer mesleklerde takip edilen en iyi uygulamalar (best practices) yazılım dünyası için geçerli değil. Diğer mesleklerdeki zihniyet ile bir yazılım yönetilemez. Yönetilmeye kalkılırsa da büyük stratejik hatalar yapılarak ortaya kalitesiz işler çıkar. Günümüzde hala yanlış yazılımcı zihniyetinden dolayı bu hatalar malesef ki yapılmaya devam ediliyor. Bir yazılım fırıncı zihniyetiyle yönetilemez. Neden fırıncı diyorum? Çünkü bir fırıncının ürettiği çıktı ekmektir. Dolayısı ile fırıncının verimliliğini ölçmek çok kolaydır. Bunun için verilen zamanda ürettiği ekmek adedine bakmak yeterli olacaktır. Fakat bu yöntem yazılım sektörü için uygun değildir.
Malesef ki çoğu yönetici alışılagelmiş yönetim şekilleri ile yazılımları yönetmeye çalışıyor. Fakat gizli gerçek şu ki, diğer meslek dalları için bilinen doğrular yazılım sektörü için genelde ters tepiyor. Çözüm bunun farkındalığında yatıyor. Yazılım bilimini ve prensiplerini özümseyip, doğru yazılımcı zihniyetini edinmekte yatıyor.
Yazılımcının verimliliği nasıl ölçülmeli?
En verimli günlerimden biri 1000 satırlık kodu fırlatıp attığım gündü. — Ken Thompson
Az kod yazan yazılımcı verimli yazılımcı mı demektir? Hayır. Ken Thompson bu sözü ile anlatmak istediği yukarıda bahsettiğim gibi yazdığınız her kod satırının uğraşmak zorunda kalacağınız bir çok yükü de beraberinde getirdiğidir. Projenizde yer alan her kod satırı gelecekte zamanınızı ayırmak zorunda kalacağınız potansiyel birer bela üreticisidir. Bu fazla kodlardan kurtulup aynı fonksiyonaliteyi daha basit bir kodla sağlamanız sizi ve takım arkadaşlarınızı büyük dertlerden kurtaracaktır.
Yazılımcının verimliliğini ölçmek gerçekten zor bir konu. Buna benim de tam olarak “verimli yazılımcı şu yazılımcıdır” diye net bir cevabım yok. Fakat yıllarca edindiğim tecrübe ile tavsiyelerde bulunabilirim.
Daha fazla kod satırı bir yazılımcının verimliliğini ölçmede iyi bir ölçüt olmadığı gibi daha az kod satırı da sağlıklı bir ölçüt değildir. Yazılımcılar bir gün daha fazla kod satırı ile çözdükleri problemi ertesi gün buldukları daha basit bir çözümle daha az kod yazarak da çözebilirler. Burada yazılımcıların verimliliğinin uzun vadede daha çok anlaşılacağını düşünüyorum. Her yazılımcı, projenin ilk aşamalarında öyle veya böyle çalışır bir ürün ortaya çıkaracaktır. Ürünün doğum aşamaları en yalın olduğu zamanlardır. Daha az kod ve düşünelecek daha az parçanın olması yazılımcıların daha hızlı ve esnek hareket etmesini sağlar. Fakat uzun vadede kod tabanı büyüdükçe ve ürünün sunduğu fonksiyonellik arttıkça yazılımcıların işleri de zorlaşmaya başlayabilir hatta durma noktasına gelebilir. Peki bu her zaman böyle midir? Tabi ki hayır. Doğru zihniyetle sağlıklı, yönetilebilir ve sürdürülebilir bir şekilde kodlanan yazılımlarda bu tip aksaklıklarla karşılaşılmayacaktır.
Yazılımcının verimini ölçmede iki taraf görüyorum. Bir tarafta yazılımın kodlanacak özelliklerinin yanı yazılımda olması gerekli olan parçalara karar veren ürün sahibi veya proje yöneticileri. Diğer tarafta da yazılımcıların kendisi.
Yöneticiler
Eğer yöneticiler ürünün gereksinimlerini doğru bir şekilde belirleyemezler, daha ilk günden mükemmeli yakalamak adına gerekli gereksiz herşeyin kodlanması gerektiğini düşünürlerse yazılımcıların işini zorlaştıracaklar aynı zamanda teslim tarihlerinin sarkmasına neden olacaklardır. Hele ki “ters gitme ihtimali olan herşey ters gidecektir” yazılımcı presibini de göz önünde bulundurursak kervan yolda düzülürken beklenmeyen aksiliklerden dolayı teslim tarihinin kaçırılacağını gören yöneticiler suçu yazılımcılarda aramaya başlayacakladır ve onların verimliliklerini sorgulayacaklardır. Halbu ki asıl suçlular kendileridir. Dolayısı ile yazılımcıların verimlilikleri onlara sunulan ürün planı çerçevesinde değerlendirilmesi gerekir. Yöneticiler yazılımcılara verimliliklerini arttıracak sakin ortamı ve planlamayı sağlamalıdırlar.
Yazılımcılar
Diğer taraftan yazılımcıların verimliliklerini ölçmede bir ölçüt olarak yazılımın kolay yönetilebilir ve sürdürülebilir olup olmadığı sorusu sorulabilir: Bir yazılım daha geliştirildiği ilk günden itibaren kolay yönetilebiliyorsa ve bu yönetilebilirliği uzun zaman boyunca sürdürebiliyorsa yazılımcılar doğru iş yapmış demektir. Peki yönetilebilir ve sürdürülebilir bir yazılım nasıl geliştirilir? Burada yazılımcıların izlemesi gereken 3 anahtar kelimeden bahsedeceğim: Basitlik, okunabilirlik ve anlaşılabilirlik.
Yazılımcılar yazdıkları her kod parçasında kendilerinin ne kadar zeki olduklarını göstermeden, akıllı kodlar yazmadan olabildiğince basit olmalıdırlar. Gerçek manada basit kod yazan yazılımcılar karşılaştıkları problemleri daha az fakat efektif kodlar yazarak çözeceklerdir. Daha az kod yazarak problemleri çözerken, okunabilirlikten ödün vermemeleri gerekir. Yazdıkları her kodun diğer yazılımcılar tarafından okunacağını göz önünde bulundurarak kod yazmalıdırlar. Az kodla basit çözüm ve okunabilirlik arasındaki dengeyi iyi tutturdukları an ortaya kaliteli ve temiz kodlar çıkacaktır. Kalite ve temiz kod da anlaşılabilirlik için ilk adımdır. Hatırlatmaya gerek yok fakat yazılım işi sosyal bir iştir. Bir proje üzerinde birden fazla yazılımcı çalışıyor. Dolayısı ile saydığım bu kriterleri başarı ile dengeleyen yazılımcılar ortaya kolay yönetilebilir ve sürdürülebilir yazılımlar çıkaracaklardır. Sonucunda da verimli oldukları aşikardır.
Bugünkü “Aykırı Yazılımcı” yazımda diğer bir konuya olan aykırılığımı paylaştım. Umarım derdimi doğru bir şekilde sizlere aktarabilmişimdir. Bu yanlış yazılım zihniyetini değiştirmek için sizin gibi aykırı yazılımcıların bu ve bunun gibi yazıları paylaşmasına ihtiyaç var. İnsanlar doğrulara yeteri kadar maruz kaldıktan sonra belki yanlış yolda olduklarını anlayıp doğru yola yönelirler. Tek derdimiz budur.
Doğru yazılımcı zihniyeti ile kalın!