Farklı vesilelerle “programlamanın neliği” hakkında konuşuyoruz, okuyup yazıyoruz. Ben de burada daha önce “Programlamanın Tabiatı ve Programcılık Üzerine – I” başlıklı bir yazı yazmıştım. Bu konu üzerine düşünen ve bizzat çalışan farklı kişiler de yazıp çiziyorlar. Örneğin arkadaşım Özcan Acar burada programcılığın sanat mı yoksa zanaat mı olduğunu tartışırken burada da bu konuda bir başka programcının yazdıklarını eleştirmiş.

Sıklıkla programlama ve programcılık, mühendis olup olmamak, okullu-alaylı vb. bağlamlarda tartışılıyor. Ben “üniversiteli mi alaylı mı” konusunu burada ele almıştım. Orada da açık bir şekilde ifade ettiğim gibi aslolan, “bilerek yapmak”tır. Yapmayı sürdürülebilir halde tutan şey bilmektir. Yapamadıkça zaten o şeyi bilmiyoruz demektir. Dolayısıyla her şart altında yapabilen ve başkalarına aktarabilen kişi, yapabilmeyi sürekli bir davranışa dönüştürmüş ve onu herkesin anlayabileceği yapıda ifade etmiş kişi, gerçekten bilendir.

Öte taraftan, gerek akademide gerek ise pratisyenleri arasında, yazılım mühendisliği olsun, onun çok temel ve belirleyici bileşeni olarak programlama olsun, tüm bunların gerçekte ne oldukları üzerine eskiden bu yana tartışmalar yapılmakta. Yani yaptığımız iş, bir bilim midir, yoksa mühendislik midir yoksa sanat mıdır yoksa zanaat mıdır? Ya da hepsi bir arada mıdır?

ABD’de yazılım sektörüne nitelikli insan yetiştiren bölümler ağırlıklı olarak “Computer Science” olarak adlandırılmalarına rağmen, bu bölümlerin yaptığı seyin ne kadar “bilim” olduğuyla ilgili şüpheler çoktur. Belki de bu isimlendirme bir öykünmedir ya da bu bölümlerin tarihi olarak Matematik’ten çıkmış oldukları düşünülerek isimlerine “science” eklenmiştir. Aslında iki kelimeden oluşan bu ismin problemi sadece “science” kelimesinden kaynaklanmıyor, esas problem”computer” kelimesinde. Dijsktra bir zamanlar “astronomy ne kadar teleskoplarla ilgiliyse, computer science da ancak o kadar bilgisayarlarla ilgilidir” (“computer science is no more about computers than astronomy is about telescopes.”) demişti.

“Computer Science” isimlendirmesi ilk defa 1959’da kullanılmasına rağmen yerine zaman zaman farklı kelimeler teklif edildi. “Datalogy” ya da “computics” bu alternatif isimlerden bir kaçı. Bu anlamda sanırım Avrupalılar daha düzgün bir isimlendirme yapmışlar. Bu alan için Avrupa’da genel olarak “automatic information” anlamlarına gelen “informatics”in türevleri kullanılıyor. Aslen yapılan iş de zaten verinin ve bilginin otomatik olarak işlenmesidir. “Computer” ya da “bilgiayar” sadece bir araç. Biz ise bu durumu dilimizde “bilgi” ve “saymak” kelimeleri ile ifade etmişiz. Başlarda, 70li yıllarda yani, bilgisayar yerine “elektronik beyin” dendiğini de hatırlıyorum ben. (Ülkemizde bu alanın “Bilgisayar Mühendisliği” olarak ifade edilmesi, hele benim üniversitemin, İTÜ, “Kontrol ve Bilgisayar Mühendisliği” gibi dahiyane bir isim 🙂 bulması ise başka bir tartışma konusu.) (Bu konudaki isimler için hızlıca Wikipedia‘ya bakabilrisiniz.)

