Kategori: Genel

Yıllar önce, Visual Basic program geliştirme ortamının yaygınlaşmak üzere olduğu bir dönemde ben de bu dili ve programı öğreneyim demiştim. Görsel kontrollerin desteğiyle uygulama yazmak çok daha kolay ve eğlenceli olacaktı. İşe başladıktan kısa bir süre sonra çok sinir bozucu bir olayla karşılaşmıştım. Bir satırdaki kodu bitirmeden başka bir satıra geçildiğinde ekranda birden bir hata mesajı beliriyordu. Program geliştirme ortamı tabii ki yarım kalmış satırı hemen yorumluyordu ve bu satır hatalıydı. Bu şekilde bakıldığında yerden göğe kadar haklıydı ama kullanıcıyı bu durumlarda bir hata mesajını okumak (tamam, hangimiz hata mesajlarını okuyor ki?) ve daha da önemlisi bu mesajı aktif bir şekilde kapatmak zorunda bırakarak kullanıcının dikkatini dağıtıyordu ve çalışma zevkini öldürüyordu. Günümüzde çok daha iyi geliştirme ortamları bu hataları daha az saldırgan yöntemlerle (Örneğin satırdaki hatalı yerin altını kırmızı çizerek) kullanıcıya iletip çalışma temposunu ve akıcılığı bozmamayı başarabiliyor. Artık eski günler bir daha geri gelmez diye düşünüyordum ki tabii ki yanıldığımı gördüm.

Üretim hattındaki paketlerin içinde yabancı maddelerin olup olmadığını kontrol eden makinelerimiz böyle hatalı bir ürün tespit edildiğinde bu paketi hemen üretim hattının dışına atıp, hatalı ürünü de ekranda gösteriyor. Daha doğrusu operatör doğru pencereyi açmışsa gösteriyor. Cin fikirli bir müşterimiz, böyle önemli bir olayın, yani hatalı bir paketin üretilmiş olmasının ne olursa olsun operatör tarafından görülmesinin gerektiğine inanarak yazılımda şöyle bir değişiklik yapmamızı istedi: Hatalı ürün hattan atılır atılmaz hangi pencere açık olursa olsun otomatik olarak hatalı ürünlerin gösterildiği pencere açılsın. Böylece operatör hemen bu durumdan haberdar olup duruma müdahale edebilecek ve üretimin kalitesi yükselecek.

Yazılımla her şeyin yapılabileceğine ve daha da önemlisi yapılan her şeyin satılabileceğine inanan satış elemanı hemen olur demiş ve bu istek bizim bölüme geldi. Tabii ki zamanında Visual Basic öğrenmeye başlayıp bunu yarıda bırakan nesle ait olan programcılar hemen bunun saçma olduğunu söylediler. “Operatör belki o anda makineyi ayarlamakla meşgul olacak ve otomatik olarak başka bir ekrana sıçramak ayarları bozmasa da operatörün asabını bozacaktır. Bu işlem üç beş kere tekrarlarsa da o operatör kesin ekranı bıçaklar” dendi. Proje yöneticisiyle konuşuldu ve ikna edildi ama müşteriyi ikna edemedik. Satış elemanı da “parayı veren düdüğü çalar” dedi ve biz de bunu programladık.

Birkaç hafta sonra servisten bir eleman bize geldi ve müşterinin yeni bir isteği olduğunu söyledi. Son yaptığımız özelliği kapatmamızı istiyormuş ve bunun için de ödeme yapacakmış. Müşteriyi kimin ikna ettiğini sorduk. Servis elemanının kendisi ikna etmiş ve çok kolay olmuş. Hayretler içinde kalmıştık. Bütün departmanın yapamadığını tek başına başarmıştı. Asıl ilginç olan ise satış elemanının olmaması gerken bir şeyden iki satış çıkarabilmesiydi. Umarım şirketteki herkes bu olaydan bir ders çıkarmıştır.

Kendini başkasının yerine koyabilmek genelde oyunlarda kullanılan bir yöntemdir. Rakibim bu durumda ne yapardı diye düşünerek iyi bir hamle ya da strateji bulmanın güzel yollarından biridir. Nedense yazılım projelerinde çok sık gözardı edilen bir yöntemdir ama. Yaptığımız programı ya da makineyi kendi klonlarımızın kullanacağını ya da bu sistemlerin bizim çalıştığımız ortamlarda kullanılacağını varsayıyoruz heralde.

İşe başladığım ilk günlerdi. Şirketin endüstriyel teraziler üretip sattığını biliyordum ama henüz hiçbir tanesini görmemiştim. Birgün hemen yanımızdaki elektronik tasarım bölümüne servisten bir dokunmatik ekran birimi geldi. Bu ekranı tasarlayan eleman elindeki şeye şaşkınlıkla bakıyordu. Servis elemanı bunun tamir edilip edilemeyeceğini sordu. Arkası paslanmaz çelikten yapılmış 20 inç büyüklüğündeki tamamen yamulmuş dokunmatik ekran tasarımcının vereceği cevabı bekliyordu. Geleceği bu cevaba bağlıydı. Sonunda herkesin bildiği cevap geldi. Yenisini gönderin!

