Emrah Olgun, çok sevdiğim dostum, telefonda son konuşmamızda beni şaşırtınca, telefonu kapadıktan sonra uzun uzun Techinox Yazılım’ı kurduğumuz zamanları düşündüm. Uzun saçlı*, ayakları yere basmayan ama yeni medya, yazılım ve yazılım üretimi üzerine çok net fikirleri olan gençlerdik.

Ofisimizi kurup oturduğumuzda ilk yaptığımız neydi biliyor musunuz? Bir uygulama çatısı geliştirmek!

Mathilda 1.0 böyle bir atmosfer içerisinde doğdu. Çocukluk ve ergenlik dönemini bitirdiğinde kendi üzerindeki kod üreticileri ile veri tabanı erişimimizden tüm CRUD** ekranlarına, kullanıcı/erişim yönetiminden loglamaya birçok işimizi hallediyordu.

Bir süre sonra artık kaynak kodunun %80’i Mathilda tarafından bizim için üretilmiş projelerimiz vardı! Bu sayede, biz kullanıcı arabirimi ve iş süreçlerine daha fazla odaklanabiliyorduk. O günün proje bütçelerinde rakiplerimiz projelerinde doğru düzgün HTML yazmaya kaynak bulamazken, kaynak kodunun üçte biri JavaScript, web tabanlı yazılımlar ürettiğimizi bilirim. Bugün için bu rakamlar alelade görünse de bütün bunlar olurken AJAX’ın henüz ismi olmadığını düşünürseniz durumun ciddiyeti daha net anlaşılır sanıyorum.

Geçen birkaç yılda her doğru kararı verdiğimizi düşündüğümüz ama sonunda tökezlediğimizde, aldığımız dersi Mathilda’ya ekledik. Yazılımlarımızı test ederken yada bir şekilde üretim ortamına kaçmış belki binlerce yazılım hatasını Mathilda üzerinde düzelttik yada engelledik.

Birçok tahminimizde yanılıp, çoğu kararlarımızı yanlış alırken yaptığımız tek doğru belki de, nasıl bir uygulama çatısına ihtiyacımız olduğunu öğrenmek ve öğrendiklerimizi Mathilda’ya geri kazandırmak olmuştur.

Yıllar alan bu geliştirme süreci sonunda Mathilda büyüdü ve mükemmelleşti. Mathilda hala çok güzel kod üretiyordu lakin artık üretilen kodun teknolojisi bize eski eski kokmaya başlamıştı. Günün gerekleri bizi nesneye yönelik programlamaya, ölçeklendirilebilirliğe ve daha kolay parçalara bölünebilir bir uygulama çatısına muhtaç hale getirirken yapılacak belliydi.

Mathilda’nın büyük bir kısmı yeniden yazılmalıydı.

Biz ise bunca yılın birikimini yeniden yazılacak versiyona nasıl aktarabileceğimizi düşünüyorduk.

Bir kere kabul etmemiz gereken bir nokta vardı ki Mathilda 1.0’ın kaynak kodu, geçirdiği evrimin yara izleri ile doluydu. Tamam, kabul, o JavaScript fonksiyonu context menünün IE6’da çalışabilmesi için o kadar garipti. Sonuçta iyi yada kötü sebeplerden dolayı elimizde okuması pek de keyifli olmayan bir kod tabanı vardı.

Bu kodu başka bir teknolojiye taşımak ve ortaya çıkan ürünü de bundan sonra geliştireceğiniz her yazılımın kalbine yerleştirmek, alınması kolay bir karar değildi. Tüm risklerin bilincinde ve biriktirilmiş know-how’un mümkün olan en büyük kısmını koruyarak Mathilda’nın yeniden yazılmasına karar verildi.

Yılların birikimi ve deneyimlerimizin eseri uygulama çatımızı güncel teknolojiler ile geliştirmemiz ne kadar vakit aldı biliyor musunuz?

3 Ay

3 Ay? Üç ay..evet sadece 3 ay içerisinde elimizde eskisi kadar becerikli ama yanında menzilimizi kat ve kat arttıran yeni becerileriyle Mathilda, rakiplerimiz üzerinde ciddi bir teknolojik üstünlüğü bize sağladı.

Madem üç ayda geliştirilebilecek bir araçtı Mathilda, peki neden ilk versiyonu ile çıkagelmemiz bizim bu kadar zamanımızı aldı? Şaşırmamak elde değil, zira yeni versiyon bizim Mathilda’yı ilk geliştirdiğimiz sürenin de altında bir zamanda tıkır tıkır işler hale gelmişti. O halde, keşke ilk versiyonumuza 6 ay harcayacağımıza 2 yıl harcasaymışız, piyasanın tozunu atacakmışız!

Adama “yavaş ol” derler. Sakinleşelim, soluklanalım…

Öncelikle belli kabuller yapmakta fayda var. Ben özetliyorum:

Eğer yazılım işi ile uğraşıyorsanız, şu anda insan oğlunun yaptığı en soyut ve en karmaşık şeyi kendinize meslek edinmiş durumdasınız.