Tanınmış ve tecrübeli bir bilim adamı olan Peter J. Denning, savunma amacıyla yazdığı “Is Computer Science Science?” başlıklı makalesinde, “Computer Science”ın (CS) ne kadar bilim olduğunu tartışıyor. Yazar makalesine alt başlık olarak şunu koymuş: “CS bilim olmanın tüm şartlarını taşıyor fakat kendinden kaynaklanan bir güvenirlik problemi var.” Yazara göre CS’i oluşturan 3 farklı disiplin vardır: Matematik, bilim ve mühendislik. Denning, CS’in, Fizik ve Kimya gibi bir “exact science” (bu terimi dilimizde nasıl ifade ediyoruz bilmiyorum, “kesin bilim” mi, bir kaç yere çevirisine baktım, “pozitif bilim” olarak karşılık verilmiş ki bu durum doğru bir çeviri değil bence) olduğunu savunuyor. Çünkü CS, adında “computer” kelimesini barındırsa da aslen bilgiyi işlemenin bilimidir. Algoritmalar ve hesaplamalı bilim (computational science) CS’i bilim yapan alanlardandır ve sayısal kesinliğe sahip çalışmalardır. Yazılımı tasarlama ve geliştirme ise temelde mühendislik çalışmasıdır. Yazar CS’in ne kadar bilim olduğu konusundaki itirazlara cevap vermeye çalışırken, “Computer Science”daki “science” yani “bilim” kısmının, diğer iki disiplin olan mühendislik ve matematikten daha geride kaldığını kabul ediyor ve ekliyor: Bu durum yakında düzelecektir.

Ben yaptığımız işin bir bilimsel tarafının olduğunu bir gerçek olarak kabul ediyorum. Programlama ve yazılım geliştirmenin son derece matematiksel dolayısıyla da bilimsel bir “hesaplama” alt yapısı var. Zaten bizim “bilgi” ve “saymak” kelimelerini yanyana getirerek ifade ettiğimiz şey İngilizce’de “computer” yani “”hesaplayıcı”dır. Veriyi ve bilgiyi işlemenin yöntemi olan her türlü algoritmik yapı, doğrudan matematiğin de konusudur. Algoritmaların karmaşıklığı, zaman ve bellek açısından ihtiyaçları, daha etkin şekilde ifade edilmeleri, tipik bir uygulamalı matematik ve sayılar teorisi konusudur. Sonuçta yazılan her program bir şekilde bir algoritmadır dolayısıyla da matematiğin ve bilimin konusudur.

Donald Knuth, programlama dünyasının muhtemelen yaşayan en ünlüsü olup, uzun yıllar Stanford’da hocalık yaptı. 1962 yılında tek cilt olarak yazmayı düşündüğü temel programlama kitabı, şu anda 4 cilt olarak yayınlanmış durumda. Hala yayınlamayı planladığı 3 cilt daha var. Knuth, programlamanın en temel kitabı olarak bilinen bu diziye, “The Art of Computer Programming” ismini vermiştir.  Çünkü Knuth’a göre programlama, bir sanattır.

Knuth gibi programlamanın bir sanat olduğunu iddia edenler, ondaki yaratıcılığa (creativity) ve bu yaratıcılığı ortaya çıkaran ilham (inspiration) kavramına vurgu yaparlar. Evet, yazılım geliştirmek de programlamak da zihinsel dolayısıyla da kavramsal, soyut ve son derece karmaşık uğraşlardır. Yazılım geliştirmenin bir sanat olduğunu iddia edenler, onun deterministic olmayan, yani başından, sonunun öngörülemeyeceği gerçeğini öne çıkarırlar. Bence de programlama, bilim ile sanatın iç içe geçtiği alanlardandır.

Mahiyeti itibariyle program yazmak ile bir film senaryosu yazmak ya da ne bileyim beste yapmak çok farklı şeyler değil. Yola çıkarken tüm detayını kestirmiş olamazsınız çünkü, ancak nereye gitmek istediğinizi bilirsiniz, hedefiniz vardır ama arasını ancak yolda anlarsınız çünkü kavramsal bir sentezlemeden bahsediyoruz. Programlama bir sanattır, çünkü doğru yoktur, aynı şeyi herkes tamamen farklı şekillerde yapabilir.

