Devlet Büyüğü ya da Spring Framework'ünden neden hoşlanmadım?

Kendi yarattığımız kavramlar altında ezilmekten ne zaman vaz geçeceğiz bilemiyorum. Aslında sistem belli bir örgüyü hep takip ediyor.

• Soyut test edilemeyen bir kavram oluştur
• Bu soyut kavrama hayati fonksiyonları yükle
• Bu soyut kavram olmadan somut işlerin olamayacağına kendini inandır
• Daha sonra bu soyut kavramın boyunduruğu altına gir

Mesela zaman kavramı. Saat'in ve tarihin ne olduğunu bilmeden ne kadar süre dayanabilirsiniz? Zaman ile ilgili çok fazla tartışma zaten var, benim de bir damla daha eklememe hiç de gerek olmadığını düşünüyorum. Ancak bugün tanık olduğum bir iki olay bu başlığı atmama sebep oldu.

Bilkent Üniversitesinde yeni dönem ders planı için İpek hoca ile görüşmeye giderken etraftaki güvenlik görevlisi sayısı ve siyah üzeri ışıklı koruma arabaları -benim hep siyah takım elbise giyen bir iş adamının kafasına renli taç takmasına benzettiğim, maymun edilmiş güzelim arabalar- etrafta bir "Devlet Büyüğü" olduğunu fark(!) etmemi sağladı. Kim olduğunu bilmiyorum ve de çok da ilgilenmiyorum. Peki bu olayın yazılım ile ilgisi nedir?

Devlet kavramı insanlar tarafından oluşturulmuş bir soyut kavramdır. Bu soyut kavrama atanan somut görevleri yerine getirilebilsin diye başka soyut kavramlar oluşturulur. Bakanlıklar, kurullar, kurumlar, ünvanlar diye gider bu silsile. Bu soyut kavramlara da somut fonksiyonlar verilir bu fonksiyonları da yerine getirsin diye daha da somut insanlar görevlendirilir. Bu görevlendirilen somut insanların esas görevleri somut fonksiyonları yerine getirmektir. İşte tam da burda komik(!) olmaya başlıyor. Bu somut insanlar, aslında var olmayan soyut kavramların aslında hiç var olmayan soyut gücünü kullanarak kendilerini onları görevlendiren somut insanlardan farklılaştırırlar. Sonuç ise görevlendirilen somut insanlar, görevlendiren somut insanların, somut görevlerini yapmak için başka somut (ya da fayda sağlayabilecek soyut) ek isteklerde bulunurlar ve bir anda kendinizi bu şekilde görevlendirilmiş bir somut kişiden ikametgah ilmuhaberesi alırken (3 tl) bulursunuz. İşlere başlangıç noktası Türkiye için o noktadır.

Hayatı kolaylaştırdığına inanılan soyut kavramların somut eziyetine dönüşen bu döngüden çıkmak artık mümkün değil. En azından yaşadığınız sürece. Öldükten sonra yaşayacağınızı düşündüğünüz soyut inançlarınız var ise bir de onun ek somut yükünü de taşımak zorundasınız tabi.

Peki yazılımda durum farklı mı? Yazılımı da insanlar gerçekleştirdiği için bir adım ileri gitmiş olması çok fazla beklentiden öte değil. Örnek vermek gerekirse kurumsal java uygulamalarına bakabiliriz. Örneğin durum yönemli (Aspect Oriented) bir uygulama yazacaksınız ve kendinize en popüler olanlarından Sprin Framework'ünü seçtiniz. Önce "Aspect Oriented" diye bir kavram bulmanız lazım. Bunun olmazsa olmayacağına inanmanız gerekiyor. Bir JEE (kurumsal java uygulaması) onsuz olmaz düşüncesine iyice inandıktan sonra bu düşünceyi gerçekleştirmek için somut Sprin projesini kullanmaya karar veriyorsunuz. İşte o anda bu somut kod satırları sizi ele geçirmiş oluyor. Kendisi de IoC, webflow vs vs gibi bir sürü soyut kavramlara somut görevliler getirmeye başladıktan sonra, siz de artık ikametgah bilginiz elinizde o xml dosyası senin bu xml dosyası benim dolaşmaya başlıyorsunuz. Ya da bkz. Portal Uygulamaları :)

