Focus on Code

Neden büyük düşünmek yerine geniş düşünmek diye bir terimle başlık attığımı düşünebilirsiniz ya da geniş düşünmek diye terim mi olur diye içinizden geçirmiş olabilirsiniz. Bu farklılık kavramlar arası bir kargaşaya neden olmamak için. Büyük düşünmek genelde yenilikçi, parlak bir fikir geliştirmek ya da büyük oynayarak daha çok kazanmak gibi anlamları taşır ve genelde kişisel gelişim kitaplarında verilen ilk telkinlerden biridir.

Geniş düşünmek daha ziyade planlama ile alakalı birşey. Yani büyük düşünmüş ve büyük bir balık yakalamış olabilirsiniz ama onu icraata dökerkenki yaptığınız planlama geniş düşünülmüştür? Yani geniş düşünmek büyük düşünmekten sonra gelen sürecin devamı şeklindedir.

Nasıl ki mükemmeliyetçi kod yazımları bir hastalıksa geniş düşünmekte çok sık görülen bir programlama hastalığıdır.

Öncelikle planlamanın belli bazı kriterleri vardır. Mesela önünüze bir proje teklifi geldiğinde ya da bir proje fikri bulduğunuzda projeyi nasıl geliştireceğinize dair düşünmeye başlarsınız yani bir planlama yapmaya başlarsınız. Bu planlamada elinizdeki kaynakları, kullanabileceğiniz kaynakları, ne kadar zamanda hangi aşamalara geleceğinizi tespit etmeye çalışırsınız. Böylece bir planlama yapar, bir akış şeması çıkarır ve projeyi bu şemaya göre ilerletirsiniz.

İşte tam bu noktada kendimin de çok sık yaptığı iki fazlı hatadan bahsetmek istiyorum.

İlk hata projenin planlanma aşamasında geniş düşünmektedir. Projeyi baz alarak siz o kadar geniş düşününür, tüm detayları o kadar çok hesaplamakla uğraşırsınız ki aslında basit gibi görünen bir proje içinden çıkılmaz bir düşünceler zincirine dönüşür. Haliyle bu düşünceler zincirini bir plana, bir şemaya dökmek çok zor hatta çoğu zaman imkansız bir hal alır. Aynı zamanda projeye hemen başlamadan projenin planlaması oldukça geniş düşünülerek hazırlanmaya çalışıldığı için sadece planlama aşaması haftalar hatta aylar sürebilir.

İkinci hata ise projenin geliştirilme aşamasında geniş düşünmeye başlamaktır. Sürekli yeni düşüncelerle planlama yapısını değiştirmeye başlarsınız. Bir basamağa geldiğinizde o basamağa aslında ilk baştaki planda varolmayan şeyler eklemeye başlarsınız. Basamaklar arttıkça detay çoğalır. Ortalarda bir yerlerde proje o kadar dallanır ki ortada ne plan ne bir akış şeması kalır. Bunun sonucu olarak projenin altından kalkamayacağınızı düşünmeye başlar ve biraz daha dener projeden cayarsınız.

Bu iki hata yani geniş düşünmek büyük bir hatadır ve çoğumuzun proje geliştirme sürecine doğrudan müdahale ederek bizi içinden çıkılmaz bir hale sokar.

Düşünmek genelde bizim zekamızı karmaşıklıktan kurtarıp yalınlığa doğru yöneltiyor gibi görünse de kimi zaman bizi yalınlıktan alır ve karmaşaya götürür. Yani zeka kendi kendini sabote eder. Mantıklı süreci mantıksız bir sürece çevirir. Sonuç ise asla başarıya gitmez.

Oysaki planlamanın mantıki sebeplere dayanması gerekir. İşte bunlardan bir kaçı :

1. İnsan zekası her zaman için basit yapıyı daha kolay kavrar. Bir programlama sorusu ne kadar çok veri içerirse içersin her zaman için alt yapılara bölünüp daha kısa ve basit bir şekille parçalardan sonuca ulaşmaya olanak sağlar. Ancak kompleks bir yapı içeren bir problemi olduğu çözmek genelde ya çok zor ya da imkansızdır. Bunu biz genelde farketmeden otomatik olarak yaparız. Örneğin bir web programının bir kısmında bir hata olduğunda tüm sorun çözme bilgilerimizi ele alırız. Ama hepsini birden kullanmayız. Kademe kademe bilgileri öncelik sırasına koyar ve en çok görünen hatadan en az görünene kadar testlerimizi yaparız.