Sonra öğrendik ki müşteri teraziye, düşük ağırlıkta bir ürün tartıldığında her yerden duyulabilen bir alarm sistemi eklenmesini istemiş. Aslında mantıklı bir istek. Bazı üretim bölümleri çok hareketli ve gürültülü olur ve buralarda görsel sinyaller her zaman fark edilmeyebilir. Bazen de operatör birden fazla makineyi kontrol ederken sistemde ortaya çıkan sorunları kaçırabilir. Dolayısıyla müşteri, operatör müdahale edene kadar bu alarmın çalması istenmiş ve biz de yapmışız. Hamur ürünleri üretilen bu fabrikada operatör alarmı susturmayı başaramayınca o an şans eseri elinde bulunan kilolarca ağırlıktakı hamur bloğunu ekrana fırlatmış. Alarmın sustuğunu hiç sanmıyorum ama eleman elinden geleni yapmış.

Birkaç gün sonra bir başka müşteriden başka bir ekran geldi. Bu yamulmamıştı ama bizim de sorunlardan düşündüğümüz kadar uzakta olmadığımız hissini veren bir durumdaydı. Ekran boydan boya yarılmıştı.

Bu ekran da yine operatörün uzun süre doğru menüyü bulamaması nedeniyle bıçaklanarak (evet demek ki bazı operatörler üretimde bıçak kullanıyor) yırtılmıştı.

Bu örneklerde ne müşteri ne de bizim ekip kendini kullanıcı operatörlerin yerine koyabildi. Sonuçta belki o operatörler ceza aldılar ama müşteriler de bir bir süre üretim yapamayıp kayıplar yaşamış oldu. Bu derece olmasa da bu işin buralara varacağını kimse göremedi mi acaba? Tabii ki görenler olmuştur, hatta söylemişlerdir de ama bazen müşteriyi, bazen de satış departmanını ikna etmek kolay olmuyor. Herkes kendini başkasının yerine koyabilseydi çok farklı bir dünyada başka başka programlar yazıyor olurduk heralde.

Çalıştığım yerde tabii ki doğru düzgün yapılmayan bir yazılım geliştirme tekniğidir. En basit şekliyle yazılmış olan programın belli kurallara göre kontrol edilmesidir. Bu kurallar ciddi ortamlarda yazılı olarak bulundurulur. Bu kuralların bulunmadığı durumlarda gözden geçirmeyi yapan kişiler kendileri karar verirler. Bu sonuçlar sonca programcıya bir şekilde iletilir. Bu birebir bilgisayar başında bir görüşme olabilir ya da başka bir şekilde ilgili programcıya yapılacak iş olarak bildirilebilir. Bu şekilde bazı karışık hatalar çok geç olmadan bulunabilir.

Bazı yerlerde bu iş statik kod analizi araçlarına paslanır. Bu ikisi birbirinin yerini tutmaz ama istatistik tutulmayan yerlerde tek başlarına yeterli oldukları sanısına kapılmak çok kolay olmakta. Kodu gözden geçirme işleminden sonra ilgili programcıyla bulunan noktaların tartışılması ilginç bir olaydır. Tecrübesiz programcılar genelde kendilerine saldırıldığı sanısına kapılırlar ve gereksiz, duygusal tartışmalara girişebilirler. İki taraf için de öğretici olabilecek bu aşama böyle şeylerle boşa harcanmamalı bence.

Teoriye dalıp asıl anlatacağım şeyi unutuyordum az daha. İlaç endüstrisinde çalışan müşteriler genelde bizden programla beraber bu gözden geçirme sonuçlarını da rapor halinde isterler. Bir seferinde bir ekipten böyle bir kod gözden geçirme isteği geldi. O gün öğlende program müşteriye teslim edilecekmiş ve bu işi yapacak boşta elemanları yokmuş. Kabul ettim. Hangi özelliklere bakmam gerektiğini sordum. Genel bir kontrol istediler, zaten tek bir dosyada değişiklik yapmışlar. Kontrol bitince programı onayladığımı belirten bir kağıdı da imzalamam gerekiyormuş. Programı açıp okumaya başladım. Bir süre sonra bir hafıza bölümünün serbest bırakılmadığını gördüm. Bu tür hatalar normalde her işletildiğinde hafızanın bir kısmını programdan çalarak daha az kullanılabilir hafıza bırakır. Bir süre sonra da programa hafıza kalmaz ve program da çalışamaz. Bunun üzerine şefe gittim ve durumu anlattım. “Bu hatayı buldum ve dolayısıyla programı onaylayamayacağım” dedim. O da baktı ve hatayı gördü. Bunun üzerine o da kendi şefine gitti ve çözüm aramaya başladılar. Programı düzeltip, test edecek zamanları kalmamıştı. Bunun üzerine raporumun altına bir ek yazıldı (hata, sistemin genel özellikleri nedeniyle ortaya çıkamaz gibi bir şeyler) ve şefim de bu raporu imzaladı. Bir sorun daha kolayca çözülmüş oldu.

Akraba kayırıcılığı tabii ki sadece şarka mahsus bir durum değil. Yani öyle düşünüp moraliniz bozulmasın. En fazla “Almanlar bizi kıskanıyor, onlar da yapıyor” deyip geçin.

Görüntü işleme projesi başladığında çok sıkışık bir zaman planımız vardı. Önce fuara yetişmesi gereken bir proje yaptık ve ardından da büyük bir müşteri için anlaşılan diğer üreticilerin yanaşmadığı bir proje. Fazladan mesailerle geçen aylar sonunda müşteri projenin ne durumda olduğunu görmek için şirkete uğramaya karar verdi. Sistemin yeterince hızlı çalışıp çalışmayacağını görmek istiyordu. Ulaşmamız gereken zaman da ciddi bir şey değildi. Bütün bir paketi inceleyip sonuçları bir sonraki makineye bildirmek için 2 saniye zamanımız vardı.