Tabi bu durumdan memnun olanlar, olmayanlar ya da ilgisiz kalanlar olacaktır. Kraldan fazla kralcı olanlar, o soyut kavram olmasa hiç bir işe yaramayacak olanlar, muhalefet edenler olacaktır. Bu nedenle hangi kavramı, ne sebeple yaratıp kullandığımıza dikkat etmek gerekir diye düşünüyorum. Bir anda projeniz dışında başka işler ile kendinizi uğraşırken bulmak çok uzak bir ihtimal değil. Özellikle artık yazılımlar framework kullanmadan geliştirmenin çok zor olduğu günümüz şartlarında.

"Happpiness in intelligent people is the rarist thing I know" - E. Hemingway

Bilgisayarlar nasıl iletişim kurar ya da biz kendi yarattıklarımızdan bir şey öğrenebilir miyiz? bölüm 1

Her gün kullandığımız bilgisayar ve bir dolu uygulama bulunmakta. Kısa bir geçmişe göre en önemli gelişme, artık internete ya da bir networke bağlı olmayan bir bilgisayar neredeyse işe yaramaz olarak görülmekte. "İletişim çağı" deniyor, ama aslında bizi iletiştirmek için çalışan bir sürü sistemler var. Bunları bir bilişimci anlattığı zaman japonca gibi gelse de aslında sistem oldukça basit. Esas belki de yapılması gereken, kurulan sistemlere bir iki adım geriden bakıp, onları anlamak belki de felsefesine vakıf olmak. Bu bilgisayarımızın içinde yaşayan küçük adamların bizi nasıl iletiştirdiği ile ilgili biraz bilgi sahibi olalım. Bu iletişim sistemi ile ilgili felsefe yapmadan önce sizi sıkmamaya çalışarak sistemi size anlatayım.

Önce bir protokollere bakalım. Bir sürü garip harf karmaşası arasından bir kaçına göz atalım.

