Page 1

1 - Yazılım Sektörünün Önündeki Engeller Türkiye'nin dünya piyasalarında daha katma değerli ürünlerle rekabet etmesi gerektiği son dönemlerde üzerinde çok durulan bir konu. Gerçi Türkiye ihracat alanında 2002 ve 2003 yıllarında önemli başarılara imza attı. İhracatımız 2002 yılında yüzde 12, 2003 yılının ilk üç ayında ise yüzde 33.2 arttı. Bu rakamlar ışığında hükümetin ihracat için 2003 yılı için koyduğu 39 milyar dolar hedefi gerçekleştirilebilir gibi görünüyor. Ancak, bu yeterli değil. 2002 yılında ihracatımızın yüzde 40.1'ini ara malları oluşturuyordu. Eğer katma değerli ürün ve hizmet ihracatımızı artırmayı başaramazsak, ihracat gelirlerimizi kısa vadede bu hızla artırmaya devam etmemiz mümkün değil. Bilgi ve İletişim Teknolojileri, en fazla değer sağlayan ürün ve hizmetleri sunması itibarıyla özel bir öneme sahip. Hindistan, İsrail gibi gelişmekte olan birçok ülke ihracatını Bilgi ve İletişim Teknolojileri'ne odaklanarak önemli oranda artırmayı başardı. Bizim de faaliyet gösterdiğimiz yazılım sektörü ise BT'nin en fazla değer yaratan alanlarından biri. Yazılım geliştirme, son derece kapsamlı ve karmaşık bir mühendislik faaliyeti. Bu nedenle yazılım sektörünün en önemli bileşenini kalifiye iş gücü oluşturuyor. Dolayısıyla bu sektörde dünya çapında rekabet edebilmemizin yolu eğitim kalitesinden geçiyor. Ancak bu eğitim, üniversitede sona ermiyor. Dinamik bir karakter taşıyan yazılım alanında, yaşam boyu eğitim bir zorunluluk. Yazılım geliştirme, genellikle yalnızca kod yazımından ibaret görülüyor. Oysa bu temelden yanlış bir yaklaşım. Tüm dünyada 377 bin üyesi bulunan ve 150 ülkede faaliyet gösteren meslek örgütü IEEE'nin bu konuda yön gösteren çalışmaları bulunuyor. IEEE'nin katkısıyla oluşturulan Yazılım Mühendisliği Bilgi Tanımı (Software Engineering Body of Knowledge SWEBOK) on ayrı kategoriyi kapsıyor. Konfigürasyon yönetimi, üretim, tasarım, mühendislik altyapısı ve mühendislik yönetimini kapsayan bu kategorilerin tümü, ortaya sağlıklı bir yazılım çıkması açısından önem taşıyor. Kodlama ise bu kategorilerden birinin alt başlığı konumunda. Bununla birlikte ülkemizdeki eğitim ağırlıklı olarak yazılımın uygulama ve kodlama yönüne odaklanıyor. Bu nedenle, ülkemizde yazılım geliştirme konusunda tüm SWEBOK kategorilerinin gereksinimlerini yerine getirecek iş gücü açığı bulunuyor. Türkiye'nin önde gelen yazılım evlerinden biri olarak bu konuya önem veriyor, öncülük görevini üstleniyoruz. Bu kapsamda düzenlediğimiz ve geçtiğimiz aylarda ilk dönemi sona eren VeriPark Staj Okulu Türkiye'de bir başlangıcı temsil ediyor. Staj Okulu'nda üniversite öğrencileri mezun olmadan önce kendilerini geliştirmeleri gereken alanlar hakkında kapsamlı bir şekilde fikir sahibi oluyor, en yeni, en güncel teknolojilerle tanışma fırsatını yakalıyorlar. Düzenli aralıklarla tekrarlamayı hedeflediğimiz Staj Okulu'nu diğer kurum içi eğitimlerden ayıran özelliği, üniversite öğrencilerine çalışma hayatına atılmadan önce sektörü tanıma olanağı sağlaması.


VeriPark olarak Staj Okulu'nu kurmamızda sektörün önemli bir sorununa çözüm getirmeyi hedeflemenin yanı sıra, deneyimlerimiz de etkili oldu. VeriPark'ın kurucuları ve ekibin büyük bir bölümü, Boğaziçi Üniversitesi'nin 1991 yılında düzenlediği Yaz Stajları'nda tanıştı. Sonuç olarak VeriPark ekibinin bir araya gelmesinde, Nesne Yönelimli Teknolojilerin tanıtıldığı bu staj programı önemli rol oynadı. Yazılım sektörünün gelişmesi ve dünya çapında rekabet edebilmesi açısından, yazılım mühendisliğinin tüm kavramlarının tanıtıldığı bu tür programların vazgeçilmez olduğuna inanıyoruz. Dileğimiz, bu tür programların sektör genelinde yaygınlaşması ve sektöre yeni katılanların tam donanımlı olarak çalışma hayatına atılmaları.

