Literatürde “yazılım bozulur” diye dilimize çevirebileceğimiz “software rots” ya da “yazılımın bozulması” anlamında “software rot” gibi tamlamalar vardır. Bu kavram ile genel olarak yazılım kalitesinin zamanla düşmesi kastedilir. Aynı anlama gelen “bit rot”, “code rot”, “software decay” vb. tamlamalar da vardır.

Yazılım fiziksel olarak tabi ki bozulmaz, kokmaz ya da küf tutmaz ama yazılımlar hayatları boyunca kendilerine yapılan eklemeler ve düzenlemelerle ki biz buna bakım (maintenance) diyoruz, genel olarak başlangıçta sahip olduğu kalitesini kaybeder. Her ne kadar yazılımın bozulması kavramı, daha çok performansında düşme bağlamında kullanılsa da bu kavram genel yazılım kalitesinin, yazılıma yapılan her türlü müdahale ile ciddi bir şekilde düşme eğiliminde olduğunu ifade eder.

Yazılımın, eklenen yeniliklerle büyümesi son derece normaldir, yazılımın tabiatındandır. Ama yazılımın büyürken, karmaşıklığının gittikçe artması da bir başka gerçektir. 1 milyon satırlık bir yazılımın kalitesini sağlamak için sarf edeceğiniz enerji, 10 bin satırlık bir yazılımın kalitesini sağlamak sarf edeceğiniz enerjiden 100 kat fazla değildir. Belki ihtiyaç duyulan maliyette üstel olarak büyüme söz konusudur. Dolayısıyla yazılım projelerinin başında bazı şeyleri örneğin dokümantasyon ya da birim testlerini görmezden gelerek ya da yapmayarak ya da mimariye fazla önem vermeyerek işinizi hallettiğinizi düşünebilirsiniz ama bu şekilde yapmadığınız her şey, teknik borç (technical debt) olarak birikir. Yazılım büyüdükçe hem bu borç kendini daha belirgin bir şekilde hissettirir hem de bu borcun ödenmesi zorlaşır. Yazılım projesinin ilk 6 ayında birikmiş 30 adam-günlük bir teknik borcunuz varsa, yani atladığınız-ıskaladığınız kısımları düzeltmek için 30 adam-güne ihtiyacınız varsa, muhtemelen bu miktar projenin 3. yılının sonunda 700 adam-güne çıkmış olacaktır.

Teknik borç ile ilgili Martin Fowler’ın orijinal yazısına ve Türkçe çevirisine bakabilirsiniz. Ward Cunningham’ın bize öğrettiği bu kavram, bir şeyi yapmanın hızlı ve derme-çatma olmasıyla, doğru-düzgün olması arasındaki farkı vurgular. Var olan bir sistemde bir değişikliği doğru-düzgün yapmak, üzerinde düşünülecek bir tasarım, etkilenecek yerleri bulmak için zaman, yeniliğe yer açmak için gerekli iyileştirmeler için adam-güne ihtiyaç duyar. Ama biz yazılımcılar, hızlı ve kirli bir şekilde, derme-çatma yöntemlerle bu değişikliği sisteme yedirmenin yollarını buluruz. Bazen uyarırız bizi yönetenleri, işimizi doğru düzgün yapmak isteriz, derme-çatma yapmanın ileride neye mal olacağını belirtiriz, bazen de ya bilgimiz ya da inancımız olmadığından, en hızlı bir şekilde yapar geçeriz, benden sonrası tufan diye düşünürüz. İlk halde bizim itirazımızı kaale almayan yöneticilerin, ikinci halde de biz yazılımcıların açmazı, yetişmeye çalıştığımız bir tarihin (deadline) olmasıdır.

Teknik borcun doğrusal olarak büyümediğini, katlanarak arttığını söyleyebiliriz. Çünkü oluşturulan her teknik borç, aynen finansal borçla ilgili durumda faizin katlanarak artması gibi birbiri üzerine binerek artar. İlk günlerde gözünüze çok gelmeyen faiz, sıfırlanmadıkça nasıl faizin faizi haline dönüşürse, yapılmayan işler de üst üste binerek çok daha büyük maliyetlere yol açar. Hatta bir müddet sonra teknik kişiler, yazılımı düzeltemeye çalışmanın beyhude olduğunu çünkü baştan yazmanın daha az maliyetli olacağını söylerler. Bu gibi sözlerin yöneticileri çılgına döndürdüğünü ya da teknik kişilerin abartması ya da kaprisi olarak göründüğünü iyi biliyorum. Ama malesef yazılımcılar çoğunlukla haklıdırlar.