DNS (Domain Name System): Bizdeki yansıması nüfusa dayalı adres sistemi olarak basitçe anlatılabilir. Yani muhtarlardan nüfus müdürlüklerine kadar kurulu tüm sistem. DNS bize kimin nerde olduğunu söyler. Yeni bir eve taşındınız, muhtara başvurup beni arayanlar artık bu adresten bulabilir şeklinde bir beyanda bulunuyoruz. Ordan da nüfus müdürlüklerine dağılıyor bu bilgi. Internette muhtarlık nasıl oluyor? Aldığımız alan adlarını (www.spp42.com gibi) Internetin muhtarına kayıt ettiriyoruz. Bu alan adı bu adreste (adres de IP adresi 141.141.123.10 gibi) Bizi bulmak isteyenlerde bu müdürlüklere başvurup adresimizi buluyorlar. Aynı işlemi bu sayfaya gelmek için siz de uyguladınız. Bilgisayarınız blog.spp42.com adresine gelmek için DNS sunucularına (muhtarlarınız) bu adres nerde diye sorup adresi öğrendikten sonra bu sayfaya geldi. Nasıl muhtara yanlış beyanda bulunulabiliyorsa (ki aslında bu suçtur) DNS kayıtları da yanlış olabilir, ya da muhtarların o kağıt karmaşasında evrak kaybetmeleri gibi DNS kayıtlarının da başına bir şeyler gelebilir. Ya da muhtarımız o adresi nasıl bulacağını bilmiyordur (bkz Türk Telekomun DNS'leri) . Daha da kötüsü kötü niyetli muhtar bize bilerek yanlış adres söylüyordur (bkz. youtube.com nasıl bloklanıyor).

SMTP (Simple Mail Transfer Protocol): Bunlar eskiden sokaklarımızda olan (ama artık neredeyse tüm sokaklarımızdan silinmiş olan) posta kutularıdır. Eğer hatırlarsanız bu kutulara mektuplarımızı atardık. İçinden bir mektup almanız mümkün değildir. Tek yönlüdür. SMTP de böyledir. Göndermek istediğimiz mailleri üzerinde yazan adreslere iletmekle mükelleftir. Adresleri nerden bulur derseniz internetin muhtarlarına (DNS) sorar tabi ki. Bu sebeple e-mail ayarlarını girerken hem gelen sunucu hem giden sunucu diye ayarlar yapılır.

POP3 (Post Office Protocol version 3): Bunlarda internetin postaneleri gibi tanımlanabilir. Ama sadece size gelen mektupları vermekle yükümlü olan bir postane. Postacısı olmayan sizin kendinizin gidip almanız gereken bir yer. Bu sebeple e-mail uygulamarında "gönder-al" diye bir fonksiyon vardır. Artık bu gönder-al işlemi belli sürelerde otomatik olarak uygulama tarafından yapılmaktadır.

Şimdilik burada bırakalım. Daha çok harf kalabalığı var. HTTP, TCP, UDP, IP vs. vs. vs.

Sıradanlığın normalliği

Sıradanlığın normaliği son dönemlerin en büyük problemi olduğunu düşünüyorum. Peki sıradanlığın normalliği demek ne demek? Türk dil kurumuna göre

sıradan: sf. Herhangi bir özelliği olmayan, bayağı, alelade
normallik, -ği is. Normal olma durumu

Etrafımıza bir bakarsanız sıradan olmanın ne kadar da reklamının yapıldığını görürsünüz. Televizyondaki reklamlar sizi ne kadar sıradışı hissettireceğini iddia eden sıradan ürünlerle dolu.

Peki fikirler? Fikirlerin de ne kadar sıradanlaştığı, aykırı fikirli olanların nasıl ezildiğini hem sosyolojik olarak gerek küresel, gerek ülkesel, gerek ailesel olarak çok net görebilmekteyiz. Toplum birliğini korumak adına aykırı uçları ya yok eder ya da kendi içerisine katmaya çalışır. Bu sebeple "kalabalıkla" aynı fikirde olmak "rahatlık" getirir. En azından bir istenmeyen "sürtüşme" olmaz. Kalabalık bir ortamda Serdar Ortaç/Justin Timberlake yerine Nick Cave dinlemeyi bir deneyin. Peki "kalabalığa" uymak ne götürür? Annemizin, babamızın, büyüklerimizin ulu bilgeliğine uymamak için ne sebebimiz olabilir? Bireyseniz kimliğiniz, kurumsanız kurumsal kültürünüz "kalabalık" içinde erir.



Yukarıdaki imaj istatistikteki "normal dağılımı" simgeleyen çan eğrisidir. Nedir bu grafiğin anlamı? Çıkan sonuçlar belli bir noktada toplanmış ve uç noktalarda ise görülen sonuç sayısı azalmıştır. Bu belli noktalarda toplanma fikirlerde de görülür. Genel olarak yazılım ile ilgili yazdığım için bu konuyu da yazılım geliştirme açısından bakacağım ancak diğer alanlara da çok rahatlıkla uygulanabilir.

Eğer yazılımınızı uygun olsun olmasın belli araçlarla belli platformlarda geliştiriyorsanız, rahatsınızdır, kalabalığa uymanın rahatlığı. Kimse size niye veritabanı olarak Oracle kullandınız diye sormaz. Ya da neden donanımları IBM aldınız diye de sormazlar. Yazılım dili olarak neden Java kullandınız ya da bu internet uygulamasını neden PHP ile yazdınız diye de genelde sorulmaz. Eğer bir soru gelirse bu uygulama yöntemi ile ilgili olucaktır büyük bir ihtimalle.

Peki ne zararı var? Bu ürünler zaten fazlası ile iyi değil mi? Sorun da burada başlıyor zaten, "fazlası" ile iyi, ya da fazlası ile yanlış kullanılıyorlar. Her işi PHP ile yaparım diye düşünenleri bir kenara koymak istiyorum. Zira bu hatanın en büyük sebebi ya dilin limitlerini tam bilmemekten geliyor ya da zaten başka bir dilde deneyimi olmamış insanlar bu hatalara düşüyorlar.

Esas problem Java dünyasında. Eğer Apache vakfının sitesini bir ziyaret ederseniz, bir sürü java projesi olduğunu görürsünüz. Özellikle JEE uygulamaları olması gerektiğinden çok daha karmaşık. Bu sebeple projelerde otomatik olarak karmaşıklaşıyor. Bir de işletme tarafının da problemli olduğu durumlarda proje iyice sıkıntıya girmekte. Java dünyası içi ağzına kadar dolu bir teknoloji çuvalı. İçinden doğru araçları çekip çıkartmak oldukca zor. Bu araçlara alışan geliştiricelerin de her önüne geleni çivi zannetmesi nedeni ile gereksiz java frameworkleri gereksiz yerlerde kullanılıyorlar.

Birileri artık "normal" olanın dışındaki fikirlerini sesli söylemeli. Herşeyi çekiç ile çözmeye kalkışan zihniyeti durdurmalıyız. Bu tüm fikirler için geçerli. Asıl ironik olan toplum olarak (tüm insanlar, geçmiş ve şimdi, sadece ülkemiz anlamında değil) değişimi reddetme ve normal olmayanı asimile etme eğilimine rağmen ilerlemelerimizi bu "normal" olmayanlara borçlu olmamız.

Python ile Dosya Okuma ve Kopyalama

Bu gün bilgisayarımda dinlediğim mp3'lerin bir kısmını cep telefonuma kaydetmek istedim. Ancak kopyalamak istediğim şarkılar bir mp3 listesinde (m3u dosyası) bulunmakta idi. Teker teker uğraşmak yerine aşağıdaki basit kodu yazmayı tercih ettim. Yazılımcı demek tembel olmak demektir :)

import shutil

file = open ('liste.m3u', 'r')
copyLocation = "kopyalanacak/klasor/"
for line in file:
  try:
      #satır sonlarındaki enter (newline) silmek için
      #line[:line.__len__()-1]
      shutil.copy(line[:line.__len__()-1], copyLocation)
  except IOError:
      pass

Progamlamacılar ve Jedi vs. Sith

Bilişim dünyasında her zaman moda olan kült kitaplar ve filmler vardır. Örneğin Dune, Otostopçunun Galaksi Rehberi, Yıldız Savaşları, Matrix, 13. Kat, Predetor, Alien gibi filmler ve kitaplar bir şekilde esin kaynağı olmuştur bilişimcilere.

Ben de bütün bu eserleri beğenmekle beraber, Yıldız Savaşları serisi, aralarında en çok keyif aldıklarımdan. 6 film, çizgi filmler ve sayısız çizgi romandan oluşan bir dünya. Yaratanlar insan olunca konular da aslında bizim günlük konularımızdan çok da uzak olamıyor. Sadece sahne farklı. Jedi ve Sith adı verilen iki farklı öğreti, ticaret, ikili ilişkiler, güç dengeleri gibi genel dünya işleri (tabi orda evren oluyor) ile örülmüş bir evren.

Programcılar da doktorlar gibi tam anlaşılamayan mesleklerdendir. Basit bir sivilce latince isimlendirilince nasıl da önemli görünür ve bu bilgiyi bilen doktor da bir anda önem kazanır. Kendi aralarındaki ve ilaç kutularının üzerindeki bize anlamsız gelen harf kümeleri bize doktorları daha da uzak kılar ve anlaşılmaz bir saygıya sebep olur. Aslında hep eşiminde de dediği gibi doktorlarda aslında belli konuda bilgileri olan danışmanlardır. Belli bir bilgi üzerine tanı koyarlar ve durumun iyileştirilmesi için fikirlerini beyan ederler. Tabi bunun arkasında ciddi bir bilim yatmaktadır ancak çok kaba hatları ile durum böyledir.

Aynı yaklaşım yazılımcılar için de geçerlidir. Anlaşılmaz kısaltmalar, kendi aralarında hangi dilde olduğu bilinmeyen konuşmalar hep onları da biz ölümlülerden uzak tutar. Aslında yazılımcılarda işini yapmaya çalışan her hangi bir insandan daha farklı değildirler.

Peki programcular ile bu Yıldız Savaşlarının ilişkisi nedir? Yıldız Savaşları bizim dünyamızdan çok da farklı bir konu anlatmıyor demiştim. Yazılımcılarda aslında çalışmak isteyen sıradan insanlardır. Peki bu iki konu birleşmez mi? Benim görebildiğim kadarı ile şu şekilde birleşebiliyor.

Jedi:
Kimdir bu Jedi? "Light side of the force" Türkçe'ye Güç'ün iyi tarafı olarak cevrilerek bir çevirme sırasında anlam kaybına uğramış olan taraftır. Neden derseniz, iyi ya da kötü kavramı durduğunuz noktaya ve zamana göre değişiyor olması. Jedi'ların ortak özelliği Jedi kurallarına sıkı sıkıya bağlı olmaları. Onlar için tanımlı belli doğrular vardır ve bu doğruları kabullenmek ve geliştirmek misyonlarını gerçekleştirirler. Kimlerdir bunlar derseniz, genelde C++ ve Java kullanıcıları arasında görülürler. Tasarım örgülerine (design patterns) sıkı sıkıya bağlı, nesne yönelimli dillerin "doğrularını" kesinlikle aşmayan, meta programlama üzerinde kafa yoran yazılımcılardır. Bu tür yazılımcılar ile görülen en büyük hata, fazla mühendislikten kaynaklanan işin bitirilememesi ve olduğundan daha da karmaşık hale getirilmesidir.

Sith:
Sith'ler ise "Dark side of the force" yani Güç'ün karanlık tarafını temsil ederler. Amaçları Güç'ü daha efektif kullanıp kendi menfaatleri doğrultusunda fayda sağlamak olan ve içerisinde oldukça zorlu bir gelişim süreci barındıran ekiptir. "Kötü" olarak tanımlanmakla birlikte tamamen subjektif bir konudur. Kimlerdir bu Sithler yazılım dünyasında? Nasıl Sith'lerde Jedi'lar gibi Güç'ün temellerine inansalar ve onu geliştirmeye çalışsalarda esas amaç fayda sağlamaktır. Yani müşteriyi memnun et ki sen de memnun olasın ilkesine inanırlar. Burda dikkat edilmesi gereken nokta müşterinin memnuniyeti aslında ürünün kusursuz olmasından kaynaklanmayabilir. Yazılım ileride bakım yapılamayacak şekilde yazılmış olabilir, yeterince ölçeklenmiyor olabilir ama o an için müşterinin istediği her şeyi yapıyordur. Jedi'lar daha ilerideki problemleri çözmek için yakın zamanlı sorunlarda hata yaşayabilirler. Sith'ler ise günü kurtarıp kendilerine de fayda sağlarlar. Genelde hızlı frameworkleri kullanıp çözüm yaratan ekiplerdir Sith'ler. Ruby on Rails, Django, Grails, Wicket gibi araçlar ile donatılmışlardır.

Trade Federation:
Trade Federation, felsefi açıdan donanımsız, tamamen ellerindeki robotların hızlı üretiminden kaynaklanan ekonomi ile Yıldız Savaşları evreninde var olmuş bir ekiptir. Kimdir bunlar yazılım dünyasında derseniz, PHP ve .Net kullanıcıları diyerek özetleyebiliriz. Pek de yazılım temellerine uymayan ama işe yarayan çözümler yaratırlar. Her sorunu bu araçlar ile çözebileceklerine inanırlar ve esas amaç ürünü çıkartmaktır bu ekip için. Bu sebeple sürükle bırak araçlarına ve basit yazılıma güvenirler.

Bu ekiplerden hiç biri bir diğerinden bence üstün değildir. Amaca göre araç ve yöntem doğru olan yaklaşımdır. Kimse yukarıdaki yazıdan alınmasın lütfen zira bu hafif bir gülümseme yaratması için yazılmış bir yazıdır. Sadece biz yazılımcılar da aslında diğer işini yapmaya çalışanlardan farklı değiliz demek için yazılmış bir yazıdır bu.

Hayatta yaptıklarımız ve Programlama ya da GOTO özlenir mi?

5 cls
10 print "Emrah"
20 goto 10
run

Öncelikle teknik bir yazı yamayacağımı belirtmek isterim, sadece arka plan bilgisi olması açısından bazı teknik detaylara ucundan değinmeyi düşünüyorum.

Yukarıdaki satırlar Commodore64 üzerinde yazdığım ilk "program" denemesinin satırlarıdır. Ekrana "sonsuza" kadar "Emrah" yazardı. Hala da yazıyordur :) 20 numaralı satır programı 10 numaralı satıra gitmeye (GOTO) zorlar ve program bu döngüden asla çıkamaz. O zamanlar "GOTO" yönermesi ile ilk tanışmam idi. Zaman geçtikce ve nesne yönelimli diller (object oriented) ile uğraşmaya başladıkça o sevgili "GOTO" yönermesi gittikçe uzaklaştı.

