Yazılımı Geliştirmek mi Geliştirmemek mi? İşte Bütün Mesele Bu!

Bir kurum düşünün ki, bir şirket örneğin, çalışanlarının bir araca, binek otosuna, ihtiyacı olduğunda paaat, hemen araba yapmaya koyuluyor. Ya da diyelim ki kurum çalışanları çok sık uçakla seyahat ediyorlar, kurumun tepesindeki yönetici bakmış olmuyor “devamlı uçak bileti al uç, nereye kadar?” diye düşünüp, biz de kendi uçağımızı yapalım diye karar veriyor ve başlıyorlar işe…

Komik değil mi? Peki aynı hikayeyi bir de şöyle anlatayım. Bir kurum düşünün ki elle yaptıkları işleri hızlandırmaya ihtiyacı var. Bu da bir yazılım ile gerçekleşebilir. Mesela kurumun bir müşteri ilişkileri yönetimi yazılımına ihtiyacı var. Benzer şekilde kurumun yöneticisi karar veriyor, “kendi yazılımımızı geliştireceğiz” diyor. Hoop, ilanlar veriliyor, programcılar işe alınıyor, BT’den anlayan birileri de kurulan BT bölümünün başına getiriliyor. Neden ilk başta anlattığım komik geliyor da bu hikaye komik gelmiyor?

Bir hikaye daha anlatayım madem: Kurumumuz büyüdü ve çalışanlarına öğle yemeği hizmeti sunmak istiyor, belki dışarıdan yemek sağlamanın daha pahalı olduğunu düşünüyor; güzel. Ve aşcı, hizmetli vs. işe alıp, başlıyor kendi yemeğini üretmeye.

Şimdi sorum şu? Yazılım geliştirmek, yemek yapmak gibi nispeten daha az bir uzmanlık ve emek gerektiren bir şey midir ki kurumlarımız kendi araçlarını ve uçaklarını yapmaya girişmezlerken, kendi yemeklerini ve yazılımlarını üretmeye girişiyorlar? “Yemekleri aşçılar yapar, yazılımları da programcılar yapar” diye mi düşünüyorlar yoksa?

Bir kurum neden kendi yazılımını yapmak istesin ki? Neler olabilir sebepleri? Bence bu sebepler iki başlık altında incelenebilir. İlki, kurumun yöneticilerinin, yemek gibi yazılımı da kendilerinin yapabileceklerini düşünmeleri, ikincisi ise herkesin yaptığı işi en ince detayıyla bildiğini ve bu bilgiyi yazılıma aktarabileceğini zannetmesi.

İlk sebep, yazılımla ilgili çok temel bir algı bozukluğu olduğunun göstergesi olan bir durum. Yani yazılımı, programcının yaptığı programlamaya indirgemek ve yazılım mühendisliği olarak ifade edilen heyhula displini “alırız iki tane programcı, ben anlatırım onlar yazar” şeklinde, hiç bir şekilde süreç barındırmayan bir “problem çözme” olarak görmek. (Zaten evvel Allah doğuştan her Türk, bir problem çözme uzmanı olarak dünyaya gelir, aldığı mühendislik eğitimi ise ona sadece bir diploma sağlar 🙂 ) Hele üniversitede bir de Fortran dersi almışsa bunu diyen kişi, yapacak hiçbir şey yok demektir.

Halbuki, yazılım üzerine kafa patlatan babalar diyorlar ki yazılım pek çok mühendislik ürününden daha zordur, çünkü yazılım soyuttur, kavramsaldır. Dolayısıyla bir yazılım sisteminin sahip olabileceği durumların (state) sayısı, elle tutulan ve gözle görülen pek çok mühendislik ürününden kat be kat fazladır. Bu yüzden pratikte sınırsıza yakın sayıda duruma sahip olan bir yazılımı tasarlamak, kodlamak, test etmek, belgelendirmek, yönetmek ve bir başkasına aktarmak çok zordur, hatta diğer mühendislik ürünlerindeki kalite sınırları içerisinde bunu yapmak ise zaten teorik olarak imkansızdır.

Günlüğümde daha önce yayınladığım ve üzerine yazı da yazdığım “No Silver Bullet” isimli makalenin yazarı Brooks’a göre yazılım geliştirme problemine en iyi çözüm “yazılımı geliştirmemektir“. Bakın aynen şöyle demiş üstad: “The most radical possible solution for constructing software is not to construct it at all.” Yani “yazılım geliştirme için en kökten mümkün olan çözüm onu kesinlikle geliştirmemektir.” Nasıl çözüm?