O sırada proje yöneticisinden ne tür yardıma ihtiyacımız olabilir gibi bir soru geldi. Biz de önümüzde bu tür sorunlarla sık sık karşılaşacağımız için zaman ölçme konusunda ufak bir desteğe ihtiyacımız var dedik. Aslında bunu yapabilecek elemanlarımız vardı ama herkes meşgul olduğundan böyle bir şey istedik. Hem işimize yarayacak bir şey olacaktı, hem de bu iş sırasında bizi soru yağmuruyla işimizden de pek alıkoymayacaktı. Yöneticimiz tamam deyip bu işle ilgileneceğini söyledi. Şaşırmıştık ama yine de daha önceki performanslarına göre iyi bir hareketti diyerek sevinçle karşıladık.

Birkaç gün sonra proje yöneticimiz müjdeyi verdi. Destek bulunmuştu. Destek verecek ekiple toplantı da o cuma yapılacaktı. Müşteri bir sonraki cuma gelecekti ve o hafta perşembe günü resmi tatildi. Kısaca pek bir zaman kalmamıştı. Bizim ekip şefi tatilde olduğundan toplantıya benim girmemi istedi. Kabul ettim.

Toplantı günü geldiğinde hazırlıklarım tamamlanmıştı. Olumsuz bir durum için de B planımız vardı. Program müşteri geldiğinde bitmiş olmayacaktı tabii ama iyi yolda olduğumuzu gösterebilirdik. Toplantı odasına girdiğimde (nedense toplantılara hep geç gidiyormuşum izlenimi bırakıyorum ama yok öyle bir şey) bizim yönetici ve diğer şirketin sahibi masada yerlerini almış havadan sudan konuşuyorlardı. Kısa bir tanışmadan sonra problemi anlattım. “Bu projede ve ileridekilerde sık sık duyarlı bir şekilde zaman ölçmemiz gerekecek ve bu altyapıyı kurmak için şu an ayıracak kaynağımız olmadığından profesyönel yardım almayı düşündük. Bu iş için kullanmayı düşündüğümüz programlar şunlar ve sistemimizin özellikleri de şöyle. Bu iş haftaya müşteri gelmeden biterse iyi olur.”

Desteği verecek eleman bunun yapılabileceğini, kolay olduğunu filan anlattı. İyi o zaman, toplantı hemen biter, gider diğer işlere bakarım diye düşünüyordum ki birden daha iyi bir planı olduğundan bahsetmeye başladı. İki saniye önceki rahatlama yerini birden korkuya bıraktı. Yöneticimiz de merak etti ve neler yapılabileceğini sordu. Eleman da anlatmaya başladı: Bizim görüntü işleme alanında oldukça fazla tecrübemiz var. Anladığım kadarıyla sizin sorun şuralarda (Bizim sorunları ne zaman konuştunuz siz ya?). Sizin kullandığınız model (Oh, oh, detaylar bile konuşulmuş) yerine monolitik bir yapı kullanarak program daha hızlandırılabilir ve böylece zaman ölçmeye gerek kalmaz (Bu nasıl bir kabus böyle?).

“İyi de bizim sadece zaman ölçmeye ihtiyacımız var” diye araya gireyim dedim ama masal devam ediyordu. “Şimdi biz müşterinin ürününü inceleyecek rutinleri yazalım. Sonra onu sizin programa entegre ederiz. Kesinlikle daha hızlı bir program olacaktır.”

“Müşteri haftaya geliyor. Önümüzdeki hafta kısa bir hafta. Böyle bir program yapsanız bile bu süre içinde entegre edilmesi imkansız.”

“Bizim hazır kütüphanelerimiz var. O kadar sürmez. Entegrasyonda sizi de destekleriz.”

Bu sırada kara kara dereyi geçerken at değiştirilmez Almanca nasıl denir acaba diye düşünüyordum. Adamın önerdiği şey bugüne kadar pratikte hiçbir zaman başarılı olamamış bir yöntemdi. Hatta Brooks kanunu diye de geçer: “adding human resources to a late software project makes it later”. Bu yeni elemanların bizim sisteme alışana kadar bir süre geçmesi lazım, ayrıca bu sıradaki iletişimler de bizim elemanları işlerinden alıkoyacak. Haftaya yetişmesine imkan yok yani.

Bunları da anlattım ve bizim proje yöneticisi dahiyane bir çözümle olaya girdi. “Aynı anda iki yolu da izleyemez miyiz acaba?”. Destek veren şirketin sahibi buna hemen olumlu yaklaştı. Ben de nasıl bir oyuna kurban gittiğimi ancak o zaman anladım.

“Çarşamba sabaha kadar rutinler hazır olursa belki entegrasyon şansımız olur. Ondan sonra imkansız. Zaman ölçümlerini de en geç o zamana hazırlarsanız iyi olur.”

Toplantıdan sonra proje yöneticisine ayrıca bu yapılan planın yetişmeyeceğini zaman ölçme kısmını en kısa sürede yaptırmasını söyledim. En azından ileride kullanabileceğimiz bir şey yapmış olurlardı o zaman. Tabii ki “hee, tamam” cevabını aldım.