Çok sıkmadan bu "GOTO" yönermesinin kullanımından bahsedeyim. Örneğin arka arkaya bir iş yapıyorsunuz ve bu işten bir şekilde çıkmanız gereken bir durum oldu. Fabrikada bant üzerinde vida sıktığınızı düşünün, elinizi kanattınız ve normal süreçten çıkıp revire gitmeniz lazım. Teknik konuşmak gerekirse for ya da while döngüsünden çıkmak için kullanılırdı. Daha sonra nesne yönelimli diller ise bunu "kırmak" (break) komutu ile yapmaya başladılar. Süreci kırıyorsunuz.

Bir diğer kullanımı ise hata durumlarında programı bir yere yönlendirmek için kullanılırdı. Yolda giderken arabanın lastiği patlarsa kenara git (GOTO kenar :)). Gene yenilenen programlama yaklaşımları bunu da "dene olmazsa bunlara bakalım" (try/catch) mekanizmaları ile değiştirdi. Yani, arabayla giderken devamlı lastik patlamış mı diye bakmaktansa, bir gitmeyi dene, yolda başına lastik patlaması gelirse kenara çek, adresi bulamazsan en yakın taksiciye sor, hiç tahmin edilmedik bir sorun ile karşılaşırsan arabayı güvenli bir yerde durdur taksi ile git yaklaşımı hakim oldu.

