Programcı Psikolojisi ve Yazılım Kalitesi

Aslında programcı psikolojisi malesef yazılım dünyasında üzerine çok da eğilinen bir konu değil. Halbuki, programcılar ve developerlar, sonuçta yazılımın esas çalışan kısmını, executable codeu, üretenler kişilerin nasıl düşündükleri, işlerini yaparken hangi düşünsel süreçlerden geçtikleri, bu kadar zor, odaklanma isteyen ve çok yönlü ve faktörlü, matematiksel bir işi yaparken neleri, nasıl göz önüne aldıkları son derece önemli.

Takip edebildiğim kadarıyla, aslında pek çok psikolojik ve bilişsel (cognitive) akademik ve uygulamalı çalışmalara konu olabilecek zengin bir alan olmasına rağmen ben bu konuda aktif bir çevre pek yok. Gerald Weinberg’in ünlü “Psychology of Computer Programming” dışında özel olarak bu konuya hasredilmiş pek bir çalışma yok gibi. Ama ben bu yazıda bu konuda yapılmış eski de olsa son derece yol gösterici bir çalışmadan bahsetmek istiyorum.

1976 yılının Şubat ayında, “Human Factors: The Journal of the Human Factors and Ergonomics Society” isimli dergide, G. Weinberg ve E. L. Schulman “Goals and Performance in Computer Programming” başlıklı bir makale yayınladılar. Bu makale aslında onların, programcılar üzerine yaptıkları deneysel bir çalışmayı anlatıyordu. Kısaca özetlemek gerekirse deney şöyle: Programcılardan oluşan 5 farklı takıma aynı programlama görevi verilir. Görev, Gaussian eleminasyon yöntemini kullanarak bir lineer denklem takımını çözecek programı yazmaktır. Fakat, görevle birlikte her takıma, yazacakları programın kalitesiyle ilgili birer de hedef verilir. Örneğin bir takıma en az çalışmayla bu görevi bitirme hedefi verilirken diğer takıma en az statement kullanarak programı yazmaları söylenir. Diğer hedefler ise, en az bellek kullanmak, en rahat anlaşılır kodu (clearest code) yazmak ve en rahat anlaşılır çıktı (clearest output) üreten kodu yazmaktır.

Takımlar görevlerini başarıyla bitirirler. Beş takımın dördü, kendisine verilen hedef açısından en iyisini yapmıştır, bir takım ise hedefinde 2. olmuştur. Yani takımlar programlama işini yaparken kendilerine verilen kalite hedeflerini tutturmuşlardır denebilir. İlginç olan taraf burası değil, diğer sonuç: Takımlar, kendilerine verilen hedef dışındaki diğer kalite konularında tutarsız bir şekilde davranmışlardır. Yani hedefleri olan dolayısıyla da odaklandıkları noktalarda çok iyi performans gösterirken, diğer takımların kalite noktalarında ciddi şekilde çuvallamışlardır. Bu durumu aşağıdaki tablo iyi bir şekilde gösteriyor.

Yukarıdaki tablodaki sonuçlardan, her takımın kendi hedefi olan kalite noktasında en iyisini (birisi en iyi ikincisini) yaparken, diğer kalite noktalarında gelişi güzel davrandıklarını anlıyoruz. Peki, bu sonuçları nasıl açıklayabiliriz ya da yorumlayabiliriz? Bu deney üzerine konuşan bir kaç yazar, bu durumu şöyle özetliyordu: “Be careful what you ask for – You may get it”, yani “Ne istediginize dikkat edin, elde edebilirsiniz”. Bunu diyenlerden birisi de bu dünyanın en iyi bilinen kişilerinden Barry Boehm. Ona göre bu bu çalışmanın iki sonucu var:

• Yazılım geliştiriciler, motivasyonu yüksek insanlardır. Yani onlara bir hedef verdiğinizde, o hedefe ulaşmak için son derece ciddi ve sıkı bir şekilde çalışırlar.
• Pratikte, farklı yazılım geliştirme hedefleri birbirleriyle çelişir. Örneğin yukarıdaki tabloya göre, ilk takım işi en az eforla yapmaya odaklanmıs ve bunu da başarmıştır. Ama belli ki ortaya çıkardıkları program anlaşılır olmakta en kötüsüdür ve kullanılan statement sayısı ve bellek miktarı açısından da sondan ikinci durumdadır. Benzer şekilde anlaşılır program yazan grup aynı ayarda anlaşılır çıktı üreten programı da yazmışlar ama

Yukarıdaki Boehm’in yorumalarını biraz geliştirebiliriz. Evet yazılımcıların ciddi çoğunluğu, program yazmaktan, değişik dil, araç ve teknikleri öğrenmekten zevk alan, öğrenmek için sürekli fırsat kollayan insanlardır. Tabi ki bunun pek çok istisnası var. İstisnaların büyük çoğunluğu ise bence ileri yaşlarda ortaya çıkıyor. Bu kadar yorucu bir işi, bu ülkedeki şartlarda yapmak uzun süre sonunda ciddi zihni ve ruhsal bozukluklar, en azından yorgunluklar oluşturuyor. Motivasyon konusunda kurumların tavırları, oradaki liderlikler de çok önemli rol oynuyor. Olumsuz yönetim ve eksik liderliğin olduğu ortamlarda da motivasyonu yüksek yazılımcıların her şeye rağmen uzunca bir müddet var güçleriyle çalışmaya devam etmenin yollarını bulduklarını çok sık gözlemledim. Fakat haklı olarak bu durum uzun sürmüyor, bir kaç yorucu pozisyon, yazılımcıyı idealistlikten, okuyup, araştırmadan uzaklaştırıyor ve bu durum işten ayrılma ile devam ediyor. Bence kötü yönetim ve eksik liderlikten kaynaklanan problemler sektörümüzdeki işten ayrılmaların en temel sebebidir.