2- Bilişim Personeli Verimliliği ve Oturma Düzeni Yazılım geliştirme biraz sabıkalı bir etkinlik. Yazılım projelerinde maliyet, zaman ve kalite açısından her üç kriteri başarı ile sağlayarak tamamlanma oranı maalesef hiç bir zaman istediğimiz oranlarda değil. Çeşitli araştırmalar, projelerin sadece %15'inin bu üç kriterdeki beklentileri sağlayabildiğini gösteriyor. Yazılım projelerinin başarılarını başka kriterler açısından inceleyen benzer araştırmalar da pek iç açıcı sonuçlara ulaşmıyor. Yazılım projelerinin başarısının altında yatan en önemli etmenlerden biri, yazılım personelinin verimliliği. Bir proje ekibinin başarılı olmasında bir çok teknik, yönetimsel ve psikolojik neden rol oynuyor. Oldukça karmaşık olan bu ekip dinamiğinin arkasında ekibi oluşturan elemanların bireysel verimliliği ise bu etmenlerin sanırım en önemlisi. Yazılım personelinin verimliliği oldukça geniş değişkenlikler gösterebiliyor. Çeşitli araştırmalar bu değişkenliğin en iyi ile en kötü arasında 1'e 10'a kadar, hatta bazı yazılım geliştirme faaliyetlerinde 1'e 20'ye kadar çıkabildiğine işaret ediyor. Hemen hemen başka hiç bir disiplinde bu kadar geniş verimlilik değişkenliğine rastlanmıyor. Örneğin bu yazının yazarı ile dünya yüz metre rekoru sahibi bir koşucu arasında yüz metrelik yarışı tamamlama konusundaki "verimlilik" farkı sadece %200 civarındadır. Yazılım personeli verimliliği içindeki değişkenliğin bu kadar yüksek olması, aynı zamanda yazılım evleri arasında da verimlilik anlamında 1-11'e kadar varan farkların oluşmasına neden oluyor. Verimliliği etkileyen ve maalesef sıkça göz ardı ettiğimiz bir konu ise ofis yerleşimi. BT yöneticilerinin bence üzerinde durmaları gereken bir konu, BT elemanlarının oturma yoğunluğunun verimliliğe doğrudan etkisi olduğudur. Bu konuda Demarco ve Lister'in yaptığı araştırmalar, önemli gerçeklere ışık tutuyor. Bu araştırmalardan sanırım en ilginci oturma sıklığı ile gürültü arasındaki ilişkiyi inceleyen ve daha sonra da gürültü ile yazılım kalitesi arasındaki ilişkiyi inceleyen araştırmalar. DeMarco ve Lister'in bu konuda yaptığı çalışmalar, "Peopleware: Productive Projects and Teams (1999, Second ed., Dorset House)" kitabında yer alıyor.


Kitapta bahsedilen bir başka araştırma ise IBM'in Santa Teresa kampusünün mimarisi sırasında yapılan bir araştırmadır. IBM kampusü kurmadan önce bir çok mühendis, destek elemanı, yazılım geliştirici ve kalite kontrol elemanının çalışmalarını izleyerek minimum oturma düzeninin ne olması gerektiğini araştırmış. Araştırma sonuçlarına göre BT elemanlarının minimum çalışma koşullarının aşağıdaki gibi olması gerektiği sonucuna varılmıştır: • • •

Her çalışana 9.2 metre karelik bir oturma alanı, Her çalışana 2.8 metre karelik bir masa yüzeyi, 1.8 metre yüksekliğinde ya da kapalı ofis şeklinde bir gürültü önleme mekanizması kurulmalıdır.

DeMarco ve Lister yukarıdaki bulguları bir çok IT firmasının oturma düzeni ile karşılaştırmış, ama sadece %16'sında her BT elemanına 9.2 metrekarelik bir oturma alanı verildiğini bulmuşlardır. Genelde "tasarruf tedbirleri" nedeniyle ofis maliyetlerinde bir tasarrufta bulunulmakta, ancak bunun çalışan verimliliğine etkisi göz önüne alındığında bu tasarrufun özellikle yazılım geliştirme etkinliklerinde bizi zarara uğrattığı ortaya çıkmaktadır. Kısaca özetlemek gerekirse programcı verimliliğini etkileyen bir çok faktör bulunuyor. Bu faktörlerin önemli bir bölümü ofis ortamı ve gürültü ile ilgili. Firmaların ofis maliyetlerinden tasarruf etmek için yoğunluğu artırmaları bir çok çalışma türü için mantıklı olmasına rağmen BT kategorisindeki çalışmalar için ters etki yaratıyor. Bu şekilde ofis maliyetlerinden tasarruf edilebiliyor, ancak bu yoğunluk ve gürültü artışı BT personel verimliliğini düşürüyor. BT yöneticilerinin verimlilik ve ofis kullanımı arasındaki ilişkiyi inceleyerek temel prensipleri devreye almaları başarılı BT operasyonları için şart! Aksi durumda düşen verimlilik ve düşen kalite ile ilgili çözümü çok daha maliyetli problemler ile karşı karşıya kalınıyor.

3 - Yazılım Projelerinde Başarı Yazılım projeleri doğaları itibari ile oldukça zor projelerdir. Bu projelerin başarılı olup olmamalarını etkileyen onlarca kriter bulunmaktadır. Bunlardan ilk aklımıza gelenler yazılım ekibinin bilgi ve becerisi, iş kapsam ve tanımının tam olarak yapılıp yapılmadığı, seçilen yazılım geliştirme ortamının üretilmek istenen yazılım konusunda bir yetersizliğinin olmaması gibi kriterler. Bu kriterler konusunda bir çok istatistiksel ve sistematik inceleme yapılmaktadır. Ancak bu incelemerin ortak bir teması vardır: Acaba yazılımda başarı nedir ?