Sonraki hafta her gün planın ne durumda olduğunu sordum. Çarşamba günü de geldi ve ne zaman ölçümü ne de söz verilen rutinler geldi. Çarşamba öğlende proje yöneticisine “Rutinler artık gelmese de olur, umarım müşterinin tatmin olacağı kadar hızlıyızdır.” dedim. Tabii ki cuma günü rutinler geldi. Bizim sisteme eklememi istediler. Ben de “Ben kendimle dalga geçebilirim, bunun için size ihtiyacım yok” dedim ve müşteriye sunum için B planını deneyeceğimizi anlattım. Hemen programa birkaç kıytırık zaman ölçme rutini ekledik, programı yeniden derledik ve müşteriyi karşıladık. İstenen zamana henüz ulaşamamıştık ama projecilerimiz bunu müşteriye iyiye gidiş olarak satabilmişti. Müşteri de memnun kalmıştı (memnun kalmaya ihtiyacı olan müşteriyi memnun etmek kadar kolay bir şey yoktur).

Destek hizmeti aldığımız firmanın sahibi bizim proje yöneticisinin sınıf arkadaşıymış. Yaptığımız toplantının sonucu baştan belliymiş yani. Böylece kendi rutinlerini bizim sisteme entegre etmeye çalışarak güzel bir proje kapmayı başardılar. Bu süre içinde zaman ölçme sistemi asla kurulmadı. Hala, B planında ne yaptıysak o kullanılıyor. Bir yılda eklediğimiz destek rutinlerini işe yaramadıkları için sistemden çıkarabilmemiz üç dört yıl daha sürdü.

Şirketteki ilk projelerimden biri, bir ürünü DBMS destekli bir hale getirmekti. Önceki versiyon Codebase denen bir sistemle yazılmıştı ve sık sık veri kaybına ya da bozukluklarına yol açmaktaydı. Transaksiyon kontrolü de zordu o sistemde. DBMS olarak MySQL’i seçtik ve projeye başladık. Programlama dili olarak C++ ve geliştirme ortamı olarak da Visual Studio 2003 ve MFC (Microsoft Foundation Classes) kullandık. MFC, ODBC (Open Database Connectivity) üzerinden veri tabanıyla iletişim imkanı sunuyordu. CDatabase nesneleri filan vardı. Değişik dilleri desteklemek zorunda olduğumuzdan da Unicode desteğini aktifleştirmiştik. Başka veri tabanlarını destekleme durumu ortaya çıkabilir diye hem şema hem de veritabanı tabloları için ayrı kütüphaneler de yazdık. Bu tür sistemler o sıralarda Java için çok yaygındı ama C++ için hoşumuza giden bir çözüm bulamamıştık. Projeyi beraber yaptığım arkadaş da o sıralarda C++’tan başka bir dile geçmeye yanaşmıyordu.

İlk basit denemelerden sonra ümit vadeden planımız garip bir sorunla karşılaşmıştı. Nerede olduğunu bilmediğimiz bir Access Violation hatasına çarpıp duruyorduk. Tabii ki hata anındaki stack trace (o anda programda işletilen komutların hiyerarşik listesi) hiçbir şey ifade etmiyordu. Anlaşılan bayağı şiddetli bir buffer overrun (program yanlış yerlere veri yazarak başka nesneleri ve dolayısıyla programın çalışmasını bozuyor) sorunuyla karşı karşıyaydık. Tabii hatanın tam olarak hangi komutta ortaya çıktığını bilmediğimizden internette de aratamıyorduk. Sonuçta buffer overrun ya da access violation nedeni bulmak için oldukça genel terimlerdi. Stack trace, hatanın fark edildiği anda okunamaz  durumda (daha doğrusu bizim durumumuzda anlamsız) olduğundan gözümüz kapalı yavaş yavaş uçuruma doğru yürüme yolunu seçtik. Problemin tek iyi tarafı tekrarlanabilir olmasıydı. Bu sayede defalarca uçuruma gelip hangi anda düşmeye başladığımızı anlamaya çalışacaktık.

Standard yöntem programı hata ayıklayıcı ile çalıştırıp adım adım işletmek olabilirdi. Hata mesajının geldiği yere bakarak programın maksimum nereye kadar ilerlediğini tahmin edebiliyorduk ve baştan oraya gitmek epey zaman alacaktı. Bunun üzerine programın çeşitli yerlerine breakpointler (Program o satıra kadar işletilir ve o noktada otomatik olarak durdurulur) koyarak nereye kadar gidebildiğine baktık. Bu yerleri de genelde hep ikiye bölerek bu aramayı hızlandırdık, yani bir nevi binary search algoritması kullandık. Bir süre sonra hata mesajının nerede ortaya çıktığını bulduk ama bu çok işe yaramıyordu çünkü buffer overrun daha önce olmuş olmalıydı. Biz sadece en geç ne zaman olmuş olabileceğini bulmuş oldu.

