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ı: 1363

Çok komik. 🙂 Zaman zaman duyuyorum, IT yöneticilerinin “biz çevik sürece geçtik” ya da “artık çevik süreçler kullanıyoruz” gibisinden cümlelerini. Hemen şunu soruyorum ya da içimden geçiriyorum: “Daha önce neyi kullanıyordunuz ki???” 🙂 Öyle ya bildiğime göre taa Orta Asya’dan bu yana bizde kervan yolda düzülüyor. Yüzyıllardır zaten çevik hatta aşırı çevikiz. O kadar çok heyecanlıyız ve aklımız heyecanımıza o kadar çok yenik düşüyor ki birisinden bize bir iş yapmasını istediyip de bir süre sonra “düşünüyorum” cevabını alırsak çoğunlukla “düşünme yap” ya da “aptal mısın neyini düşünüyorsun?”  şeklinde laflar ediyoruz. İşin tuhafı, yazılım geliştirme gibi son derece soyut ve aşırı değişken çıktıları olan bir disiplinde de benzer şekilde kervanın yolda düzüldüğünü düşünmemiz. Tabi tüm bunlar birer kültür meselesi. Yazılım geliştiren ya da yöneten kişi, örneğin milli takımmızın Hollanda maçında bir mucize bekliyor. Zaten Çeklere karşı 3-2’lik mucizeyi de biz gerçekleştirmiştik. Olaylara bakışımız, toplumun hangi katmanından gelirsek gelelim aynı açıdan yani, sistematiklik yerine gelişi güzellik, takım yerine tek tek kişilerin kurtarma becerilerine odaklı, uzun vadede bir şeyleri yerleştirip başarmak yerine tamamen random, rastgele, ne zaman olacağı belli olmayan çıkışları beklemek. Yazılımı da bu şekilde ele alıyoruz genelde. Dolayısıyla diyorum ki bize sadece “çeviklik” değil “disiplin” de lazım. Bize “agility” değil “process-orientedness” lazım daha çok, yani kimin ne yapacağının belli olduğu, iyi tanımlandığı yazılım geliştirme süreçleri gerekli diye düşünüyorum.

Ne demek istediğimi bir örnekle anlatmaya çalışayım. 15 yılı aşkın süredir iş yazılımları geliştiren bir şirkete danışmanlık veriyorum. Zamanında bu şirketin yazılım müdürlüğünü de yaptığımdan 15 yılda nereden nereye geldiklerini çok iyi biliyorum. Ben şirketten ayrılırken 45-50 kişilerdi, şimdi ise 150’ye dayandılar sanırım. Sirketi zamanında kurup tırnaklarıyla kazıyarak bu noktaya getiren kişiler uzun süre haklı olarak programcılarının, müşterilerinin sorunlarını çözmekte sıklıkla yetersiz kaldıklarından şikayet eder ve problemi “proaktif olmamak” ya da en azından “inisiyatif almamak, alamamak” çekirdek davranışına indirgerlerdi. Tamamen haklılardı. Çünkü son derece çekirdekteki iş uygulamalarını geliştiren bu kurumun çalışanlarının müşterilerinin problemlerini çözmede “iki eli kanda olsa bile” şeklinde bir davranışa sahip olması, müşteri memnuniyeti açısından son derece önemliydi onlar için. Dolayısıyla “agile” davranarak işe başladılar. Simdi ise büyüdüler, “analist-programcı-proje yöneticisi-tester” düzeninden PMP sertifikasına sahip proje yöneticilerinden oluşan proje yönetim ofisine, yazılım mimari gibi rollere sahip bir development grubuna, 30 civarında analistin olduğu bir analiz grubuna, yeni oluşturulmakta olan ap-ayrı bir tester yapısına ve İK, Finans vb destek birimlerine sahip, ülkemiz standartlarında kocaman bir yazılım evi haline geldiler. Ve geldikleri noktada artık sistematik olmak zorundalar, kaliteye daha fazla önem veriyorlar, çünkü sektörlerinde bu ülkede lider oldukları gibi yurt dışına da açılmaya çalışıyorlar. Ve artık yöneticileri örneğin developerlarının müşteriden gelen bir hata bildirimine balıklama atlamalarını istemiyor. O hatanın kayıtlara geçmesini, gerçek sebebinin bulunmasını, gerekiyorsa analizinin yapılıp, etki ve maliyet gibi bilgilerin ortaya çıkmasını, o anı kurtarmak yerine daha sağlıklı bir çözüm üretilip, bu çözümün gerekiyorsa tüm müşterilerde yaygınlaştırılmasını hatta bir sonraki sürümün parçası olmasını ve en önemlisi de bu bilgilerin ilgili herkes tarafından bilinmesini istiyorlar. Bu yüzden developerin bu döngüye girmeden hatayı kendi başına halletmeye kalkmasının, nihayetinde, hata halledilse bile doğru bir davranış olmadığını, belki müşterisini memnun edeceğini ama şirketi açısından sürdürülemez bir davranış olacağını, yine müşteri odaklı ama daha sistematik bir çözüm döngüsü içinde olmak gerektiğini çalışanlarına anlatmaya çalışıyorlar. Çalışanlarının kariyer planları ve mutlu olmaları üzerine daha fazla kafa patlatıyorlar. Eskiden eğitim harcamaları ancak zorunluluk durumunda ve pek çok kısıtla yapılabilirken şimdi her sene San Francisco’ya JavaOne’a 4-5 çalışanını gönderiyorlar, çalışanlarını elde tutmak ve daha mutlu ve üretken kılmak için “yetenek yönetimi” çalişmaları yapıyorlar.  Çünkü artık çok daha zor bir yönetim problemiyle karşı karşıyalar. Sadece çevik olmak yerine sistematik çeviklik istiyorlar. Bu amaçla analiz olsun tasarım olsun ya da development olsun, nasıl bir sürece sahip olmaları gerektiği üzerine birlikte kafa yoruyoruz. Risk analizi, bütçe çalışmaları, yıllık eğitim planı vb. çalışmalar çok daha önemli hale geldi artık. Hala çevikler ama artık daha çok disiplinli bir çeviklik var.