Diğer yorum ile ilgili ise aklıma şunlar geliyor. Yazılım geliştirme, karmaşık ve pek çok kalite faktörü olan bir çalışmadır. Bu kalite faktörlerinin hepsini birden yerine getirmek zor hatta imkansızdır. Bu zorluğun ve imkansızlığın bence iki sebebi var. İlki, Boehm’in de belirttiği gibi, çelişen istekler. Örneğin yukarıdaki örnekten de açıkça görüldüğü gibi, programı geliştirmek için harcanacak efor konusunda bir hedef konduğunda, yazılımın en temel kalite unsuru olan anlaşılırlık doğrudan düşüyor. Bu duruma ülkemizde daima sahit oluyoruz. Yazılımcılar olarak en büyük rahatsızlıklarımız, birbirine çelişen isteklerle karşılaşmak ve bizden bunları isteyenlerin, aslında biraz sağ duyu sahibinin bile anlayabileceği şeyler olmasına rağmen, isteklerdeki çelişkiler konusunda duyarsız davranmaları. Bu durumu ancak BTye stratejik olarak bakabilen kurumlar ve onların içındeki güçlü BT birimleriyle çözebiliriz.

Bir diğer sebep de bence yazılım geliştiren kişilerin, bu faktörlerle nasıl uğraşacakları konusunda bilgisiz ve yetersiz olmaları. Örneğin üniversitelerin Bilgisayar Mühendisiliği bölümlerinde algoritmik karmaşıklıkla ilgili ciddi dersler olmasına, big-o (O) notasyonu, algoritmaların işlem sayıları dolayısıyla hem zaman hem de bellek karmaşıklığı ile ilgili bilgi verilmesine rağmen, bırakın karmaşık bir algoritmanın maliyetini hesaplamayı, normal list ile bağlı (linked) list arasındaki performans farkından haberdar olmayan o kadar çok programcı-developer gördüm ki. (Matematik ve matematik mühendisliği gibi bölümlerde de discrete matematik, combinatorics gibi derslerin olduğunu biliyorum.) İster yeni mezun olsun ister tecrübeli olsun kimsenin bunlardan haberi yok, herkes nasıl alışmışsa her yerde onu kullanarak yazıyor kodunu. Yeni mezunların ezici çoğunluğu bu konudan bahsedildiğinde ilk defa duyuyormuş gibi davranıyor. Yazılım geliştiren kişilerin liderleri, önderleri durumunda olan senior programcı ve developerların, mimarların da bu konular hakkında çok fazla sistemli bilgi sahibi olduklarını, yanındaki daha genç olan kişileri yönlendirip, eğitebildiklerinden de emin değilim. 10-15 sene yazılım geliştirme projelerinde developer olarak çalışmış ve yaşı 35’e gelmiş kişilerin örneğin JVM’in belek yönetimi ve kullanılmayan nesnelerin belleklerini geri toplaması (garbage collection) ile hiç ilgilenmemiş olmaları açıkçası bana çok garip geliyor.

Bu ülkede malesef aşırı teknoloji odaklı olduğumuz için, yeni diller ve araçlar öğrenmemize rağmen, yeni teknikler ve yaklaşımlara bu kadar ilgi duymuyoruz. Dolayısıyla, kurumsal uygulamalarda o kadar çok performans ve ölçeklenirlik problemi yaşayan sistemlerle karşılaşıyorum ki, inanılmaz. Zannedersiniz kodları yazanlar orta okul mezunları. Lise sonda üç katlı integral çözmekle övünenlerin yazdıkları kodlarda isimlendirmede bile problem var. (Tabi aslolan üç katlı integral çözmek değil, aslolan hayattan bir problemi üç katlı integral olarak tanımlayabilmek. Kendim de dahil olmak üzere çözenini çok gördüm ama tanımlayabileni pek görmedim.)

Bugünün senior programcı ve developerları ya da mimarları, yazılımın kalite kriterleriyle ilgili doğru dürüst bilgi sahibi olmayıp, yazılımda olması gereken süreçlerden de bihaber kaldıklarından, kendileri kod yazarken çektikleri sıkıntılar üzerine ciddi olarak düşünüp, araştırarak, aslında yanlış yol tutturduklarını, sebep ve çözümleriyle birlikte ortaya koyacak hale gelemiyorlar. Bu yüzden bu kişiler yönetici olduklarında, “biz böyle gördük, tırmaladık, fedakarlıkla yaptık” diye düşünüyorlar ve yönetimlerinde de bu düşünceler çok etkili oluyor.

Özet olarak söylemek gerekirse, yazılım projesinin pek çok hedefi aynı anda yerine getirmesi gerekir. Kod kalitesi de belki de maliyetle birlikte bu hedeflerden en önemli ikisidir. Ama ülkemizde malesef çoğu zaman maliyet üzerine oynarken kod kalitesini göz ardı etme eğilimindeyiz. Bunun da  en temel iki sebebi, yöneticilerin çelişen istekleri ve mühendislerin bilgisizliğidir diye düşünüyorum.

Evet, ne istediğinize dikkat edin, bakarsınız oluverir 🙂  

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