Kötü Programcıya Övgü

0
FZ
Harold kötü bir programcıydı, gerçekten kötü bir programcı. Hani hem kendisi hem de etrafindaki herkes için kendine yeni bir meslek bulması gereken türden. Ama Harold iyi biriydi ve bir işte ömür boyu çalışacaklardandı; çok uzun süredir şirketteydi. Ezelden beri alt kademelerde olan bir programcısıydı, hiçbir zaman terfi etmedi, her sene maaşına en düşük zammı aldı ve yeri çok değiştiriliyordu. Ama kimse onu işten çıkarmak istemiyordu. Böylelikle ne zaman yeni bir proje başlasa ve yeni adama ihtiyaç olsa, Harold'ın takımının müdürü bu durumu fırsat bilip onu yönetmek zorunda kalacak bir sonrakı bahtsız kişiye gönderiyordu Harold'ı. Bir seferinde bu kişi ben oldum.
Kötü Programcıya Övgü

Bu olay, bir şirkette uzun yıllar kalmanın günümüzdekinden daha anlamlı olduğu 1980'li yıllarda geçiyordu. Yönettiğim ekip çok istekliydi. Belirleyici özelliğimiz daha iyi bir takım olma isteğimizdi ve bu hedef için de epey çalışıyorduk. İyi tanımlamış ve denenmiş süreçlerimiz vardı, gereksinim ve tasarım modelleme yaklaşımları geliştirdik ve gerçekleştirdik; gereksinimleri, tasarımı, kodu, test planlarını, test olaylarını, her şeyi denetleyen kapsamlı bir gözden geçirme yöntemi uyguladık ve bu yöntemi aynı zamanda mükemmelleştirdik. Hatta yenilikçi bir test etme yöntemi geliştirdik. Ve daha etkin olduğumuz zaman, daha da etkin hale gelmek için çok çalışıyorduk. Sonra takıma Harold katıldı.

Harold ekibe katılmadan çok daha önce ekipçe bir anlaşma yapmıştık: hiç kimsenin kötü bir işini projeye dahil etmeyecektik, o iş ister baş tasarımcıdan gelsin, ister test koordinatöründen, isterse de müdürden. Ve hatta Harold'dan gelse bile. Ekibin her üyesinin %100 başarılı olması için gerekli tüm süreçleri, şablonları, desteği, kaynakları, eğitimi, gözden geçirmeyi ve geribildirimi sunuyorduk. Bu başarı oranını ölçen metrikleri bile tanımlamıştık. Harold bize katıldığında ona sistemimizi gösterdik ve eğer bizim ekibin bir üyesi olacak ise bahsettiğimiz süreçlere tam olarak uymanın şart olduğunu açık açık belirttik. Bu disiplin herkes için geçerliydi, Harold için bile.

Bir Program Yeniden Tasarlanıyor

Harold'a verilen ilk görev kolay bir program sayılırdı. Kodlamaya başlamadan önce aldığı pakette iyice gözden geçirilmiş gereksinimler, tüm grafikleriyle birlikte ortaya konmuş görsel tasarım, test koşullarını geliştirmesi için kullanılabilecek, geçerliliği kanıtlanmış bir süreç ve biten kodun gözden ne zaman geçirileceğine dair bir zaman planı vardı. Harold kodu yazarken proje ile ilgili başka meseleler gündeme geldi ve bu yüzden kodunu gözden geçirme tarihini aksattık. Harold gözden geçirmemiz için bize kodunu getirdiğinde birim testlerini çoktan yazıp geçmişti. Bu durum normal ve beklenen süreçteki çalışma sırasına uymuyordu ama Harold'ın hatası değildi ve yazdığı program çalışıyordu, en azından Harold'a göre. Ancak kodu incelemeye başladığımızda gördük ki yazdığı program gözden geçirilmiş ve onaylanmış tasarıma kesinlikle uymuyordu. Harold ekibin sistem tasarımcılarına alternatif bir tasarım sunup bunu savunmamıştı, kendi kafasına göre ne şekilde istiyorsa öyle kod yazmıştı. Bu yüzden de yazdığı kod incelemeyi başarı ile geçemedi. Harold şok geçirmişti: "... ama tüm birim testleri geçti!..." diye bağırmıştı. İtirazları ve şikayetleri kurulum yöneticisine kadar çıkmıştı: "... çalışan bir şeyi yeniden yazmamı istiyorlar!..." Neyse ki bu protestosu görmezden gelindi ve yönetici de ekibin tarafını tuttu. Harold programı tekrar yazmak zorunda kaldı, bu sefer özgün belgelerdeki tasarıma uyacak şekilde. Kod yeniden gözden geçirme sürecine girdiğinde ilk tasarıma uygundu, iyi çalışıyordu ve bir iki basit yorum dışında hiç sorun çıkarmadan süreci başarı ile geçmişti.

Bazen yazılım süreçleri tüm bireysellik ve yaratıcılık izlerini silip atacak şekilde uygulanıyormuş gibi görünür.

