Yazılım ve Değişim – II

Bu blogda sıklıkla söyleyip, vurguluyorum:  Yazılımın bakımı, geliştirilmesinden daha pahalıdır. Hatta şu cümleyi slogan gibi tekrarlarım. “Yazılımı geliştirmeye odaklananlar yanlış yapıyorlar. Yazılımı geliştirirken odaklanılması gereken şey, onun ileride nasıl değişeceği olmalı. Yazılımın en temel kalite sıfatı ne kadar rahat değişebildiğidir çünkü. Bu konuyu burada da ele almıştım, özellikle diğer mühendislik dallarındaki değişimin tabiatıyla, yazılımdaki değişimin tabiatının çok farklı olduğunu vurgulamıştım. Şimdi biraz daha bu konunun üzerine gidelim.

Problem şu ki ülkede yazılımı yönetenler de dahil olmak üzere hemen herkes öyle ya da böyle yazılımı “geliştirmeye” odaklanmış durumda. Nedense yazılım için değişimin mahiyetini ve önemini algılamış durumda değiliz. Uzun vadeli düşünemeyeşimiz, hayatımızı uzun vadeli stratejiler yerine günlük taktikler üzerine kurguluyor olmamız, yazılıma yaklaşımımızı da etkiliyor tabi olarak.

“Yazılımı hızlıca bitirelim, piyasaya sürelim, …yı kaçırmayalım”, “müşterinin tarihlerine uyalım, faturamızı keselim”, “iş birimi ne olursa olsun … tarihine yetişmesini istiyor” vb. sözler, bizim yazılımla ilgili en temel gerçeği görmemizi engelliyor. Bu gibi baskılar, bazen müşteri beklentilerinden, bazen ekonomik zorunluluklardan bazen de aynı kurumdaki iş birimlerinin kaprislerinden, neyden kaynaklanırsa kaynaklansın, bizim yazılımla ilgili en temel gerçeği görmemizi, dolayısıyla yazılımın ekonomisini anlamamızı engelliyor. Yazılım ile ilgili en temel gerçeğin ilk kısmı, yazılımı geliştirmenin çok da önemli olmadığı, şu ya da bu şekilde herhangi birisinin bir yazılım geliştirebileceğidir. Bu gerçeğin tamamlayıcı diğer yarısı ise, bir yazılımın fikir olarak akla gelişinden, gelişitirilip, devreye alınıp, sonrasında bakımının yapılıp, nihayetinde kullanımdan kaldırılmasına kadar geçen sürede yapılan masrafın büyük bir kısmının aslında o yazılımı geliştirmeye değil, geliştirdikten sonra değiştirmeye harcanıyor olmasıdır. Yani yazılımın bakımı, geliştirilmesinden çok daha pahalıdır. Maliyet en önemli unsursa, yazılımın bakımı, geliştirilmesinden çok daha önemlidir demektir.

Aşağıda, yukarıda bahsedilen durum, Stephen Schach’ın “Object Oriented And Classical Software Engineering” isimli kitabının 8. baskısında aşağıdaki iki diyagramda resmedilmiştir:

Bu diyagramlardan ilki 1976-81, ikincisi ise 92-98 yılları arası için verilmiştir.

Bu iki diyagram bize iki şeyi söylüyor: İlki yukarıda özetlediğim gerçek, yazılımın bakımı, geliştirilmesinden daha pahalıdır. Diğeri ise yıllar geçtikçe yazılımın bakım maliyetinin tüm maliyeti içindeki payının artması. Bu durum bize ters gelebilir ama malesef, yazılımla ilgili bilgi ve tecrübemiz arttıkça, yazılımların bakım maliyetleri azalmıyor, aksine artıyor. Bunun en temel sebebi de yazılımların büyümesi, hayatımızda daha fazla yerde olması ve sonucunda değişiminin de daha büyük çaplarda olmasıdır. Yazılım ile ilgili teknolojilerin ve yaklaşımların gittikçe daha ileri, faydalı ve uygulanabilir olması, yazılımı geliştirmeyi ve bakımını yapmayı daha kolay hale getirmiyor.