Yazılım üretimini zor kılan, bizim yazılım üretimi tanımımızdır. Biz yazılım üretimini yapması gereken her şeyin kendisine söylenmesine ihtiyaç duyan bir nesneye -bilgisayara-, bir işi yeteri kadar yapabilecek zeka vermek olarak tanımlıyoruz. Bu tanımlamanın yanında getirdiği gerçek, yazılım üretiminin en temel sorununun “yazılımı oturup yazmak” olmadığıdır.

Her ne kadar planlama toplantılarında aksi düşünülerek konuşulsa da, yazılım üretimine ayrılan kaynakların çok küçük bir kısmı gerçekten klavye başına oturup kod yazmaya ayrılmaktadır.

Hmm. Bir Saniye..

Amacımız yazılımı “yazmak” iken niye biz vaktimizin çok çok çok daha büyük bir kısmını “yazmak harici” aktivitelere ayırıyoruz? Niye müşteri isterlerini derliyor, garip standart şekiller ile modeller hazırlamaya bunca emek harcıyoruz?

Proje süresinin %20’sinde oturup kod yazdık desek, projenin tüm süresinde bu kodu 5 kere yazardık değil mi? Bir-iki kereyi geçtim, 5 kerede de doğru yazılım ile çıkamaz mıyız? Niye bırakıp şu dokümantasyonu kod yazmaya oturmuyoruz?

Yazılım üretiminin temel sorunu yazılımı “yazmak” değil de ondan.

Artık “yazmak” yada “yazabilmek” yazılım üretiminin önemsiz konularıdır. Biz vaktimizin büyük bir çoğunluğunu bilgisayara aktarılması isteneni, anlayıp, anladığımızı dokümante etmeye, dokümanlarımızı birbirimize gösterip içeriklerini karşılamaya harcıyoruz.

Bunları yapıyoruz zira gerçekten “en doğru” kodu yazmanın daha iyi bildiğimiz bir yolu yok. İşin kötüsü bildiğimiz bu yöntemin de garantisi yok.

Bizim asıl derdimiz, geliştirmek istediğimiz yazılımın yapması gerekenler konusunda farkındalığı oluşturmaktır.

Gerisi hikaye! Eski Mathilda’yı geliştirirken işte bu edindiğimiz farkındalıklarımızı ilk ürünün üzerine yamaya yamaya bir noktada biriktirmiştik. Mathilda’nın 2.0 versiyonuna karşı yükümlülüklerimizi biz son birkaç yıldır zaten yerine getiriyorduk. Eğer tüm model zaten elinizin altında ve yapacağınız iyileştirmeler de deneyimleriniz ile sabit ise kodu “yazmak” dediğiniz nedir ki?…

İyi bir yazılım, birkaç sene olgunlaşma evresine ve bir kerede olmasa bile parça parça, tekrar tekrar yazılmaya ihtiyaç duyar. Bu gerçek, aynı evrenimizdeki kütle çekimi gibi, bugün itibari ile bildiğimiz hangi yazılım geliştirme teknolojisi, hangi yazılım geliştirme metodunu kullanırsanız kullanın kaçamayacağınız bir gerçektir.

Her yıl işlemciler güçlerine takla attırırken, 4GB bellekli diz üstü bilgisayarlarımızı anlamlı kılan yazılımlar, Moore kanununa bağlı gelişmiyor ne yazık ki. Yazılım üretimi noktasında 10 sene önce neredeysek, bugün de o civarlardayız.

İşte bu sebeple yazılım geliştirmeye harcadığımız sürenin %80’ini yazılımı “yazmanın” haricinde aktivitelere ayırmak zorundayız.

Bu gerçekliği kavrayamamış ekiplerin nasıl debelendiklerini anlatmaya da gerek yok. Böyle bir ekip ya kusurlu ve eksik ürünler sunmak –yani işinin hakkını vermemek- yada ister toplamak ve yazılım modellemek gibi işleri editör üzerinde yapmak zorundadır.

Şimdi doğruya doğru, ister toplamak ve yazılım modellemek için bunca araç varken bunları editör ile yapmaya çalışmak, çay kaşığının arkasını tornavida yapıp IKEA mobilyası monte etmeye benzemiyor mu?

Biliyorum, kod yazmaya oturmak daha “havalı” yada kimileri için daha “keyifli” ama kodu “yazmak” haricindekileri yapmadan da yazılım yazılım olmuyor. En azından şimdilik elimizden gelenin en iyisi bu.

Bu pencereden bakınca bazı şeyler gerçekten garip görünmeye başlayabiliyor. Bir yandan “yazılımcı” olarak yetiştirdiğimiz insanlara veri yapıları ve algoritmalar öğretip sınavda da 1000’den küçük asal sayıları bulan fonksiyonlar yazdırırken, bir test mühendisi açısından yazılım geliştirmenin anatomisinde bunların ne kadar komik göründüğünün farkında mısınız?

Ocak ve Şubat ayları içerisinde Türkiye’de olacağım. İstanbul, Bursa ve Ankara’da oturup birer kahve içip yanında sektörden, yazılım testi ve kalitesinden bahsetmek isteyenler bana ozay[nokta]civelek[at]gmail[nokta]com adresinden ulaşabilirler.

İyi Testler!

* Uzun saç konusunda David‘i hariç tutuyorum zira onun hiç bir zaman fazlaca saçı olamadı.

** CRUD : Create, Read, Update, Delete