Yazılımda başarıyı, aşağıdaki üç konuda projenin beklenenleri sağlaması ya da daha iyi bir performans göstermesi diye düşünebiliriz: -Zaman planı - Maliyet - Kalite Zaman planı yazılımın çeşitli hedef noktalarına (milestone) belirlenen zamanda varılmasını ve hedefleri yerine getirmesini kapsar. Bir yazılım projesinde bulunması beklenen "analiz kapanış", "tasarım kapanış", "kod geliştirme kapanış" gibi hedeflere vaktinde ulaşılması buna örnek oluşturur. Bunun sağlanabilmesi, bu hedef noktalarına erişen proje aktivitelerinin her birinin vaktinde ya da daha erken bitirilmesi ile mümkün olmaktadır. Bu çerçevede zaman planına uymayı hedefleyen bir proje ekibinin odaklanması gereken iki nokta doğal olarak bu hedefin kendisi ve bu hedefe ulaşmak için gereken her aktivitenin zamanında bitirilmesidir. Maliyet ise yine proje tamamlandığında öngörülen bütçe sınırları dahilinde bu hedefe varmaktır. Proje tamamlanma noktasına gelmeden önce geçilmesi gereken hedefler vardır. Bu hedeflere erişmek için oluşturulan bütçelerin sağlanması ve bunun takibi, tüm projenin bütçe hedefini tutturmasında önemli bir rol oynayacaktır. Yazılım projelerinin kalite beklentisi ise iki boyutludur. Bunlardan ilki tamamlanan yazılımın başlangıçta belirlenen gereksinimleri ne kadar sağladığıdır. İdeal durumda projelerin tüm gereksinimleri yerine getirmesi beklenmektedir. Ancak çoğu durumda yazılım projeleri "hata" dediğimiz problemler ile birlikte tamamlanır. Bu nedenle kalitede başarıyı aradığımız zaman, bunun istenenleri tamamıyla yapmak ve ortaya çıkan sonucun, yazılımın müşterisi ve kullanım alanının kabul edebileceği bir hata düzeyinde teslim etmek olduğunu görüyoruz. Örneğin X ışınları üreten bir cihazı kontrol eden bir yazılımda bulunması kabul edilebilecek hata oranı, eğlence amaçlı bir yazılımdan çok daha düşük olacaktır. Yazılım endüstrisinde hataların sık sık dört kategoride sınıflandırıldığını görüyoruz: -Kabu edilemez (Show stopper) - Kritik önemli (Critical) - Önemli (Important) - Az önemli (Cosmetic) Projelerin kabul kriterleri sırasında özellikle yazılacak kod satır sayısının büyüklüğüne bağlı olarak yukarıdaki hata sayıları ile ilgili kabul kriterleri belirtilebilir. Yazılımın başarısnı bu şekilde saptadıktan sonra CHAOS çalışmasına değinmek istiyorum. ABD tabanlı Standish Group (www.standishgroup.com) tarafından yapılan bu


çalışma ile her yıl binlerce yazılım projesi yukarıda belirlenen kriterler bazında sorgulanmaktadır. Bu grubun 1994 - 1998 yılları arasında yaptığı çalışmada 23 bin yazılım projesi incelenmiştir. 1994 yılında projelerin sadece yüzde 16'sı bu üç kriteri yerine getirerek başarılı kabul edilebilmiştir. Aynı grubun geçen yıl yaptığı çalışmada ise bu oranın yüzde 34'e çıktığı gözlenmiştir. Tahminen bu artışın nedeni, yazılım geliştirme endüstrisinin proje yönetimine verdiği önemin artmasıdır. Geçen süre içerisinde bu konuda kazanılmış bilgi ve deneyimin de artmış olması da nedenler arasında gösterilebilir. Görüldüğü gibi yazılım projelerinde başarı oranı istenen düzeylerin halen oldukça altındadır. Bu oranın yukarı çekilmesi ile ilgili yapılması gerekenler uzun bir süreden beri bilinmekte, ancak uygulamada problemler yaşandığı için bu kadar düşük başarı oranları ile karşılaşılmaktadır. Peki bizim kendi dahil olduğumuz projelerde başarı oranını nasıl yüksek tutabiliriz ? Sanırım bu sorunun birden çok doğru cevabı vardır. Bu doğru cevapların hepsinin ortak noktası bir an evvel yazılımda başarı ve bu başarıyı etkileyen faktörler konusunda bilgi edinmektir. Başarılı yazılım geliştirmek için tüm geliştirme ekibi olarak proje yönetimine daha fazla odaklanmalıyız. Başarıyı etkileyen kriterler hakkında bilgi sahibi olup, bunlara dikkat edilen bir proje yaklaşımı ile yazılım geliştirmeliyiz.

4 - Yazılım geliştirmeye değişik bir bakış... Programcılıkta sabahlamanın verdiği huzur ve tatmin çok meşhur. Programcılar sabaha kadar çalışma konusunda herkesi şaşırtan derecede istekli ve beceriklidir. Bu gece çalışması boyunca beyin bir "akış" yakalayarak saatlerin su gibi geçtiği bir çalışma ortamı oluşur. Bu çalışma sırasında beyin en derin konsantrasyon düzeylerine erişir ve genellikle zor programlar bu kesintisiz, onlarca saat süren çalışmalarda ortaya çıkar. Beyin bu stilde çalışırken kişilerin mutlu oldukları, mutluluk düzeylerinin arttığı bilimsel çalışmalarla gözlemlenmiştir. Bu çalışmalar eski Chicago Üniversitesi Psikoloji Bölüm Başkanı Mihaly Csikszentmihalyi tarafından yapılmıştır. Çalışmalarda çeşitli disiplinlerden yüzlerce kişinin günlük uğraşları incelenmiş ve bu sırada "mutluluk" düzeyleri gözlemlenmiştir. Bu çalışmaların programcılar tarafındaki bulguları ise ilginçtir. Her ne kadar programcılık bir bilim dalı (Computer Science), bir mühendislik (Software Engineering) olarak düşünülse de programcıların beyninin sanatçıların çalışma stiline sahip olduğu ortaya çıkmıştır. Programcılık sırasında beyin bir "akış" moduna geçmekte, etraftan ilişkisini kesmekte ve bir probleme günlerce konstantre olabilmektedir.


