Ultra Lüks

Biliyorsunuz yazılim sektörü sadece biz yazılımcılardan oluşmuyor. Bu sektörün proje yöneticisi, satış elemanı, testcisi gibi emekçileri de var. Bu meslek gurupları içinde teknik anlamda yazılımın nasıl yapılması gerektiğini bilen ya da bilmesi gereken biz yazılımcılarız. Bu sektördeki diğer meslek guruplarından bu konuda bir ümit beklemeyin.

Durum böyle olmasına rağmen, bir yazılım projesinin nasıl yürütülmesi gerektiği konusunda en az söz sahibi olan biz programcılarız. Bize gelene kadar birçok insan köklü bilgi sahibi olmadan yazılım projelerine yön veriyor, vermeye çalışıyor. Biz programcılar için yazılım kalitesi ön planda iken, ön planda olmalıyken, bu kişiler çok daha değişik parametrelerin gravitasyonuna kapılıp, açıkçası işi berbat ediyorlar. Bu şahısları motive eden en önemli faktör: “ürünü bir an önce satmak”.

Bir ürünü çabucak satmanın önündeki en büyük engel nedir? Cevap: zaman kaybı olarak algılanan aktiviteler. Hangi aktiviteler örneğin? Cevap: birim testleri yazmak, birlikte kod inceleme seansları yapmak (peer code review), sürekli entegrasyon vs. İnanmıyorum dercesine kafanızı sağa, sola salladığınızı görür gibiyim. Benim gibi bunların yazılım kalitesi açısında önemli aktiviteler olduğunu düşünüyorsunuz değil mi? Ama programcılar haricindeki diğer yazılımla ilgili meslek guruplarında böyle bir algılama ne yazık ki mevcut değil. Onlar için bu saydıklarım lüks, biz programcılar ise büyümeyi becerememiş ve istekleri bitmeyen şımarık çocuklarız.

Ellerinden gelse bizi hemen kapıya koyacaklar ama göbekten bize bağlı olduklarını bildiklerinden sesleri çıkmıyor. Bizim de sesimiz çıkmıyor. Arkadaş, yukarda saydığım aktivitelerin gerekliliğine inanmış, ama uygulanmadıkları yerde masaya yumruğunu vurup, “savulun ulan, biz bu aktiviteleri yapacağız, işinize gelirse“ diyen cesur bir programcı görmedim. Ağlamayan bebeğe kim emzik verir ki? Bize bu şekilde davranmaları ve anormal şartlarda çalıştırmaları normal!

Yukarda saymış olduğum aktiviteler modern yazılım pratiklerinden bazılarıdır. Nasıl bir duvar ustasının spatula, fırça gibi alet, edevatı olmadan çalışması zorsa, biz programcıların da bu pratikleri uygulamadan anlamlı sonuç üretmesi zordur. Ha, bu söylediklerim zaten günü kurtarmaya çalışanlara değil! Ben yazılım yapmayı bir bilim ve mühendislik dalı olarak görenler adına konuşuyorum.

Saydığım aktivitelerin lüks olarak görülmesini engelleyememişken, test güdümlü yazılım gibi aktiviteler nasıl algılanıyor sizce? Cevap: ultra lüks! Adam kafadan “iki programcı neden aynı işi yapsın ki, boşuna kaynak harcamam” diyor. Bak! Bak! Arkadaşım sana iki çift sözüm var: Birincisi biz kaynak değiliz, insan evladıyız, ikincisi şimdi sana test güdümlü yazılımın faydalarını anlatırdım, ama anlama kapasiten var mı bilmiyorum.

Zor! Gerçekten bu şartlarda, bu köhnemiş kafalarla beraber çalışmak çok zor. Bir dünya hayal ediyorum, içinde profesyonel programcıların mutlu, mesut oldukları, test güdümlü yazılım gibi pratiklerin ultra lüks değil de, gerekli oldukları düşünülen, proje gidişatını yetkin yazılımcıların tayin ettiği bir dünya. Ne yazik ki böyle bir dünya yok. Elimizdeki ile yetinmek zorundayız. Ama bu ara sıra masaya yumruğumuzla vuramayız anlamına gelmiyor.

EOF (End Of Fun)
Özcan Acar



Yazılım Hakkında Genel Düşünceler kategorisinden son yazılar

Share Button
0.00 avg. rating (0% score) - 0 votes

Etiketler: ,