Program unit test gibi yöntemler kullanılmadan yazılmış olduğundan parçaları tek tek hızla test etme şansımız da yoktu. Elimizdeki tek araç visual studio içindeki hata ayıklayıcısıydı. Nesnelerin değerleri filan normal gözüküyordu. Bununla oynarken sadece nesnelerin değerlerini değil aynı zamanda bu nesnelerin bulunduğu adreslerdeki (ve bu adreslerin çevrelerinde) değişiklikleri de görebildiğimizi fark ettik. Visual studio her işletilen satır için seçilen adres bölgelerindeki değişiklikleri kırmızı gösterebiliyordu. Çaresizlikten buralara bakayım dedim. Sonuçta hatanın yaklaşık hangi satırlarda olduğunu bulabilmiştim. O satırlardaki nesnelerin hangi adreslerde olduğunu da buldum. Ondan sonra dürbünümü o alana tutup programı satır satır işletmeye başladım. Her satırda ufak tefek kırmızı değişiklikler görünüyordu ama bunlar aradığım şey değildi. O nesnelerin büyüklüklerini bildiğimden bu kırmızı bölgelerin nesnenin içinde mi dışında mı olduğunu hesaplayabiliyordum. Böyle motivasyonumu kaybetmiş bir şekilde satırları tek tek işletirken birden adres ekranı havayi fişek patlaması gibi kıpkırmızı oldu. En son hangi satırda olduğuma baktım hemen ve veri tabanıyla bağlantı kurma komutunu gördüm. İnternette arattım. CDatabase, buffer overrun filan dedim ve binlerce sonuç aldım. Meğer MFC’nin o versiyonu unicode ile bir hesap hatası yapıyormuş ve bu sayede epeyce bir adres alanına yanlış değerler yazıyormuş. Böyle olunca da program bir sonraki adımda nereye gideceği bilgilerini de bozmuş oluyor. Evet, sorunu bulmuştum ama çözüm neydi? Forumlara bakılırsa Microsoft yakında bir yama yayımlamayı düşünmüyordu ama biz programı müşteriye söz vermiştik.

Sonuçta çaresizliğimizin doruğunda visual studio’nun küçük boyutlarda yaptığı bir şeyi yapmaya karar verdim. Veri tabanı nesnesinin sağına ve soluna dev gibi yasak bölgeler inşa ettim. Yanlış hatırlamıyorsam 10 kB büyüklüğünde boş alan koydum. Bir nevi hendek yöntemi. Bu şekilde diğer nesneleri veri tabanı nesnesindeki hatalardan korumayı başardım. Şansımıza veri tabanı nesnesi sınırları içinde bir sorun çıkmamıştı. Aylar sonra gelen Microsoft yaması ile bu utanç verici çözümü de kaldırdık ama bence bu utancın büyük kısmı Microsoft’a aittir. Bütün bu hatayı arama ve düzeltme süreci neredeyse iki hafta sürdü. Aslında bu iki haftada hatanın adını aramış olduk, adı konulunca kendimizi sanki herkesin aynı sorundan muzdarip olduğu bir ortamda bulduk.

Yaklaşık bir yıl süren işşizliğimin sonlarına doğru iş arama yöntemimi değiştirmem gerektiğine karar vermiştim. İş ve işçi bulma kurumu her ay en son net maaşımın yüzde seksenini otomatikman veriyordu ama bir yılın ardından bunda daha fazla kesintilere gideceklerdi. Ayrıca bana gönderdikleri iş teklifleri de artık iyice saçmalaşmaya başlamıştı. Bunun üzerine internetten çevredeki şirketlere bakmaya başladım. Ehliyetim olmadığından tren ve yürüyerek makul bir zaman içinde ulaşabileceğim bir iki tanesini seçip özgeçmişimi yolladım. Ondan sonra son bir yıldır yaptığım işlere geri döndüm. Uyumak ve reality show seyretmek.

Noel öncesi bir gün televizyonda talk show seyrederken telefon geldi. Öğleden sonra müsaitsem benimle görüşmek istiyorlardı. Randevu defterime baktım ve reality showları başka bir güne kaydırabileceğimi gördüm. Olumlu cevap verdim ve yola çıktım. Yirmi dakika ötedeki Kaiserslautern şehrine ilk gidişimdi. Trene bindim  ve istasyonda indim. Haritalardan baktığım otobüs durağına gittim ve 102 nolu otobüsü beklemeye başladım. Lanet otobüsten iki tane vardı. Hangisine binmem gerektiğini bilmiyordum. Sormaktan çekinip taksiyle gideyim dedim. Zaten az zamanım kalmıştı. Taksiye bindim adresi verdim. Bir gözüm saatte diğeri de taksimetrede gitmeye başladık. Görüşme saatine çok az kalmıştı ki şöför birden yanlış geldiğini, gitmemiz gereken sanayi merkezinin şehrin diğer tarafında olduğunu söyledi. Yapacak bir şey yoktu. Peki o zaman şehrin öbür tarafına gidelim dedim. Neyse ki şehir küçükmüş. Beş dakika kadar gecikmeyle şirkete vardım. Parayı uzattım ve adam yok dedi. “Benim hatam. Alamam.” dedi. Ben de Almanca’m çok iyi olmadığından ısrar etmedim.

İçeri girdim ve kısa süre sonra beni görüşme odasına aldılar. AR-GE şefi ve iki yazılım bölümü yöneticisi masada yerlerini aldılar. Sonra başladık. Şirketin neler yaptığından haberim olup olmadığını sordular. Internetten baktığımı, endüstriyel teraziler filan yaptıklarını söyledim. Sonra bana bir tane terazi birimi verdiler. Küçük bir metal parça, çok az hareket ediyor ve bununla paketleri çok hassas tartıyorlardı. Bu parça ile ilgili sorular sormaya başladılar. Tabii ki internet sayfasından bu aletin şemalarına çalışmıştım ama şemalar tersti. Bu yüzden bazı sorulara yanlış cevap verdim.

