Tasarımlı Tasarımsıza Karşı

Yukarıdaki grafik, önemli bir grafik, ama benim icadım değil. Geçenlerde Martin Fowler’un konuşmasında kullandığı grafiklerden biri. Bir tek grafiğin, çok şeyi açıklıyor olması bizi hem şaşırtmış, hem hoşumuza gitmiş, hem de duygularımıza tercüman olmuştu.

İşin ana fikri şu: Yazılım projesinde, yapılan iş tasarımla yapılırsa, baştan işler biraz yavaş gidiyormuş gibi görünse de, nihai olarak yapının doğru olması, proje ilerledikçe, artan verim, durumu telafi eder ve belli bir süre sonra tasarımsız durumun kat kat üstüne çıkar. Yapılan iş tasarımsız yapılırsa, baştan hızlı gidiyor gibi görünse de, sonradan verim düşer ve işler ilerlemez bir noktaya doğru gider.

Şimdi tepki şu: Manzara buyken, herhalde kimse tasarımsız iş yapmaya kalkışmaz, değil mi?

Değil, maalesef değil, hiç değil…

Hangi yolun takip edildiği, bir yazılım yönetimi problemi elbette. Hiç bir yönetici, yazılımcılara, “şu işleri tasarımsız yapın da sonradan işler ilerlemez duruma gelsin” demiyor. Ama elbette bir şeyler yapıyor ki, sonuç sıklıkla bu oluyor. Nedir bunlar? İşte cehenneme giden yoldaki iyiniyet taşlarının kısmî listesi:

• Kesin X zamanda faaliyete geçmemiz / projenin bitmesi lazım!
  Klasik “matbu proje süresi” meselesi. Elbette, yöneticiye sorarsanız çok sayıda, hepsi de mantıklı görünen açıklama vardır. Aşağı-yukarı, bunların tamamı da “eğer bu sürede olmazsa kaybedilecek para” veya “işin batması” üzerinedir. (İşin batması da para meselesidir elbette.) Ancak, şöyle bir gerçek de vardır: Bir projenin, siz onu doğru ölçseniz de ölçemeseniz de tamamlanabileceği bir minimum süre vardır. Eğer daha kısa zamana zorlarsanız, o zaman takımı tasarımsız iş yapmaya zorlamış olursunuz. Böylelikle, işi kurtarayım derken, yapılan tüm işi nihai olarak çöpe atarak batmayı yada daha fazla para kaybetmeyi garantiye almış olursunuz.
• Bizim projemiz kısa, hemen yapıverelim!
  Grafiğimizdeki kritik süre olarak işaretli yer, oldukça önemli bir zamandır. Her nedense, o sürenin aylar sonra geleceği düşünülür. Ama, (Martin Fowler’ın da dediği gibi) kritik zaman haftalar içinde gelir. İşler yavaşladıkça, daha çok “çakma” iş yapma refleksi de devreye girer. Ben, grafiğin ucu aşağı dönenini bile gördüm (işler o kadar sardırdı ki, yeni bir şeyler yapmaya çalışmak, eskileri bozmaktan başka bir işe yaramaz oldu).
• Şu darboğazı bir atlatalım da…
  Nedense hayatımız hep darboğaz ve acil durumların ucuca eklenmesinden oluşur. O darboğaz zannetiğiniz yer, aslında yazılım aleminin normal çalışma durumudur. Eğer normal durumun bu olduğunu ikrar ve kabul edemiyorsanız, kısa vadede acil durum ilan eder ve tasarımsız eğrisine mutluluk içinde biner ve kıyamete gidersiniz.
• Müşteriye hemen çıktı göstermemiz lazım!
  Müşteri velinimettir, bu kesin. Ama projeyi müşteri veya onun keyfiyeti yönetemez, bu da kesin. Eğer işin başında tasarımlı çalışmanın düşük çıktı üretme hızını müşterinize anlatamıyor ve yazılımcılarınızı bu baskıdan koruyarmıyorsanız, projenin erken safhalarında hemen çıktı üretmek istersiniz. O zaman da, hangi eğriye binersiniz? Tabii ki tasarımsız eğriye… Hayırlı yolculuklar…
• Herkes bir satır kod yazsa, bu iş zaten biter!
  Hızlı iş çıkartmak adına, takımdaki herkesin çıktı gösterecek işlere atamak, yada takımı baştan bu şekilde kurmak, takımda “kafası suyun üzerinde duracak” yani gelişen problemler ve tasarımsal problemlerle uğraşacak kimseyi bırakmamak da, sizi kısa yoldan tasarımsız eğriye bindirir.

Türk insanı olarak, bir haftadan uzun plan yapamama ve bir haftadan uzun hafızaya sahip olamama problemimiz olduğundan (hani bakınız memleket gündemi) bu durum bizde daha da ağır yaşanıyor. Yani, aramızda en delikanlı olan, bir ay sonrasını planlayabiliyor. Bu sebepten, herhangi bir noktada, (a) en uzak gördüğünüz mesafe bir ay ise ve (b) kritik zamanın aylar sonra geleceğine inanıyorsanız; her karar noktasında, tasarımsız eğriyi seçersiniz… Eğrinin ilerisini göremiyorsunuzdur çünkü.

Peki, bu işin öbür aşırısı yok mu? Elbette var. Ona, “analysis paralysis” yani analiz felci deniyor. Baştan tasarım ve planlama yapacağız diye bir türlü işe başlayamama durumu. Tavsiye ettiğimiz şey, tabii ki bu değil. “Agile” dediğimiz metodolojiler, bundan kaçınmak üzere düşünülmüş şeyler. Öte yandan “çevik” (“atik” mi deseydik “agile” karşılığı?) olmak, tasarımsız hareket etmek değil. Tasarımın da, proje ile beraber şekillenmesi anlamına geliyor… Ama, tasarımsız kod yazmak, “çak çak” iş yapmak anlamına gelmiyor.

“Yazılımcının suçu ne?” deyip duruyorum ya… İşte bir suç ortaya çıkıyor bu noktada:

Yazılımcının suçu, baskılara bel verip, daha sonra işleri zorlaştıracağını bildiği kodları tasarımsız bir şekilde yazmaktır.

Yani, değerli yazılımcı kardeşim, sana tavsiyem şudur:

Bu ahval ve şeraitte dahi, birinci vazifen, kodunu tasarımsız yazmamak, kodun mimari yapısını iç ve dış tüm baskılara karşı korumaktır. Muhtaç olduğun kudret, ellerinin altındaki klavyede mevcuttur.