One Comments

  • mabulgu

    20 Haziran 2012

    Çok önemli ve hassas bir konuya değinmişsiniz hocam. Mesele aslına bakarsanız sizin de bahsettiğiniz gibi deadline odaklı düşünmek, ki “aman çabuk bitsin” baskısı ile proje sürecinde yapmamamız gereken birçok şeyi yapabiliyoruz. Bunun en basit ve en çok tekrarlanan örneği kendini tekrar etmeme(DRY) prensibinde ortaya çıkıyor, ki kendimizi artık kopyalarken bulabiliyoruz.

    Bir yandan proje yetiştirmeye çalışırken diğer yandan kendimizi geliştirmeye çalışıyoruz, ki artık bu ikisi yaklaşım olarak birbirinden bir yerden sonra çok uzaklaşmış, proje geliştirme aşaması ile edinilen teorik bilgiler artık apayrı şeyler olmuş oluyor. Dolayısıyla teori teoride kalıyor, pratiğe dökemiyoruz maalesef. Bu günümüzde çoğu programcının yaşadığı bir sıkıntıdır muhakkak.

    Aslında bu biraz da şu odaklanıldığını söylediğim “deadline” meselesinin aslında yanlış hesaplanmasıyla ilgili. Yanlış diyorum çünkü TDD, CI, Code Review yapılan bir projede hata oranının düşüp, normalde bugfix’lerden kaybedilen zamanın çokca kazanılacağı hesaba katılmıyor. İnsanoğlunun hastalığı sanırım bu, yakın gelecekteki güzellikler hep daha uzaktakilerden – sanırım görülmeleri zor oldukları, görülemedikleri için- çok daha cazip geliyor, ve dolayısıyla doğru olan yaklaşım yakın geleceğe yönelik olanmış gibi gözüküyor. Bunu sınavlara hazırlanan öğrencilerin yakın gelecekteki(ya da o anki) bir keyfi, uzak gelecekteki bir güzelliğe(sınavı kazanıp iyi bir bölüm okuması) tercih etmesine benzetebiliriz. Arkadaşlarıyla gezer, televizyon izler vs. ama ders çalışmaz.

    Proje yönetimi meselesi için ise durum yine buna benzerdir. “Haydi bitirelim de canlıya geçirelim!”. TDD’den veya Code Review’dan bahsedildiğinde lüks sanılıp burun kıvırılır. “Önce canlıya geçelim, sonra başlarız”‘a döner olay. Aslında yazılımcının dediği yapılsa bir zaman sonra o an aceleyle geçilenden daha sağlam, kontrol edilebilir, daha az hatalı bir sistem çıkacaktır ortaya. Ama işte, bir anlatılabilse…

    Ben yukarıda bahsettiğim bu tabiri caizse hesap yanlışı sebebine “proje yönetiminde parametre eksikliği” diyorum. Onların biz yazılımcıları anlamaları da zor olduğundan maalesef iş yine bize düşerek o parametreyi bizim göndermemiz gerekiyor. Bunu da ancak biraz proje yönetimi dilinden konuşarak başarabilir, tüm hesap kitabı dökerek daha iyi aktarabiliriz diye düşünmekteyim.

    şimdi sana test güdümlü yazılımın faydalarını anlatırdım, ama anlama kapasiten var mı bilmiyorum.

    Mesele onların kapasitesini bizimkine yükseltmek değil, kendi frekansımızı onlarınkine ayarlamak olmalı diye düşünüyorum. btsoru.com’da naçizane fikrimi belirtmiştim:

    İletişimin öneminin farkındayım, iletişimi düzgün kurmalı, özellikle müşteri ilişkilerinde açık, net, geri bildirimli bir sistemi benimsemeliyim. Yazılımcı olarak çekingen ya da sıkıcı gözükmeme sebebiyet verebilecek teknik konuşmaları işletmeci/analist/yönetici diline çevirebilmeliyim. Başkalarını bu konuda teşvik etmeliyim. (Not:XP gibi yöntemlerin güçlü olduğu nokta iletişimdir. Yazılımcı bunu sağlar ve teşvik ederse, o firma XP gibi yöntemleri daha rahat uygulamaya koyabilecek konuma gelir.)

    İşte önermiş olduğum bu maddenin sebepler listesi arasına yukarıda bahsini ettiğiniz büyük problemi eklememiz bu durumda en doğrusu olacaktır.

    İletişimin öneminin farkındayım, iletişimi düzgün kurmalı, özellikle müşteri ilişkilerinde açık, net, geri bildirimli bir sistemi benimsemeliyim. Yazılımcı olarak çekingen, sıkıcı, BOŞ ya da LÜKS İSTEYEN BİRİ olarak gözükmeme sebebiyet verebilecek teknik konuşmaları İÇİNDE BULUNDUĞUM PROJENİN GELECEĞİ VE DOLAYISIYLA KENDİ KİŞİSEL VE KARİYER GELİŞİMİM İÇİN işletmeci/analist/yönetici diline çevirebilmeliyim. Başkalarını bu konuda teşvik etmeliyim. (Not:XP gibi yöntemlerin güçlü olduğu nokta iletişimdir. Yazılımcı bunu sağlar ve teşvik ederse, o firma XP gibi yöntemleri daha rahat uygulamaya koyabilecek konuma gelir.)

Bir cevap yazın