Ardından zeka testine geçtik. İşin uzmanları için belk işe yarar bir test olabilir ama bu ekibin bunu bilerek yaptığını sanmıyorum. Neyse işte. Klasik terazi bilmeceleriydi. On adet toptan ağır olanını üç tartıda bulmak gibi oldukça basit şeyler sordular. Ortaokuldan beri bu tür bilmecelerle ilgilendiğimden ölçecek bir durum yoktu.

Bilmeceleri bitince programlama bilgimi ölçmeye karar verdiler ve terazi birimi yazılım şefi aşağıdaki soruyu sordu:

int x = 42;
int y = 15;
x ^= y;
y ^= x;
x ^= y;

Bu kod ne yapar

Kısa bir C kodu bu. Öğrenmek istedikleri şey sanırım bit işlemlerini yapabilip yapamadığımdı. Yukarıdaki işlemler XOR diye bildiğimiz bit işlemleri. Yani aynı değerdeki bitler 0, farklı değerlerdeki bitler de 1 sonucunu verecek. Soruyu görünce istemsizce gülümsedim. Bir iki saniye ne desem acaba diye düşündüm ve bu değiş tokuş fonksiyonudur dedim. Yani işlem sonunda y değişkeninde 42, x değişkeninde de 15 değeri olur. Sorgu ekibi şaşırmıştı. İlk kez doğru cevap almışlardı ve daha da kötüsü bu cevabı hiçbir şey ölçemeyecekleri bir şekilde almışlardı. Nasıl bilebildiğimi sordular. Ben de bilmeceleri sevdiğimi ve bu “bilmeceyi” de daha önceden bildiğimi söyledim. Güldüler ama ben de tedirgin oldum, şimdi bir şey ölçemediklerinden daha basit ve yapamayacağım bir şey sorabilirlerdi. Bunu engellemek için konuşmaya devam ettim. “Ama değiş tokuş için bunu kullanmamak lazım, çünkü bu haliyle her zaman çalışmaz. Bunu fonksiyon şeklinde yazarsak referans ya da göstericiler kullanmak lazım ve o zaman da iki göstericinin de aynı adresi gösterdiği duruma dikkat etmek lazım. Yoksa iki değişken de sıfırlanır (a xor a = 0).”

 void xorSwap (int *x, int *y) {
     if (x != y) { //bu kontrol adresteki değerin sıfırlanmasını engeller
         *x ^= *y;
         *y ^= *x;
         *x ^= *y;
     }
 }

*x ^= *y ^= ( *y ^= *x );

Bana sorulan sorudaki işlemin tek satırda yapılmasıydı bu. Bu görüşmedeki durumdan daha feci bir durumdu çünkü yukarıdaki  satır dilin kurallarına göre tanımlanmamış bir davranıştır, yani derleyici burada istediği her şeyi yapabilir ve bu andan itibaren program da artık özgürdür. Neyse ki arkadaşı ikna etmek şefi ikna etmekten daha kolay oldu.

Bence bir iş görüşmesinde bundan çok daha iyi bilgi ölçme, değerlendirme imkanları vardır. Örneğin işe başvuran kişi bir hata ayıklama, kod inceleme ya da “pair programming” seansına davet edilebilir. Bu sırada kendisiyle çok daha zengin bir iletişim kurulabilir.

Projede uzun zamandır giderilmeyen çeşitli hatalar var. Bunlar sistemin çalışmasını çok kısıtlayan hatalar değil ama en azından rahatsız edici şeyler.

Birbiriyler haberleşme yapan uygulamaların daha bu haberleşmeye hazır olmadan iletişime geçmeleri en basit örneklerden biri. Sistemde, haberleşme başladığı an belli aşamaların bitirildiği varsayılır. Bunun dışında haberleşme başlayınca yine karşılıklı olarak beklenen davranışlar da vardır ve bunlar protokollerle tanımlanmıştır. Kontrol birimi makinenin durumunu bildirirken haberleşme başlatılırken açılmış olan oturumun kod numarasını kullanmalıdır gibi. Eğer bu oturum kod numarası kullanılmazsa diğer uygulamalar bu mesajları göz ardı eder ve sistem beklendiği gibi çalışmaz (ama çalışır).

Başka bir hata ise çok farklı makinelerin üretilmesine rağmen ortak arabirimlerin ihmal edilmesi. Örneğin, görüntü işleme birimi belli durumlarda otomatik olarak tekrar ayarlanmalı. Bunu yapmak için belli bir modüldeki bir parametreye bir değer yazmak yeterli. Projeye 10 yıl önce başladığımızda da böyle yaptık. Zamanla daha farklı kameralar kullanmaya başladık, dolayısıyla da yeni modüller ve parametreler tanımlandı. Bazı modüllerde birden fazla parametrenin kullanılması gerekti. Böylece bu parametreyi kullanan uygulamanın kodu iyice karışık haller almaya başladı. Bu sorunu halletmenin yolllarından biri tabii ki bu işlem için bir arabirim tanımlamak. Anlaşılan bu parametre diğer parametrelere göre daha özel bir duruma sahip ve nerede olduğu da makineye göre değişebiliyor. Eğer otomatik ayarlama diye bir komut tanımlansaydı bu her makinede kolayca uygulanabilirdi ama görüntü işleme grubu bunu programlayamayacağını bildirdi. Anlaşılan kullandıkları kütüphanede bu değişikliği yapabilecek birine sahip değillerdi. Bir başka çözüm olarak yazdığım program bir konfigürasyon dosyasında bu bilgileri tutabilir ve her makine için bu dosya değiştirilebilir. Bunun avantajı tabii ki tek bir kodun her makine için çalışması. Tabii ki dezavantajları da var. Makineyi kuran elemanın bu dosyanın dilini anlaması lazım ve görüntü işleme birimiyle beraber bu değişiklikleri yapması lazım. Bu çözüme de yanaşılmadı. Ben de bütün bildiğim parametrelere ayarlama anında değerler yazmaya başladım. Tabii ki bazı makinelerde bu modüller mevcut olmadığından ekranda uyarı mesajları görünüyordu.

