Battı Balık Yan Gider

Batan projeleri ben batan gemilere benzetiyorum. Batmaya meğil gösteren bir gemi nasıl bunu belli ediyorsa, batmaya meğilli bir yazılım projesi de parmak kaldırıp, dikkat ben batıyorum der. Bir projenin batacağı nasıl anlaşılır? Şöyle:

  • Big design up front olarak isimlendirilen, kahin vari, bugünden yarının nasıl olacağını bilme kibiri ile tüm yazılım mimarisi ve tasarımının yazılım öncesi yapılması. Kutsallaşan bu tasarımı sorgulamak ve değiştirmek imkansızdır. Yazılımın ana kurallarından birisi: değişmeyen değişikliğin kendisidir. Madem bunu biliyoruz, neden proje başlamadan herşeyi ön görmeye çalışıp, acayip acayip tasarımlar yapıyoruz? Bu mimari ya da tasarımın müşteri gereksinimlerini bir zaman sonra taşımayacağı ortada değil midir? Müşterinin neye ihtiyacı olduğunu nasıl tahmin edebiliriz? Kendisi bile bunu bilemez. Piyasa koşulları bugünden yarına öyle bir değişir ki, proje müşteri için anında tüm anlamanı yitirebilir. Projelere pragmatik bir tasarım ile başlanmalıdır. Gerekli olduğu zamanlarda bu tasarım revide edilerek, güncelleştirilir.
  • Birim, entegrasyon, regresyon, fonksiyon ya da onay/kabul testlerinin olmaması. Sıfır birim test kodunun olduğu projeler bilirim. Birim testleri olmayan bir projeyi yeniden yapılandırmak (refactoring) imkansızdır. Ya bazı kafalar bunu bilmiyor ya da umursamıyorlar. Test konseptlerini bilmeyen programcılar olabilir. Bu bir ayıp değil. Hemen oturup öğrenmeliler. Ama asıl problem ayağı yere basmayan zaman tahminleri ile proje planlaması yapan proje yöneticileridir. Baktılar proje yetişmeyecek, askerlerine emir vererek, testlerin yapılmamasını sağlarlar, çünkü test yazmak zaman kaybıdır onlar için. Böyle yapmaya devam edin!
  • Programcıların DRY ve KISS prensiplerine sadık olmamaları. Bu kodun bakımını, değiştirilmesini ve geliştirilmesini zora sokan bir durumdur. Bir noktadan sonra (point of no return) kod tabanı o kadar katılaşır ki, yeni müşteri gereksinimleri için yoğrulamaz hale gelir. Çöpe at, yeniden yap!
  • Sürekli entegrasyon yapılmaması. Bakımın ve geliştirmenin kolay olabilmesi için yazılım sistemlerinin modüler olması gereklidir. Modüler bir yapı entegrasyon işlemlerini gerekli kılar. Altı ayda bir entegre edilen modüler bir sistemin adam akıllı entegre edilemeyeceği ortadadır, çünkü entegrasyonun doğası sorunludur. Bu sorunu aşmak için altı ayda bir değil, yazılım sistemi her gün entegre edilmelidir. Bunun için Jenkins ya da Cruise Control gibi entegrasyon serverleri kullanılabilir. Ya sürekli entegre et, ya da bu diyarı terk et!
  • Projelerde maliyeti düşürmek için tecrübesiz programcıların çalıştırılması. Üniversite mezunu bir gençten bir usta kıvamında kod yazması beklenemez. Usta programcılar ağaçta yetişmiyor. Zaman içinde yeni üniversite mezunu yazılımcı gençlerde tecrübe kazanıp, ustalaşacaklardır. Lakin bir projeye çok sayıda genç yazılımcı dahil edip, projenin zamanında tamamlanmasını beklemek utopiktir. Eğer projede hiç usta programcı yoksa, iş daha da kötü olacaktır. Eğer projede usta programcılar varsa, bunlar zamanlarının büyük bir kısmını gençleri eğitmek için harcayacaklardır. Bir projede genç yazılımcı olmasın demiyorum. Ama mutlaka iş bitirici usta programcılar olmalı ve bu programcıların kendi işlerine odaklanmaları saglanmalıdır.
  • Mimari kararların firma bünyesindeki merkezi bir noktada alınması. Çoğu büyük firmada kendilerini mimar grubu olarak tasvir eden bir yapıya rastlamak mümkündür. Firmada yazılım alanında olup biten herşeye burunlarını sokma alışkanlığı vardır bu grubun. Herşeyden haberdar olmak isterler, aldıkları tüm mimari kararların uygulandığını titizlikle takip ederler. Oysaki merkezden birileri ne yaptığımıza bir göz atacak diye zaman kaybetmek anlamsızdır. Böyle kararların merkezi bir yerden, sahada ne olup bittiğini bilmeden alınması proje gidişatını zora sokabililr. Elini kirleten proje ekibindeki programcılardır. Projeyi ilgilendiren tasarım kararlarını onlar almalı ve uygulamalıdırlar. Merkez mimar grubu yine genel gidişatı yönlendirici kararlar alsın, ona birşey demiyoruz, ama lokal projelere karışmasınlar, karışmak istiyorlarsa sahaya inip, ellerini kirletsinler. Bakalım o kararları yine öyle rahatlıkla alabilecekler mi!

Listemize müşterinin ne istediğini anlamamak, yanlış teknolojik araçların seçimi, yazılım ekibinin yeteneklerine güvenmemek, iteratif bir çevik süreci kullanmamak gibi daha birçok neden ekleyebiliriz.

Yazılım genç bir sektör değil. Genç bir sektörde çalışıyoruz argümanının arkasına saklanarak, batan projelerin sorumluluğundan kendimizi kurtarmaya çalışmamız doğru değil. 1950, belki de daha öncesinden beri insanlar programlar yazıyor. Donanımcılara bir baksanıza. Almışlar başlarını, gidiyorlar. Bilmem kaç çekirdekli işlemciler yapıyorlar. Biz yazılımcıların onları takip etmesi bile hayal oldu. Donanımda muazzam gelişmeler olurken, biz yazılımcılar olduğumuz yerde sayıyoruz. Yazdığımız programlar birden fazla çekirdek üzerinde koşmakta zorlanıyor. Daha bu işe bile hakim değiliz. Lakin bunların hepsi yazılımdan anlamıyoruz anlamina da gelmez. Yazılım mühendisi olarak bilmemiz ve uygulamamız gereken prensip ve pratikler var. Bunlar:

Projelerin batmasında biz yazılımcılar da rol oynuyoruz. Kendimizi geliştirip, yazılım pratik ve prensiplerine daha çok hakım olmamız gerekiyor. Bu konulara işimize olan saygımızdan dolayı daha fazla odaklanmalıyız. Bu konulara hakim olan üstatların peşlerini bırakmamalıyız. Onlardan öğrenebildiğimiz herşeyi öğrenip, işimizi daha kaliteli yapmaya çaba sarf etmeliyiz.

Ama tek suçlu biz değiliz. Proje yöneticileri herşeyi doğru yapıyor denemez. Firma bünyesinde verilen yanlış politik kararlar, yöneticilerin programcıları insan olarak değil de, kaynak olarak görme eğilimleri, ayakları yere basmayan proje planlaları, maliyeti düşürme güdümlü işçi alımları, genel olarak kötü yönetim, projelerin başarısızlıkla sonuçlanması çabuklaştırmaktadır.

Biz programcılar işimizi doğru yaparsak en azından projeyi siz batırdınız diye bize yüklenemezler :)


EOF (End Of Fun)
Özcan Acar

Post Views: 234