Daha İyi Bir Takım, Daha İyi Bir Sistem

Takımca ilginç bir şey fark ettik: Harold başarısız bir programcı olduğu için daha iyi bir takım haline gelmiştik: sürecimizi daha iyi tanımlamış ve daha sıkı uygulamaya başlamıştık, ölçümleri kurmuş ve daha tutarlı bir şekilde almaya başlamıştık, programcılara (özellikle Harold'a) destek ve yönlendirme sağlamayı daha iyi öğrenmiştik. Her şeyden önemlisi, bir takım hedefi ve etiği benimsemiştik: asla kötü iş kabul etmeyecektik ve iş yapamayan, daha zayıf bir takım üyesini de kolayca takımdan çıkarmayacaktık; kişinin takım standartlarına ulaşabilmesi için ne gerekiyorsa onu yapacaktık. Takım üyeleri bu hedefi desteklediği, kaynaklardan yararlandığı ve geçerli ürünler ürettikleri sürece takımımızın bir parçası olabilirdi ve takım onları profesyonel olarak gözetecekti. Bu etik bizi daha iyi bir ekip yaptı.

Modern fizik, bir sistemin davranışının o sistemin tek tek parçalarının davranışının doğrudan bir fonksiyonu olmayabileceğini öğreniyor. Bir saatin içindeki çark dişlerinin hepsi büyük çark dişi olmak zorunda değil. Bazen bir sistemde daha az iyi parçalar kullanarak daha iyi davranış elde edebilirsiniz. Bazen en iyi takımlar sadece süper kahramanlardan oluşmazlar ve eğer bir takım bir sınırlamayı aşmakta kararlı davranırsa, kendi personelinden kaynaklanan bir sınırlandırma bile olsa, o sınırlandırmanın olmadığı durumundakinden bile daha iyi bir takım haline gelebilir. Kötü programcıları işe almalıyız demiyoruz ama takımlar bir kutudaki birbirine bağlanmamış somunlar ve civatalar gibi değiller, onlar bir sistem. Etkin bir takımın dinamikleri bazen göründüğünden daha karmaşık ve inceliklidir ve performansı düşük kişilerin projeye ürettikleri ürünlerin ötesinde ve farklı etkileri olabilir.

Bazen yazılım süreçleri tüm bireysellik ve yaratıcılık izlerini silip atacak şekilde uygulanıyormuş gibi görünür. Sanki sistem kurmak, düşünce gerektirmeyen bir süreç haline getirilmeye çalışılır. Bu takımda biz bunu özellikle yapmamaya özen gösterdik; ama aynı zamanda kimsenin değerini ve getirisini düşünmeden herhangi birşeyi herhangi bir anda değiştirmesine izin vermemeye dikkat ettik. Kuşkusuz kimseye sadece tembellikten, yanlış anlamalardan veya yetersizliklerinden dolayı değişiklik yapmalarına izin vermedik. Ve kimsenin başarısız olmasına da izin vermedik.

Harold'ın Kurtuluşu

Harold'ın kodu onaylandığında kendisi herkesi şaşırtan şu sözleri sarf etti: "Biliyor musunuz, bu tasarım benim daha önce yaptığımdan çok daha iyi." Aslında o andan sonra Harold bizim yaklaşımımıza tamamen inanmaya başladı ve yine herkesi şaşırtacak şekilde bizim ekibin ve sürecin misyoneri gibi davranmaya başladı. Bununla kalmadı, ekibin sürecine ve kullandığı araçlara da katkıda bulundu, elbette uygun ekip incelemeleri ve onaylarından sonra.

Ekibimiz yazılan bir kodun inceleme esnasında varabileceği en üst kalite seviyesini "OLDUĞU GİBİ" olarak belirlemişti. Yani incelenen kodda hiçbir hata yoksa, hiçbir işlevsel sorun, tasarıma dair bir şüphe yoksa, belgelendirme tamamen yapılmışsa ve imla hatası dahi yoksa bu sistem "OLDUĞU GİBİ" kabul edilebilir, mükemmel bir sistem olarak etiketleniyordu. Projenin yaşam döngüsü boyunca gerçekleştirdiğimiz 500 incelemeden sadece tek bir kişinin hazırladığı bir kod "OLDUĞU GİBİ" kalite seviyesiyle geçebilmişti. O kişi Harold idi.

Phillip G. Armour'ın "In Praise of Bad Programmers" başlıklı makalesinden yazarın izni ile Elif T. Kuş, Yaşar Safkan ve Emre Sevinç tarafından Mart 2010'da çevrilip yayımlanmıştır.

Kaynak: http://ileriseviye.org/blog/?p=3025

Görüşler

0
Tarık
Çok soğuk bir hikaye.

Çok soğuk başarısız programcı VS Başarılı programcı karşılaştırması

Bana programcılık, hacker hikayesinden çok robotize ISO9001, OHSAS18001 kalite standardı başarım kılavuzlarını hatırlattı.

İnsanların neden medya hacker lığına özendiklerini şimdi az biraz anlayabiliyorum. Zira uzmanlık arttıkça herkesin ilgisini çeken edebiyat yerini böylesi soğuk hikayelere bırakıyor anlaşılan. Biraz insan edebiyatı yahu!, dönün artık şu Mars atmosferinden...!
0
ekomut
Kesinlikle katılıyorum.
0
mtkocak
İhsan berbat bir programcıydı. Çalıştığı işyerinde, beyaz duvarlarda oynaşan huzursuz jaluzi gölgelerinin verdiği mutsuzluğun otomatik termostatlı klima sesleriyle karıştığı zamanlarda çalışırdı hep. Klima rüzgarında titreşen jaluzi yaprakları her zaman koda eklemeyi unuttuğu son class yüzünden çöken moralinin getirdiği melankoliyle cıvıldaşmakta, fotokopi kağıtlari ise bu soğuk gecelerde etrafta uçuşmaktaydı.
0
Tarık
...
0
Tarık
...
0
SydBarrett
İşini severek, samimiyetle yapmaya çalışan, farklı düşünen ve özeleştiri yapabilen insanın mutlu sonu.

Motive eden bir yazı, Teşekkürler.
Görüş belirtmek için giriş yapın...

İlgili Yazılar

KazaA Lite

butch

Napster yanlış saflara geçtiğinden beri P2P ortamlarında rahat yüzü görememiş biri olarak bugün slashdot'da haberine rastladığım KazaA Lite'ı denedim. Sanırım bir süre rahat edeceğiz çünkü program gerçekten başarılı. Unutmadan söyleyeyim KazaA Lite, KazaA'nın casus programlardan(spyware) arındırılıp, geliştirilmiş bir yan sanayi ürünü :)

QT Kütüphanesi Micros~1 Windows'da GPL Lisansına Kavuşuyor

vst

Trolltech'in web sitesinde duyurduğu habere göre, geliştirme aşamasının sonlarında olan QT4 Micros~1 Windows platformunda da çift lisansa sahip olacak: ticari lisans ve GPL lisansı.
Windows, Linux ve Mac üzerinde öncelikle grafik arayüz tasarımında kullanılan QT kütüphanesi, programlama arayüzü sayesinde C++ dilinin ağır yükünü hem hafifletiyor, hem de neredeyse tam platform bağımsızlığı sağlıyor.
Bu kararıyla, özgür/açık kaynak kodlu yazılımın yaygınlaşmasını ciddi oranda ivmelendireceğini düşündüğümüz Trolltech'in, sık sorulan sorular bölümünde verdiği cevaplar okunmaya değer.

Bir Açık Yazılım - JmxMonitor

malkocoglu_2

JmxMonitor, Java JMX standartını kullanan ve bir veya daha fazla servisi izlemek (monitoring) için kullanılabilecek bir yazılımdır.

http://jmxmonitor.sourceforge.net

Java JMX standartı, uygulamanızın istatistiklerini MBean temelli basit Java nesneleri üzerinden dısarıya afişe etmenizi sağlıyor. Bu istatistik MBean'leri işleme konulduktan sonra, JmxMonitor genelci bir yaklaşımla (generic) herhangi bir uygulamadaki tüm MBean'leri listeleyip, admin'e "gözlemek istediklerim" adlı bir liste olusturmasına izin vermektedir. Gözlenmesine karar verilen makina/port/obje/attribute dörtlüsü için bir eşik değeri (threshold) girildikten sonra, JmxMonitor arka plan süreci tarafindan periyodik olarak esasa değeri bu eşik değerine karşılık kontrol eder. Eşik değer ihlalleri, ana sayfadan ve e-mail ile sistem yöneticisine bildirilecektir.

Python 2.4

tongucyumruk

18 aylık uzun bir bekleyişin ardından Python 2.4 çıktı. Yenilikler arasında özellikle dekoratörler, geliştirilmiş üreteç desteği ve long veri itipi ile integer veri tipinin birleştirilmesi göze çarpıyor. Özellikle MS Windows kullanıcılarını ilgilendiren bir diğer yenilik ise bu sürümden başlayarak Python'un MS Windows platformunda msi paketleri kullanılarak dağıtılacak olması. Yeni sürümdeki yeniliklerin bir özetini buradan okuyabilir, daha detaylı bilgiyi ise A. M. Kuchling'in dökümanından okuyabilirsiniz. Yeni sürümü indirmek içinse buraya

Truva Linux 1.0 Beta Duyuruldu!

anonim

2004 yılı Nisan ayında bir grup Linux gönüllüsü tarafından Türk Linux kullanıcılarının ihtiyacına göre hızlı, güvenilir, kurulumu ve kullanımı kolay işletim sistemi hazırlanması amacıyla başlatılan Truva Linux Projesi'nin ilk ürünü "Helen" kod adlı "Truva Linux 1.0 Beta" sürümü duyuruldu.