Entropi, ilk olarak termodinamiğin ikinci yasası ile karşımıza çıkmış olsa da genellikle bir sistemdeki düzensizliğin ölçüsü olarak kullanılmaktadır. Fizikte faydasız enerji olarak da ifade edilen entropi, bir sistemdeki belirsizlik ve bozulma etkisi olarak da ifade edilmektedir. En özet ve güzel ifadeyle entropi, bir sistemin minimum enerji kullanımı ve maksimum düzensizliğe geçiş eğilimi olarak belirtilmektedir. Kısacası tüm sistemler düzensizliğe geçiş eğilimindedir. Entropi, düzensizliğe doğru gidişin ifadesi, düzensizliğin ölçüsüdür.
İşletmelerde, bilgi akışlarında, projelerde ve yazılımlarda da benzer bir eğilim söz konusudur. Burada önemli olan bir sistem her zaman bozulma eğiliminde olduğunun bilinmesi ve bu bozulma öncesi efektif kullanım süresinin doğru tahminlenmesidir. Daha önceki yazılarımızda da bahsettiğimiz üzere her proje için bir amortisman süresi belirlenir ve belirlenen bu süre boyunca ilgili projenin kullanımına devam edileceği düşünülür. Dolayısıyla entropi etkisinin süreceği bilinmekle beraber proje çıktısı olan ilgili ürün/hizmet/sonuç amortisman süresi boyunca kullanılabilir olmalıdır.
Amortisman süresi ve entropi etkisi tamamen tahmine dayalı olsa da bu tahmini yaparken göz önüne alınmasının fayda sağlayacak bazı kuramlar ve yaklaşımlar bulunmaktadır.
Tesler Kuramı:
“Every application has an inherent amount of irreducible complexity. The only question is: Who will have to deal with it — the user, the developer, or the designer?” – Larry Tesler
(Her uygulama doğal olarak indirgenemez bir karmaşıklığa sahiptir. Bu aşamada tek soru şudur: Kim bu karmaşıklık ile uğraşmak zorunda kalacak – kullanıcı, yazılımcı veya tasarımcı?)
Karmaşıklığın korunması olarak da bilinen bu kuram, insan-bilgisayar etkileşiminde her uygulamanın kaldırılamayacak, gizlenemeyecek ve daha basite indirgenemeyecek düzeyde bir doğal karmaşıklığa sahip olduğunu belirtmektedir. Bu yaklaşımın doğal bir sonucu olarak karmaşıklığa kimin maruz kalacağı sonucuna ulaşılmaktadır. “Yazılımcı, kullanıcılara daha basit bir uygulama sunmak için kodu mu karmaşıklaştırmalı, yoksa kodu basit tutarak kullanıcıya daha karmaşık bir arayüz mü sunmalı?” sorunsalında optimize bir çözüm bulunmalıdır.
Karmaşıklığı kullanıcıdan sisteme taşımanın yazılım ekibinin eforuna, proje süresine ve maliyetine etkisine değip değmeyeceği proje yöneticisine kalmış bir karardır. Kararın etkisine ve etkinin büyüklüğüne göre ilgili paydaşlarca değerlendirme yapılmalıdır. Fakat unutulmamalıdır ki eğer hitap ettiğiniz kullanıcı kitlesi için sürdürülebilir bir tekele sahip değilseniz, tercih çoğunlukla kullanıcının zamanından yana olacaktır.
Arayüzün zamanla gelişmesi ve kullanıcıların zaman içerisinde öğrenmesi için – özellikle agile, design thinking gibi yaklaşımlarda – her zaman bir MVP oluşturulması ve ilk çıkışın bununla yapılması önerilmektedir. Proje çıktısı ne kadar çok özelliğe sahip olursa arayüz o kadar karmaşık olacaktır. Entropi yaklaşımı gereği giderek daha fazla karmaşıklaşacaktır. Dolayısıyla ilk çıkışta basit bir arayüzle çıkıp sonraki birkaç arayüz adımının ilk çıkışta planlanması gerekir.
Efsanevi Yaklaşım Murphy Kuramı:
“Anything that can go wrong will go wrong.” – Edward A. Murphy
(Eğer bir işin kötü gitme ihtimali varsa kötü gider.)
Hiç açıklamaya gerek bulunmayan bu kuramı Sod daha detaylandırarak “Eğer bir işin kötü gitme ihtimali varsa, olabilecek en kötü zamanda kötüye gidecektir” demiştir.
Burada düşüneceğiniz en güzel örnek, hepimizin en az bir kez yaşadığı şekilde: en önemli müşteri belki yılda bir kez uygulamanızı kullanır ve o uygulama ile ilgili belki yılda bir kez sorun çıkarsa tam onun kullandığı zamana denk gelecektir ve bu müşterinize asla derdinizi anlatamayacaksınız. Çünkü bu müşteri doğrulama yanlılığı (doğrulama önyargısı – confirmation bias) gereği sizi dinlemeyerek, sürekli uygulamada sorun yaşandığı tepkisini verme eğiliminde olacaktır. Bu kuram ışığında durumu değerlendirdiğimizde en önemli müşterinizde memnuniyeti asla sağlayamayabilirsiniz.
Eğer bir uygulama kullanıcısı veya testçisi iseniz de mutlaka kullanım/test sayısını arttırmanız gerekir. Tek seferlik her işlemin hata ile karşılaşma olasılığı çok daha yüksektir.
Hutber Kuramı:
“Improvement means deterioration” – Patrick Hutber
(İyileştirme, bozulma anlamına da gelir.)
Tüm sistemler bir harmoniye sahiptir ve sistemin bir bileşeninde iyileştirme yapılması, sistemin diğer kısımlarında bozulmaya neden olabilir veya mevcut bir bozukluğu gizleyebilir. Bu yaklaşım göz önüne alındığında proje veya iyileştirme – özellikle refactoring çalışmalarında – analizi yapılırken etkileşimler mutlaka belirlenmelidir.
Yapılan her iyileştirmenin entropiyi arttıran bir etkisi vardır. İyileştirme projeleri entropi etkisine, sıfırdan yazılan projelerden daha açıktır.
Kırık Camlar Teorisi:
Yine oldukça yaygın kullanıldığından açıklanmasına gerek olmayan bir teori. Burada IT projeleri olarak dikkat edilmesi gereken husus, düşük kaliteli sistemler (temeli sağlam olmayan sunucu parkurları, kalitesiz kodlara sahip yazılım projeleri, kötü teknik tasarımlar gibi) üzerlerine geliştirilen yeni yapıların da kalitesiz olmasına dolayısıyla kalitenin giderek düşmesine neden olabilirler. Dolayısıyla yeni geliştirmeler öncesinde taban sistemin gözden geçirilmesinin gerekliliği mutlaka proje ekibince değerlendirilmelidir.
Pencereler kırılmaya başladığından fonksiyonel sistemler çok hızlı şekilde bozulacaktır. Entropi etkisinin çok yüksek olduğu aşikar olan bu teori, bir kez daha refactoring’in önemini hatırlamamıza yardımcı olacaktır.
Soyutlama Sızıntısı (Leaky Abstractions) Kuramı:
“All non-trivial abstractions, to some degree, are leaky.” – Joel Spolsky
(Bütün önemsiz soyutlamalar bir miktar sızdırır.)
Bu kuram, sistemleri kurgulamak için yapılan bir kabulün, sadeleştirmek için yapılan bir soyutlamanın, soyutlaması beklenen detayları ve/veya altında yatan sorunları ana sisteme sızdırdığını ve bu sızıntıların beklenmedik davranışlara yol açabileceğini belirtmektedir. Dolayısıyla bir soyutlamanın yanılmazlığına güvenilmemelidir.
Oluşturulan sistem karmaşıklaştıkça soyutlama sayısı artar. Özellikle karmaşıklığı gizlemek için soyutlama, belli özelliklere ulaşmayı imkansız hale getiren bir bağımlılığın (dependency) üzerine inşa edilirse veya üzerine inşa edilen bağımlılık soyutlamanın sahip olmadığı bir temel yeteneğe sahipse mutlaka sızıntı olacağı iddia edilmektedir.
Soyutlamada altta yatan bir detay atlandığında kurtulmak istenen karmaşıklığı bir miktar da olsa yazılıma aktaracaktır. Sızıntı ne kadar çok ve büyük olursa bozulmaya etkisi o kadar fazla olacak dolayısıyla entropi etkisini arttıracaktır.
Goodhart Kuramı:
“Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” – Charles Goodhart
(Gözlemlenen herhangi bir istatistiksel düzenlilik, kontrol amacıyla üzerine baskı uygulandığında çökme eğilimi gösterir.)
Bir projeyi değerlendirirken, örneğin bir stress testi planlarken, proje ilk testi geçemezse güncellenmiş yazılımın sadece bu testi geçmek için güncelleneceğini unutmamak gerekir. Bu güncelleme ise farklı bozulmalara neden olabilir. Kuramın ulaşacağı sonuç çok güzel özetlenmiştir:
“Bir ölçüm hedef haline geldiğinde, iyi bir ölçüm olmaktan çıkar.” – Marilyn Strahern
Benzer bir yaklaşım olan Campbell kuramının bir sistemi sadece kantitatif veriler ile ölçmenin, sonuçları manipüle etmeye ve yozlaşmaya o derece açıklık sağladığını belirttiğini de eklemeden geçmeyelim.
Dolayısıyla testin 7 prensibinden olan “Exhaustive testing is impossible” (Tüm detayları test etmek imkansızdır) ve “Absence-of-errors is a fallacy” (Hatasızlık bir yanılgıdır) sonuçlarına ulaşabiliriz.
IT Projelerinin Entropisi
Buraya kadar hem entropi kavramı hem de entropi etkisini arttıran bazı kuramlar hakkında bilgi vermiş olduk. Görüldüğü gibi özellikle yazılım projeleri fizik yasalarından muaf gibi görünse de entropiden fazlasıyla etkilenmektedir. Özellikle teknik borçlar biriktikçe entropi de artmaktadır.
Zaman zaman yazılım çürümesi (software rot) olarak da ifade edilen entropinin en önemli faktörünün projede çalışanın psikolojisi ve çalışılan kurumun kültürü olduğu unutulmamalıdır.
Entropiyi minimize edebildiğiniz projeler yapabilmeniz dileğiyle…
NOT: Yazılım projelerine etki eden kuramları kısaca tanıtan bir çalışma için bu kaynağa da göz atmanızı öneririz.
