Search Results for: maaş

Yanlış Sorular, Yanlış Olmayan Cevaplar – I

Kültür, Bilgi ve Düşünce

Yok, çok sabrettim bu yazıyı yayınlamamak için ama olmadı. Şu mesajı alınca patladım artık:

“Selam …  bilgisayar mühendisliğindeyim, 1. sınıftayım, vaktiniz olursa bana yardımcı olursanız sevinirim. Kafam karışık, hangi tarafla ilgilenmem, nelere yoğunlaşmam konusunda sıkıntı yaşıyorum, mobil teknolojileri konusuna ilgi duyuyorum ama iyi para kazanabilir miyim, maaşı ne kadardır bilmiyorum. Mobilemi odaklansam yoksa web de çok iş var diyorlar, ne yapsam. Ne dersiniz? ”

Hani denir ya “bir kişinin niyeti ya da seviyesi sorduğu sorudan anlaşılır” diye, hepimiz karşılaşmışızdır bu sözü akla getiren durumlarla. Bana da çok sık geliyor bu cinsten sorular. İnsanların, beni fikrine itibar edilen birisi olarak görmeleri benim için çok güzel, onur verici bir şey. Ama açıkçası sorulanlar sıklıkla üzerine düşünülmemiş ve sorgulanmamış, basma kalıp sorular oldukları için çok da hoşlaşmadığım durum oluşuyor. Şunu da ekliyeyim ki, bu tür soruları çocuklarım bana sorduğunda nasıl cevap veriyorsam üşenmeden herkese öyle cevap vermeye çalışıyorum.

Bu soruları temelde iki gruba ayırmak mümkün. Birinci gruptakiler, sistemsiz ve düzensiz bilgilenmenin getirdiği cinsten sorular. Bilgilenme sistemsiz olunca, durum bilgilenmeden çıkıyor ve bir hazımsızlık haline geliyor. Bunu, soruyu soran kişinin sorarken dile getirdiği ve onun temellendirici olduğunu düşündüğü “malumat”tan, sorunun içindeki çelişkili mantıktan vs. anlıyorsunuz. Diğer türden olan sorular ise belki aslında yanlış değil ama benim çok da benimsemediğim açıdan ya da yanlış bulduğum bir duruş noktasından sorulduğu için, doğru düzgün cevap vermek istemiyorum, biraz da geyik vesilesi biliyorum. İşte o “yanlış” sorular ile onlara karşı ürettiğim “yanlış olmayan” cevaplardan oluşan liste:

Programcı olmak için üniversite okumaya gerek var mı?

Gerek yok, okuma‐yazma bilmek kafidir! Nihayetinde programcılık bir zanaattir ve insanların okumaya niyeti olmayan çocuklarını tamirciye, berbere ya da boyacıya verdikleri gibi, yakında da programcı olması için, örneğin etraflarındaki, tanıdıkları vasıtasıyla ulaştıkları, irili-ufaklı, yazılım geliştiren pardon programlama yapan esnafları bulur, çocuklarını emanet ederler. Muhtemelen bu gidişle şehirlerde program yazanlar için sanayi bölgeleri de oluşturulacak. Zaten bu ülkenin bu konudaki en bilinen sivil örgütlerinden birisinin ismi Yazılım Sanayicileri Derneği değil mi canım! Eğer size böyle yardımcı olacak bir aileniz yok ise siz de sosyal medya aracılığıyla bulur bir programlama ustası, yanında pişerek öğrenirsiniz. Üniversite okuyanların kaybettiği vakti siz iş başında öğrenerek kazanırsınız. Nasıl olsa Steve Jobs da Bill Gates de Larry Ellison da üniversite mezunu değiller! Ama üç gün sonra basit de olsa bir matematiksel düşünce kırıntısı olması gereken küçük bir algoritmada çuvallarsan ağlamak yok!

Anlamıyorum ki bu ülkeyi ben. Ama anlaşılmayacak bir şey yok, master-doktora yapanların olduğu bir sınıfta, dönemin daha ilk dersinde, hocaya sorulan ilk soru, “hocam klasik mi yapacaksınız test mi?” olduğu bir ülkede, okumuşlar ne durumda ki okumamışlar ne durumda olsunlar diye düşünmeden edemiyorum tabi.

Java ölüyor mu?

Ölmüyor tabi ki. Java daha 20’sine yeni girdi. Cobol 50’sini, C 40’ını devirmişken!