Peki ihtiyacı varsa yazılıma, ne yapacak kurum? Satın alacak tabi ki, yani araca ya da uçağa ihtiyacı olduğunda yaptığı gibi, o işi en iyi yapanından ya fiziksel olarak ya da hizmet olarak satın alacak. Olay bu kadar basitken, yazılım ile ilgili algımız hangi noktadadır ki insanlar “bizim neyimiz eksik, yazarız yazılımımızı” diye düşünüyorlar? Hatta yazılım geliştirmeyi bir prestij konusu haline getirebiliyorlar.

Hatta bakın, mizahın dibine vuralım ve insanoğlunun yazılımla ilgili durumunu dile getiren şu söze kulak verelim: “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” Türkçesini vermeye çalışayım: “Bugün programlama denen şey, aptalların bile kullanabileceği daha büyük ve iyi programlar yazmaya çalışan yazılım mühendisleriyle daha büyük ve iyi aptallar üretmeye çalışan Kainat arasındaki bir yarıştan ibaretttir. Şu ana kadar Kainat kazanmaktadır.” Nasıl? Süper değil mi? Cook bir fantazi romancısı ve bu sözü 1989’da söylemiş.

Cook’ın bir incisi daha var: “The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea.” (Cook bunu da 1995’te söylemiş.) Yukarıda bahsettiğim yazılım ile ilgili hastalıklı algımız acaba Cook’un bahsettiği 3 en tehlikeli şeyden ilki ve sonuncusu ile ilgili olabilir mi? Her yerde tonla var da. 🙂

Evet CRM, ERP vb. yazılımları üretmek, asal sayıları bulan bir program yazmaktan çok daha zor. En temel fark ise ilki bir süreç, ikincisi ise bir süreç gibi algılayamayacağımız kadar kısa bir sürede yaptığımız bir problem çözme. Aslında biraz üzerine düşündüğünüzde asal sayıları bulan program yazmanın da bir süreç olduğunu, birbirini takip eden ayrık zihinsel faaliyetler içerdiğini ve her bir faaliyetin farklı yetkinlikler gerektirdiğini farkedersiniz. Örneğin “asal sayı”nın ne olduğunu ortaya koymak ile daha sonra programı, örneğin Java ile, yazmak tamamen ayrı bilgi ve yetkinlik gerektiriyor.Ve çok kısa da olsa bu faaliyetler ayrık olarak zihnimizde yapılıyorlar.

Yukarıdaki örnekte iş bilgisi olarak adlandırabileceğimiz “asal sayı” bilgisi o kadar temel ki biz onu ortaya koymak için çaba bile sarfetmiyoruz. Ama aynı basitliği, bir ERP ya da başka bir iş yazılımı geliştirirken bulmayı ummak Cook’un yukarıda bahsettiği “daha büyük ve iyi aptallık”tan başka nedir ki? Böyle bir basitleştirmenin iki sebebi var: İlki yazılımın “büyük” olmasından ne anladığımızla alakalı: Bir sayıya kadar olan tüm asal sayıları bulan ya da bir sayının asal sayı olup olmadığını bize söyleyen program ile ERP gibi bir işi modelleyen yazılımlar arasındaki zorluk farkı sadece bir “çok” kelimesiyle vurgulanamayacak kadar farklı boyutta. Yani yazılımlar, diğer pek çok mühendislik ürünü gibi doğrusal olarak büyümezler. Dolayısıyla da tekerleğin daha büyüğünü yapmak ya da kolonun daha uzununu veya sağlamını yapmak gibi birşey söz konusu değil yazılımda. Yazılımda iki farklı yapı birbirine benziyorsa bu bir hatadır ve bu iki yapı, tek bir yapı altında birleştirilmelidir. Dolayısıyla yazılımın büyümesi, sayı ve boyut olarak büyümek demek değildir, çeşitlilik olarak büyümektir. Ve her biri, diğerinden olabildiğince farklı olduğu için her birini geliştirmek apayrı bir zeka ve gayret gerektirir.

Asal sayı programını basitçe yapan bir kişinin ERP yazılımını benzer şekilde yapabileceğini düşünmesinin diğer sebebi ise herkesin yaptığı işi her yönüyle çok iyi bildiğini düşünmesi. Bu da ikinci tür temel algı bozukluğumuzu oluşturuyor. Bir işi elle yapan kişi, hele de uzun süredir yapıyorsa, bu konuda bir yazılım geliştirmekten bahsedildiğinde söyleyeceği şey “ben anlatırım programcılar da yazar”dır. En azından ben bunu çok sık duyuyorum. Ama bence gerçek hiç de öyle değil. Asal sayılar hakkında taa 10-12 yaşında öğrendiğimiz ve çok basit olduğunu düşündüğümüz şey üzerine insanlığın üç-beş bin senelik bilgi birikimi var. İş yapış şekillerimiz hakkındaki bilgimiz kaç senelik? Bu konuda, yine “No Silver Bullet” makalesinden bir alıntı yapayım:

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Türkçesi:

“Bir yazılım sistemi geliştirmenin en zor olan kısmı, ne geliştireceğinize kesin olarak karar vermektir. Kavramsal olan böyle bir işin diğer hiçbir kısmı, detaylı teknik ihtiyaçları, bütün kullanıcılara, makinalara ve diğer yazılım sistemlerine olan arayüzleri de dahil olacak şekilde, belirlemek kadar zor olamaz. Diğer hiçbir kısmı, yanlış yapıldığında, üretilen sisteme bu kadar zarar vermez. Diğer hiçbir kısmın daha sonradan düzeltilmesi bu kadar zor olmaz.”

Dediği şey şu: “Ben bu işi senlerdir yapıyorum, çok iyi biliyorum, ben anlatırım programcılar yazar” ya da “çalışanlarımız iş süreçlerimizi en detayıyla size aktaracaklar” gibi sözlere kanmayın. İnsanlar yazılım projelerindeki gecikmelerin genelde programcıların kifayetsizliğinden kaynaklandığını düşünme eğilimindedirler. Halbuki projelerdeki en büyük gecikme sebebi, özellikle bu proje ülkemizde yapılıyorsa, kesinlikle ve kesinlikle ne yapılması gerektiğini bilmemek ve karar da verememektir. Projeye üzerine çok da düşünülmemiş, ayrıntıları ortaya kesinlikle konmamış ama heyecan verici bir fikirle başlanır: Cook’un “a user with an idea” ile kastetiği şey bu olsa gerek 🙂 Daha sonra analistler ya da analist-programcılar, kullanıcıdan, müşteriden, yani projenin sahibi kimlerse onlardan, detayları istemeye başlarlar: “Bunu hep böyle mi yaparsınız?”, “Bunu burada mı yaparsınız?” “Bunu sadece siz mi yaparsınız” gibisinden sorular gelince projede ilk patlaklar ortaya çıkmaya başlar. Çünkü kullanıcının o ana kadar hiç düşünmediği bu ayrıntılı sorulara cevap vermeye bazen bilgisi, bazen yetkisi, bazen de niyeti, çoğu zaman da üçü birden yoktur. (Halbuki yazılım projelerinin “ihtiyaç analizi” safhası, nasıllığı tarif edilmiş iş süreçlerinin, yazılım merkezli ihtiyaçlarına odaklanmalıdır, iş analizi içermemelidir. Yani böyle bir çalışmada üzerinde düşünülecek ve karar verilecek konular, idealde, olabildiğince “burada bu düğme (button) olsun mu?” ya da “şu bilgiyi bu şekilde mi sunalım” gibisinden yazılımsal noktalarla sınırlı olmalıdır.) Yapılacak yazılımın bir eski halinin hali hazırda kullanılıyor olması halinde bile durum pek değişmez, çünkü tonla yeni özellik, entegrasyon noktası, yeni tür kullanıcı vs. vardır.

Peki kim bilir de cevaplar bu soruları? Çoğunlukla hiç kimse. Neden? Çünkü işleri yapan insanlar, işlerin günlük meşgalesinde sistemli olarak işleri hakkında düşünmezler. Bu durum tamamen tabidir ve de kesinlikle onların suçu değildir. Çünkü kurumda bulunan birilerinin, çalışanların yaptıkları işleri formal olarak tarif etmeleri gereklidir. Bu da bizi “süreç” kavramına götürür. İş bölümü, uzmanlaşma gibi kavramların da içinde olduğu süreç  kavramı, modernleşmenin, aydınlanmanın, sanayi devriminin en temel yapı taşlarındandır. Batı, yaptığı işi süreç olarak tarif edip, süreçlerdeki uzmanlık gerektiren ayrık faaliyetleri, iş bölümü ile uzmanlarına havale ettiği için üretimde bu hale geldi. Dolayısıyla herhangi bir karmaşık işin, faaliyetin, üretimin ya da ne bileyim ameliyatın en temel tarifi süreç üzerinden yapılır oldu.

