Yazılım zor zenaat, bu çok açık. Çünkü yazılım, diğer mühendislik dalları gibi fiziksel değil, soyut bir uğraş alanı. Yazılımın soyut olan doğası, onun durumunu tüm detaylarıyla anlamayı imkansız hale getiriyor. Çünkü kontrol altında tutabildiğimiz etmenler, kontrol altında tutamadıklarımız yanında sayıca çok daha az. Bu yüzden örneğin bir yazılımı her türlü detayıyla test etmek pratikte imkansızdır. Bu yazıda, yazılımın karmaşık yapısı kadar önemli olan değişkenliğini ele almaya çalışacağım.

Hemen herkes yazılımda değişmesi mümkün olmayan bir şey olmadığında hemfikirdir. Yani yazılımda her şey değişebilir, tek fark değişimin maliyeti olabilir. Diğer mühendislik ürünlerindeki degişimi düşündüğümüzde, yazılımdaki değişmeyle çok ciddi mahiyet farklılıkları olduğunu gözlemleyebiliriz. Örneğin, araçlardaki, binalardaki ya da köprülerdeki değişimle ilgili konuştuğumuzda, yani inşaat ve makina mühendisliğinin ürünlerini ele aldığımızda, değişmenin asıl sebebinin ilgili malzemenin aşınmış, bozulmuş vb. durumda olması olduğunu söyleyebiliriz. Bu durumda yedek malzemelerin, orijinal olanlarla, montaj noktaları gibi ilgili açılardan aynı standartta üretilmiş olması, değişim için yeterli olur. Yani mühendislik ürünlerinde değişim, var olana yeni bir şey katmaktan ziyade, yerine geçirmek (replacing), var olanı, standartları açısında uyumlu olan daha yenisiyle değiştirmek anlamına geliyor. Yazılımda ise aşınma, bozulma söz konusu değil. Dolayısıyla değişimi gerektiren durumlar, temelde yeni ortaya çıkan ihtiyaçlardır. Bu yüzden yazılımın değişmesi, daha önce sahip olmadığı özelliklere sahip olması anlamına gelmektedir. Yeni fonksiyonel ihtiyaçlar, örneğin yeni süreçler ya da var olan süreçlerdeki değişiklikler, yeni iş kuralları ya da benzer şekilde var olan iş kurallarında değişiklikler, iş kurallarının çoğunlukla daha esnek hale gelmesi, yeni tür kullanıcılar, yeni entegrasyonlar, yeni teknoloji vs. hep yazılımı değişmeye zorlayan etkenlerdir.

Değişim, yazılım mühendisliğini çok derinden etkileyen bir faktördür. Örneğin, geliştirilmesine 100 TL harcanan bir yazılımın, ömrünün sonuna kadar değiştirilmesine ne kadar para harcandığını sorsam tahmininiz ne olurdu? Buna cevap aramak için Google’a gidip “software maintenance cost” aramasını yapın ve çıkan resimlere bakın. Farklı onlarca grafik göreceksiniz ama hepsi bir şeyi analtıyor: Yazılımın esas maliyeti geliştirilmesinde değil, değiştirilmesinde. O grafiklerdeki oranlara bakarak 100 TL’ye geliştirilen bir yazılımın ömrünün sonuna kadar 400-500 hatta 700-800 TL gibi masraflara bakımının yapıldığı sonucunu çıkarabilirsiniz. Ben bu oranın ülkemizde 10 gibi olduğunu düşünüyorum, yani 100 TL’ye geliştirdiğimiz yazılımın bakım maliyetinin onun 10 katına yani 1000 TL’ye kadar çıktığını düşünüyorum. Bunun pek çok anlamı var:

• Yazılımlar için bütçeleme yaparken sadece geliştirme maliyetini göz önüne almanın doğru olmaması. Esas maliyet, buz dağının görünmeyen kısmı, bakımda aslında.
• Bütçemiz kısıtlı olduğundan şunu/bunu yapamayacağız. Örneğin “dokümentasyon yapamayacağız”, “teste vakit yok”, “eğitim bütçemiz çok kısıtlı”, “ek kaynağa para ayıramıyoruz” gibi cümleler anlamsız. Gerekli olan  şeylere para ayıramayarak 100 TL’ye geliştirdiğimiz yazılımı ayakta tutmak, düzeltmek ve daha da geliştirmek için 5-6 senelik ömründe 1000 TL harcamak zorunda kalıyoruz ama.
• Yanlış ata oynuyoruz, kafamızı “yazılımı nasıl geliştirelim ki ihtiyaçlarımızı karşılasın”a odaklamak yerine “yazılımı nasıl geliştirelim ki gelecekteki ihtiyaçlarımızı karşılaması kolay olsun”a odaklamalıyız. Yazılım Mühendisliğinde önemli olan yapmak değil, değiştirmektir çünkü.
• Başarısız yazılımların değişeceğini sanıyoruz ama geçek şu ki başarısız yazılımlar çoğu zaman değişemediklerinden başarısızdırlar, değişen yazılımlar başarılı olanlardır.
• En acısı da belki yeni mezunların, çalışacakları işlerde hep yeni projeler geliştireceklerini düşünürken, 12 aylık maaşlarının yaklaşık olarak sadece ve sadece 1,2 tanesini yeni projede kod yazmak için alıp, geri kalanını başkalarının yazdıgı berbat kodu önce anlamak sonra düzeltmek, yeni özellikler eklemek, başka bir teknolojiye çevirmek gibi bakım ya da değişim dediğimiz çalışmalar için hakediyor olmaları. Düşünsenize makina mühendisi olarak eğitim aldınız ve iş hayatına atıldınız, tek yaptığınız iş ise bir araba tamircisinde gelen arabaların bujilerini temizlemek, gerekirse değiştirmek. Ya da çiçeği burnunda bir inşaat mühendisi olarak elinizde mala, çatlayan duvarları sıva yapıyorsunzu devamlı, nasıl olurdu? Malesef bizim sektörde hayat böyle, sonra bu yazılımcılar niye böyleler? 🙂 (Gerçi bu duruma pek çok kötü örnek verilebilir, konservatuarda Dede Efendi ya da Beethoven’i öğrenip mezun olunca düğünlerde Ankara’nın Bağları çalmak zorunda kalmak da benzer bir şey. 🙂 )

Diğer mühendislik ürünleri olabildiğince az değişecek ve değişmesi gerektiğinde de kolay değişecek şekilde tasarlanıp üretilmektedirler. Bir araba üretilirken nelerin hızlıca değişmesi gerektiği çok açık bir şekilde belirlenmiş olduğundan, örneğin silecekler, tekerlekler, su ve yağ cinsinden şeyler, bunları bizler bile değiştirebiliyoruz. Çünkü buradaki değişim yukarıda da belirttiğimiz gibi parçayı değiştirmedir, yeni bir yapı ekleme değildir. Ya da bir köprü inşa edilirken örneğin üzerindeki asfalt vb. kaplamanın ya da varsa halatlarının nasıl değişeceği tamamen öngörülmüş durumda, bu yüzden de kolay değişecek şekilde tasarlanmıştır. Bu noktada fiziksel ortamlarda ve malzemelerle çalışan mühendislerin, sık değişecek kısımların kolay değişebilmesi gibi bir prensip üzerinde uzlaştıkları görülüyor. Bu yüzden örneğin bir arabanın sileceklerini değiştirmekle trigger kayışını ya da transmissionunu değiştirmek aynı kolaylıkta değil.

Yazılımın aşırı değişken olan doğasına rağmen “değişebilen yazılım” yerine yazılımın sadece geliştirilmesine odaklanmak, herhalde 100.000 TL’ye bir binek aracı satın alıp sonra sileceklerini değiştirmek için 5.000 TL ya da ne bileyim lastiklerini değiştirmek için 20.000 TL vermekle eşdeğer bence. Düşünün böyle, değişim göz önüne almadan, sadece ve sadece üretilmesine odaklanarak tasarlanmış bir aracın motorunun içindeki trigger kayışı gibi parçalarını değiştirmek muhtemelen 100.000 TL’ye mal olur. Böyle bir aracı kim almak ister ki? Dün aracıma 4 tane lastik aldım ve sadece lastikler için para ödedim, değiştirilmeleri ve balans için ücret ödemedim, çünkü eski lastiklerin janttan çıkarılıp yenilerinin takılması, balanslarının ayarlanması ve arabaya monte edilmeleri o kadar kolay ve hızlı ki yarım saatte işim bitmişti.