Ben buradaki rakamalrın ülkemiz için biraz daha farklı olduğunu düşünüyorum. Memleketimizde bakımın maliyetinin, tüm yazılım maliyet içinde %90’dan az olmadığını düşünüyorum. O kadar ki pek çok proje bakımda tamamlanıyor. Pek çok yazılım evi bakımla ayakta duruyor. Proje sözleşmesinde üzerinde hem fikir olunan pek çok özellik, düzgün bir planlama olmamasından ve farklı niyetlerden dolayı ancak bakımda tamamlanabiliyor.

Yazılımı geliştirmenin zor olduğu şeklindeki algımızın büyük kısmı aslında değiştirmenin zor olmasından kaynaklanıyor. Yukarıda da bahsettiğim gibi yazılımı herhangi bir sekilde geliştirmek kesinlikle zor değildir. Bu durum, belli becerilere sahip bir kimsenin bir araba yapmasından farklı değildir. Ama problem şurdadır ki herhangi bir kimsenin yaptığı arabaya çok ucuz bile olsa para verip almak istemeyiz. Çünkü kalitesi hakkında ciddi endişelere sahip oluruz. Bu durumu ünlü Gerald Weinberg çok veciz bir şekilde şöyle belirtiyor:

“If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.”

Yani

“Eğer inşaatçılar binalarını, programcıların programlarını yazdıkları gibi dikselerdi, ilk gelen ağaçkakan medeniyeti yerler bir ederdi.“

Komik ama bir o kadar da gerçek değil mi?

Yazılımda aslolan, değiştirmek için geliştirmekdir. GoF bunu “design for change” yani “değişim için tasarla” diye ifade ediyor. İnsanlar, inşaat mühendisleri ve mimarların tasarlayıp ürettikleri binalarda, sadece barınma aramakla kalmıyor, nasıl rahatlık, konfor, dayanıklılık vb. sıfatlar da arıyorlarsa biz yazılımcılar da yazılımlarımızın sadece fonksiyonel olarak müşteriyi tatmin eder noktada kalmasını değil, fonksiyonelliğin kalitesine de önem vermeliyiz. Foksiyonellikle ilgili en temel kalite maddesi ise, değişebilirliktir. Bu yüzden geliştirdiğimiz yazılım sistemlerinin, aynı zamanda müşterinin yeni isteklerini de hızlıca karşılayabilecek kalitede olmasını sağlamak zorundayız.

Yazılımcılara da bu konuda çok iş düşüyor. Daha rahat değişen mimariler ve nesne yapıları nasıl kurgulanır, katmanlar, modüller ve nesneler arasındaki bağımlılıklar (coupling) nasıl yönetilir, iş süreçleri ve iş kuralları nasıl esnek ve değişebilir yapılır, tüm bunlar yazılımcılar olarak bilmemiz gereken şeylerden. İşin açıkçası bu konularda iyi olduğumuz söylenemez. Bırakın bunları, daha doğru düzgün isimlendirme yapamadığımız kodlarımızla, esnek, hızlı değişen mimariler kurgulamak bize çok uzak malesef.

Değişimin kendisinin fark yaratan en büyük etken olduğu, değişimin hızının gittikçe yükseldiği bir devirde, yazılımların bu değişime ayak uydurmasını beklemek, iş birimleri için son derece normal. Ama onların da, bu beklentiyi sağlamanın, eskiden bu yana uyguladığımız yazılım geliştirme yöntem ve teknikleriyle olamayacağını anlamaları gerekli. Yani hem proje süresi, çalışan kalitesi ve iş gücü aynı kalsın ama daha büyük, daha donanımlı ve daha kolay değişen yazılımlar geliştirilsin. Hiç bir makul zihin bunu kabul etmez. Kalite, hız ve fiyatı düşündüğümüzde, her üçünde de en iyi durumda olamayız. En fazla ikisini seçip üçüncüden taviz vermek zorundayız. Bu durum “project triangle” oalrka da adlandırılır:

Proje üçgeni

Proje üçgeni şunu söyler bize: İkisini seç. Çünkü üçü bir arada olamaz.

Benzer şekilde yazılım müşterileri hızlı değişen yazılımlar istiyorlarsa, bedelini öngörmek ve buna göre yazılım geliştirilmesine rıza göstermek zorundalar. Fakat bu durumu onlara anlatacak kişiler ise bizleriz. 

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