Ote taraftan çevikliği yukarıda olduğu gibi kelime manasıyla almak yerine bir yönetim felsefesi ya da yazılım geliştirme paradigması olarak ele aldığımızda, yani “agile processes” ya da “çevik süreçleri” düşündüğümüzde, pek tabi olarak yukarıda kastettiğimiz çeviklikten farklı bir noktada durduğumuz aşikardır. Bunu da şöyle açıklayabiliriz: Çevik süreç kavramı bizim ülkemizde çıkmadığı gibi bu paradigma çerçevesinde oluşturulan metodolojilere bir katkımız da henüz olmadı. Çevik süreçlerin temeli, ozellikle ABD’de aşırı yapısal ve bürokratik, bundan dolayı hantal ve müşteriden uzak yazılım organizasyonları ve onların yazılım geliştirmeye yaklaşımlarına bir tepki olarak yayınlanmış Agile Manifesto‘ya dayanır. Tabi olarak bu manifesto bir günde yayınlanmadı. Eskiden bu yana yazılımın başarısızlık ve başarısının neye bağlı olduğu üzerine kafa yoran pek çok akademisyen ve uygulayıcı vardı. Bunların en iyi bilinenleri Barry Boehm ve onun spiral modeli ile Kent Beck’in Extreme Programming’idir. Benzer şekilde Jim Highsmith’in yazılarını, bu konudaki itirazları ve çözüm önerilerini okuduğumu hatırlıyorum. Bu anlamda 90lı yıllarda Unified Process gibi, yazılım projesini bir seferde bir big bang gibi kurmak yerine daha daha müşteri odaklı, mimariyi merkeze koyan ve riski önceleyen metodolojiler konuşulmaktaydı. Agile Manifesto da bu dünyanın babaları tarafından, ağır süreçler yerine insanları ve iletişimi, hantal ve okunmayan dokümanlar yerine yinelemeli ve artımlı (iterative, incremental) olarak geliştirilen, her an çalışır halde tutulan ve müşteri tarafından test edilebilen kod yapısını, müşteride analiz yapıp, “2 sene sonra kullanıcı kabul testinde görüşelim” diyen anlayış yerine, müşteriyle yakın ilişki içinde olan, onu da elini taşın altına koymanın en temel risk yönetimi olduğunu düşünen bir paradigmayı, proje planını kutsamak yerine değişimi nasıl yöneteceğini düşünen bir felsefeyi dünyaya duyurdu. Çok da iyi oldu, özellikle de bizim için. Neden? Çünkü bizim zaten genlerimizden, kültürümüzden, alışkanlıklarımızdan ve aşırı faydacı ve anlık yapımızdan dolayı çok daha uzunca bir müddet o hantal ve aşırı bürokratik yazılım geliştirme metodolojilerini uygulamamız mümkün değildi. Bu yüzden çevik süreçler, bu hantal süreçlere sahip yazılım evlerine dinamizm getiriken bize sistematiklik getirdi. Ne kadar sistematiklik? Tam olması gerektiği kadar bence? Fazlası değil, çünkü fazla sistematiklik bize göre değil. Bu anlamda çevik süreçler, bizim gibi bir kaç bin senedir çevik yaşayanlara disiplin sağlayor, ben de bu yüzden yukarıda “disiplinli çeviklik”i kullandım.

Agile Manifesto’ya imza atanlardan birisi de Jeff Sutherland aynı zamanda Scrum’ın da yaratıcısı. Yukarıda bahsettiğim o hantal yapıdan tamamen haberdar ve ona karşın daha çevik ama gerektiği kadar sistemli bir yazılım geliştirme yönetim metodoloji ortaya koymuş birisi. Scrum ülkemizde de yaygınlaşıyor ve ben buna çok seviniyorum. Bize disiplin getirirken damarlarımızda olan çevikliği ise övüyor ama onu sistematik olarak kullanmamıza imkan sağlıyor.

Bu blogun takipçilerinden olan bir dost ise bana gönderdiği bir emaille, Jeff Sutherland’in 16-17 Ocak 2014 tarihlerinde ülkemizde yapılacak Scrum Master eğitimi için İstanbul’da oalcağını hatırlattı. Scrum Turkey tarafından düzenlenen bu çalışmayla ilgili ayrıntılı bilgiye buradan ulaşabilirsiniz.

İçimizdeki çevikliğe zapt-u rapt vurmanın zamanı geldi de geçiyor bile 🙂

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