İşte planlama aşaması da her zaman için geniş düşünmeyle değil basit düşünmeyle hallolmalıdır. Geniş düşünüldükçe problem zorlaşır. Problem ne kadar basite indirgenirse o kadar kolay çözülür. O zaman kendi kendimizi sabote etmenin anlamı var mıdır?

2. Planlama yaparken planın her parçasının her zaman için mantıki sebeplere dayanması gerekir. Örneğin sizden bir web programı yapılması istendiğinde sizin belkide zekanızı göstermek için fazla birşey eklemeye çalışmanız mantıki bir davranış değildir. Çünkü insanın kendisinin zeki olduğunu ispatlamaya çalışması mantıki bir hareket değil güdüsel bir harekettir.

Ya da başka bir örnek verelim. Sizden web’den yollanan emailin posta kutusuna gelmesini sağlayan bir program yazmanız isteniyor. Siz ise buna veritabanı bağlantıları ekliyor, kişilerin webden bakmasına imkan sağlayacak web arayüzü yazıyor, onla da yetinmeyip ticket sistemi ekliyorsunuz. Bunda herhangibir mantıki sebep bulmak oldukça güçtür.

3. Planlamanın bir hesap işi olduğunu asla unutmamak gerekir. Birşey planlarken eldeki kaynakları, kullanabileceğimiz kaynakları, zamanı, bizden istenileni, yapabileceklerimizi tam ve net olarak bilmemiz ve planımızı buna göre yapmamız gerekir.

Örneğin gelen bir proje teklifi ya da aklımıza gelen güzel fikri planlarken günde en fazla 4 saat çalışabilecekken 6 saat üzerinde çalışıp 4 ayda bitireceğimizi hesaplarsak bu yanlış bir planlama olur. Ya da sadece programlama bilen bir kişi olarak projenin tasarımını da yapabileceğimizi düşünmek gene yanlış bir planlamadır. Ya da elimizde Delphi kaynağı olmadan bu kaynağı projeyle beraber varetmeye çalışıp zamanı geciktirmek, projenin diğer noktalarına gereken ilgiyi gösterememek de gene düzgün bir planlama örneği değildir.

Sınırısız kaynak ve bilgimiz olsaydı belki istediğimiz kadar geniş düşünüp planlamayı şu an varolmayan ama varolacak kaynaklar üzerinde şekillendirebilirdik. Ama böyle bir imkanımız hiçbir zaman varolmadı ve varolmayacak.

4. Planlama yaparken her zaman için projeleri bilginizin en yüksek olduğu alana çekmek zorundasınızdır. Örneğin 8 yıldır mySQL üzerine projeler geliştirmiş ve veritabanı motorunun iğne deliğine kadar her noktasına kadar hakimseniz önünüze gelen projede ihtiyaç olmadığı halde bu sefer postgresql ile yapmayı denemek gene düzgün bir planlama olmaz. Bu doğrudan doğruya bir kaynak israfıdır. Haliyle önünüze gelen proje teklifinde ya da bulduğunuz yenilikçi fikirde bir yerlerde geçen bir teknlojinin alternatifini çok daha iyi bir şekilde biliyorsanız projeyi ya da projenizi kendi sahanıza çekmeniz her zaman daha mantıklı bir iş olacaktır. Bir projeyi bilmediğiniz bir teknoloji ile yapabileceğinizi anca düşünürsünüz, peki bunu uygulayabilecek imkanınız var mı?

5. Planlama yaparken işin niteliğine göre guruplar oluşturmaya çalışmak gereklidir. Bir kişinin yapabileceği şeyler her zaman için sınırlıdır. İki kişinin yapacabileceği şeyler gene sınırlı olmakla beraber bir kişinin yapabileceği şeylerden her zaman daha çoktur. O zaman bir planı kendimize odaklı olmaktan çıkarıp bölerek kaynak kullanımını azaltmak ve sonuca giden yolu yani planın işleyişini hızlandırmak mümkündür.