Sanatta da programlamada da çoğu kez ortaya koyduğunuz şey hiç bir zaman bir seferde mükemmel olmaz, muhtemelen pek çok yazarın, bestecinin eserlerine son halini vermeden, üzerinde senelerce çalıştıkları gibi yazdığımız programların da üzerinden tekrar tekrar geçmemiz gerekir. (Biz buna refactoring diyoruz.) Ve her bir üzerinden tekrar geçiş eserimizi daha mükemmel kılar ve bize muthiş bir haz verir. Hangimiz şöyle bir şey yaşamamıştır: Daha önce defalarca baktığınız, gördüğünüz kodunuzun öyle bir yönünü farkedersiniz ki, çok ufak bir değişiklikle örneğin müthiş bir kısaltma, hızlandırma yaparsınız ya da o ana kadar gözünüze çarpmamış bir hatasını giderirsiniz. İşte bu yaratıcılıktır, öngörülemezliktir ve böyle bir tecrübe sizin egonuzu tavan yaptırır. Belki de bu sanat ruhudur programcıları, diğer insanlar gözünde “farklı” kılan. Belki de bizi bilim adamlarından ayıran, “benimkisi daha güzel” düşüncesinin çok yaygın olmasıdır. Belki de başkalarının “ne anlıyorsun bundan” diye sorduğu durumda, o garip ifadelere bakarak sanki bir Mevlevi ayinindeymişcesine haz almaktır programlama.

Ben bu satırları yazarken Knuth’ın The Art of Computer Programming serisinin ilk cildini indirdim Internet’ten ve önsözünü okumaya başladım. Bakın ne diyor üstad:

“The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it can be an aesthetic experience much like composing poetry or music.”

Yani

“Dijital bir bilgisayar için program hazırlama süreci çok çekicidir, (bu durum) bunun sadece ekonomik ve bilimsel olarak mükafatlandırıcı/faydalı olmasından dolayı değil, aynı zamanda bir şiir yazmak ya da müzik bestelemek gibi estetik bir tecrübe olmasından dolayıdır.”

(Bu arada bu kitabı okuyanların CVlerini Bill Gates’e gönderebilirler, çünkü kendisi bu kitabı okuyabilenlerin nasıl bir tip olabileceğini biliyor 🙂 Kaynak, Wikipedia.)

Yazılım projesi de programlama da bir sanat eseri gibi yolda nelerin gündeme geleceğini ve nihayetinde detayda neyin ortaya çıkacağını çok da bilmeden girişilen bir çalışmadır. Bilimin prensipleri vardır, halbuki sanat daha çok çalışmayla ortaya çıkar, defalarca denersiniz. Bilim sizi sınırlar, sanat ise ancak serbest kılar. Bilim var olanı açıklar, sanat ise sentezler, yeni şeyler ortaya koyar, bu anlamda bilim bulur ama sanat yaratır.

Yaptığımız işin sanatsal tarafı olduğu kesin, tamamen sanat olmadığının kesin olduğu gibi. Bilimsel tarafı olduğu da kesin, tamamen bilim olmadığı gibi. Ama aslolan, nasıl olması gerektiği. Code Complete’in yazarı Steve McConnell da bu konuyu düşünenlerden. Buradan ulaşabileceğiniz yazısında “Yazılım Mühendisliği ne olmalıdır?” sorusunun daha doğru olduğunu ifade eder ve bu soruya “mühendislik” olarak cevap verir. YMnin örneğin iş analizi son derece subjektif dolayısıyla yaratıcılığa el veren, sanatsal öğeler içerebilir, programlama kısmı gibi. Ama belli ki bu tür pek çok farklı çalışmayı bir süreç halinde ve tekrar edilebilir olarak formüle edebilmek, onu mühendislik disiplini haline getirebilmekle mümkün olabilir. Gittikçe daha hızlandırmak, daha verimli hale getirmek örneğin ve çıktı kalitesini arttırmak, böyle bir mühendislik disiplinin amacı olabilir. Böylelikle bilimsel YM süreçleri ve metotları oluşur ve bunları uygulayanlar iyi yazılım ürünleri üretirler.