Başarılı programcıların çoğu konsantrasyon yetenekleri ile çevrelerini şaşırtır. Saatlerce sıkılmadan bir ekran başında vakit harcayabilirler. Bu saatler bir çok kez günlere kadar uzayabilir. Yaşamsal faaliyetler dışında hemen hemen her şeyden izolasyon gereklidir. Microsoft'ta Office yazılım geliştirme ekibinden bir programcının kendini odasına kilitleyip "bitmeden çıkmayacağım" demesi, Bill Gates'e bile kapıyı açmaması meşhurdur. Bu olay daha sonra Douglas Coupland'ın Microserfs (1996) kitabına konu olmuştur. Bu sırada kendini odaya kilitleyen programcının arkadaşlarının süper marketten gidip yassı yiyecekler alması ve kapının altından odaya atmaları, programcılar arasındaki dayanışmanın güzel ve sevimli bir örneği. Bu çalışma sırasında programcı en derin düşüne moduna geçer ve etraftan kendini izole etmeye çalışır. Bir çok programcı bu amaçla müziği kullanır. Ancak müziğin programcılık sırasında beyne olan etkileri üzerine yapılan çalışmaların bulguları şaşırtıcıdır. Kreatif programlama ile müzik dinleme sırasında kullanılan beyin bölgesi aynıdır. Beyin bir müziğe konsantre olmuşken çok derin programcılık yapılamıyor. Ya da yeteri kadar iyi yapılamıyor. Programcının müziği kapatınca etraftaki gürültünün etkisi ile müziği dinlediğinde beynin gerekli bölgesinin meşgul edilmesi arasında bir tercih yapması gerekir. Tahminen bu nedenle izolasyon amaçlı müzik kullanımında elektronik müziğin, hard rock, alternatif rock ve heavy metal gibi müzik türlerinin daha fazla tercih edildiği görülür. Müzik, beyin ve programcılar üzerinde çalışmalar halen sürüyor, bu derin konu araştırılmaya devam ediyor. Şu anki bulgular, kritik kodların geliştirilmesi ve müzik dinleme sırasında kullanılan beyin bölgelerinin aynı olduğunu gösteriyor. Monoton kodlama (maintenance) diyebileceğimiz program geliştirme kısmı ise beynin başka bir bölümünde gerçekleşir. Bu tür kodların geliştirilmesi sırasında müziğin programlamaya herhangi bir negatif etkisi görülmemiştir. Programcının kritik kodları yazmak için ihtiyaç duyduğu "akış" modunu koruyabilmesi için izolasyona ihtiyacı bulunur. Bu izolasyon arttıkça çalışma derinleşir, ilk önce beyinde yazılmak istenen programın çatısı oluşur, problem önce beyinde çözülür, daha sonra beyinde çözülen bu problem koda çevrilir. Programcının beyni pencereden dışarıyı seyrederken ya da gözler sabit bir yere bakıp dalıp gittiği zaman bu problem çözülmeye çalışılır. Hatta programcının beyni bu problemi uyurken, araba sürerken ve diğer başka monoton işleri yaparken ele almaya devam eder. Bu durumda sıfırdan ve baştan yazılan bir programa bakıldığında kodlama toplam sürenin oldukça az bir bölümünü almaktadır. Bu çalışma sırasında beyin son derece karmaşık bir aktivite içerisine girmiştir. Var olmayan bir çözümü oluşturmak için "kreatif" süreç başlamıştır. Bu süreç duyu organlarını izole etmiş ve yaratıcılığa yoğunlaşmıştır. Bu süreç sırasında programcı onlarca konuda karar vermektedir. Değişken isimlerinden, akış yöntemlerine, parametrelerin cinsinden, kullanıcı ara birimine kadar bir programcı sürekli bir "karar alma" uğraşısı içerisindedir. Programcılar bu nedenle bir günde yüzlerce kararın altına imza atma becerisine sahip iyi birer karar vericidirler. Tam bu yoğun programlama sırada birisinin programcının omzuna dokunduğu zaman bir "ara verme" operasyonu başlar. Bu ara verme operasyonu tam gaz giden bir arabada