Amma çok meraklıyız ölümlere Allahı’m! Daha üniversiteye başlayalı 2 ay olmuş, soruyor “Java ölüyor mu?” Fesubhanallah! Nedir bizim bu “ikinci eli kaça gider” takıntımız yahu? Aynı şey. Al arabanı, keyfini çıkar! Soracaksan da ne bileyim tüketimi cüzdanına uygun mu, kırmızı ışıkta pati çektirme merakın varsa torku nasıldır, vs. sor, öğren. Daha içine oturmadan ikinci elinin kaça gideceğinden sana ne? Var mı garantin o kadar yaşayacağına? Allah korusun belki o arabayla birlikte sen de gideceksin öbür dünyaya, ikinci el olacaksın …

Daha üniversite ödevi dışında doğru düzgün kod yazmamışsın, bu dünyadaki teknolojilerin nasıl üretildiğinden, nasıl gelişip kök saldığından bir gram haberin yok, Java’nın ölmesinden bahsediyorsun.

Java’nın ölmesini soranların zaman zaman tekrarladıkları sebeplerden bazıları şunlar: “.NET artık açık kaynak kodlu oluyor.” ve “Android yazarken artık Java dışında başka diller de kullanılabilir.” Anlamadım ki, bunları söyleyenler, Java’nın nereye hitap ettiğinden, .NET’in nereye hitap ettiğinden, ya da Java’nın zaten çıktığından bu yana açık kaynak kod yaklaşımını desteklediğinden ya da Microsoft’un .NET’in neresini nasıl açık kaynak kodlu hale getirdiğinden, getirmeyi planladığından ve en temelde de açık kaynak kodlu olmanın ne anlama geldiğinden haberleri var mıdır acaba? Ya da Java bu popülerliğini Android ile mi kazandı da Android için Java dışında diller kullanıldığında Java ölsün!

Gıcık oluyorum çok, daha bırakın bilgiyi, malumat sahibi bile olmadan, kendini fikir sahibi sanıp, kelli felli sorular soranlara arkadaşlar. İnsan biraz düşünür ya, aklına gelen ilk cümleyi soru olarak sorar mı?

Öğrenciyim, neye odaklanayım?

Allah Allaaahhh, ben mi başka gezegenden geldim, bu ülke mi zıvanadan çıktı? Anlamadım ki? Cevabı sorunun içinde zaten arkadaşım: Öğrenciysen odaklanacağın şey belli: derslerin. Derslerine odaklanacaksın. Ne Androide, ne Java’ya, ne de başka bir teknolojiye odaklanmayacaksın, sadece ve sadece derslerine odaklanacaksın, bu kadar basit. İşletim Sistemleri, Algoritmalar, Networking, Veri Yapıları, AI, neyse okulunda öğretilen ona odaklanacaksın. Programlama Dilleri dersinden 78 mi aldın, “22 puanı nereden kaçırdım”a odaklanacaksın. Sanki adam Stanford’da doktora yapıyor da “hımm, neye odaklansam acaba?” diye soruyor.

Genç üniversiteye girmiş, önünde bir sürü öğrenmesi gereken ders var, onları bırakıyor, dershanecilik yapan yerlerden gidip kurs alıyor örneğin. Neymiş .NET öğreniyormuş, okulda ise .NET öğretilmiyormuş. Eğitimi veren de aynı bu öğrenci gibi, zamanında derslerini düzgün bir şekilde öğrenip, esaslı bir şekilde kendini yetiştirip ilerleyeceğine, işte “nereye odaklansam” diye diye sonunda dershanede eğitimciliğe odaklanan birisi. Eğitmenin kendine hayrı yok ki sana olsun!

Bizim bu gençlerin odaklanma sorusunun ardında yatan düşünce şu: Matematik, algoritma, vs. ıvır zıvır zaten, kimse bunlarla iş yapmıyor, piyasada çalışmak için bunları bilmeye gerek yok (ki tamamen doğru ve bu arada piyasamızı bu şekilde kurgulayan ve devam ettiren öncülerimizi ve yöneticilerimizi burada saygıyla anıyorum.).