Aslında McConnell’in Code Complete isimli kitabının 2. bölümünde de belirttiği gibi, yazılımda da diğer pek çok şeyde olduğu gibi metaforlar kullanırız. Bu metaforlar konuyu anlamamızı kolaylaştıran benzetmelerdir. Ve bu metaforların hiç birisi kendi başına doğru değildir. Örneğin, projelerin sonunda, canlıya geçiş sırasında çalışanların kendilerini “itfaiyeci” gibi hissetmeleri, yaptığımız işin tamamını resmetmez.

Söyle diyor McConnell:

“A confusing abundance of metaphors has grown up around software development. David Gries says writing software is a science (1981). Donald Knuth says it’s an art (1998). Watts Humphrey says it’s a process (1989). P. J. Plauger and Kent Beck say it’s like driving a car, although they draw nearly opposite conclusions (Plauger 1993, Beck 2000). Alistair Cockburn says it’s a game (2002). Eric Raymond says it’s like a bazaar (2000). Andy Hunt and Dave Thomas say it’s like gardening. Paul Heckel says it’s like filming Snow White and the Seven Dwarfs (1994). Fred Brooks says that it’s like farming, hunting werewolves, or drowning with dinosaurs in a tar pit (1995). Which are the best metaphors?”

Yani

“Yazılım geliştirme etrafında şaşırtıcı sayıda metafor türemiştir. David Gries’e göre yazılım yazmak bir bilimdir (1981). Donald Knuth ise o bir sanattır der (1998). Watts Humphrey, o bir süreçtir der (1989). P. J. Plauger ve Kent Beck ise onun bir araba sürmek gibi olduğunu söylerler, ama buna rağmen tamamen zıt sonuçlara ulaşırlar (Plauger 1993, Beck 2000). Alistair Cockburn ise o bir oyundur der (2002). Eric Raymond ise onun bir pazar yeri olduğunu söyler (2000). Andy Hunt ve Dave Thomas ise o bir bahçıvanlıktır der. Paul Heckel ise o bir “Pamuk Prenses ve Yedi Cüceler” (Snow White and the Seven Dwarfs) (1994) filmini çekmek gibidir der. Fred Brooks ise o, kurtları avlayan ya da dinazorları bir tuzakta boğan çiftçilik gibidir der (1995). Sizin en iyi metaforunuz hangisi? ”

İşte size bir kaç tartışma daha: SD Times, Jason Gorman, CodeSqueeze, Research Gate’de iki tane, 1 ve 2 ve Jonah Kagan.

Eskiler “barika-i hakikat müsademe-i efkardan çıkar” demişler, neticede kimsenin aksi fikir belirtmediği yerde hiç kimse zaten düşünmüyor demektir. Neticede düşünmek, yazarak paylaşmak ve eleştirilmek hem cesurca hem de güzel bir şey. 

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

Hayatta en sevdiğim şeylerden birisi programlama yapmak. Ne zaman bir vesile ile böyle bir imkan bulsam, kendimi makinanın başında sabahlamış buluyorum. Başka hiçbir şey, bu günlükte yazı yazmak dahil, beni makina başında sabahlatmıyor. Bu duruma, 90’lı yılların başından bu yana alışkınım aslında. Benim gibi programcı olan kişilerin en temel tutkusu, programlama. Dolayısıyla programlamanın ve programcılığın en temel özelliği “tutku”. Acaip tutkulu insanlar programcılar, manyaklık derecesinde bir durum bu.