Peki bunların bizim hayatımızla ne ilgisi var. Programcıların kendi aralarındaki anlamsız konuşma konularından biri daha değil mi "GOTO"? Düne kadar aynı fikirde olmama rağmen 5.3 versiyonu ile beraber PHP'ye "GOTO" komutunun getirilmiş olması tamamen fikrimi değiştirdi. Tekrar belirteyim PHP iyidir, kötüdür tartışmasının çok yanlış olduğunu, bir dilin ancak hangi projede ve nasıl kullanıldığı ile ilgili değerlendirilmesi gerektiğini düşünenlerdenim. Peki PHP bu kadar nesne yönelimli bir dil olmak için çabalarken bu nostaljik komut nerden geldi?

"GOTO" komutunun sevilmemesinin sebebi program akışını düzensiz (unstructered) bir şekilde bozması ve ileride içinden çıkılamaz bir hale getirebilme potansiyelinin olmasıdır. Potansiyel diyorum zira düzgün kullanımlarda GOTO en azından zararlı olmamaktadır. Peki programcılar bu hataları yapıyorda biz gerçek hayatta yapmıyor muyuz?

Hiç baştan yanlış kurguladığımız bir işte ilerleyip çamura battıktan sonra bırakıp işleri bir yerlere gitmek (GOTO biryerler :)) istemedik mi? Sistemi düzgün kurmak yerine, bir şey olursa şuradan kaçarım planları daha yapılabilir gelmektedir. İşte zaten bu noktada tecrübe öne çıkıyor. Tecrübeli kişi daha rahat plan yapabiliyor, süreçleri daha düzgün tasarlayabiliyor ve ne hatalar olabileceğini önceden kestirebildiği için hata ile karşılaşılacağında ne yapılacağını biliyor. Kaçmıyor (GOTO neresi olursa) Her şeyi kısa yoldan yapma isteği, planlamadan işe başlamak arzusu normal yaşantımızda karşımıza çıkıyorda yazılımda neden olmasın? Nasıl iyi yönetici, kötü yönetici, iyi sporcu, kötü sporcu varsa iyi yazılımcı, kötü yazılımcı da olacaktır, eğer "kaçmak" (GOTO) eylemini iyi ya da kötü olarak tanımlıyorsanız.

