Bugün öğleden sonca Camlıca’daki Oracle Partner Hub’da, üniversite öğretim üyelerine yönelik “Oracle Akademi Günü”nde “Neden Üniversitede Java?” başlıklı bir seminer verdim. Seminerin sunumuna buradan ulaşabilirsiniz. Yakında içeriğini de bir yazıyla burada paylaşacağım.
Toplam görüntülenme sayısı: 1362
Sıklıkla yazılımcı olmak isteyen arkadaşlardan bana fikir soran emailler geliyor. “Yazılımcı olmak istiyorum, ne okuyayım?” diye soruyorlar. Gerçi bu soruyu “Yazılımcı olmak istiyorum, ne yapmalıyım?” şeklinde soranlar da oluyor ama ben her halukarda “Yazılımcı olmak istiyorum, ne okuyayım?” sorulmuş gibi cevap vermeye çalışıyorum 🙂
Öncelikle şunu belirteyim en baştan: Bir şeyi ögrenmenin tek yolu üniversite okumak değildir. Hatta lise ya da ilkokul okumak ta değildir. Ama ilkokul-ortaokul-lise-üniversite gibi formal kurumlarla eğitim ve öğretim almak ve bir konuda bu yolla yetkinlik sahibi olmak, bir şeyi öğrenmenin zamanımızda en temel, en yaygın ve en kolay yoludur.
Alternatif öğrenme yolları olan insanlar farklı şeyleri deneyebilirler. Örneğin ABD’den bildiğim “home schooling” ya da “evde öğretim” bir alternatiftir. Okuldaki örgün egitimi değişik sebeplerle istemeyen ve evinde kendisi ve tuttuğu ögretmenlerle ya da ücretli kurslar yanında kilise-cami gibi cemaat organizasyonları vs. desteklerle çocuğunu eğiten ve ilkokul-ortaokul-liseyi bu şekilde bitirmesini sağlayan çok ciddi bir kitle var orada. Keşke bizde de devlet bu özgürlüğü bize tanısa; açık ki hem devlet olarak böyle bir özgürlük hem de toplum olarak böyle bir sorumluluk anlayışından çok uzağız malesef.
Ya da belki farklı toplumlarda etraftaki ilim sahiplerinden diz-dize eğitim alan kişiler vardır ya da aklıma gelmeyen başka yöntemler. Ama açık ki ülkemizde ne evden öğretim var ne de sektörümüzdeki bilgi ve tecrübeyi klasik yöntemlerle elde edebiliriz. Sektörümüze yönelik kurs vb. ögretim merkezlerinin zaten eğitim vermek gibi bir hedeflerinin olmadığını, öğretmek noktasında da yoğun bir bilgi ve eğitmen kirliliği içinde boğulduğunu, dersanecilik mantığıyla, daha çok umut sömürüsüne dönüştüğünü görmemek mümkün değil diye düşünüyorum. İyi hatırlıyorum, üniversite sınavında 3-4 sene bir şey yapamamış birinin bana elinde bu tür kurslardan birisinin broşürüyle gelip, 8-10 bin TL ödeyerek “Yazılım Mühendisliği” kursuna gitmek için bana akıl danışması, hele benim gibi birine bu yapması büyük cesaret işiydi 🙂 Burada bu konuyla ilgili güzel bir yazı var.
Yukarıda da bahsettiğim gibi, üniversite okuyarak formal bir yolla bir konuda bilgi sahibi olmak, bir şeyi öğrenmenin zamanımızda en temel, yaygın ve kolay yoludur. Lakin daha önce de bu blogda belirttiğim gibi, aslolan tutku, yetenek, gayret, azim ve disiplinli çalışma gibi sıfatlardır bir insanı bilgili, yetkin ve başarılı kılan. Bence bu noktada aslında bir insanın liseyi nerede ve nasıl okuduğu muhtemelen üniversiteyi nerede nasıl okuduğundan daha önemlidir.
Yazılım ve etrafındaki teknolojilerle ilgili herhangi bir formal eğitim görmemiş yani işletme, felsefe vb. çok farklı konularda eğitim görmüş ama belli ki tutukusu, gayreti, zekası ve akıllıca kararlarıyla kendini yetiştirmiş son derece yetkin insanlar gördüm ve beraber çalıştım. Bu insanlar bilgisayar mühendisliği vb. konularda eğitim görmemişlerdi ama şurası kesindi ki iyi eğitim almışlardı, disiplinli, çalışkan ve akıllı insanlardı. Ve bilgiye ve bilenlere karşı tevazu içindeydiler ki o seviyelere gelebildirler.
Bu duruma bir de tersinden bakalım. Üniversite okumuş olmak bilgilenme ve yetkinlik kazanma için her şeyi çözüyor mu? Tabi ki çözmüyor. Bilgisayar mühendisliği eğitimi almış olmasına, hatta lisede çok iyi yerlerde okumuş, üniversiteye giriş sınavlarında derece yapmış olmasına rağmen herhangi bir sistemli çalışma disiplini kazanmamış (daha doğrusu muhtemelen çok iyi sahip olduğu halde üniversitede ya da sektörde çalışırken kaybetmiş), bakkal vari iş yapan, ya da en temel örneğin işletim sistemi kavramlarından habersiz, yazdığı programın karmaşıklığı sorulduğunda ilk defa duymuş gibi davranan kişilerle de karşılaştım. İyi BM bölümlerinden mezun olup, daha doğru düzgün isimlendirme yapamayan, örneğin bana “Akın bey şöyle 5 dakikada bize threadleri anlatırmısınız” diyen insanlarla da karşılaştım. Bilgi ve tecrübe bu kadar da aşağılanmaz ki? Değişik kişilere atfedien “Bu kadar cehalet ancak tahsille mümkün olur” bu olsa gerek. Benim 10 yaşındaki kızım, bilgiye ve bilene böyle yaklaşmıyor.
İki senelik meslek yüksek okulu bilgisayar programcılığından mezun ama pek çok bilgisayar mühendisinden daha çalışkan, daha güzel iş çıkaran kişiler de gördüm.
Sonuçta durum şu: Kimse kalkıp ta “doktor olmak istiyorum, tıp okumalı mıyım?”diye sormuyor. Bereket sormuyor 🙂 Ama “yazılımcı/programcı olmak için üniversite okumak gerekli midir?” sorusu üzerine internette tonla tartışma var. Nedir yazılımcı/programcı olmayı bu kadar basit gösteren şey bize? Ben en temel Java eğitimlerine “java” kelimesinin tarihi ve batılı dillere geçişiyle başlıyorum. Anlamak böyle bir şey çünkü, kendisinin bile 10 gün sonra ne yaptığını anlamadığı, üç-beş PHP cümlesini bir araya getirerek bir web sayfası yapmayı programcılık ya da yazılımcılık olarak gören zihniyetteki kişileri, diş çektirmek için eli alet görmüş bir nalbanta falan göndermek lazım bence 🙂
Her hangi bir üniversite bitirmediği halde kendini yetiştirmiş kişiler de gördüm ama hakikatten iyi olanları o kadar nadir ki. Bu türden kişilerin, ileri konularla uğraşacak noktalara gelebilmesine rağmen, en temel konularda hem bilgi ve beceri hem de yöntem açısından eksik ve sıkıntılı olduklarına defalarca şahit oldum. Bunun en temel sebebi ise “eğitim” eksikliği, yani formal olarak bilgi ve beceri aktarımının olmaması. Bilgi ve beceri, aynen bir binanın temelsiz olamaması gibi ancak sistemli bir şekilde üst üste konarak elde edilecek şeylerdendir. Bir şeyi öğrenmenin en kolay, en basit yolu ise olsa olsa sistemli öğrenme olabilir. Sadece birilerinin yaptıklarına bakarak, internetten kod örnekleri indirip çalıştırarak hatta sağlam ve ciddi bir şekilde kitap okuyarak bile gerekli yetkinlikleri elde etmek hem zordur hem de uzun yoldur, çok vakit kaybettirir. Nihayetinde bu riskleri almak yerine doğru düzgün, sistemli bir eğitim almak zaruridir.
Bu noktada “yazılımcı/programcı olmak için bilgisayar mühendisliği okumak gerekli midir?” sorusunun cevabını bir sonraki yazıda vermeye çalışacağım.
Toplam görüntülenme sayısı: 9767
Karşı karşıya olduğu iş bilgisini, analitik olarak irdeleyemeyen analistler, ne sağlıklı bir iş bilgisine sahip olabilirler, ne müşterilerinin ihtiyaçlarını anlayıp uygun çözümler bulabilirler, ne verimli toplantılar yapabilirler ne de işe yarar dokümantasyon yazabilirler.
Sıklıkla karşılaşıyorum ciddi tecrübeye sahip analistlerle. Sık sık danışmanlıklarda ve eğitimlerde, bazen de iş görüşmelerinde. Mesela iş görüşmesinde karşılaşıyorum örneğin finans sektöründe 10 senedir analist olarak çalışan adayla ve şunu soruyorum: “İş analizi ile yazılım ihtiyaç analizi arasında herhangi bir fark görüyor musunuz?” Pek fazla bir şey çıkmıyor. Peki diyorum, “yazılım ihtiyaçlarını kategorilere ayırmak istersek ne gibi farklı tipler aklınıza gelir?” Yine pek hikmetli bir cevap gelmiyor. Yaptığı işi ise genel olarak “müşteriyle görüşürüm, isteklerini bir dokümana yazarım, sonra ekran tasarımını yaparım, …” diye özetliyor. “Ekran tasarımı” işinin bir tasarım-design olduğunu ve bir “analiz” faaliyetinde nasıl yer aldığını sorunca bazen önce cümlemi tekrar etmemi istiyor ve “evet haklısınız” diye devam ediyor, bazen bu kadar da ilerliyemiyoruz. Gerçi ben isminde hem “ihtiyaç” hem de “tasarım” kelimeleri bulunan ihtiyaç analizi dokümanları çok sık gördüğümden alışkınım ama yine de sormadan duramıyorum 🙂
“Yazdığınız dokümana gelelim” diyorum ve “dokümanda ne gibi başlıklarınız var?” diye soruyorum. Amacım hiç olmazsa pratik olarak yaptıklarına bakarak iş ve ihtiyaç analizi ile ilgili ne kadar “analitik” olduğunu anlamak. “İhtiyaçlar” diyor dokümandaki ilk başlık içın. Tabi diyorum, sonuçta “İhtiyaç Analizi” dokümanında ihtiyaçlar olur 🙂 İhtiyaçlar başlığı altında ne gibi alt başlıklar olduğunu sorunca da, olmadığını, ihtiyaçları alt alta sıraladığını söyluyor adayımız. “Müşteri anlatır ihtiyacını, ben de yazarım” diyor. Buna da şükür, çünkü daha kötüsü var: Müşteri kısa bir emaille, bir telefon konuşmasıyla ya da bir araç yardımıyla iki satırla gönderebilir ihtiyacını. Ama müşterinin ihtiyacını anlatıp, analistin de hiç bir analitik süreçten geçirmeden anlatılanı yakalayıp yazılım geliştirenlere ilettiği bir süreçte analiste “postacı” demek daha uygun olmaz mı? “Sonra niye programcılar bizden memnun değiller?” diye sormanın ne alemi var ki?
Demeye çalıştığım şey şu: İşini yapışı açısından, pozisyonun ya da rolün isminde var olan “analitik” olma ile yakından uzaktan ilgisi olmayan kişilerin, iş bilgisini ve yazılım ihtiyaçlarını analitik olarak ele almaları mümkün değil. Bu durumda tonlarca iş bilgisi, bir şekilde bir araya getirilmiş cümlelerden ibaret olacak, yani “malumat” olarak kalacak. Analitik olarak ele alınmadığı için, içinde herhangi bir soyutlama da içermeyecek. Gittikçe büyüyen ve karmaşıklaşan iş bilgisini ve yazılım ihtiyaçlarını, bölük-pörçük malumat öbekleri olarak ele almak sanırım bir BT kurumu içın yapılabilecek en büyük hatadır.
İş bigisini ve yazılım ihtiyaçlarını analitik ya da çözümleyici olarak ele almaktan kastımız şu: Öncelikle bir ihtiyaç kategorizasyonu olmalı. Örneğin fonksiyonel olan ve olmayan ihtiyaçlar olarak ayırım. Sonrasında iş ihtiyaçları, kullanıcı ihtiyaçları ve fonksiyonel ihtiyaçlar şeklinde farklı soyutlama seviyelerinde ihtiyaç hiyerarşisinin kurulması gerekli. Ayrıca kullanıcı ihtiyaçlarının, kullanıcı süreçleri olarak “süreç” tabanlı ifade edilmesi çok önemlidir. Yani içinde insan olan farklı roldeki kullanıcılarla birlikte haberleşilen farklı yazılım ve donanım sistemlerinin de olduğu ki bunların tümüne birden biz aktörler diyoruz, kullanıcı iş akışlarının ortaya konması. İş akışlarındaki alternatif ve sıra dışı durumların belirlenmesi, yani olumlu sonuçlanan senaryolar dışında olumsuz ve alternatif senaryoların da ortaya konması, süreç analizi için olmazsa olmazdır. Kurum seviyesindeki iş süreçleri öncelikle kurum çapında çizilip detaylandırılabilir. Kullanıcıların iş sureçleri ise örneğin use-case (kullanım şekli) olarak yakalanabilir ve UML’in aktivite diyagramlarıyla daha görsel ve analitik hale getirilebilir.
İş süreçlerindeki farklı tipteki iş kurallarının ayrı bir başlık altında toplanması da çok önemlidir, çünkü iş süreçleri pek çok hesaplama, kısıtlayıcı ya da tetikleyici cinsten kurallar içerir. İş süreçleri ve kurallarından sonra süreçlerdeki atomik olan fonksiyonel ihtiyaçların ayrıca tek tek yakalanması ve bunların süreçlerle ilişkilendirilmesi en detaylı fonksiyonel ihtiyaçları ortaya çıkarır. İnsan aktörlerin dahil olduğu süreçlerde, aktörün sistemle etkileşiminin detaylandırılması amacıyla kullanıcı arayüz analizinin (tasarımı degil!) yapılması da unutulmaması gereken analiz çalışmalarındandır.
Ayrıca iş süreçlerindeki kısıtların, kalite ve uyum standartlarının ortaya konması, entegrasyon detaylarının belirlenmesi, sistem ihtiyaçlarının çıkarılması ve mimari ihtiyaçlar olarak fonksiyonel olmayan ihtiyaçların hem süreç hem de sistem tabanında ortaya konması, analitik ve tam bir ihtiyaç analizi çalışmasının olmazsa olmazlarındandır. Tüm bunlar, aslında “malumat” seviyesindeki iş bilgisi ve yazılım ihtiyaçlarının “bilgi” seviyesine çıkarılması faaliyetlerindendir. Bir konunun öğlerini analitik olarak kategorilere ayıramazsanız, hiyerarşiler kurgulayamazsanız, o konu hakkında da düşünemezsiniz, dolayısıyla aklınızdaki sadece ezber olur, malumat ya da information olur ama bilgi ya da knowledge olmaz. Ayrıca farklı iş ve yazılım ihtiyaçları arasında öncelik-sonralık, sebep-sonuç ilişkilerinin belirlenmesi, benzer şekilde yazılım ihtiyaçlarının maliyetlerinin, karmaşıklıklarının ve risklerinin ortaya konması, yine analitik olmanın parçalarındandır. Dikkat ederseniz bu paragrafta saydığımız maddeleri bilebilmek için önceki paragraflarda bahsettiğimiz “analitik-çözümleyici” çalışmaların yapılmış olması şarttır. Örneğin, malumat seviyesinde kalmış, kategorize edilip, alt parçalarına ayrılmamış ihtiyaçların maliyetini nasıl hesaplarsınız ki? Tecrübeliyseniz biraz destekli atış yapabilirsiniz ancak.
Yukarıdaki gibi yazılım ihtiyaçlarına analitik olarak yaklaşmayan analistlerin gerek müşterilerle gerek ise geliştiricilerle toplantılarının verimli olmasını beklemek de nafiledir. Onlarca insan, saatlerce konşurlar ama yine de ortaya doğru düzgün bir şey çikmaz. Bir toplantının başarısı öncelikle o toplantının ne kadar odaklı olduğuyla ilgilidir. Son derece genel, odaklı olmayan konuları ele alma niyetiyle yapılan toplantılar çok sık görülen cinstendir. Odaklı olmadığı için de önüne gelen ya çağırılmıştır ya da duyup gelmiştir. Başarılı analiz toplantıları ekranlar üzerinden yapılmaz örneğin! Başarılı analiz toplantılarının önceden belirlenmiş, hangi konularda nasıl kararlar alınacağı listelenmiş, bunlar dışındakiler gündeme geldiğinde unutmamak için ve bir sonraki toplantıda ele alınmak üzere not alıp devam edilen, az ama özü tartışan ve olabilidiğince 1,5-2 saati geçmeyen, maximum 6-7 kişinin bir araya gelişleri olması gerekir. Bir analiz sürecindeki bir toplantı iki saati geçiyorsa, katılımcı sayısı 10’dan fazla ise, zaman zaman bazı katılımcılar makinalarında Facebook vs. ortamlarda vakit geçiriyorlarsa, bilin ki orada hata analisttedir, çünkü toplantıyı düzgün organize edememiştir. Bunun da sebebi aslında organizasyonsuzluk değildir, aksine analistin kafasında herhangi bir analitik yaklaşım olmaması, dolayısıyla “şu sürecin şu akışı ya da akıştaki şu iş kuralları” şeklinde odaklı bir toplantı organize edememesidir. Bu şekilde çalışmayan analistlerin çoğunlukla ya var olan ekranlar ya da yaptığı ekran tasarımları üzerinden toplantı yaptıklarına çok defa şahit olmuşumdur.
İş bilgisine ve yazılım ihtiyaçlarına bu şekilde yaklaşan analistlerin, ne malumat dolu konuşmalarının yazılımcıları tatmin ettiğini ne de aynı yapıdaki dokümanlarının yazılımcılar tarafından okunduğunu söylemek mumkündür. Bunun sonucunda da yazılımcı, programı yazarken karşılaştığı boşluklar, çelişen noktalar vb. konularda çok sık bir şekilde analiste döner. Analist haliyle zaten cevap veremeyeceği bu tür noktalar içın çok sıklıkla müşteriye döner. Çünkü programcı, gerçekliğe analistten daha yakındır bu yüzden analistin analitik bir süreç işletmemesinin getirdiği sıkıntılarla hemen yüzyüze gelir. Hem müşteri hem de programcı tarafında “patinaj” olarak algılanan bu kifayetsizlik, sonuçta analistin devre dışı bırakılıp, müşterinin doğrudan programcıyla görüşerek ilerlemelerine sebep olur. “Ne vereyim abime/ablama” sendromu olarak isimlendirdiğim bu durum olabilecek en kötü haldir ve sebebi ise kesinlikle “postacılık”tan öteye gidemeyen analist ve onu doğru bir şekilde eğitip yönlendirmeyen yöneticisidir.
Analitik bir süreçten geçmeyen ihtiyaçlar üzerine ne doğru düzgün bir mimari bina edebilirsiniz ne de fonksiyonel bir tasarım ortaya koyabilirsiniz. Yapacagınız tek şey, programlama olabilir. Ama bunun da gideceği yer aşırı refactoring, bol copy-paste ve nihayetinde daha ilk baştan yamalı bohça görünümlü, kalitesiz koddur. Böyle geliştirilmiş yazılımların bakım maliyetleri çok ama çok yüksektir.
Benzer şekilde analitik bir süreçten geçmeyen ihtiyaçlar üzerine sağlıklı bir proje planlaması yapılamaz, efor tahminleri çok afaki olur. Analitik olarak bileşenlerine ayrılmamış müşteri ihtiyaçlarını test etmeniz de çoğu zaman ya çok meşekkatlidir ya da hepten imkansızdır. Olan biten şey, gerçek testin ancak canlı kullanımda, operasyonel kullanıcılar tarafından yapılmasıdır. Ama problem şu ki, hatalar hem müşteride memnuniyetsizlik yaratır hem de bu hataları düzeltmek için çok geç bir zamana gelinmiştir, maliyet çok artmıştır.
Yazılım projelerinde, en analitik olması gereken rol, sanılanın aksine programcılar değil, analistlerdir. Ama gerçekte analistlerin yaptığı ya postacılıktır ya da malumat biriktirme ve aktarmadır. İlki çoğunlukla analistleri ortadan kaldırmaya ikincisi ise son derece maliyetli bir yazılım geliştirme sürecine sebep olur. Analitik bir süreç izlemeyen analistlerin bulunduğu kurumların sadece bugünleri vardır, yarınları yoktur.
Analitik analistlerle çalışmanın keyfi bambaşkadır…
Toplam görüntülenme sayısı: 1537
Aslında programcı psikolojisi malesef yazılım dünyasında üzerine çok da eğilinen bir konu değil. Halbuki, programcılar ve developerlar, sonuçta yazılımın esas çalışan kısmını, executable codeu, üretenler kişilerin nasıl düşündükleri, işlerini yaparken hangi düşünsel süreçlerden geçtikleri, bu kadar zor, odaklanma isteyen ve çok yönlü ve faktörlü, matematiksel bir işi yaparken neleri, nasıl göz önüne aldıkları son derece önemli.
Takip edebildiğim kadarıyla, aslında pek çok psikolojik ve bilişsel (cognitive) akademik ve uygulamalı çalışmalara konu olabilecek zengin bir alan olmasına rağmen ben bu konuda aktif bir çevre pek yok. Gerald Weinberg’in ünlü “Psychology of Computer Programming” dışında özel olarak bu konuya hasredilmiş pek bir çalışma yok gibi. Ama ben bu yazıda bu konuda yapılmış eski de olsa son derece yol gösterici bir çalışmadan bahsetmek istiyorum.
1976 yılının Şubat ayında, “Human Factors: The Journal of the Human Factors and Ergonomics Society” isimli dergide, G. Weinberg ve E. L. Schulman “Goals and Performance in Computer Programming” başlıklı bir makale yayınladılar. Bu makale aslında onların, programcılar üzerine yaptıkları deneysel bir çalışmayı anlatıyordu. Kısaca özetlemek gerekirse deney şöyle: Programcılardan oluşan 5 farklı takıma aynı programlama görevi verilir. Görev, Gaussian eleminasyon yöntemini kullanarak bir lineer denklem takımını çözecek programı yazmaktır. Fakat, görevle birlikte her takıma, yazacakları programın kalitesiyle ilgili birer de hedef verilir. Örneğin bir takıma en az çalışmayla bu görevi bitirme hedefi verilirken diğer takıma en az statement kullanarak programı yazmaları söylenir. Diğer hedefler ise, en az bellek kullanmak, en rahat anlaşılır kodu (clearest code) yazmak ve en rahat anlaşılır çıktı (clearest output) üreten kodu yazmaktır.
Takımlar görevlerini başarıyla bitirirler. Beş takımın dördü, kendisine verilen hedef açısından en iyisini yapmıştır, bir takım ise hedefinde 2. olmuştur. Yani takımlar programlama işini yaparken kendilerine verilen kalite hedeflerini tutturmuşlardır denebilir. İlginç olan taraf burası değil, diğer sonuç: Takımlar, kendilerine verilen hedef dışındaki diğer kalite konularında tutarsız bir şekilde davranmışlardır. Yani hedefleri olan dolayısıyla da odaklandıkları noktalarda çok iyi performans gösterirken, diğer takımların kalite noktalarında ciddi şekilde çuvallamışlardır. Bu durumu aşağıdaki tablo iyi bir şekilde gösteriyor.
Yukarıdaki tablodaki sonuçlardan, her takımın kendi hedefi olan kalite noktasında en iyisini (birisi en iyi ikincisini) yaparken, diğer kalite noktalarında gelişi güzel davrandıklarını anlıyoruz. Peki, bu sonuçları nasıl açıklayabiliriz ya da yorumlayabiliriz? Bu deney üzerine konuşan bir kaç yazar, bu durumu şöyle özetliyordu: “Be careful what you ask for – You may get it”, yani “Ne istediginize dikkat edin, elde edebilirsiniz”. Bunu diyenlerden birisi de bu dünyanın en iyi bilinen kişilerinden Barry Boehm. Ona göre bu bu çalışmanın iki sonucu var:
Yukarıdaki Boehm’in yorumalarını biraz geliştirebiliriz. Evet yazılımcıların ciddi çoğunluğu, program yazmaktan, değişik dil, araç ve teknikleri öğrenmekten zevk alan, öğrenmek için sürekli fırsat kollayan insanlardır. Tabi ki bunun pek çok istisnası var. İstisnaların büyük çoğunluğu ise bence ileri yaşlarda ortaya çıkıyor. Bu kadar yorucu bir işi, bu ülkedeki şartlarda yapmak uzun süre sonunda ciddi zihni ve ruhsal bozukluklar, en azından yorgunluklar oluşturuyor. Motivasyon konusunda kurumların tavırları, oradaki liderlikler de çok önemli rol oynuyor. Olumsuz yönetim ve eksik liderliğin olduğu ortamlarda da motivasyonu yüksek yazılımcıların her şeye rağmen uzunca bir müddet var güçleriyle çalışmaya devam etmenin yollarını bulduklarını çok sık gözlemledim. Fakat haklı olarak bu durum uzun sürmüyor, bir kaç yorucu pozisyon, yazılımcıyı idealistlikten, okuyup, araştırmadan uzaklaştırıyor ve bu durum işten ayrılma ile devam ediyor. Bence kötü yönetim ve eksik liderlikten kaynaklanan problemler sektörümüzdeki işten ayrılmaların en temel sebebidir.
Diğer yorum ile ilgili ise aklıma şunlar geliyor. Yazılım geliştirme, karmaşık ve pek çok kalite faktörü olan bir çalışmadır. Bu kalite faktörlerinin hepsini birden yerine getirmek zor hatta imkansızdır. Bu zorluğun ve imkansızlığın bence iki sebebi var. İlki, Boehm’in de belirttiği gibi, çelişen istekler. Örneğin yukarıdaki örnekten de açıkça görüldüğü gibi, programı geliştirmek için harcanacak efor konusunda bir hedef konduğunda, yazılımın en temel kalite unsuru olan anlaşılırlık doğrudan düşüyor. Bu duruma ülkemizde daima sahit oluyoruz. Yazılımcılar olarak en büyük rahatsızlıklarımız, birbirine çelişen isteklerle karşılaşmak ve bizden bunları isteyenlerin, aslında biraz sağ duyu sahibinin bile anlayabileceği şeyler olmasına rağmen, isteklerdeki çelişkiler konusunda duyarsız davranmaları. Bu durumu ancak BTye stratejik olarak bakabilen kurumlar ve onların içındeki güçlü BT birimleriyle çözebiliriz.
Bir diğer sebep de bence yazılım geliştiren kişilerin, bu faktörlerle nasıl uğraşacakları konusunda bilgisiz ve yetersiz olmaları. Örneğin üniversitelerin Bilgisayar Mühendisiliği bölümlerinde algoritmik karmaşıklıkla ilgili ciddi dersler olmasına, big-o (O) notasyonu, algoritmaların işlem sayıları dolayısıyla hem zaman hem de bellek karmaşıklığı ile ilgili bilgi verilmesine rağmen, bırakın karmaşık bir algoritmanın maliyetini hesaplamayı, normal list ile bağlı (linked) list arasındaki performans farkından haberdar olmayan o kadar çok programcı-developer gördüm ki. (Matematik ve matematik mühendisliği gibi bölümlerde de discrete matematik, combinatorics gibi derslerin olduğunu biliyorum.) İster yeni mezun olsun ister tecrübeli olsun kimsenin bunlardan haberi yok, herkes nasıl alışmışsa her yerde onu kullanarak yazıyor kodunu. Yeni mezunların ezici çoğunluğu bu konudan bahsedildiğinde ilk defa duyuyormuş gibi davranıyor. Yazılım geliştiren kişilerin liderleri, önderleri durumunda olan senior programcı ve developerların, mimarların da bu konular hakkında çok fazla sistemli bilgi sahibi olduklarını, yanındaki daha genç olan kişileri yönlendirip, eğitebildiklerinden de emin değilim. 10-15 sene yazılım geliştirme projelerinde developer olarak çalışmış ve yaşı 35’e gelmiş kişilerin örneğin JVM’in belek yönetimi ve kullanılmayan nesnelerin belleklerini geri toplaması (garbage collection) ile hiç ilgilenmemiş olmaları açıkçası bana çok garip geliyor.
Bu ülkede malesef aşırı teknoloji odaklı olduğumuz için, yeni diller ve araçlar öğrenmemize rağmen, yeni teknikler ve yaklaşımlara bu kadar ilgi duymuyoruz. Dolayısıyla, kurumsal uygulamalarda o kadar çok performans ve ölçeklenirlik problemi yaşayan sistemlerle karşılaşıyorum ki, inanılmaz. Zannedersiniz kodları yazanlar orta okul mezunları. Lise sonda üç katlı integral çözmekle övünenlerin yazdıkları kodlarda isimlendirmede bile problem var. (Tabi aslolan üç katlı integral çözmek değil, aslolan hayattan bir problemi üç katlı integral olarak tanımlayabilmek. Kendim de dahil olmak üzere çözenini çok gördüm ama tanımlayabileni pek görmedim.)
Bugünün senior programcı ve developerları ya da mimarları, yazılımın kalite kriterleriyle ilgili doğru dürüst bilgi sahibi olmayıp, yazılımda olması gereken süreçlerden de bihaber kaldıklarından, kendileri kod yazarken çektikleri sıkıntılar üzerine ciddi olarak düşünüp, araştırarak, aslında yanlış yol tutturduklarını, sebep ve çözümleriyle birlikte ortaya koyacak hale gelemiyorlar. Bu yüzden bu kişiler yönetici olduklarında, “biz böyle gördük, tırmaladık, fedakarlıkla yaptık” diye düşünüyorlar ve yönetimlerinde de bu düşünceler çok etkili oluyor.
Özet olarak söylemek gerekirse, yazılım projesinin pek çok hedefi aynı anda yerine getirmesi gerekir. Kod kalitesi de belki de maliyetle birlikte bu hedeflerden en önemli ikisidir. Ama ülkemizde malesef çoğu zaman maliyet üzerine oynarken kod kalitesini göz ardı etme eğilimindeyiz. Bunun da en temel iki sebebi, yöneticilerin çelişen istekleri ve mühendislerin bilgisizliğidir diye düşünüyorum.
Evet, ne istediğinize dikkat edin, bakarsınız oluverir 🙂
Toplam görüntülenme sayısı: 1759