Neden acaba programcılar böylesine tutkulular? (Öyle ya bir kurumda, en anlaşılmaz, diğer çalışanlar, özellikle de İnsan Kaynakları tarafından en uç noktada görülen insanlardır genelde programcılar.) Sanırım yaptığımız iş, zihni melekelerimizi sonuna kadar kullanmamızı sağladığı için. Zaten, zihni açıdan böyle ağır bir iş, tutku olmadan, başka türlü yapılamaz. Zihni melekelerimizi sonuna kadar kullanmamızı sağlayan şey ise bence, programcının, programlama esnasında kendisiyle uğraştığı faktörlerin sayısının yüksek oluşudur. Faktör sayısının yüksekliği, faktörlerin durumlarının sayısı ve aralarındaki ilişkilerin karmaşıklığı, faktörlerin aralarındaki ilişkilerin sayısı ve karmaşıklığı, yapılan işin ne kadar karmaşık olduğunun en temel belirleyicisidir. Bunu şöyle ifade edebiliriz: Genel olarak bir programcının, üzerinde çalıştığı konunun, yani süreç, iş kuralı, algoritma, arayüz, iletişim protokolü, vs. her ne ise, faktör sayısı, yani değişken olsun sabite olsun, konunun matematiksel modelinde var olan soyutlamaların sayısı ile bu soyutlamaların aralarındaki ilişkilerin sayısı ve karmaşıklığı, normal bir insanın günlük hayatının herhangi bir kesitinde baş edebileceğinden çok daha fazla sayıdadır.

Bir örnekle ne demek istediğimi anlatayım: Programcının yaptığı programlama işi, karmaşıklık açısından, açık kalp ameliyatı yapan bir doktorunkinden farklı değil. Açık kalp ameliyatı yapan doktor da, kan basıncı, kanama riski, beyin fonksiyonları vb. tonla faktörü aynı anda yöneterek, bir ameliyat gerçekleştirir. Muhtemelen, böyle bir operasyon sırasında göz önünde bulundurması gereken faktörlerin sayısı, bu faktörlerin durumlarının sayısı ve aralarındaki ilişkiler ile bizzat faktörlerin aralarındaki ilişkilerin sayısı, normal hayatın herhangi kesitinde karşılaşacağınızdan çok daha yukarıdadır ve açık kalp ameliyatında durumun bir de kritikliği söz konusudur. Ben kritiklik tarafını çıkarırsak, bir programcının yaptığı iş olan programlama ile bir kalp cerrahının yaptığı iş olan açık kalp ameliyatını, karmaşıklık açısından benzer buluyorum ve bu konuda değerli doktorlarımızın hoş görüsüne sığınıyorum :). Fakat kalp cerrahımızın bir kaç avantajı var: İlki, bir programcıdan çok daha fazla eğitim ve pratik tecrübe kazandıktan sonra böyle bir işe girişiyor. Bereket ki bu durum böyle, yoksa sanırım açık kalp ameliyatlarının başarı oranı, bizim yazılımlarımınız başarı oranına düşerdi 🙂 Bir programcı, kesinlikle ve kesinlikle, bir kalp cerrahının içinden geçtiği eğitim ve çıraklığa (kadavra üzerinde uygulamadan başlayarak tonla ameliyatı seyretme vb. iş başı eğitimi kastediyorum) sahip olmadan açık kalp ameliyatına girişen bir gariban bence. Dahası, kalp cerrahımız, operasyon sırasında pek çok yardımcıya sahip: Mesela hemşirelerden birinin görevleri arasında doktorumuzun alnından akan teri silmek bile var. Gördünüz mü hiç kıvranan, depresyona girmeğe ramak kalmış bir programcının, değil terini silmeyi, durumunu farkedip, anında onu o ortamdan uzaklaştırıp, ona yardımcı olan bir kişi, görevli, rol vs? 🙂 Ben yöneticilik yaptığım zamanlarda, bunu farkettiğimde kendisine terapi uyguladığım, ortamdan uzaklaştırıp, çay-yemek vesilesi ile gerilmiş psikolojisini rahatlatmaya çalıştığım çok programcı arkadaşım oldu. Üstüne üstlük, cerrahın, faktörlerini kontrol eden pek çok cihazı var ve özenle tasarlanıp geliştirilmiş bu cihazlar, faktörlerin durumlarını görsel olarak sunuyorlar ve herhangi bir ciddi durum değişmesinde ses vb. yollarla, doktoru ve etrafındaki “n” tane yardımcısını uyarıyorlar. Gördünüz mü hiç, programcı program yazarken, “yazdığınız program şu noktada performans problemi verir”, ya da yanıp sönen “deadlock riski”, “deadlock riski”, ya da ne bileyim “unscalable code”, “unscalable code” diye uyarıda bulunan cihazlar etraflarında? Çok komik değil mi? Ama kalp cerrahları işlerini yaparken böyle yardımları devamlı alıyorlar, onlarsız iş yapmıyorlar. Çok tipik durumdur, Java ile geliştirilip, bol ve umarsızca nesne oluşturulup sonrasında, canlı ortamda çok hızla, bellek (memory) problemleri yaşayan dolayısıyla ölçeklenemeyen (unscalable) yazılımlar. Tipik bir programcının, teknik olan 1000 kelimelik bir konuşmasının içinde geçen bir kavram değildir “ölçeklenirlik” ya da “scalability”, ama çok önemlidir. Neden durum böyledir? Ölçeklenirlik bir faktördür ama yeterli eğitim ve tecrübeye sahip olmayan bir programcı, bu faktörü fena halde ıskalar. Çünkü o, program yazarken, en görünen ve fonksiyonel doğruluk ve tamlık açısından en bariz faktörlere odaklanır da ondan. Zaten programcının zihni, bu faktörler ve karmaşıklıklarıyla iğdiş olurken, ölçeklenirlik gibi bir faktörü düşünmesi imkansızdır ve tam da bu yüzden aslında “yazılım geliştirme, bir programcıya bırakılmayacak kadar önemlidir”. Tam da bu yüzden bu faktörler, gerek mimari gerek ise fonksiyonel tasarım çalışmalarıyla öncesinde ele alınmalıdır ki programcıya, kaldıramayacağı kadar, iş düşmesin. Yani, bir açık kalp cerrahının, ameliyat öncesinde “n” tane farklı daldaki doktordan “konsültasyon” alması, “m” tane tahlil vs. yapmasına benzer bu durum. Bunları yapmadan girilen bir ameliyatta, cerrahın faktörleri kontrol etmesi ne kadar zor ya da imkansız ise gariban ve sefil 🙂 programcıdan beklenen şey de bu kadar zor hatta imkansızdır.