Kararlarımızı ne kadar doğru verebiliyoruz?

Hepimiz yanlış ya da doğru kararlar veririz. Hayatımız boyunca o kadar çok karar veriyoruz ki, bunların hepsinin yanlış ya da hepsinin doğru olması imkansız. Buna bir de evrensel doğru/yanlış üzerine tartışmaları eklerseniz iş iyice içinden çıkılmaz hale gelir.

Ancak, hepimizin verdiği bu kararlar sırasında psikologların ve bilişsel bilimcilerin toparlamış olduğu bazı hata grupları var ki, gerçekten karar verme sürecinin ne kadar zor olduğunu ortaya koyuyor. Bir konu üzerinde araştırma yaparken karşıma gelen ve karar verme hataları diye kabaca tanımlanabilen gruptan bazı örnekler vermek istiyorum.

Bandwagon effect: yani başkaları da yapıyor diye bizim de aynı şeyler yapmamız ya da düşünmemiz. Moda bunun için belki de en güzel örnek. Peki yazılımda nerde görülüyor derseniz, neredeyse her yerinde. Basit PHP ile bile yapılabilecek bir uygulamayı içinden çıkılmaz Java frameworkleri ile yapmak mesela. Herkes kurumsal yazılımlarını Java ile geliştiriyor biz de öyle yapmalıyız durumu. Ne sakıncası var derseniz, karşınızda böyle biri var ise ve siz de ona gerçeği anlatmak için uğraşıyorsanız, çok nafile bir çaba olacaktır. Hem siz işten anlamaz olarak algılanacaksınız hem de gereksiz yere zaman kaybedeceksiniz.