Ancak gurup çalışmasının başlı başlına bir sorun olduğunu da gözden kaçırmamak gerekir. En azından ben şimdiye kadar henüz böyle bir gurup oluşturabilmiş değilim. Özellikle Türkiye gibi kişisel kabiliyetlerini bilmeden herşeye yüzde 51 ortak olma mantalitesine sahip, projede koyduğu kadar almayı değil her zaman en büyük payı almaya çalışan kişilerden çokca olan bir yerde pek de mümkün değil. ( Tabii bu kişiler eminim Microsoft’un 10.000′de 1 hissesine sahip olmak isterlerdi.) Bir proje hiçbir zaman için koyduğunu almak anlamına gelmez, bu tarz düşünceyi değiştirmek gerekiyor. Çünkü proje dediğimiz şey genelde ticari niteliktedir. Ticarette ise bir işin tutma şansı her zaman için tutmama şansından daha azdır. Kişilerin önce riski göze alması gerekiyor. Yani vereceği kaynağın tamamen ziyan olmasını da baştan kabul etmeliler. Ancak herkesin memur olacağı varsayılarak yetiştirildiği bir ülkede ticari zekaların türemesini beklemek her ne kadar umutsuz bir düşünce olsa da imkansız değil. En azından bu tarz bir gurup oluşturmayı denemek gerekiyor. Sonuçta gurup oluşmazsa en fazla bir projeniz daha yatmış olur ki bunun da genelde çok büyük kaybı olmaz. ( Tabii eğer ticari bir işletmeyse çok ciddi ticari kayıpları da olabilir. Ama burada bir şirket içinde maaşla çalışan kişileri gurup olarak işlemediğimi farketmiş olmalısınız)

6. Planlama yaparken işi parçalara bölmek. Parçalara bölmek her ne kadar işleri kolaylaştıracak bir yöntemse de yanlış kullanılırsa işi zorlaştıran bir hal alır. Yani kararının çok iyi ayarlanması gerekiyor. Burada kararı verilecek olan durum şudur : Bu elimdeki proje parçasını bir daha bölmeye gerek var mıdır yok mudur? Bu kararı vermek çoğu zaman oldukça zordur. Ancak belli bir zaman bu işlerde çalışan kişilerin böyle bir yeteneği zamanla kazandığını da söylemek lazım.

7. Planlama yaparken motivasyon kayıplarının önüne geçmek. Bir iş ne kadar uzarsa kişilerin motivasyonu o kadar düşer. Bu herkesin bildiği ve kabul edebileceği bir kural. Mesela kimi kişilerin büyük bir hevesle sarıldığı işlerden bir zaman sonra soğuduğunu ve bir adım ötede ise işi bıraktığını görebilirsiniz. Çünkü sonuca ulaşmak zorlaştıkça kişilerin motivasyonu düşmektedir.

Bunun önüne ancak projeyi en hızlı şekilde bitirmeye çalışmakla engel olunabilir. Zaten programlama camiasında genel olarak hatayı sürüm çıkararak düzeltme şansı her zaman olur. O sebeple iskeleti düzgün tasarlanmış bir programın yan öğelerinde hatalar ya da eksiklikler olsa bile bunları parça parça gidermek mümkündür. Yani aslında kimse sizden mükemmel, herşeyi planlanmış ve hesaplanmış, hiçbir eksiği olmayan birşey istemez, isteyemez. Sizden ilk etapta istenen projenin konusu olan şeyi halleden programı ne kısa sürede bitirmenizdir. Süreci kısa tutmanın ise motivasyon açısından inanılmaz bir yararı olacaktır.

8. Planları takip eden planlar yapmak. Bir plan başarıya ulaştığında yani ürün ilk etapta istenilen herşeye cevap verecek bir yapıya ulaştığında her zaman için müteakip planlarla projeyi geliştirmek mümkündür. Bir program yoktur ki yapılıp bittiğinde mükemmele ermiş olsun. O zaman gene ilk başta dediğimiz noktaya döneriz. Yani olabildiğince geniş düşünüp her şeyi ilk etapta düşünerek yapmak mantıki bir davranış değildir çünkü her zaman için revizyon yapma imkanı vardır.

Yani özetle yukarıda belli başlıklar altında topladığım konular aslında çoğumuzun sık sık yaşadığı planlama aşamasındaki geniş düşünmenin bizim üzerimizde yarattığı olumsuz etkileri ve nasıl çözülebileceğini biraz daha netleştirmek içindir. Geniş düşünmek belki bir kişinin birşeyi çok geniş bir açıdan ve detaylı olarak irdeleyebileceği anlamına gelir. Ancak çoğu zaman reel olarak faydalı olmaz, hatta zararları olur.

Toplumun ve bizim mükemmel şeylere değil (zaten aslında hiçbir zaman için mükemmel sonuç yoktur) işe yarar, iş gören şeylere ihtiyacı vardır. Bu da ancak planlama aşamasında mükemmeliyetçiliğin bir başka yansıması olan geniş düşünmeyi bırakıp planlarımızı gerçekleri ve mantıkı sorguları baz alarak planlamakla olabilir.

{ Okumaya devam et : Programlama Hastalıkları III : Kod Rüyaları }

This entry was posted on Friday, August 22nd, 2008 at 08:40:24 and is filed under focusoncode.You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.