aniden frene basma gibidir. Derinleşen "kreatif" süreç derinliğini yitirir ve duyu organları "açılarak" omuza dokunan kişi ile iletişime geçilir. Bu geçiş çoğu zaman o kadar kolay olmamakta ve programcılar bu nedenle zor iletişim kurulan kişiler olarak görülmektedir. Bir soru sorulmaktadır. Eğer bu soru şu an üzerinde çalışılan konuyla ilgili ise mevcut kreatif süreç bu soruyu cevaplamakta kullanılır. Sorunun "bağlam" ile ilgili olması, sürecin durdurulmasını gerektirmez. Örneğin bir veri tabanı tasarımında yandaki programcı bir tablodaki alanın ne işe yaradığını sorduğunda süreç durdurulmadan cevap verilebilir. Cevabın verilmesi için gerekli bütün malzeme, zaten o sırada beynin çalışma bölgesine getirilmiş hazır halde bulunmaktadır. Ama eğer bu soru bambaşka konularla ilgiliyse: "Bu iş ne zaman bitecek"ten tutun da , "dün maçı seyrettin mi?" ye kadar değişik açılardan gelen bir soru olabilir. Bu durumda ancak bu kreatif süreç durdurularak bu soruya cevap verilebilmektedir. Ya da çoğu programcı bu soruyu "duyacak" ama "algılamayacaktır". O an durumu kurtaracak bir cevap vereceklerdir: "yarına biter" vs gibi. Yapılan basittir: kreatif süreç bölünmeden çalışmaya devam etmek istenmektedir. Bu sırada soruyu soran kişi doğal olarak programcıların zor iletişim kurulan kişiler olduğunu düşünecektir. Oysa programcının beyni hız kesmemeye çalışmaktan başka bir şey yapmamaktadır. Programcılar çoğu zaman konuşmayı pek sevmeyen ve zor iletişim kuran kişiler olarak bilinmektedir. Bu yanlış inancın temelinde, programcıların konsantre olma yetenekleri ve bölünmelere karşı geliştirdikleri iletişim "önlemleri" yatmaktadır. Oysa yazılım geliştirme ekipleri oldukça konuşkan olabilirler. Fark konuşulan konularda yatmaktadır... "Windows mu iyidir, Linux mu?" tartışmalarını dinleseniz programcıların az iletişim kurdukları konusundaki fikirleriniz tam tersi yönde değişecektir. Eğer bölündüğü sırada programcı soruyu tam olarak algılayıp doğru bir cevap vermeye çalışırsa, soru "bağlam" dışı ise kreatif sürecin durması gerekmektedir. Duran bu akışın yeniden eski kaldığı noktaya geri dönebilmesi, kişiye çok bağlı olmakla beraber, on beş dakikaya kadar çıkabilmektedir. Konsantre olma yeteneği yüksek olan programcılar bölünen bu süreci daha hızlı bir sürede eski noktaya getirebilmektedir. Programcılık sırasında beynin bu çalışma stilinin anlaşılması programlama ortamlarının ne kadar özenle seçilmesi gerektiği konusunda önemli ipuçları sağlamaktadır. Programcıların bu bölünmelerden korunması gereklidir. Daha da önemlisi programcıların kendilerini bu bölünmelerden korumaları gerekmektedir. Csikszentmihalyi ve ekibin yaptığı çalışmalar bu derin çalışma sürecinin ne kadar kırılgan olduğunu ve izolasyona ihtiyaç duyduğunu açığa çıkarmaktadır. Kanımca bir çok yazılım hatası (bug) bu bölünmeler sırasında ortaya çıkmaktadır. Televizyonda bir motor yağı reklamını izlediğimi hatırlıyorum. Reklamda "motor ısınıncaya kadar olan sürede aşınır yıpranır oysa bu motor yağı mıknatıs özelliklerine sahiptir ve


motor çeperine yapışık kalarak ısınma sırasında bile motorun yıpranmasını önler" diyordu. Bu reklamda anlatılan olayı programcılıkta çok gördüğümüzü düşünüyorum. Yeteri kadar ısınmadan, soğuk bir "beyinle" yapılmaya başlanılan programcılık sonucunda oldukça "hatalı (bogus)" kodlar üretildiğini düşünüyorum. Meslek hayatımda karşılaştığım binlerce yazılım hatasını masaya yatırdığımda bu tür hatalarla karşılaştığımı görüyorum. Hataların bu kreatif sürecin hangi aşamasında yazılmış olabileceğini tahmin etmeye çalışıyorum. Bir programcı bölünme ile karşılaştığı zaman -üstelik bu bölünme bir SMS mesajı yazmak gibi zor ve zahmetli olup, beyni oldukça uğraştıran cinsten ise- programlama sürecinin beyinde eski aktivite düzeyine yükselmesi çoğu zaman yaklaşık 15 dakika sürecektir. Bu süreç sırasında hatasız bir kod üretimi için programcının kritik bir kod yazmaması gereklidir. Konsantrasyonun tam sağlanamayacağı bu ısınma dönemi, unutulan kontroller, atlanan olasılıklar ve hiç kodlanmayan program akış dallarına neden olacaktır. Çağımızda bu bölünmelerin başlıca sebepleri cep telefonları, gelen SMS mesajları ve Instant Messaging programlarıdır. Bölünmemek için iletişimsizliğe ihtiyacımız varken çağımız bir iletişim çağı olmuştur. Watts Humprey, Software Engineering Institute tabanlı Personal Software Process'in (Kişisel Yazılım Süreci - PSP) geliştiricilerinden birisidir. Kendisi uzun yıllar IBM'de çalışmış, OS390 projesinde yer almış ve yazılım geliştirmenin önemli duayenlerinden birisi olmuştur. PSP bir programcının iyi program yazması konusunda kendini nasıl geliştireceğinin ana hatlarını çizer. Humprey'in PSP'yi anlattığı "Introduction to PSP" kitabını aldığımda şaşırdığım bir konu olmuştu. Kitabın ilk bölümlerinin zaman yönetimi ve bu bölünmelere karşı mücadele olduğunu görüp şaşırmıştım. Humprey, programcıları bu bölünmelerle mücadele konusunda bilinçlendirmeye çalışıyordu. Yazılım geliştirme sürecinin tam verimiyle çalışması için bu sürecin korunmaya ihtiyacı olduğu çok açık. Bir programcının etrafında oturanlar, yöneticileri, ona SMS gönderenler bu sürecin geç cevap alacaklarının farkında olmalıdır. Böyle bir zihinsel durumdaki yazılım geliştirmeciyle olan iletişim senkron (eş zamanlı) değil asenkron (farklı zamanlarda) olmalıdır. Şu sıralar programcılıkta popüler olan yeni bir akım var. Entegre edilen sistemlerin birbirleriyle senkron bağlantılar yerine "loosely coupled" (gevşek eşleştirme) dediğimiz asenkron yöntemlerle bağlanması. Sanırım "akış" anını yakalamış bir programcı ile iletişimin de en sağlıklısı "loosely coupled" türden olacaktır.