Odaklanmak için bilmek lazım bir kere. Bilmeyen adam neye odaklanır ki? Kendi disiplinini anlamamış, kim ne demiş, tarihi olarak nereden gelip nereye gidiyor, temel akımlar nelerdir, kim neyi nasıl yapmışı anlamadan, temel tanımlar, aralarındaki ilişkileri nedir bilmeden, hakim olmadan, neye nasıl odaklanırsın ki? Geçtim her şeyi, IDEsiz “hello world” yazamayan neye odaklanabilir ki? Hiç bir şeye odaklanmasın bence. Bu şekilde odaklanmaya çalışanlar sadece serseri mayın gibi dolanır ortalıkta, hiç bir şeye de yar olmaz. Her şeyin bir yolu, yöntemi vardır çünkü. Her şeyin bir tabiatı vardır. İnsanların seneler boyu tecrübeyle keşfettikleri şeyleri yok sayıp, onlardan yararlanmadan yenisini keşfedemezler. Bizim gençlerimiz bu dünyada oksijenle beslenmeden hidrojenle beslenmenin yolunu arayan uzaylılar gibi. Bir de duyuyorlar gazete küpürlerinde, mor inekmiş, Steve Jobsmış vs., sanıyorlar ki gökten zembille iniyor bu şirketler, başarılar vs.

“Web programlamaya odaklanıcam”, “Androide odaklanıcam”, cümleler hep böyle. Odaklan bakalım web programlamaya. Sanırsın 20 senedir web geliştiriyor, çok ciddi bilgi ve tecrübe sahibi ve belli noktalardaki sıkıntıları çok iyi biliyor ve oralara odaklanıp çözüm getirecek tüm dünyaya. Odaklanmaktan anladığı da etrafta var olan zilyon tane teknolojiyi, yok JavaScritpmiş, Node.js miş,  gelişi güzel, Google örnekleriyle çalıştırmak vs.

Hiç bir öğrencinin 4.0’lık olmasını beklemiyorum, çocuklarımın da öyle olmalarını istemedim hiç bir zaman, hele bu ülkede asla! Merak ve tutku nedir çok iyi bilirim. Ama malumatfuruşluğun ya da Google abur cuburunun da insanın beynini ne hale getirdiğini çok iyi bilirim.

Ohhh, içimi döktüm, biraz rahatladım. Derdim kimsenin kalbini kırmak değil. Amacım, zamanında tüm bu soruları sormuş ama elinden tutup kendine yol göstermeye çalışan birisini bulamayıp, cevaplarını yaşayarak öğrenmiş birisi olarak yol göstermek.

 

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

Nitelikli Eleman Açığı mı Niteliksiz Yönetici Fazlası mı?

BT, Yazılım Mühendisliği ,

Sosyal mekanlarda gezinirken “Yazılım Sektörünün En Önemli Sorunu Nitelikli Eleman Açığı” başlıklı bir yazı gördüm. Aslında sık sık gördüğümüz, ezberlenmiş türden başlıklardan birisi. Nedense bu sefer farklı geldi bana ve bu yazıyı yazmaktan kendimi alıkoyamadım. Bu tür açıklamalarda sık sık BT sektöründeki sivil toplum kuruluşları öne çıkıyor. Bu haberde de Yazılım Sanayicileri Derneği‘nin (Yasad) adı geçiyordu. Bu haberi Yasad’ın sayfasında da görmek mümkün.

Bu ülkedeki yazılım sektöründeki patronların ve yöneticilerin bir araya gelip dernekler oluşturmaları ve sektörü geliştirme amaçlı faaliyetlerde bulunmaları, devleti bu konuda yönlendirmeleri güzel bir şey. Her devlet gibi bizim devletimizin de bu tür danışmanlıklara ihtiyacı var. Ama ya bu yönlendirmeyi yapanların kendilerinin yönlendirme ihtiyaçları varsa? Ya bu tür kuruluşlar, “sektörün yetişmiş nitelikli elemana ihtiyacı var” derken gerçek ihtiyacın nerede olduğunu ciddi bir şekilde atlayıp, yazılımda daha iyi durumda olan yabancıların sektör gazete ve dergilerinde gördükleri haberlerde ifade edilen problemlerinin aynısının bizde de olduğu vehmine kapılıyorlarsa? İşin açıkçası bunları yazarken “yazlılım sanayicisi”nin ne anlama geldiğine ve “eleman” kelimesine takılmamaya çalışıyorum, çünkü bu yazıyı kara mizah yapmak istemiyorum.