Yukarıda örnekle anlattığımı daha sistematik olarak ifade edersek, bu şekilde programlama yapmada iki problem var: İlki, konunun zaten matematiksel modelinin kurulmamış olmasının getirdiği bir zorluk. Normal şartlarda, iyi bir analiz ve tasarımdan geçmiş ve bundan sonra programcının önüne gelmiş programlama işlerinde programcı, konudaki açık ve seçik olarak belirlenmiş yani, soyutlanmış faktörler ve aralarındaki ilişkileri rahatça anlar ve bunları bir programlama diliyle en iyi şekilde ifade etmeye odaklanır. Bir programcının en temelde iş tanımı budur ve bundan ne az ne de fazla bir şey yapar. Fakat, düzgün bir analiz ve tasarımdan geçmemiş programlama işlerinde ki neredeyse her zaman durum budur, programcının, önceden başka zihinlerin üzerinde düşünüp, değişik soyutlamalarla, konu içindeki faktörleri ve aralarındaki ilişkileri ortaya çıkarmış olması gibi lüksü olmadığından, konunun faktörlerini ve aralarındaki ilişkileri de bizzat kendisinin soyutlaması gereklidir. Dolayısıyla karmaşıklık bir kat daha artar. Bütün bu soyutlamaları bir seferde kavramak için bence 200’lerin üzerinde bir IQ seviyesine sahip olmak gerektiğinden ve böyle bir IQ seviyesine sahip olan programcı bulmak zor olduğundan, bulsanız bile bir programcının kazancına razı olmayacağından vs. vs. :), ve programcıların faktörleri soyutlamak için, UML gibi formal olsun ya da bir beyaz kağıt ya da tahta üzerinde, formal olmayan herhangi bir notasyon kullanarak bile çalışmadıklarından, çünkü programcıların formal notasyonu, bizzat programlama dilinin kendisi olduğundan, yazıkları program-kod parçası, hem soyutlama aracı hem de bu soyutlamaların programlandığı, gerçekleştirildiği ortam haline gelir. Karışık oldu değil mi? Demek istediğim şu: Programlama dili ile program yazmak, hem konunun anlaşılması için gerekli bir eskiz ortamı hem de sanki eskizi yapılmış ve anlaşılmış konunun, bir yazılım olarak ifade edildiği ortam haline gelmesidir bu durum. Bu da çok berbat bir haldir: Neden berbat? Bir, böyle bir çalışma şekli, programcının zihnini acaip yorar. Programcının tutkusu olmazsa bunu şu dünyada “hiçbir Allah’ın kulu” yapmaz. İki, programlarımızı yaz boz tahtasına döndürür bu şekilde çalışma. Programlarda bırakın kaliteyi, bir iç bütülük, bir insicam kalmaz, ortaya çıkan programı “şiir gibi oldu be abi” şeklinde ifade etmek kesinlikle mümkün değildir. Böyle durumlarda programcı, sonradan geri bakıp bu kodla yüzyüze gelmek istemez, yaptığı bu işle kesinlikle övünmez, utanır ondan çünkü. Peki bu durum yazılım kullanıcılarına nasıl yansır? Elbette hata, kullanılamayan, çok sık problem çıkaran sistemler olarak yansır, eğer yukarıda anlattığım sürecin bir yerlerinde kaliteyi arttırıcı gözden geçirmeler, sıkı fonksiyonel ya da fonksiyonel olmayan testler yoksa.