Aslında pek çok mühendislik ürününde ayırt edici unsur kalitedir. Neden durumumuz olduğunda 150.000 TL harcayarak bir araç satın alıyoruz da “aman canım aynı şeyi yapıyor” deyip 5.000 TLlik bir araçla yetinmiyoruz? Mühendis olarak ben örneğin, biraz vakit ayırsam, uğraşsam, herhalde bir araç yapabilirim ve 10.000 TLye sattığımı ilan edebilirim. Sonuçta gidiyor mu gidiyor, duruyor mu duruyor, nedir problem? Problem, “saatte 100 km hızla giderken, yerlere yeni yağmur düştüğünde 10 metre önünüzdeki araç sert bir fren yaptığında benim aracımda mı yoksa 150.000 TL verip aldığınız örneğin bir BMW 3.20’de mi olmak isterdiniz?” sorusu aklımıza geldiğinde ortaya çıkıyor. Ben yerler ıslak olmasa da, öndeki araç hiç fren yapmasa da BMW içinde olmayı tercih ederdim. Peki aynı durumda biz neden yazılımın değişim maliyetini göze almadan, sadece fonksiyonelliğine ve maliyetine bakarak tercihde bulunuyoruz ki? Bence en temel sebebi, yazılımın aşırı değişken olan mahiyetini henüz anlamamış olmamız. Buna günü kurtarmaya odaklı milli, aşırı faydacı karakterimiz de bu duruma katkıda bulunuyor ama yazılım konusundaki cehaletimiz daha önde bence.

Eğer bir araba reklamı yapsaydım, “evladiyelik” diye ilan ederdim arabayı. Ama bir yazılım sisteminin reklamını “evladiyelik” diye yapmayı düşünmezdim, onun yerine “kolay değişebilir” diye reklam yapmak daha akıllıca olurdu. Yapmak ile değiştirmek arasındaki denge, fiziksel mühendislik ürünlerinin tam tersine işliyor bizim mesleğimizde. Bu yüzden yazılımı yönetenler, 10 günde geliştirilmiş basit bir yazılıma bazı eklemelerin 2 haftada yapılabileceği gibi bir söz duyunca developera yükleniyorlar, çünkü kendilerini kandırılıyor hissediyorlar sanırım. Çünkü akıllarında 1 senede yapılan dairelerinin 3 günde boyanması ya da ne bileyim 1 haftada banyonun ya da mutfağın tamamen değiştirilmesi gibi tecrübeler duruyor. Yazılımı iyi yönetebilmemiz için, değişikliklerin kolay yapılabılabileceği yazılımlar geliştirmeye önem vermeliyiz. Ancak böyle bir anlayışla, yazılımın 10 gün yerine örneğin 50 günde geliştirilmesini planlar ve gerekli değişiklikler için developerdan “2 günde olur” diye tahminler bekleyebiliriz.

Bence bir programı, benim bir mühendis olarak bir binek aracı üretmem gibi matematiksel düşünme kabiliyetleri gelişmiş pek çok kişi, programcı ya da herhangi bir mühendis yazabilir. Bu kişinin üniversite mezunu bile olmasına gerek yoktur, akıllı ve meraklı bir lise mezunu yapabilir bu işi. Ancak yazılım, özellikle de rahat değişebilen bir yazılım, sadece ve sadece Yazılım Mühendisleri tarafından geliştirilebilir. Çünkü yazılım, programcılara ve proje yöneticilerine bırakılmayacak kadar zor bir iştir.

Yazımızı bir sloganla bitirelim: Kimileri program yazar, kimileri yazılım geliştirir. 🙂

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