Yazılımın içinden birisi olarak ülkemizin en ciddi sorununun nitelikli eleman eksiği olduğuna katılmıyorum. Bu tür haberlerde, konuşmalarda geçen “eleman” kelimesiyle kastedilenin (“eleman” nitelendirmesiyle her ne kadar kelle sayısı hesabı yapan dolayısıyla da itici bir anlayışı yansıtsa da), üniversitelerden sektörümüze sunulan mezunlar olduğu açıktır. Denilen, üniversitelerden yeterince mezun gelmediği ve gelenlerin de ihtiyacı karşılamadığı iddiasıdır. Evet bu bir problem, üniversitelerden hem sayı hem de kalite olarak yeterli mezun çıkmıyor. Ama kendimizi kandırmayalım, problemin büyüğü bu değil, yani bence durum bundan daha vahim. Bakın “eleman açığı”ndan şikayet şu anlama geliyor: “Ülkemizdeki yazılım sektörünün başka problemleri olsa da en büyüğü eleman açığıdır. Yani sektör var olan elemanları düzgün bir şekilde değerlendiriyor, imkanlar elverdiğince iyi işler çıkarıyor ve daha çok yeni elemana ihtiyaç duyuyor. Dolayısıyla en büyük engelimiz eleman açığı, eleman sayımız yetse, siz görün bizi.” Tırnak içinde yazdığım bu düşünceyi ifade eden yine Yasad’ın sayfasındaki şu habere bakılabilir. Haberde sektörün eleman açığının giderilmesiyle uçuşa geçeceğimiz ifade ediliyor.

Bence yine kendimize kendimizin propagandasını yapıyoruz. Çok açık bir şey var, ülkemizdeki yazılım sektörü dişe dokunur bir şey geliştirmekten malesef uzak. Geliştirdiklerimiz kalite olarak son derece düşük, o yüzden dünya yazılım piyasasına sunulabilecek cinsten değil. Çünkü hala kahramanca savaşan yazılımcılara bağlı olarak iş yapıyoruz, süreç tabanlı yazılım geliştirmeden çok uzağız. Daha program ile yazılım arasındaki farkı kavrayabilmiş değiliz. Nasıl futbol oynuyorsak öyle yazılım geliştiriyoruz; ikisinin de en temel dinamiği kaos.

Yazılım sektörünün esas sorununun “eleman açığı” olduğunu söyleyerek, kayıp yüzüğünü, kaybettiği samanlıkta aramayıp, kapının önünde arayan ve neden böyle yaptığı sorulduğunda da “samanlık karanlık ama” diyen Nasrettin hocamızın tiye aldıklarından oluyoruz. Bence bu ülkenin yazılım sektöründeki en temel problem nitelikli eleman açığı değil, niteliksiz yönetici fazlasıdır! Var olan iş gücü potansiyelimizi bile değerlendirmekten uzağız, kaotik bir şekilde iş yapıyoruz, başarımız çoğunlukla şansa bağlı, enerjimizi ve zekamızı yanlış yerlere harcıyoruz. Ve bence bu durumun en başlıca sebebi, yazılım “elemanları” değil, yazılım yöneticileridir, karar vericileridir.

Kifayetsiz yazılım yöneticilerine sahip olmamızın bence iki sebebi vardır. İlki yazılım yöneticilerimizin bizatihi kendileri ile bir şekilde yazılım geliştirme süreçlerini yöneten ya da yön verenler (örneğin daha üst düzey “C” seviyesindeki yöneticiler), daha yazılımın ne olduğundan, tabiatından, süreçlerinden, rollerinden ve yetkinliklerinden vs. habersizler. Bu konuda en temel ayrımları bile bilmediklerine ben defalarca şahit olmuşumdur. Çünkü bu yöneticiler muhtemelen kariyerlerinin başında teknik pozisyonlarda bulunmuşlardır ama daha işlerinde ustalaşmadan yönetici oluvermişlerdir ya da daha doğru ifadeyle yapılıverilmişlerdir. Dolayısıyla henüz öğrenmedikleri bir işi yönetmeye çalışıyorlardır. Yani, tabii olarak gördüklerini uyguluyorlar. Örneğin, projelerdeki en temel problem çözme yöntemleri, fazla mesaidir. Çünkü onlar da fazla mesai ile projeleri kurtarmaya çalıştılar.

Mesleğinde yeterince olgunlaşmadan yönetici olmanın bir başka handikapı da, kendilerini yönetici yapanlara karşı çıkamama şeklinde kendini göstermektedir. Zaten kafasında henüz bir sistem oluşturacak, süreci baştan sona kavrayacak şekilde olgunlaşmamış durumda olduklarından, teknik kaliteyi öne çıkarmaları, iş yapış şekilleriyle ilgili bir yenilik yapmaları ve nihayetinde var olan düzeni değiştirmeleri, üstlerinin kararlarına karşı çıkabilmeleri mümkün değildir. Bundan dolayı bizim sektörümüzde orta düzey yönetici olmak, tokmağı başkasının elinde olan davulu sırtında taşımaktır.