Bir Batı ülkesindeki iş ortamında ya da en azından ABD’de bu o kadar açık ve seçik görülen bir şeydir ki, işlerde bir aksama olsa kimse “kim aksıyor” ya da “kim bunu böyle yaptı” diye sormaz genelde, “Ne aksadı” ya da “Neresi problemli” gibi süreç-odaklı sorular sorulur. Ülkemizde ise süreç kavramı zihnimizde olmadığından, sorularımız direk olarak “kim” ile başlar. Yani hedefimizde süreç değil, daha sorarken anlaşılan, bir “kişisel kifayetsizlik” vardır. “Haa, Ali mi, zaten o …” diye devam eder zaman zaman. Ülkemizde böyle bir yanlışlığı üstü kapalı ama herkesin net olarak anladığı bir biçimde “zeka”ya hamletme eğilimi de vardır. Halbuki dünyadaki işlerin belki %99’u IQ’sü 80 olanlar tarafından yapılabilecek şeylerdir. (NVT Bilim’in Kasım sayısında, insanların %95’i IQ olarak 70 ile 130 arasında, %99,5’i ise 60 ile 140 arasındaymış. Bu bilgiler de benim teorimi destekler görünüyor.) Ben ABD’de bulunduğum ve çalıştığım ortamlarda, ne hoca ya da öğrencilerin ne de iş arkadaşlarımın ve yöneticilerimin, bir aksaklıkla ilgili olarak sürece odaklanmadan direk kişiye ve onun kifayetsizliğine odaklandıklarına şahit olmadım. Sorgulanan şey, önce sürecin doğru kurgulanıp kurgulanmadığı, sonra da sürecin o noktasında bulunan çalışanın, gerekli faaliyeti ya da çalışmayı yapmak için yeterli bilgi, yetkinlik ve tecrübeye sahip olup olmadığı, olmalıdır. Bu öylesine bir farktır ki ABD’ye örneğin, ilk gidenler, oradakilerin çoğunluğun aptal olduğunu düşünürler. Uzunca bir müddet kalanlar ise farkı farkederler, mesele zeka değil süreçtir çünkü. Ve 9 tane 80 IQ’lu adam ile bir tane 120 IQ’lu bir adam, takım kurup, süreç bazlı çalışarak, 10 tane 130 IQ’lu ama süreç kavramını içselleştirmemiş bir takıma üretim hızında olsun kalitede olsun galip gelirler.

Toplarlarsam, belli bir iş alanında çalışan kurumlar, ihtiyacı olan yazılımları yazmaya çalışmak yerine, işlerini süreç tabanlı olarak tarif etmeliler. Bunun için önce işlerini “kim, ne zaman, neyi, nasıl yapar, neyi üretir, sonrasında ne olur, kurallar nelerdir?” gibi soruları sorarak en ince ayrıntısına kadar belirlemeliler. Sonra bu tarife uygun bir şekilde süreçlerini ciddi bir süre çalıştırmalılar ve çalışanlarını bu süreçlerle ilgili yetkinliklerle donatmalılar. Bu arada da süreçlerini sürekli iyileştirerek en verimli, hızlı, bürokrasiden arınmış hale getirmeliler. Ve eğer bir yazılıma ihtiyaçları varsa, yazılımı geliştirmek yerine, olabildiğince standartlaşmış, “yağsız” (lean) hale gelmiş, çevikleşmiş (agile) süreçlerini, var olan yazılımlarla otomatize etmeyi tercih etmeliler. Tabi ki bu da kolay değil ve kendine göre tonla sorunu var ama yazılım geliştirmek apayrı bir dünya, kendine has özellikleri var ve tonla da sürece sahip; bu yüzden onu ehline bırakmak en akıllıcası. Bu noktada “en iyi kod, yazmadığınız koddur” 🙂  (Bu sözü başka kimseden duymadım, dolayısıyla aksi ortaya çıkana kadar telif hakları bana aittir. 🙂 ) sözünün doğruluğuna inanıyorum. Öte taraftan süreç haline getirilmeyen, standartlaşmamış çalışma şekli, kişiye bağımlıdır. Bu şekilde çalışan bir kurumun çalışanlarının işlerini tarif etmeleri, filin bir tarafını yakalayan körlerin yaptıklarından farklı değildir. Bu yüzden de süreç tabanlı çalışmamak, zaten hantal, yavaş ve verimsiz bir yapıya sebep olurken, bu yapıyı yazılımla betonlaştırmak, hantal ve verimsiz çalışma şeklini sadece ve sadece daha “pahalı” hale getirecektir. Nihai durumda işler hızlanmayacak belki de yavaşlayacaktır.

Ülkemizde, en iyi örneği olan SAP‘nin 40 yıla yaklaşan bir sürede ve binlerce yazılımcıyla bu hale geldiğine bakmadan, her önüne gelenin ERP karmaşıklığında bir yazılım yazmaya girişmesi, algımızdaki yazılım ve işimizle ilgili yanılsamalardan kaynaklanmakta. Ne yazılımın doğasından haberdarız ne de işlerimizi süreç olarak tarif edebiliyoruz. Bu durum böyle devam ettiği müddetçe Cook’un dediği gibi Kainat devamlı bizi aptal yerine koymaya devam edecektir.

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