Ancak anne karnındaki veya küçük bebek olan yazılımlarda ölüm oranı hayli yüksektir. Örneğin, fikrin o kadar parlak olmadığı anlaşılabilir, başka işlerin bastırmasından (mesela aşağıda göreceğimiz gibi, can çekişmekte olan yazılımlarla uğraşmaktan) dolayı geliştirme faaliyetleri yavaşlayabilir ve durabilir. Geliştirme bitmiş olsa bile istekleri karşılayamayabilir, kullanıcılar tarafından benimsenmeyebilir, firma içi politik sebeplerle kullanımı engellenebilir vs. vb.
Bazen bir yazılım fikrini kabul ettirmek için bir prototip geliştirilir. Bu prototip o kadar beğenilir ki, "biz bunu kullanmaya başlayalım, esasını da arada geliştiririz" fikri ortaya atılır ve prototip gerçek gibi kullanılmaya başlanır. Asla esas yazılımı geliştirme fırsatı ortaya çıkmaz ve prototip zamanla esas yazılım haline gelir. Elbette prototiplemenin doğasından dolayı altyapısı sağlam olmayan şekilde...
Eğer yazılım yukarıdaki doğum ve ilk serpilmesini başarıyla atlatmışsa, yani gerçekten kullanılmaya başlanmış, işe yaradığı görülmüş ve esas iş ona bağımlı hale gelmişse, artık o yazılım yaşamaya başlamıştır. Bundan sonra da zor ölür zaten...
Yazılımın Kendine Özgü Doğası
Yazılım da bir üründür sonuçta, ama alıştığımız bir çok ürün çeşidi gibi sabit özelliklere sahip değildir. Adeta bir aile fotoğrafı gibidir; devamlı değişir ve gelişir. Diğer yandan fiziksel bir ürün olmadığı için bildiğimiz anlamda aşınmaz. Aşınmaması, yenisini satmayı zorlaştırır. Hoş, Microsoft neredeyse bir moda firması gibi görünüm trendleri yaratarak Office ve Windows ürünlerini temel işlevlerini neredeyse hiç değiştirmeden (amiyane tabirle aynı eşşeği boyayıp babasına tekrar satarak) yeniden satabilmektedir. Bu elbette ayrı bir yazı konusudur.
 |