Bu ülkenin, daha mesleğini öğrenmeden o mesleği yönetmeye çalışan yöneticileri var. Bu ülkenin daha 30’una gelmediği halde, hızını almış giderken, teknik olarak ilerlerken, yaptığından zevk alırken, programcılıktan tam işin mimari ve mühendislik kısımlarına atlamaya hazırlanan ya da ekran analistliğinden çıkıp sistem analistliğine doğru ilerleyen civa gibi gençlerini bulunduğu ortamdan aniden koparıp, “sen yöneticisin artık” diyen ve muhteşem mühendis adaylarını berbat yöneticilere dönüştüren bir kültürü var. O kadar çok arkadaşım var ki bu durumda olan. Hepsi çok iyi eğitim almışlar, mesleklerinin ilk 5-6-7, bilemediniz 10 yılında bu eğitimin üzerinde deli gibi bilgi ve tecrübe inşa etmişler. Bu arkadaşlarım ya da tanıdıklarım, tam mesleklerinde çıraklığı atıp, olgunluk çağlarına gelmişler, bundan dolayı da belki daha stratejik konulara ele atacaklar, iş yapış şekillerini düzeltecekler, kaliteyi arttırmaya odaklanacaklar ya da meşreplerine ve ilgilerine göre değişik konularda uzmanlaşacaklar, belki kimileri kitap yazacak, belki çok odaklı, niche, bir konuda bir gelişme sağlayacaklar ve hem ülke hem de insanlık adına bir katkıda bulunacaklar. Ama sektörün böyle insanlar yetiştirmek gibi bir derdi yok ki!  Hemen tüm bu şekilde gelişmeye çalışan arkadaşlarımın önü, daha yüksek maaşla yönetici yapılarak kesilmekte. Daha geçen gün bu şekildeki bir arkadaşım “ben bu ülke için bir kayıpım” dedi bana. Çünkü iyi bir mühendisken, sırf maddi ve sosyal şartlardan dolayı yönetici oluvermişti.

Kifayetsiz yöneticilere sahip olmamızın ikinci sebebi ise, bu yöneticilerin bu makama gelirken hatta geldikten sonra herhangi bir yöneticilik formasyonundan geçmemiş olmalarıdır. Genelde işini iyi yapan, iyi eğitim almış, zeki ve başarılı yazılımcılar, programcı olsun, analist olsun, 3-5 sene içinde bir şekilde yöneticiliğe tabii olarak geçerler. İyi mühendis, iyi programcı, iyi sistemci, iyi bir yönetici olmak için gerek sebep olabilir ama yeter sebep değildir. Yüksek empati yeteneğine sahip olmadan iyi bir sistemci olabilirsiniz, iyi bir organizatör olmadan iyi bir programcı olabilirsiniz, iyi bir arabulucu olmadan iyi bir tasarımcı olabilirsiniz ama bunlar olmadan iyi bir yönetici olamazsınız. Bu durumun benim sıklıkla gözlemlediğim, en açık göstergesi ise yazılım yöneticilerimizin ezici bir kısmının, senelerdir yöneticilik yapığı halde hala doğru detay seviyesinde bulunmayı beceremeleridir. Ya hala çok teknik davranırlar ve bu yüzden altında çalışan teknik insanlara güvenip iş teslim edemezler, bu yüzden de detayda boğulurlar, ya da işin sadece tarihleri ve maliyetiyle ilgilenirler ve üst yönetimin kararlarını altlarına uygulatmak dışında bir insiyatifleri yoktur. Her iki halde de başarılı olamazlar.

Yöneticilik, öğrenilebilir. Ama bir eğitim ve öğrenim sürecinden geçmeden bir şekilde yönetici olanlar ki buna ben de dahilim ve ne olduğunu çok iyi biliyorum, ancak hasbel kader yöneticilik yapabilirler. Yani sektörümüzdeki yöneticiler genel olarak, ne yazılımı ne de yönetimi bilmeyen insanlardır. Yöneticilik algısı ve yeteneği olanlar, uzun vadede başarılı yönetici olabilirler, örneğin hangi detayda kalacaklarını öğrenirler, teknik insanlarla nasıl konusacaklarını belirlemiş olurlar belki ama bu sırada kaç çalışan ve proje telef olur, bilinmez.