Fowler, yukarıda adresini verdiğim yazısında, üretim hızımızı ölçemediğimizden ve nihayetinde teknik borcu, finansal borç gibi algılayamadığımızdan dolayı, yanlış olarak aldığımız ya da almamız gerekirken almadığımız kararların üretim hızımızı nasıl etkilediğini farketmediğimizi ifade ediyor. Ben çoğu yöneticinin yazılımcıların bugları çözmede ve yenilikleri sisteme kazandırmada neden bu kadar yavaş olduklarını devamlı sorguladıklarını ama yazılımcıların işlerini yaparken bu teknik borçla nasıl savaştıklarını anlamaktan kaçındıklarını sıklıkla gözlemliyorum. Alınması gerektiği halde alınmayan ve “çocuklar yolda öğrenir” denen eğitimler, yapılmayan dokümantasyonlar, yazılımcıların kafalarını duvara vura vura öğrendikleri dolayısıyla tekrardan keşfettikleri tekerlekler, yapılması gereken ama akla bile gelmeyen mimari prototip, deneme-yanılma çalışmaları ve testler, tecrübeli yazılımcıya açık ihtiyaç varken, ucuz olsun diye daha genç ve tecrübesiz kişilerle iş yapmaya çalışmak, son derece teknik derinlik isteyen konularda bile uzmanına sormak yerine, bilgisiz ve tecrübesiz ama iyi niyetli kişileri 3-5 günlük eğitime göndererek tüm sorumluluğu onların sırtına bindirmek, müşteriyi yatıştırmak amacıyla bilinçli-bilinçsiz verilen her türlü söz, hepsi teknik borcu oluşturan etkenlerdendir.

Eskiden bu yana yazılım projelerinde teknik borcun %100 giderilemeyeceğini düşünmüşümdür. Özellikle ülkemizde tamamen proje odaklı yazılım işlerinde, yazılımı geliştiren şirketlerin, projeyi sattıkları kurumların maddi ve manevi tahakkümü altında olduklarını iyi biliyorum. Bundan dolayı da, örneğin kapsamın projeyi satın alan firma tarafından sürekli olarak değiştirildiği ve genişletildiği bir ortamda, yazılımı geliştiren firmanın teknik borcu kapatmak için bir şey yapmayacağının, en fazla kullanıcı kabul testlerini geçecek kadar iyileştirme yapmaya imkan vereceğinin çok aşikar olduğunu yaşayarak öğrendim. Ama bu durum böyle davranan yazılım evlerinin, aynı projeyi başka yerlere satma durumunda, teknik borcun kendilerine zorluk çıkarmaya devam edecekleri gerçeğini, yukarıda bahsettiğim tahakkümün oluşturduğu stresten dolayı farketmediklerini, düşünmediklerini hatta düşünmek istemediklerini de çok defa gözlemlemişimdir.

Teknik borç konusunda beni en rahatsız eden şey, teknik borcun kendisinden ziyade bu konuda nasıl davrandığımızdir. Bu ülkede yazılımı yönetenlerin ciddi bir kısmı teknik borç kavramından haberdar değildir. Diğer ciddi bir kısmı da kavramdan haberdar olsa bile mahiyetinden, sonuçlarından, örneğin varlığının bakım sürecini nasıl sıkıntılı hale soktuğunu anlamaktan çok uzaklar. Bundan dolayı yöneticiler, yazılımcıların dillerinin döndüğünce “bunu muhakkak yapmalıyız” cinsinden itirazlarını malesef mükemmeliyetçilik ya da yazılımcı kaprisi olarak göme eğilimindeler.

Örneğin yazılım müdürü olarak çalıştığım bir yazılım evinde patron, benim “bu şekilde olmaz” deyip ayrıntılı olarak açıkladığım bu teknik borç kavramını anlamayıp, benim karşımda, benim altımda çalışan ve benim işe aldığım tecrübeli kişilere danışıp, onlardan gelen “olur ama sonrasında bakımı çok maliyetli olur” şeklinde ifadeyi benim aleyhime kullanıp, “tamam böyle yapıyoruz” diye karar aldığını çok iyi hatırlıyorum. Sonuçta beni işe alırlarken “şöyle kaliteli iş yapalım, böyle kaliteli olsun” diye esip gürleyip, iş bu kaliteyi oluşturacak takımı kurmaya geldiğinde “ama çok pahalı adam alamayız” diye rampa yapıp sonrasında da iş yapış şeklime karşı çıkanlarla çalışmam mümkün olmadığından, hafta sonu yapılan bu toplantıdan sonra ben Pazartesi günü istifa etmiştim. Bu durum, saygısızlık vb. haller yanında çok tipik bir teknik borç aymazlığıdır. Bu şekilde düşünen kişiler, hayatlarında aldıkları en ufak kararların bile bir sonucu ve maliyeti olduğunu bilirler ama nedense yazılım projelerinde böyle bir durumu imkan dahilinde görmezler.