| Soldaki MS Excel 1992 model, sağdaki 2007 model |
Hoş, fiziksel ürünler, örneğin otomobiller de elektronik eklenti bağlamında işlev çorbası haline geliyorlar, ama yazılımdan en önemli farkları, ölebilme imkanına sahip olmaları. (Otomobillerin ömrü aslında uzun diye itiraz gelebilir, ama bu uzun ömür muhtemelen ilk sahibinde değil, sonraki ve daha fakir olan sahibinde devam edecektir. Ayrıca ne olursa olsun otomobillerin işlev kümeleri bir yazılıma göre çok daha küçük ve belirgindir.)(Sonradan ekleme: Cep telefonları ölebilme özelliğine sahip bilgisayarlar olarak ayrı bir yazıyı hakediyorlar. Yazacağım)
Yaşatma Çabaları
Yazılımı düzgün şekilde yaşatmak yolundaki en önemli çaba, düzenli ve disiplinli şekilde yapılacak refaktöring'dir. Refaktöringi kısaca açıklarsak, bir yazılıma özellik eklendikçe kod bozulmaya ve kokmaya başlar. Koku alındıkça yazılım koduna dalınmalı ve kokunun kaynağı bulunarak bir daha ortaya çıkmayacak şekilde yok edilmelidir. Eğer bu zamanında yapılmazsa teknik borç hanesine yazılır. Sonra bu borcun ödenmesi, yani gerekli refaktöringin yapılması gerekir.
Yaşama başlayan bir yazılıma gelecek ilk tehdit, "ikinci sistem etkisi"'dir. Yaşama hakkı kazanan bir yazılım sempatiktir, ve kullanıcıları dahil herkesin aklına bol bol eklenebilecek yeni özellikler gelir. Yazılımcılar başarının da getirdiği sarhoşlukla 2.0 versiyonunu geliştirmeye başlarlar. Geliştirilen yeni yazılımın içine kullanıcıların ve yazılımcıların aklına gelen her fikir (çok verimlidir bu dönem lanet olsun), ve yanında 1.0'ı geliştirirken bir an önce bitsin diye yapılamamış özellikler de eklenmeye çalışılır.
Beklenti böylesi yüksek olunca sonuç, genelde hüsrandır. Özellikle yazılım hayatına prototip olarak başlamışsa ikinci sistem etkisi daha da şiddetli olur. Yine de bu öldürücü değildir, çünkü en kötü ihtimalle 1.0 versiyonu kullanılmaya devam edilir. Gelgelelim 2.0 geliştirilecek diye 1.0 versiyonuna hiç refaktöring yapılmamıştır. Teknik borç artmıştır, ama 2.0 için o kadar çaba harcanmıştır ki, refaktöring için takat kalmamıştır.
Veyahut 2.0'a kör topal geçilir, ama 2.0 yetiştirilecek diye bir çok refaktöring yapılmayarak borçlu bir geçiş yapılmıştır. Üstteki paragrafın son cümlesini tekrar yazalım: 2.0 için o kadar çaba harcanmıştır ki, refaktöring için takat kalmamıştır.
Genelde yazılım ilk darbeyi ikinci sistem etkisinden alsa da, bu etkiyi bir şekilde atlattığımızı farzetsek bile, her ihtimalde refaktöring çabalarının teknik olmayan yöneticilerin desteğini alması neredeyse imkansızdır. Hoş, teknik yönetici olsa bile, firma besin zincirinin yukarısına çıkıldıkça nasıl olsa teknik olmayan, yani refaktöringi engelleyecek bir yöneticiye rastlanacaktır. Morali bozmak pahasına şunu da ekleyelim ki, aslen teknik kökenli olsa bile, yukarının oksijeni az stresli atmosferinde mücadele veren bir yöneticinin de refaktöringe ikna edilmesi zordur. Bir kere neden yapılması gerektiği anlaşılmaz, her zaman kuyrukta bekleyen çok önemli para kazandıracak özellikler vardır. Onların yapılması gerekir. Refaktöring sonra yapılabilir. Hem bozulmayan bir şeyi neden tamir edesiniz ki?
Diğer yandan yazılım geliştikçe gerek yazılımsal olarak, gerekse son kullanıcı için dökümantasyon yapılması gerekir. Genelde çoğu yazılımın herhangi bir dökümantasyonu yoktur, bu işe vakit ayrılabilen şanslı yazılımlar için ise, her ne kadar ilk dökümantasyon şevk ve çoşkuyla yapılmış olsa bile, aynı refaktöring gibi dökümantasyonun da değişikliklerle beraber güncellenmesi gerekir. Ama ah zaman, buna izin vermez ki! Ayrıca özellikle ilk zamanlarda bilgiler programcıların ve kullanıcıların kafasında canlıdır, sanki hiç unutulmayacakmış gibi gelir.
Yanlış anlaşılmasın, refaktöring yapılmadan da yazılımda değişiklik yapılabilir. Bu değişiklikler "saplama" adını verdiğimiz yöntemle yapılır. Örneğin yeni bir veri tutulması gerektiğinde veritabanı tablosundaki varolan kolonların işe yarayıp yaramayacağı araştırılmaz, hemen yeni bir kolon eklenir. Belki bu işlem sonucunda varolan bir kolon boşa çıkıyordur, ama o kolonu silmek için varolan kodun incelenmesi ve yeniden yapılandırılması gerekeceğinden (yani refaktöring), ve bu sonraya bırakıldığından (bu da teknik borç) veritabanı tablolarındaki kolon sayısı artma eğiliminde olur. Bir süre sonra veritabanı tabloları sayıca şişerler, kimse ne işe yaradıklarını tam olarak bilemez, silmeye de cesaret edemez.
Sürünme Safhası
Refaktöring yapılmaması sebebiyle artan teknik borçlara süresi geçmiş dökümantasyon da eklenince bir noktadan sonra yazılım değişiklik yapılması oldukça zor hale gelir. Zira yapılmaya çalışılan her değişiklik, yazılımın başka yerlerinde öngörülemeyen başka hatalara yolaçabilir. Hem hataları düzeltilemeyen hem de özellik açısından geride kalmış yazılım, bir süre sonra kullanıcıların memnuniyetsizliğine yolaçar.
Kullanıcıların memnuniyetsizliğine yol açan yazılımdan, bir süre sonra programcılar da kaçmaya başlar. Bir kere, eskiden güzelce çalışan yazılımın şimdi kötü olmasının faturası en son çalışan programcılara çıkarılır. Kimse bütün gün aşağılanmaktan hoşlanmaz. Bu yüzden artık cazibesi kalmamış yazılımın bakımını yapacak yazılımcıları da bulmak zordur. Genelde ofis içi politika mücadelesi sonucunda yeni işe alınmış programcılar bu göreve atanabilir, ancak bunlar bu işi hem yapamazlar, hem de işin sıkıcılığı ve usandırıcılığı karşısında işten çabuk ayrılma eğiliminde olurlar. Bu durumda yönetim zoruyla bakım işi tecrübeli programcılara verilir. Bu kişiler de böyle bir iş kilitlendiğinde genelde ilk fırsatta işten ayrılırlar, veyahut ayrılmasalar bile depresif bir şekilde çalışmaya devam ederler. Bu kişileri ofiste ayırtetmek tecrübeli bir göz için çok kolaydır.
Teknoloji geliştikçe, yani yazılımın üzerinde çalıştığı donanım, işletim sistemi, veritabanı sunucusu gibi altyapı parçaları değiştikçe, yazılımın da buna göre adapte edilmesi gerekir. Ancak bu tarz değişiklikleri yapmak da artık zorlaşmıştır; herşeyden önemlisi artık istek yoktur. Eski donanımlar, işletim sistemleri, veritabanı sistemleri herşeye rağmen yaşayan ve işe yarayan yazılımın hatırına kullanılmaya devam edilir. Bu durum, sözü edilen teknoloji katmanlarını sağlayan firmalar için yeni ürün satamamak anlamına gelir ve hiç hoşlarına gitmez. Gelgelelim onlar da durumu fırsata çevirip eski ürünleri için daha çok teknik destek parası isterler. Artık yazılımın çalıştırılma maliyeti de artmıştır.
Can Çekişme
Bu safhada yazılımdan ne kullanıcılar ne de programcılar memnun değildir. Toplantılarda sıra sözkonusu yazılıma gelince derin bir offf çekilir. Bazı yöneticiler öfke nöbetleri, tehdit gibi metodlarla durumu düzeltmeye çalışırlar, ama bu doğal olarak sinir bozmaktan başka hiçbir işe yaramaz. İş akışı da değiştirilemeyen yazılıma uymak zorunda kalır, bu da rekabet kaybına yolaçar.
Genelde bu durumlarda yazılımı yeniden yazma kararı alınır. Bu işe belli bir şevkle başlanacağı düşünülse bile, genelde sonuç iyi olmaz. Çünkü eskimiş dökümantasyon yüzünden aslında yazılımın ne yaptığı çok belli değildir. Bunu koda bakarak anlayabilecek programcılar da ya bu işe vakit ayırması imkansız derecede üst düzey yönetici olmuşlardır, ya da çoktan işten ayrılmışlardır. Yeni yazılım eski yazılımın tüm özellikleri sağlamalıdır, ama ortada belli bir özellik kümesi bile yoktur; genelde son dakikada "aaa, bu yazılım X'i yapamıyor" diye ortaya çıkar ve sinirler gerilir. O yüzden yeni yazılım popülarite kazanamaz, zaten kullanıcılar şikayet etmeyi severler, ama değişikliği pek sevmezler. Ayrıca yeni yazılım geliştirilirken eskisinin de iyi kötü bakımının yapılması gerekliliği programcıların iş yükünü arttırıyordur; iki arada bir derede kalınır. Sinirler gerilir. "İkinci sistem etkisi"nin çok daha kötü versiyonu yürürlüktedir.
Bu yazı ölüme gelmeden bitecek, çünkü yazılımın ölümü ancak yeni yazılımla veya işin iflas etmesiyle olur. İkisinin de gerçekleşmesi zordur. Genelde yazılım can çekişerek, sürünerek de olsa, ama gerekirse çevresindekileri öldürerek çalışmaya devam eder. Örneğin Kaliforniya valisi ünlü aktör Arnold Schwarzenegger gibi güçlü bir adam bile 1960'lardan kalmış ve de ölmemekte direnen ücret bordrosu yazılımı yüzünden eyalet çalışanları için asgari ücret reformunu hayata geçiremez. Veyahut COBOL gibi kimsenin kullanmak istemediği bir programlama dilinde geliştirilmiş yazılımlar 2009 itibariyle İngiltere'deki iş hareketlerinin %70-%80 arasını yönetirler.