5 - Yazılım Geliştirmede Aşırı Çalışma Geçen gün Marmara Üniversitesinde Bilgisayar Mühendisliğinde okuyan Vedat Güneş isimli bir öğrenci ilginç bir yazı ulaştırdı. Yazının yazarı çok çalışmaktan bıkmış ve usanmış bir an önce emekli olup tarımla uğraşmayı istiyordu. Programcılığın aşırı çalışma konusunda oldukça zor bir meslek olduğunu belirtiyordu. Yazının ana fikrine katılmamak mümkün değil. Kim hayatının önemli bir kısmını bilgisayar başında, sosyal bir hayattan yoksun geçirmek isteyebilir. Yazının katılmadığım noktası ise her programcının kaderinin aynı olduğu izlenimi vermesi idi. Tanıdığım bir çok iyi programcı son derece gelişmiş bir sosyal çevreye, hobilere, kaliteli ve dengeli bir özel hayata sahip. Belki bu dediğim noktaya benim tanıdıklarım 30'larında geldiler ama en azından bu mesleğin asosyallik, aşırı çalışma ve kötü hayat koşulları ile ilişkili olduğu ile ilgili genel inanışının aksine tersi örneklerdir. Hiç birimiz gece gündüz, dur durak vermeden çalışmak istemeyiz. Zaten çalışamayız. Çalışsak da üretim kalitemiz düşük olur. Günün sonunda pek akılcı bir iş yapmış olmayız. Ancak hepimiz programcılık kariyerimizde kim bilir kaç kez gece gündüz, bayram, hafta sonu demeden çalıştık. Peki neden bu durum ortaya çıkmakta? Bu durumun nedenlerine girmeden önce aşırı çalışma ile ilgili bir konuyu açığa getirmek istiyorum. Programcılar başarma duyusu yüksek, azimli ve çalışkan kişiler. Bunlardan birinin eksik olduğu durumda kişiler üç ay programcılık yapıp bu mesleği terk ederler. Bu üç kişilik özelliği bir araya geldiği zaman ise ilginç bir çalışma disiplini oluşur. Bu disiplin de çoğu zaman mesai saatleri sonrası çalışmayı doğurur. Bu yazıda aşırı çalışma problemi kişinin "kendi isteği" dışında "gönüllü olmayarak" yapılan çalışmaları anlatmakta. Bu ayırıma dikkat. Ben yazılım geliştirmeyi çok severim. Fırsat bulduğumda da bir kaptırırsam saatlerce yazardım. Temel amacımız multu olmaktır. (Bknz. Aristo). Çalışma ile mutluluk arasında yüksek bir korelasyon vardır. Bu yazıda bahsedilen aşırı çalışma problemi, çalışırken kendimizi "mutsuz" hissetiğimiz durum. Bir çok developer gece gündüz çalışırken mutlu hisseder. Keyif alır. Yaratıcılığın zevkini tadar, vaktin nasıl geçtiğini bilmeden sabahlar. Bu dışarıdan aşırı çalışma gibi görünse de, konuya yabancı olanlar durumun vehametine üzülse de, bu aşırı çalışma değil tam tersine "çalışmaya doyamamak" tır. Bu yazıda bahsedilecek olan aşırı çalışma "gönülsüz", "isteksiz" ve bize mutluluk değil tam tersi duygular uyandıran, bu mesleği ve yaptığımız işi sorgulatan çalışmalar. Modern yazılım geliştirme yaklaşımları bu problemden kurtulmayı başarmıştır. O nedenle bu problemden kurtulmak için hem umut hem de elimizde onlarca örnek var. Bu yazının amacı da bu konuda birey olarak bizlerin neler yapabileceğine ışık tutmak.


Eğer bir projede aşırı çalışma gerektiren koşullar oluşmuşsa, kişilik özelliklerimiz nedeniyle, organizasyon yapımız ve başarma isteğimiz nedeniyle hepimiz aşırı çalışmayı seçiyoruz. Bu seçim o an yapılabilecek tek doğru seçim. Bununla ilgili kendimizi kötü hissetmemiz, olayı bir hayat böyle geçer mi, üç aydır hafta sonları buradayım gibi büyütmek yersiz, gereksiz ve hatta hatta o projenin o an bulunduğu kritik ortamında oldukça zararlıdır. İlk önerim bu olaya takılmamaktır. Bu bir kader değil, aksine basit yöntemlerle çözülebileceği artık bilinen tipik bir problem. Aşırı çalışma gerektiren koşullar oluşmuşsa, ne yazık ki, bu koşulları ortadan kaldırıncaya kadar aşırı çalışmak zorundayız. Başka bir yaklaşım düşünülemez. Aksi bir tutum hem kendi huzurunuzu bozar, hem proje ekibinin moralini bozar, hem de projeyi riske atar. Bir kişinin mutsuz yaklaşımı genele yayılan bir isteksizliğin nedeni olabilir. Bir an önce gece gündüz çalışılıp söz konusu "koşulların" eritilmesi ve normal sağlıklı çalışma koşullarına dönülmesi gerekir. Esas olayımız bundan sonra başlar. Neden aşırı çalışmanın koşulları oluşmuştur ve esas önemlisi bunların bir daha oluşmaması için neler yapmalıyız? Bu soruların incelenip cevaplarının verilmesi gereklidir. Aşırı çalışmanın nedenlerine baktığımızda bu nedenleri dört grupta toplayabiliriz: a) Satış sürecinde verilen sözler b) Proje yönetim sürecinde verilen sözler, alınan kararlar c) Kişi ve takım kaynaklı nedenler (çalışma şekli, yetkinlikler, motivasyon gibi) d) Çalışma ortamının gürültülü ve verimsiz olması Bu yazıda insan kaynaklı nedenlere eğilip, bunların içinden de kişi kendisi ile ilgili neler yapabilir bir kaç öneride bulunacağım. Diğer grupta bulunan nedenler de oldukça önemli. Ben genel olarak iğneyi başkasına çuvaldızı kendine batırmayı seven birisiyim. Aşırı çalışma koşullarının oluşması durumunda satış sırasında verilen sözler, müşterinin ve bizim proje yönetimi konusunda deneyimsiz oluşumuz gibi etmenler çok önemli rol oynar. Bu konuda ayıca kendi üzerimize düşen çeşitli ödevler de bulunur. Bunları bir liste halinde vermeye çalışacağım. Ancak problemin satış ve proje yönetimi tarafını boş bırakıp sadece aşağıdaki liste ile çözmeye çalışmak yeterli olmayacaktır. Aşırı çalışmanın önlenmesi için on öneri: 1. İşinizi sevin. Başarının önemli bir kısmı işinizi sevmekte yatar. Yaptığınız işi sevmiyorsanız hemen o işi bırakın. İşinizi sevmiyorsanız aşırı çalışmak kaçınılmaz. Hem sevmeyip hem de aşırı çalışıyorsanız mutsuz olacağınız da ortada. O işi yapmayı bırakarak hem kendinize hem de iş arkadaşlarınıza büyük bir iyilik yapmış olacaksınız. Zorla güzellik olmaz, sevmiyorsanız, çok uğraşmayın, başka bir mesleğe geçiş yapın. 2. Planlı ve programlı çalışmayı öğrenin. Bir programı yazarken vaktinizin en büyük bölümü analiz ve tasarıma geçmeli. Aksi takdirde sürekli bir kod yaz, test et, hataları düzelt döngüsü şeklinde geçecektir. Önümüzdeki hafta ne ile uğraşacağınızı şimdiden planlayın,