Confirmation bias: yani inandığımız şeyleri destekleyen bilgileri arama ve kabullenme eğilimi. Kimse yanlış olmak istemez. Bu ciddi bir stress kaynağıdır. Bu sebeple fikirleri bizimle ters düşmeyen gazeteleri okur, kanalları izleriz. Algısal sıkıntılarımızın belki de en rahatsız edicisi. Peki yazılımda yok mu? Bol miktarda. Yukardaki örneği biraz terse çevirirsek o kişileri hemen tanıyacaksınız. Gerçekten ciddi bir framework kullanılması gereken bir uygulamada PHP ile yazıcaz diye diretmek ve bunu da desteklemek için PHP ile (muhtemelen ciddi oranda zorlanılarak, ispat amaçlı yapılmış) uygulamaları örnek vererek bu kararını desteklemek isteyen yazılımcılara rastlamak hiç de düşük bir oran değildir.

Not Invented Here: Benim favorim. Kabaca "Burada icat edilmedi" olarak çevirebiliriz. Başka bir firma ya da birileri tarafından yapıldığı/belirtildiği için ürünü/fikri reddetme eğilimi. Çok iyi bir tabirle çamur atma da denilebilir. Bu neredeyse her yerde görülür. Başka bir firmanın yaptığı ürünlere çamur atılır, nasıl yavaş çalıştığı anlatılır. Teknolojisi yerilir ya da her şeyi çalışıyorsa programlama tekniği kötülenir. Tabi bu başka bir firma olmak zorunda da değil. Firma içinde eski personelle daha önce yapılmış çözümlerde aynı şekilde karar hataları tanrılarına kurban edilebilir. Eğer bir çözümü siz bulmamışsanız, o iyi bir çözüm asla değildir :)

Bir kaç ilginç hata daha var ancak ileriki yazılara :) şimdilik bu kadar.