Demeye çalıştığım şey, Fowler’ın yukarıdaki makalesinde vurguladığı şeydir. Aslen önemli olan teknik borcun ne kadar olduğu değildir. Önemli olan bu teknik borcun nasıl yapıldığıdır. “Etimiz, budumuz bu” diyerek, bilinçli olarak altına girilen borçtan dolayı mutsuz olurum belki ama bundan dolayı istifa etmem, savaşırım. Ama kavramlardan bihaber şekilde, cahil cesur olura uyarak, farkında bile olunmadan alınan teknik borca katlanmak zordur, çünkü devamlı kendinizi duvara konuşuyor hissedersiniz. Yöneticileriniz sizden bir şey isterler, siz bunu yapmanın zorluğundan, ciddi zaman alacağından ve bu durumun en büyük sebebinin de var olan sistemin sıkıntılı alt yapısı olduğundan bahsedersiniz ama karşı taraf sizi iyi niyetli olmamakla, iyi çalışmamakla, sonuç odaklı olmamakla vs. suçlar. Bu durumu Fowler, aşağıya Türkçe çevirisinden aldığım bir dörtlü durumla şöyle açıklıyor:

Teknik borç kadranı.

Özellikle en sıkıntı çektiğim türden yöneticiler kasten teknik borç oluşturup bunun bedelini yazılımcılara ödetenler yani “kasten ve umursamaz” olanlardır. “Neden yavaş?”, “neden bu kadar uzun sürüyor?” sorularını devamlı sorarlar ama cevabı dinlemezler, anlamaktan kaçınırlar ya da anlamıyor görünürler. Bu ülkedeki yazılım yöneticilerinin ya da yönlendirenlerin ciddi bir kısmı bu tiptedirler. Bu tipten insanlarla çalıştığınızda davulun sırtınızda olduğunu ama tokmağının başkasında olduğunu hızlıca hissedersiniz.

Bu duruma “kasten ve tedbirli” olarak yaklaşanlarla daha rahat çalışılabilir. Çünkü kasten teknik borç oluştursalar da bunun sorumluluğunu üzerlerine alırlar, kimseye bundan dolayı yüklenmezler, hatta “şimdi bu şekilde idare edelim, sonra düzeltiriz” derler. Sonra düzeltilir mi düzeltilmez mi bilinmez ama en azından sorumluluk alan ve ahlaki olarak umursamaz olmayan kişiler, stres seviyenizi yükseltmezler. Yazılımcı olarak siz de “nihayetinde karar sizin, sonuçlarına katlanıyorsanız, eyvallah, öyle yapalım” demeyi seçebilirsiniz. Benim ABD’de çalışırken kısıtlı kaynaklardan dolayı teknik borca girmeyi seçen yöneticilerim genelde bu cinstendi.

Sanırım benim bahsettiğim patronumun da dahil olduğu, ülkemizdeki yazılım yöneticilerinin-yönlendirenlerinin büyük çoğunluğunun en temel sıkıntısı, yukarıdaki kadranda “yanlışlıkla ve umursamaz” çeyreğinde olmalarıdır. Yani “yazılım nedir?”, “yazılım nasıl geliştirilir?”, “yazılımın alt süreçleri nelerdir?”, “yazılım mimarisi nedir?” gibi sorular onların zihinlerinde yoktur. Muhtemelen bu soruların ancak yurt dışındaki kocaman projeler için geçerli olduğunu ama kendi durumları için önemli olmadığını düşünüyorlardır. Bundan dolayı bu yöneticiler farkında olmadan teknik borç oluştururlar ve bunun ne anlama geldiğini ve nasıl riskler oluşturduğunu da bilmezler. Durumun sıkıntısını ise yazılımcılar çeker ve yazılımcılar artık yöneticilerine laf anlatmaya çalışmayı çoktan bırakmışlardır. Bu yüzden bu ortamlarda işten ayrılmalar yüksek orandadır. (Yukarıda bahsettiğim durumu yaşadığım yazılım evi de sonrasında kapısına kilidi vurmak zorunda kaşmıştı.)

Son çeyrekte olanlar iyi niyetli ama bilgi ve tecrübe konusunda “”yanlışlıkla ve umursamaz” olanlarla aynı durumdadırlar. “Yanlışlıkla ve tedbirli” olanlar, iyi niyetleri sayesinde bilmediklerini öğrenirler çünkü düşünürler ve bundan dolayı eksiklik hissetmezler ve çevrelerindeki teknik insanlarla iş birliği yaparlar. Bu tipten olan yazılım yöneticileri, imkan verildiğinde, zamanla daha doğru kararlar alırlar ve iyi ve öngörülü bir yönetici haline gelebilirler.

Bu yazıda teknik borcun oluşması ve doğası ile ilgili noktalara değindik. Teknik borcu nasıl ortadan kaldırabileceğimize ise bir sonraki yazıda kafa yorarız.

Toplam görüntülenme sayısı: 3430