Bu ülkenin yazılım sektörünün tek sıkıntısı hakikatten üniversiteden sektöre akan mezunların sayısı olsaydı, örneğin onlara karşı da bu sektör “deneyimin yok ama” sendromunu yaşatmazdı ve bu ülkede çok daha farklı şeyler olurdu.

Ben de yöneticilik yaptım, sıkıntılarını iyi biliyorum. Bu ülkede orta düzey yazılım yöneticisi olmak çoğu zaman yukarıda da söylediğim gibi, tokmağı başkalarının elinde olan davulu taşımaktır. Sektörümüzde yönetici olmak çoğu zaman tetikçiliktir, üstte verilen kararların aşağıya uygulatılmasından sorumlu olmaktır, örneğin bitiş tarihini üstlerinin belirlediği projeyi, alttakilerin ensesinde boza pişirme pahasına bitirmektir. Dolayısıyla bence sektörümüzün sıkıntıları ne teknolojiktir, ne kişi sayısıyla ilgilidir ne de doğrudan maddidir; yoğun olarak kültüreldir. Teknik kaliteye önem vermeyen ve her şeyi insan manipulasyonu ile yapmaya çalışan zihniyetimizi değiştirmedikçe her ilçeye bir üniversite kursak bile, yazılım gibi yüksek soyutlama gerektiren disiplinlerde durum değişmeyecektir.

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

Yazılım ve Değişim – I

Yazılım Mühendisliği

Yazılım zor zenaat, bu çok açık. Çünkü yazılım, diğer mühendislik dalları gibi fiziksel değil, soyut bir uğraş alanı. Yazılımın soyut olan doğası, onun durumunu tüm detaylarıyla anlamayı imkansız hale getiriyor. Çünkü kontrol altında tutabildiğimiz etmenler, kontrol altında tutamadıklarımız yanında sayıca çok daha az. Bu yüzden örneğin bir yazılımı her türlü detayıyla test etmek pratikte imkansızdır. Bu yazıda, yazılımın karmaşık yapısı kadar önemli olan değişkenliğini ele almaya çalışacağım.

Hemen herkes yazılımda değişmesi mümkün olmayan bir şey olmadığında hemfikirdir. Yani yazılımda her şey değişebilir, tek fark değişimin maliyeti olabilir. Diğer mühendislik ürünlerindeki degişimi düşündüğümüzde, yazılımdaki değişmeyle çok ciddi mahiyet farklılıkları olduğunu gözlemleyebiliriz. Örneğin, araçlardaki, binalardaki ya da köprülerdeki değişimle ilgili konuştuğumuzda, yani inşaat ve makina mühendisliğinin ürünlerini ele aldığımızda, değişmenin asıl sebebinin ilgili malzemenin aşınmış, bozulmuş vb. durumda olması olduğunu söyleyebiliriz. Bu durumda yedek malzemelerin, orijinal olanlarla, montaj noktaları gibi ilgili açılardan aynı standartta üretilmiş olması, değişim için yeterli olur. Yani mühendislik ürünlerinde değişim, var olana yeni bir şey katmaktan ziyade, yerine geçirmek (replacing), var olanı, standartları açısında uyumlu olan daha yenisiyle değiştirmek anlamına geliyor. Yazılımda ise aşınma, bozulma söz konusu değil. Dolayısıyla değişimi gerektiren durumlar, temelde yeni ortaya çıkan ihtiyaçlardır. Bu yüzden yazılımın değişmesi, daha önce sahip olmadığı özelliklere sahip olması anlamına gelmektedir. Yeni fonksiyonel ihtiyaçlar, örneğin yeni süreçler ya da var olan süreçlerdeki değişiklikler, yeni iş kuralları ya da benzer şekilde var olan iş kurallarında değişiklikler, iş kurallarının çoğunlukla daha esnek hale gelmesi, yeni tür kullanıcılar, yeni entegrasyonlar, yeni teknoloji vs. hep yazılımı değişmeye zorlayan etkenlerdir.