Sıkı durun, yukarıdaki anlattıklarıma bir katman zorluk daha geliyor: Ya programcının zihninde kod yazarken yaptığı bu soyutlamalar çok sık bir şekilde, konunun yani işin sahibi olan kişi tarafından değiştiriliyorsa? Yani aslında yukarıda bahsettiğim, iş süreçi, kuralı vs.nin sahibi olan kişinin kafası henüz net değilse ve arada analiz ve tasarım katmanları da olmadığından, iş sahibi ile programcı devamlı karşı karşıya kalıp, konuşuyorlarsa? Bakın işte bu “hiçbir şekilde yapılacak iş” değildir. Böyle bir ortamda, normal şartlarda kimse çalışmak istemez. Benim sık sık, “insan yapmaz bunu” dediğim haldir bu. Bunu ülkemizdeki pek çok programcı yapar ama, neden biliyor musunuz? Bir, hoşuna gider, çünkü zorluk büyüdükçe ve kendisi başardıkça ya da en azından başardığını düşündükçe (problem de bu ya zaten, başardığını düşünmesi 🙂 ), egosu kabarır ve bu durumun çok fena farkındadır programcı. İki, programcının gücü artar, kendisine bağımlılık artar, her şeyi kontrol edebiliyor olmak müthiş bir şeydir çünkü. Üç, belki de en kötüsü, yazılım endüstrisi açısından, programcı, bu sıkıntılı durumun aslında nasıl olması gerektiğini bile bilmez, çünkü okulda ve sonrasında çalıştığı ortamlarda ona “yazılım=program” yanılsaması, gerçek olarak sunulmuştur çoğu zaman. (Komiktir, bir programlama diliyle doğru düzgün bir program bile yazamayacak durumda olan kişiler, kendilerini “Yazılım Mühendisi” olarak tanıtıyorlar mesela 🙂 Halbuki, bir derleyici (compiler) yazacak kadar yetkin bir programcı olmak bile o insanı “Yazılım Mühendisi” yapmaz, çünkü “yazılım” farklı bir şeydir. Farktan ne kastettiğimi anlamak için, “böyle bir derleyiciyi kullanmak ister misiniz” diye kendinize sorun ve neden “hayır” diye cevap verdiğiniz üzerine düşünün mesela.) Aslında durum, “programcısın, programcı kal”dır sadece 🙂 (Neyse, bu konu da bir yazı gerektirir, o yüzden dalmayalım oraya.)