yapılması gereken işler varsa onları şimdiden planlayın. PSP (Personal Software Process) eğitimlerinden sonra eğitime katılanların hata yoğunluklarının dört kat azaldığı gözlemlenmiştir (Bknz. http://www.stsc.hill.af.mil/crosstalk/1998/03/dimensions.asp). Dört kat daha az "bug" aşırı çalışma problemini kökünden çözecektir. Çalışma şeklinizi PSP'deki gibi iyileştirin. 3. Tahmin yeteneğinizi geliştirin - "Estimation" - bir işin ne kadar süre alacağı konusundaki tahmin yeteneklerinizi geliştirin. Bir işin yapılma süresini normalinden az tahmin ederseniz malasef gecelemekten başka çareniz yok. İşi teslim etmemek de tabiki bir seçenek ancak bu yazı başarmayı prensip edinmiş developer'lara yönelik olduğu için başka çareniz yok diyorum. Tutarlılık prensibi gereği verdiğiniz sözü tutmaya çalışacak, kendinizden başka sorumlu tutacak kimse olmadığı için de bu bizi mutsuz edecek. Oysa sizin mutlu olmanız gerekli. Dünyanın en zevkli işini yapıyorsunuz. Tahmin yetenekleriniz iyimserlik, bilgisizlik ya da plansızlık nedeniyle yanlış tahminler üretiyor olabilir. Önerim bu işi keyifle yapabilmek için tahmin becerilerinizi geliştirin. 4. Bölünmelerle mücadele edin. Sizi bölen kişilere o an musait olmadığınızı söyleyin. Sabah 9 ile 10 arasını bu plansız bölünmelere ayırmaya çalışın. Sizi bölen kişiye bu tür çalışmaları belirtilen saatte yaptığınızı söyleyin. Hatırlar mısınız, üniversitede öğretim üyelerinin "ofis saatleri" vardı. Öğretim üyeleri her zaman bölünmek yerine haftanın belli sürelerini "bölünmeye" ayırırlardı. Aynı taktiği siz de uygulayın. Gerekirse "iletişimsizlik" için kulaklık takın, kapalı bir odaya geçin. Bölünmemek için gece çalışmayı seçmeyin onun yerine bölünme ile mücade etmeyi seçin. Bu amaçla arkadaşlarınızdan ve yöneticilerinizden yardım isteyin. Yöneticiniz sizi bölüyorsa bunu ona nazikçe ama mutlaka ve mutlaka söyleyin. Cep telefonunuzu, MSN'i, e-mail programınızı program yazarken mutlaka kapatın. 5. Önceliklendirin. Üzerinizde yapılması gereken onlarca iş olabilir. Bu işlerin her birisinin düne bitmiş olması gerekiyor olabilir. Panik olmayın, stres olmayın. Bir öncelik sırası verin, sırasıyla bu işleri yapın. Aynı anda birden fazla işi yapmaya kalkmayın kalite düşebilir. Onun yerine hakkını vererek teker teker işleri yapmaya odaklanın. İşler düne yetişmesi gerekiyordu ise malasef aşırı çalışma moduna geçmemiz gereklidir. Bu moda geçip yüksek öncelikli işleri aradan çıkarın. Savaş alanında yaralılar sıraya dizilir, en acil durumdakine tıbbi hizmet verilir, sırayla diğerlerine geçilir. Böyle bir durumda doktor aşırı çalışır. Ama tahmin ediyorum bu durumda mutsuz olmaktan daha ciddi işleri olduğu için aşırı çalışmayı sorgulamaz. Aşırı çalışırken yanlış önceliklendirme yapılmamalıdır. Bu doktorun önceliklendirme hatası can kaybına neden olacaktır. En önemli problemleri öne alın. Bir çok projede önceliklendirme hataları yapılmakta, düşük öncelikli işler için sabahlanırken, önemli işler için yorgun beyinler, ağrıyan bilekler ve uykusuz gözler kullanılmaktadır. Siz öyle yapmayın.


6. Kod becerilerinizi arttırın. Bu amaçla başka programcıların yazdıkları kodları inceleyin, onların yöntemlerini öğrenin. Dört dörtlük teknik becerilere sahip olmalısınız. Bol bol başkalarının kodunu okuyun. 7. Sıfırdan yazmayın, re-use etmeye çalışın. Devraldığınız kod kötü olabilir, iyi tasarlanmamış olabilir. Oturup bunu baştan yazma konusunda hemen karar vermeyin. Bunu yöneticilerinizle, etraftaki arkadaşlarınızla tartışın. Kodu yazan kişi ile konuşun. 8. Over design yapmayın. Her projenin gereksinimleri, kalite beklenti düzeyi farklı farklıdır. 300 kişinin kullanacağı bir web uygulamasını on binlerce kişi kullanacakmış gibi "stateless" ve "n-Tier" bir mimaride yazmaya çalışmayın. Her projeyi mümkün olan en sade şekli ile en basit formda yapmaya çalışın. "Simplicity- the art of maximising work not done- is essential" temel prensibiniz olsun. İş tatminini, süper mimariler, algoritmalar ve müthiş uygulamalar yerine memnun müşteriler, söz verildiği sürede biten projeler ve tasarımsal sadelikte bulmaya çalışın. 9. İletişim yeteneklerinizi arttırın. Örneğin kibarca nasıl "hayır" denilir öğrenin, bir isteğinizi elde etmek için nasıl müzakere etmeniz gerekli öğrenin, analiz dokümanı nasıl yazılır, bir toplantı nasıl yönetilir öğrenin. İyi bir dinleyici olun. Çok soru sorun. İyi dinlemeyip çok soru sormazsanız ne programı yazmanız gerektiğini çok geç fark edersiniz. Anlamadığınız bir iş atamasını kendi başınıza yorumlamak yerine gidip iş atamasını yapan ile konuşmayı, programınızı kullanacak kişi ile arkadaş olmayı, bu kişiye sabahları günaydın diyip, hatrını sormayı öğrenin. Müşterinizi sevin. Müşterinizin sizi sevmesini sağlayın. Şirinlik yapın. İletişimde ukala görünmekten kaçınıp, alçakgönüllü olun. Kişiler sevdikleri kişilerin işlerini kolaylaştırmaya çalışır. Sevmedikleri kişilerin işlerini yokuşa sürer, geri plana iter. Sizi sevdiklerine emin olun. İletişim bir araçtır. Compiler'inizi nasıl kullanmayı biliyorsanız, iletişim denilen aracı da bir compiler gibi kullanmayı bilin. Sadece bu madde başlı başına bir kitap konusu bile olabilir. Kısaca iletişim yeteneklerinizi geliştirin. 10. Bol bol okuyun. Dünyanın en zevkli işini yapıyorsunuz. Bu iş nasıl yapılır, nasıl yapılmaz okuyarak öğrenin. Proje yönetimi, zaman yönetimi, bilgi güvenliği, user interface design, psikoloji okuyun. Okuduklarınızı paylaşın. Etrafınızda bu mesleğin bir kültürünün oluşmasını sağlayın. Steve McConell, Tom De Marco, Watts Humprey, Bruce Tognazzi'yi okuyun. ACM'e üye olun. Seminerlere gidin. Kendinizi yetiştirmeye önem verin. 2004 yılındayız. Hala daha annenizin yöntemleri ile program yazmaya devam etmeyin.

Yukarıdaki liste bu problem konusunda kendimize düşen ödevleri göstermekte. Proje yönetimi, satış süreci ve diğer yönetim süreçleri bu probleme neden olabilir. Çalıştığınız ortamdaki satış ve proje yönetimi süreçlerinde bu soruna karşı önlemlerin alınması


mutlaka gerekli. Bu amaçla talepkar olun. Bulunduğunuz ortamın satış ve proje yöneitm süreçlerinde gerekli kontrolleri içermesini isteyin. Kanımca bunların içinde en önemlisi verilen taahütlerde ve sözlerde sizin onayınızın alınmasını istemektir. Çalışma ortamınız konusunda ise tüm takım arkadaşlarınız ile beraber hareket etmelisiniz. Aynı odada çalışıyorsanız karşılıklı konuşmaların olmaması, ortamın bir kütüphane sessizliğinde olması gerekli. Dikkatinizi dağıtacak geri plan sesleri ve düzenli gürültüler az olmalı. Sanırım kütüphane sessizliği bir program yazmak için gereken ideal ortamı çok iyi anlatıyor. Aşırı çalışma, bu meslekte kemikleşmiş, kronik bir sorun hatta hatta kaçınılmaz bir kader değil. Şu ana kadar onlarca yazılım geliştirme organizsayonunda yüzlerde developer ile çalışma şansı buldum. Yetkinliklerini arttırmış, planlama ve tahmin becerilerini geliştirmiş ekipler bu problemi çok kolay bir şekilde aşmıştır. Özellikle yurt dışında bir çok yazılım evinde bu problem artık halledilmiştir. Yeter ki bu konuda herkeste ortak bir bilinç oluşmuş olsun, bu problemin basit yöntemlerle çözülebileceği inancı yerleşmiş olsun. İşinizi ve çalışmayı sevmeyi son bir kez daha kendimi tekrarlamak pahasına da olsa hatırlatmak istiyorum. Sakıp Sabancı'yı kaybettik. Röportajda soruyorlar, başarının sırrını neye borçlusunuz diye. Cevap çok güzel: "Sevmek, sevmek, sevmek. Vatanını sevmek, milletini sevmek, işini sevmek." Hepinize severek geliştirilen kodlar diliyorum.

Yazılım Geliştirme  

Yazılım Geliştirme

Read more
Read more
Similar to
Popular now
Just for you