Değişim, yazılım mühendisliğini çok derinden etkileyen bir faktördür. Örneğin, geliştirilmesine 100 TL harcanan bir yazılımın, ömrünün sonuna kadar değiştirilmesine ne kadar para harcandığını sorsam tahmininiz ne olurdu? Buna cevap aramak için Google’a gidip “software maintenance cost” aramasını yapın ve çıkan resimlere bakın. Farklı onlarca grafik göreceksiniz ama hepsi bir şeyi analtıyor: Yazılımın esas maliyeti geliştirilmesinde değil, değiştirilmesinde. O grafiklerdeki oranlara bakarak 100 TL’ye geliştirilen bir yazılımın ömrünün sonuna kadar 400-500 hatta 700-800 TL gibi masraflara bakımının yapıldığı sonucunu çıkarabilirsiniz. Ben bu oranın ülkemizde 10 gibi olduğunu düşünüyorum, yani 100 TL’ye geliştirdiğimiz yazılımın bakım maliyetinin onun 10 katına yani 1000 TL’ye kadar çıktığını düşünüyorum. Bunun pek çok anlamı var:

  • Yazılımlar için bütçeleme yaparken sadece geliştirme maliyetini göz önüne almanın doğru olmaması. Esas maliyet, buz dağının görünmeyen kısmı, bakımda aslında.
  • Bütçemiz kısıtlı olduğundan şunu/bunu yapamayacağız. Örneğin “dokümentasyon yapamayacağız”, “teste vakit yok”, “eğitim bütçemiz çok kısıtlı”, “ek kaynağa para ayıramıyoruz” gibi cümleler anlamsız. Gerekli olan  şeylere para ayıramayarak 100 TL’ye geliştirdiğimiz yazılımı ayakta tutmak, düzeltmek ve daha da geliştirmek için 5-6 senelik ömründe 1000 TL harcamak zorunda kalıyoruz ama.
  • Yanlış ata oynuyoruz, kafamızı “yazılımı nasıl geliştirelim ki ihtiyaçlarımızı karşılasın”a odaklamak yerine “yazılımı nasıl geliştirelim ki gelecekteki ihtiyaçlarımızı karşılaması kolay olsun”a odaklamalıyız. Yazılım Mühendisliğinde önemli olan yapmak değil, değiştirmektir çünkü.
  • Başarısız yazılımların değişeceğini sanıyoruz ama geçek şu ki başarısız yazılımlar çoğu zaman değişemediklerinden başarısızdırlar, değişen yazılımlar başarılı olanlardır.
  • En acısı da belki yeni mezunların, çalışacakları işlerde hep yeni projeler geliştireceklerini düşünürken, 12 aylık maaşlarının yaklaşık olarak sadece ve sadece 1,2 tanesini yeni projede kod yazmak için alıp, geri kalanını başkalarının yazdıgı berbat kodu önce anlamak sonra düzeltmek, yeni özellikler eklemek, başka bir teknolojiye çevirmek gibi bakım ya da değişim dediğimiz çalışmalar için hakediyor olmaları. Düşünsenize makina mühendisi olarak eğitim aldınız ve iş hayatına atıldınız, tek yaptığınız iş ise bir araba tamircisinde gelen arabaların bujilerini temizlemek, gerekirse değiştirmek. Ya da çiçeği burnunda bir inşaat mühendisi olarak elinizde mala, çatlayan duvarları sıva yapıyorsunzu devamlı, nasıl olurdu? Malesef bizim sektörde hayat böyle, sonra bu yazılımcılar niye böyleler? 🙂 (Gerçi bu duruma pek çok kötü örnek verilebilir, konservatuarda Dede Efendi ya da Beethoven’i öğrenip mezun olunca düğünlerde Ankara’nın Bağları çalmak zorunda kalmak da benzer bir şey. 🙂 )

Diğer mühendislik ürünleri olabildiğince az değişecek ve değişmesi gerektiğinde de kolay değişecek şekilde tasarlanıp üretilmektedirler. Bir araba üretilirken nelerin hızlıca değişmesi gerektiği çok açık bir şekilde belirlenmiş olduğundan, örneğin silecekler, tekerlekler, su ve yağ cinsinden şeyler, bunları bizler bile değiştirebiliyoruz. Çünkü buradaki değişim yukarıda da belirttiğimiz gibi parçayı değiştirmedir, yeni bir yapı ekleme değildir. Ya da bir köprü inşa edilirken örneğin üzerindeki asfalt vb. kaplamanın ya da varsa halatlarının nasıl değişeceği tamamen öngörülmüş durumda, bu yüzden de kolay değişecek şekilde tasarlanmıştır. Bu noktada fiziksel ortamlarda ve malzemelerle çalışan mühendislerin, sık değişecek kısımların kolay değişebilmesi gibi bir prensip üzerinde uzlaştıkları görülüyor. Bu yüzden örneğin bir arabanın sileceklerini değiştirmekle trigger kayışını ya da transmissionunu değiştirmek aynı kolaylıkta değil.