Dolayısıyla, programcının karşılaştığı üç katmanlı zorluklar şunlardır: Soyutlamaların yapılması, soyutlamaların gerçeklenmesi ve bu gerçeklenmenin, soyutlamalardaki değişimi göz önüne alacak şekilde yapılması. Sabahtan akşama değil de değişen iş ihtiyaçlarına göre makul miktarda değişen iş süreçlerini ve muhtemel değişim noktalarını göz önüne alarak program yazmak, zaman verildiğinde bir programcıdan bekleyeceğiniz şeylerdendir. Ama gerek iş süreçlerindeki gerek ise ölçeklenirlik gibi yazılım mimarisindeki soyutlamaların gerek ise bu iki konudaki muhtemel değişim noktalarının belirlenmediği bir süreçte, programcıdan hem bunları hem de bunlar sonucunda ortaya çıkan yapının bir programlama diliyle gerçekleştirilmesini beklemek hayalciliktir, programcıya da eziyettir.

Bütün bunlardan sonra, bir programcının sahip olması gereken en temel karakter özelliklerini sıralayabiliriz:

1. Yüksek soyutlama gücü. Yani çözümlemeci/analitik düşünebilme yetkinliği. Daha açık bir ifade ile, olguları sistematik bir şekilde bileşenlerine ayırabilme, bu bileşenlerin durumlarını ve aralarındaki ilişkileri ortaya çıkarabilme, bileşenler arasındaki bağımlılıkları ortaya çıkarabilme, bunları sistematik bir şekilde yapabilme ve aktarabilme  yetkinliğidir çözümlemeci olmak. Bu yetkinliklerin ciddi bir kısmı Allah vergisidir ama iyi bir Matematik, Fizik vb. eğitimle güçlendirilmiş olmalıdır.
2. Odaklanma: Hiç bir zihin, ilk maddedeki noktada ne kadar yetkin olursa olsun, eğer odaklanma sorunu yaşıyorsa, içinde bulunduğu kişiyi iyi bir programcı yapamaz. Odaklanmadan bu kadar karmaşıklık yönetilemez.
3. Sabır: Programcı, iğneyle kuyu kazar gibi iş yapar, aynı konuya bazen sil baştan yaklaşır bir kaç defa ve en son denemesinde başarır örneğin. Dolayısıyla azim ve sabır son derece önemlidir.
4. Denemeci yaklaşım: Programcı, doğruyu bulana kadar çok dener, çok test yapar ve çoğu zaman ancak bir kaç denemeden sonra doğruyu bulur. Bir kere yapıp, oraya takılan kişiler, aynı olaya farklı açıdan bakamayanlar hiç bir zaman iyi bir programcı olamazlar. Bir noktaya takılıp ilerleyemeyenler zaten 1. maddeden de geçememişlerdir çoğu zaman.

Bunlar dışında, formal algortima, veri yapıları, programlama dili, gerekli araçlar vs.nin bilgisi de gereklidir ama ben bu yazıda daha çok karakter özelliklerine dikkat çekmek istedim.

“Abbas Güçlü” vari bir bitiriş yapalım, özetin özeti şudur: Ey programcılar ve programcı olmaya talip gençler: Bu yazıda anlatılanlar size çekici geliyorsa ancak, iyi bir programcı olabilirsiniz. Ey yazılım evleri, BT yöneticileri, programcılarınıza acıyın ve insan içine çıkacak yazılımlar geliştirmek istiyorsanız, yazılım geliştirme işinizi, “programcıların programlaması” olarak değil de bir süreç olarak ele alıp,  programcılarınızdan önce ve sonra konumlandırdığınız kişiler ve çalışmalarla, programcılarınızın işini kolaylaştırın, yazılımlarınızın kalitesini arttırın.

Ve siz de bugün bir programcı bulup ona sarılın 🙂

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