Test grubu bu hata mesajlarını her gördüğünde bunlar üzerine kısa toplantılar yapılıyordu ve her seferinde bunların nasıl çözüleceğini anlatıyordum. Cevap hep aynıydı: Bu değişiklikleri yapacak zamanımız yok. Doğru bir çözüm ile sorunlara yaklaşılmadığından daha kışkırtıcı çözümler aramaya başladım. Diğer uygulamaların protokolleri çiğnediği her durum için hata mesajları tanımlamaya başladım. Her seferinde bu hataları kullanıcı arabiriminde gösteriyorum.

Bu sabah görüntü işlemecilerden biri geldi ve bir makinede ufak tefek sorunlar olduğunu söyledi. Sorunların neler olduğunu sordum. Yazdığım uygulama mevcut olmayan modüllerdeki parametreleri sorguluyormuş. “Tabii ki yapıyor” dedim. “Bana verilmiş tanımlı bir arabirim olmadığı sürece bütün parametreleri sorgulayacağım” dedim. Görüntü işlemeci de “Veri tabanında o parametrenin olmadığını biliyorsun, onu sormana gerek yok ki” diye cevap verdi. Durumu daha açık bir şekilde anlatmam gerektiğini anladım ve kısa tiradıma başladım. “Eğer veri tabanında olmayan parametreyi sorgulamazsam hata mesajı gelmez. O zaman da herkes makine doğru çalışıyor diye düşünür. Makine doğru çalışıyor izlenimi yaratırsam kimse daha temeldeki bu tasarım problemleriyle ilgilenmez. Yani bütün bu hata mesajlarını sizi rahatsız etmek için yapıyorum. Bu program ve tasarım hataları giderilene kadar da mesajları göreceksiniz. Bunların ne olduğunu soranlara da durumu anlatmak zorunda kalacaksınız. Bunu durdurmanın yolu çok kolay. Protokollere uyun. Bana arabirim verin.” diye karşılık verdim.

Sonra ne mi oldu? Tabii ki hiçbir şey. Eleman, birkaç hafta sonra aynı konuşmayı tekrar yapmak üzere gülerek uzaklaştı. Ben de bir sonraki hata mesajım ne olsun acaba diye düşünmeye başladım.

Aborijinlere gönderilen peygamber Wendho, kavmindekilerin aksine okuma yazma biliyordu. Bu mucize sayesinde kavmi kendisinin peygamber olduğuna hemen ikna oldu. Wendho kendisine gelen vahiyleri bir kitapta topladı ama bu kitabın çok az bir kısmı günümüze kadar korunabildi. Aslında korunabildi yerine saklanabildi demeliyim, çünkü Wendho kitabi kavmine bırakmadı. Kitabın sayfaları çok uzun zaman sonra bir sandık içinde toprağa gömülü olarak bulundu.

Yer yer okunabilen parçalardan aktarılan kısımlar şöyle:

Haberci melek sordu: Sana verdiğimiz emirleri kavmine ilettin mi? Ben de “ilettim” dedim. “Nasıl karşıladılar?”.  “Her zamanki gibi karşıladılar, yüce haberci” dedim.

… Artik işitmede iyice zorlanmaya başladım. Her üç kelimenin birini anlamıyorum. Acaba haberci meleğe bundan bahsetsem mi? Daha önce söylemediğim için çok kızarsa? Böyle devam edeyim en iyisi…

…Haberci melek bugün de sordu. “Ey tanrının …, kavmin yüce … emirlerine … mu? … eksiksiz …? “Herşey yüce tanrının izniyle yolunda” dedim.

Melek devam etti: “Yüce tanrı, … vahiy …”

Wendho: “Tabii yüce haberci”

Melek: “Kıyamet … inananlar … cennete … Her … yetmişiki … verilecek.”

Wendho: “Tabii yüce haberci”

Melek: “İnanmayanlar da … gidecek.”

Wendho: “Tabii yüce haberci”

Melek: “Günde … kere … etmeyenler de …”

Wendho: “Yüce haberci, aslında …”

Melek gürledi: “Eyyy Wendho, tanrının sözünü ne cüretle kesersin?”

Wendho: “Tabii yüce haberci”

Melek: “Git, … kavmine … göster”

Wendho: “Tanrının izniyle, hemen.”

Okunamaz durumda olan birkaç sayfadan sonra son sayfada şunlar yazıyordu.

… Artık dayanamıyorum buna. Kavmime vahiyleri doğru iletip iletmediğimi bilmiyorum. Beni dinleyip dinlemediklerini bile bilmiyorum. Yeni vahiy gelecek diye her gün korkuyla uyanmak çok feci. Keşke yüce tanrı canımı alsa da kurtulsam.

Wendho kitabını sandığa koydu ve birazdan olacakları bilir gibi küreğini alıp derince bir çukur kazdı, sandığı dikkatlice bu çukura yerleştirdi ve üzerini toprakla örttü. Gömünün yerini belirten hiçbir işaret bırakmadı. Artık bütün işlerini bitirdiğinden yatağına uzanıp hazırladığı çayını içmeye başladı. Daha bitirmeden yüce tanrı da Wendho’nun son dileğini yerine getirdi.