Yazılımın aşırı değişken olan doğasına rağmen “değişebilen yazılım” yerine yazılımın sadece geliştirilmesine odaklanmak, herhalde 100.000 TL’ye bir binek aracı satın alıp sonra sileceklerini değiştirmek için 5.000 TL ya da ne bileyim lastiklerini değiştirmek için 20.000 TL vermekle eşdeğer bence. Düşünün böyle, değişim göz önüne almadan, sadece ve sadece üretilmesine odaklanarak tasarlanmış bir aracın motorunun içindeki trigger kayışı gibi parçalarını değiştirmek muhtemelen 100.000 TL’ye mal olur. Böyle bir aracı kim almak ister ki? Dün aracıma 4 tane lastik aldım ve sadece lastikler için para ödedim, değiştirilmeleri ve balans için ücret ödemedim, çünkü eski lastiklerin janttan çıkarılıp yenilerinin takılması, balanslarının ayarlanması ve arabaya monte edilmeleri o kadar kolay ve hızlı ki yarım saatte işim bitmişti.

Aslında pek çok mühendislik ürününde ayırt edici unsur kalitedir. Neden durumumuz olduğunda 150.000 TL harcayarak bir araç satın alıyoruz da “aman canım aynı şeyi yapıyor” deyip 5.000 TLlik bir araçla yetinmiyoruz? Mühendis olarak ben örneğin, biraz vakit ayırsam, uğraşsam, herhalde bir araç yapabilirim ve 10.000 TLye sattığımı ilan edebilirim. Sonuçta gidiyor mu gidiyor, duruyor mu duruyor, nedir problem? Problem, “saatte 100 km hızla giderken, yerlere yeni yağmur düştüğünde 10 metre önünüzdeki araç sert bir fren yaptığında benim aracımda mı yoksa 150.000 TL verip aldığınız örneğin bir BMW 3.20’de mi olmak isterdiniz?” sorusu aklımıza geldiğinde ortaya çıkıyor. Ben yerler ıslak olmasa da, öndeki araç hiç fren yapmasa da BMW içinde olmayı tercih ederdim. Peki aynı durumda biz neden yazılımın değişim maliyetini göze almadan, sadece fonksiyonelliğine ve maliyetine bakarak tercihde bulunuyoruz ki? Bence en temel sebebi, yazılımın aşırı değişken olan mahiyetini henüz anlamamış olmamız. Buna günü kurtarmaya odaklı milli, aşırı faydacı karakterimiz de bu duruma katkıda bulunuyor ama yazılım konusundaki cehaletimiz daha önde bence.

Eğer bir araba reklamı yapsaydım, “evladiyelik” diye ilan ederdim arabayı. Ama bir yazılım sisteminin reklamını “evladiyelik” diye yapmayı düşünmezdim, onun yerine “kolay değişebilir” diye reklam yapmak daha akıllıca olurdu. Yapmak ile değiştirmek arasındaki denge, fiziksel mühendislik ürünlerinin tam tersine işliyor bizim mesleğimizde. Bu yüzden yazılımı yönetenler, 10 günde geliştirilmiş basit bir yazılıma bazı eklemelerin 2 haftada yapılabileceği gibi bir söz duyunca developera yükleniyorlar, çünkü kendilerini kandırılıyor hissediyorlar sanırım. Çünkü akıllarında 1 senede yapılan dairelerinin 3 günde boyanması ya da ne bileyim 1 haftada banyonun ya da mutfağın tamamen değiştirilmesi gibi tecrübeler duruyor. Yazılımı iyi yönetebilmemiz için, değişikliklerin kolay yapılabılabileceği yazılımlar geliştirmeye önem vermeliyiz. Ancak böyle bir anlayışla, yazılımın 10 gün yerine örneğin 50 günde geliştirilmesini planlar ve gerekli değişiklikler için developerdan “2 günde olur” diye tahminler bekleyebiliriz.

Bence bir programı, benim bir mühendis olarak bir binek aracı üretmem gibi matematiksel düşünme kabiliyetleri gelişmiş pek çok kişi, programcı ya da herhangi bir mühendis yazabilir. Bu kişinin üniversite mezunu bile olmasına gerek yoktur, akıllı ve meraklı bir lise mezunu yapabilir bu işi. Ancak yazılım, özellikle de rahat değişebilen bir yazılım, sadece ve sadece Yazılım Mühendisleri tarafından geliştirilebilir. Çünkü yazılım, programcılara ve proje yöneticilerine bırakılmayacak kadar zor bir iştir.

Yazımızı bir sloganla bitirelim: Kimileri program yazar, kimileri yazılım geliştirir. 🙂

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