Hz. Alvis, Kvenlere gönderildiği bilinen tek peygamberdir. Kendisine kitap ya da vahiy indirilmedi. Buna rağmen tanrı ona evrenin bütün bilgilerini bahşetti. Hiçbir meslekle uğraşmayan Alvis bütün gün etrafta dolaşır ve insanların sorduğu soruları cevaplardı. Okuma yazması olmadığından bugüne kadar kalan tüm bilgiler arkadaşlarının bize aktardıklarıdır.

-Bir gün öğlen vakti pazarda gezerken balıkçı Hendrik, Alvis’le dalga geçmek istedi. Bir balık yumurtasının nasıl şişip kocaman balık haline geldiğini sordu. Alvis de anlatmaya başladı: “Balık yumurtası bir hücredir. O hücre büyür ve zamanı gelince ikiye bölünür. Sonra bu iki hücre büyümeye başlar ve sonra onlar da bölünür. Bir süre sonra belli yerlerdeki hücreler daha farklı bölünmeye, daha özel şekiller almaya başlar. Böyle böyle değişik organlar oluşur ve en sonunda çok sayıda ve farklı hücrelerden meydana gelen bir balık”.

-Bir akşam gökyüzündeki renkli ışıkları gösterip “tanrılar acaba bu sefer ne diyor?” diye soran çobana sakince şunları anlatmıştı: “O ışıkların tanrılarla bir ilgisi yok. Güneş’ten çıkıp dünyanın çevresindeki gaz tabakasına giren çok küçük parçacıkların bu tabakadaki daha büyük parçacıklarla çarpışarak yörüngelerinde hareket eden parçacıkları başka yörüngelere çıkarması ve sonra bu parçacıkların eski yörüngelerine dönerken aldıkları enerjiyi başka bir parçacık şeklinde geri vermelerinden ibaret. Bu şekilde renkler oluşuyor. Değişik renkler değişik miktarda enerji demek oluyor.” Çoban bu açıklamadan hiç memnun olmadı ve “Sen benim dinime neden saygı göstermiyorsun?” deyip evine gitti.

-Alvis insanların kendisine sorular sormasından çok hoşlanırdı. Her soruya verecek cevabı vardı. İnsanlar ise bu cevapları ya anlamıyorlardı ya da zaten eğlenmek için sorduklarından dinlemiyorlardı. Alvis bu durumdan hiç şikayetçi olmadı ve kimseyi de cevapsız geri göndermedi.

Hz. Alvis’in ölümü

Alvis’in ölümü o güne kadar kendisine inanmayan kavmini tanrının varlığı ve kendisinin de onun peygamberi olduğu konusunda ikna eden tek mucizesidir. O gün öğleden sonra köy halkı avdan dönenleri karşılamaya gittiler. Tabii ki Alvis de onlarla beraberdi. Avlanmış hayvanlar yere serildiğinde köy halkı birden bir adım geri attı. Geyiklerden biri beyazdı ve bu iyiye işaret değildi. Kalabalık hemen bunun kutsal bir yaratık olduğunu ve bunu öldürmenin köye lanet getireceğini konuşmaya başladı. Bunun üzerine Alvis daha sonra veda hutbesi diye de anılacak konuşmasını yapmaya başladı:

“Bu kutsal bir geyik değil. Avladığımız diğer geyiklerle aynı. Sadece bir gen hatasına sahip. Bu nedenle vücudundak, renk veren maddeler çok az ve kırmızı yerine beyaz görünüyorlar. Daha ilginç bir durum ise şu avlanmış tavşanlarda görülebilir. Dikkat ederseniz sert kış döneminden önceki yıllarda avladıklarımızdan daha kalın derileri var. Ayrıca daha da iriler. Yiyecek miktarı eskisinden daha az ama önceki hallerine geri dönmemişler. Demek ki  evrimleşmişler, kalıcı bir şekilde. Son sert kış döneminde hayatta kalmayı başaranların soyu bu. Genleri bir şekilde değişip daha kalın derili olanlar o kışı atlatabildi ve hayatta kaldılar. Sonra da ürediler ve o genler sonraki nesillere aktarıldı. Bu her zaman olan bir işlemdi. Biz de değişe değişe, çevreye uya uya, hayatta kala kala bu hale geldik. Eskiden, yani çok eskiden iki ayak üzerinde bile yürümüyorduk mesela.”

Kalabalıktan homurdanmalar duyulmaya başladı. “Yine delirdi bu”, “Dediklerinden bir kelime bile anlamadım”, “Saçmalamayı bırak”. Alvis’in arkadaşları bir olay çıkmasından korkarak onun koluna girerek uzaklaştırmaya çalıştılar ama Alvis onları iterek konuşmaya devam etti.

“İnanmıyor musunuz? O zaman size ilk insanların ortaya çıkışını da anlatayım…”

Tam bu sırada kalabalık, büyük bir ışık ve gürültüyle etrafa saçıldı. Yerden kalkabildiklerinde gördükleri şeyle hayrete düştüler. Alvis’ten geriye sadece kömürleşmiş bir yığın kalmıştı. Köyün dericisi bu mucizeyi şu şekilde onayladı:

“Tanrı onu bize gönderdi ve şimdi de geri aldı. Keşke dediklerini anlayabilseydik.”