Bilgisayar Mühendisleri Portalı

Joel Test’in en güzel tarafı her bir soruya kısa Evet veya Hayır yanıtı verilebiliyor olmasıdır. Günlük yazılan satır sayısı veya her bir bükülme noktası için ortalama hata sayısını bilmeniz gerekmez. Ekibinize her bir “evet” yanıtı için 1 puan verin. Ancak bu testi nükleer santral yazılımınızın emniyetli olup olmadığından emin olmak için kullanmamanız gerekir.

12 puan mükemmel, 11 idare edilebilir, fakat 10 veya daha düşük ise ciddi sorunlarınız var demektir. İşin doğrusu birçok yazılım şirketi 2 veya 3 puan ile çalışmakta ve bu şirketlerin ciddi yardıma ihtiyacı var. Çünkü Microsoft gibi firmalar her zaman12 puan ile çalışmakta.

Şüphesiz bunların dışında da başarı veya başarısızlığı belirleyen faktörler var: Diyelim ki mükemmel bir yazılım ekibiniz var ve hiç kimsenin istemediği bir ürün üzerinde çalışıyorlar. Sonuçta kimse o ürünü istemeyecek. Veya yukarıda sözü geçen özelliklere sahip olmaksızın dünyayı değiştiren inanılmaz yazılımlar yaratan silahşörler ekibi düşünülebilir. Kurallarımız bunların dışındaki tüm durumlarda geçerlidir, yani, bu 12 maddeyi karşılıyorsanız istikrarlı biçimde ürün çıkaran disiplinli bir ekibiniz var demektir.

Ticari kaynak kodu kontrol paketlerini kullandım, ücretsiz olan CVS’yi kullandım, CVS’nin gayet iyi olduğunu rahatlıkla söyleyebilirim. Eğer kaynak kodu kontrolunuz yoksa, programcıları birarada çalışmaya zorluyorsunuz demektir. Programcıların diğerlerinin ne yaptıklarını bilme şansı yoktur. Hatalar kolaylıkla geri alınamazlar. Kaynak kodu kontrolunun bir diğer güzel özelliği, kaynak kodlarının her programcının hard diskinde kaydedilmiş olmasıdır—Bu güne kadar kaynak kodu kontrol sistemi kullanan bir projede büyük miktarda kodun kaybolduğunu hiç duymadım.

Bununla kastettiğim şu: Kaynak kodlarının son halinden bir sistem oluşturmak kaç adım gerektirmekte? İyi ekiplerde, tüm kaynak kod ayrılışlarını en baştan oluşturan tek bir betik (script) vardır, her bir kod satırı yeniden oluşturulur, EXE’ler yaratılır, tüm değişik sürümler, diller, ve #ifdef kombinasyonları için kuruluş paketi ve son ürün (CDROM oluşturulması, web sitesi güncellenmesi gibi) yaratılır.

Eğer bu işlem birden fazla adımı içeriyor ise, hataya açık demektir. Üstelik ürün dağıtımı aşamasına gelindiğinde “en son” hataların düzeltilmesi, son EXE’lerin yaratılması çevriminin çok hızlı yürümesi gerekir. Eğer kodun derlenmesi, kuruluş oluşturucunun çalıştırılması gibi işlemler için 20 adım gerekiyorsa, zamana karşı çalışılan bu çok sıkışık ortamda deli olmanız işten değildir ve çok aptalca hatalar mutlaka yapılır.

Bu yüzden çalıştığım son şirket WISE’den InstallShield yazılımına geçiş yaptı: Çalışma ortamımız, kuruluş işleminin, NT'de otomatik olarak gece çalışmasını gerektiriyordu ancak WISE bunu sağlayamadı, bu yüzden bu ürünü kullanmaktan vazgeçtik.(İyi niyetli WISE ekibi son sürümlerinin gece sistem oluşturulmasını sağlayacağı konusunda bana garanti verdiler)

Kaynak kodu kontrol sistemi kullanılırken, bazen bir programcı kazara oluşturulan sistemi bozan bir değişiklik yapar. Örneğin, yeni bir dosya eklenir, kendi bilgisayarında herşey doğru çalışır, ancak bu dosyayı kod deposuna aktarmayı unutur. Bilgisayarını kapatıp olan bitenden habersiz evine gider, mutludur. Ancak diğer tüm programcıların çalışması durur ve sonuçta diğer herkes evine gider ama kimse sevgili programcımız kadar mutlu değildir.

Sistemin oluşturulmasının bozulması çok kötü (ve çok yaygın) bir durumdur. Bu nedenle günlük sistem oluşturulmasını zorunlu hale getirir. Bu sayede sistemde oluşan hiçbir bozulma gözden kaçmaz. Büyük ekiplerde, bozulmaların hemen duzeltilmesini garanti etmenin en iyi yolu öğle arasında günlük sistem oluşturulmasının yapılmasıdır. Herkes yemekten önce olabildiğince çok değişikliği kaydeder. Geri döndüklerinde sistem oluşturma işlemi tamamlanmıştır. Eğer herşey yolunda ise ne ala! Herkes kaynak kodlarının son haliyle devam eder. Eğer sorun var ise , düzeltme işlemi yapılır, fakat bu sırada herkes bozulma olmayan daha önce oluşturulmuş kaynak kodları üzerinde çalışmaya devam edebilir.

Excel ekibinde sistem oluşturulmasının hatalı olmasına neden olan kişiye ceza olarak, bir sonraki hataya kadar sistem oluşturma işlemleriyle ilgilenme zorunluluğu getiriyorduk. Bu yanlış yapmamak için iyi bir motivasyon olmasının yanısıra, herekese işlerin nasıl yürüdüğünü öğretmenin iyi bir yoluydu da.

Günlük sistem oluşturma ile ilgili daha ayrıntılı olarak Günlük Sistem Oluşturma Sizin Arkadaşınızdır isimli makalemi okuyabilirsiniz

Ne derseniz deyin eğer tek başınıza bile kod yazıyorsanız, kod içinde oluşan bilinen tüm hataları listeleyen bir veri tabanı yok ise kod kalitesi düşer. Birçok programcı hataları hafızalarında tutabileceklerini düşünür. Ance bu çok saçmadır. 2 veya daha fazla hatayı aynı zamanda hatırlayamam ve bir sonraki gün, sistemin dağıtımı aşamasında unutulur. Hataların mutlaka çok ciddi bir şekilde takip edilmesi gerekir.

Hata veritabanı çok basit veya çok karmaşık olabilir. Minimum veri tabanı her bir hata için aşağıdaki bilgileri içermelidir:

Eğer hata takip yazılımının karmaşık olması hata veri tabanı oluşturmanıza engel oluyorsa, yukarıda belirlenen önemli alanları içeren 5 sütunlu bir tablo oluşturun ve kullanmaya hemen başlayın.

Hata takip sistemi konusunda daha detaylı bilgi için Sorunsuz Hata Takibi yazımı okuyabilirsiniz.

Windows için Microsoft Word’ün ilk sürümü “ölüm marşı” projesi olarak adlandırılmıştı. Sürekli gecikmeye uğradı ve hiçbir zaman bitirilemedi. Tüm ekip anlamsız uzun saatler boyunca çalışıyordu fakat proje tekrar tekrar gecikiyordu, herkesin üzerinde inanılmaz bir stres oluşmuştu. Lanet şey en sonunda piyasaya sürüldüğünde bir yıl gecikmiş durumda idi. Microsoft tüm ekibi Cancun’a tatile gönderdi ve ciddi bir vicdan muhasebesine girişti.

Farkedilen en önemli şey proje yöneticilerinin “takvim” konusunda çok ısrarcı olmaları nedeniyle programcıların kodlama işlemini alelacele yapmaları, hata düzeltme aşaması programın bir parçası olmadığı için de yazılan kodun çok kötü olmasıydı. Hata sayısını azaltma konusunda hiçbir çaba gösterilmemişti. Tam tersine uygulanan yöntem hata sayısının artmasına neden olmuştu. Bir yazı karakterinin yüksekliğini ölçmek için kod yazması gereken programcının kısaca “return 12” yazdığı ve bunun her durumda doğru çalışmadığını görmek için hata raporunun gelmesini beklediği rivayet edilir. Takvim, hatalara dönüşmeyi bekleyen özellikler listesinden ibaret hale gelmişti. Çalışma sonu özeleştiri raporlarında bu durum “sonsuz hatalar metodu” olarak adlandırıldı.

Problemi düzeltmek için Microsoft tüm birimlerinde geçerli olacak şekilde “sıfır hata metodunu” adapte etti. Firma içindeki programcıların çoğu, bu duruma kıkır kıkır güldü. Yönetimin, tepeden gelen bir emirle tüm hataları sıfırlamak istediği sanıldı. Aslında “sıfır hata”, herhangi bir anda yeni bir kod yazmadan önce en yüksek önceliğin hataların düzeltilmesine verilmesi anlamına geliyordu. Neden böyle olduğu şöyle açıklanabilir.

Genellikle, bir hatayı düzeltmeden önce ne kadar uzun süre beklenirse hatanın düzeltilme maliyeti(zaman ve para olarak) o kadar yüksek olur.

Örneğin, derleyicinin yakaladığı yazım veya söz dizimi hatası yapıldığında, bu hatanın düzeltilmesi çok basit bir işlemdir.

Kod içinde ilk çalıştırmada ortaya çıkan bir hata var ise, bu hatayı hemen hemen hiç zaman harcamadan düzeltebilirsiniz, çünkü kodun tamamı aklınızdadır.

Eğer birkaç gün önce yazmış olduğunuz bir kodda hata bulursanız, hatayı yakalamanız biraz zaman alabilir, fakat yazdığınız kodu tekrar okuduğunuzda herşeyi tekrar hatırlarsınız ve hatayı kabul edilebilir bir sürede düzeltebilirsiniz.

Fakat, birkaç ay önce yazmış olduğunuz kod içinde bir hata bulursanız, kod hakkında muhtemelen birçok ayrıntıyı unutmuş olduğunuz için hatanın düzeltilmesi çok daha zor olacaktır. Bu esnada bir başkasının kodunu düzeltiyor olabilirsiniz ve bu kodu yazan programcı Marmaris’te tatilde olabilir. Bu durumda hatanın düzeltilmesi bilimsel bir keşif gibidir: Ağır, metodlu ve büyük bir titizlik içinde çalışmanız gerekir ve tedaviyi bulmanızın ne kadar süre alacağı konusunda tahmin yürütmeniz çok zordur.

Ve eğer dağıtımı yeni yapılmış bir kod içinde hata bulduysanız, bu hatanın düzeltilmesi için inanılmaz miktarlarda harcama yapmanız gerekecektir.

Tüm bu nedenler hataların derhal düzeltilmesini gerekli kılar: çünkü daha az zaman alır. Bir diğer neden ise, yeni bir kodun yazılmasının alacağı sürenin, var olan bir hatanın düzeltilmesinin alacağı süreye göre daha kolay tahmin edilmesi ile ilgilidir. Örneğin, eğer size bir listeyi sıralamak için ne kadar süre gerektiğini sorarsam bana doğruya yakın bir tahminde bulunabilirsiniz. Ama eğer Internet tarayıcının 5.5 sürümü yüklendiğinde programınızın çalışmama nedenini tahmin etmenizi istersem, hiçbir tahminde bulunamayabilirsiniz, çünkü tanım gereği hataya neyin sebep olduğunu bilmiyorsunuz. Hatanın bulunması 3 günde sürebilir 2 dakikada sürebilir.

Tüm bunlar, düzeltilmek üzere bekleyen birçok hatayı içeren bir çalışma takviminiz var ise, bu takvim güvenilir değil anlamına gelir. Ama eğer tüm bilinen hataları düzeltti iseniz, ve geriye sadece yeni kodların yazılması kaldı ise, çalışma takviminiz çok daha gerçeğe yakın olacaktır.

Hata sayısının sıfırda tutulmasının diğer büyük yararı ise rekabet avantajı sağlamasıdır. Bazı programcılar bunu ürünün her an sürüme hazır halde bulundurulması olarak düşünürler. Eğer rakip firma müşterileriniz çalan yeni bir özellik geliştirdi ise, sadece bu özelliği ekleyerek, birikmiş birçok hatayı düzeltmeye gerek kalmaksızın hemen yeni ürününüzü piyasaya sürebilirsiniz.

Eğer geliştirdiğiniz kod işiniz açısından önemli ise, kodların yazımının ne zaman tamamlanacağının işiniz açısından önemli olması için birçok nedeniniz var demektir. Programcılar tahmin yürütme konusundaki aksilikleri ile meşhurdur. Satıcı personele “tamamlandığında bitecek” diye çıkışırlar.

Ne yazık ki bu işin tamamlanmasını garanti etmez. Ticaretin gerektirdiği birçok planlama kararına ihtiyaç vardır: Demolar, ticari gösterimler, reklamlar bunlardan sadece bazılarıdır. Bunu yerine getirmenin tek yolu bir takvimin olması ve bu takvimin güncel tutulmasıdır.

İş takvimi olmasının bir diğer önemli yararı, hangi özelliklerin yerine getirileceği konusunda karar vermeye zorlamasıdır. Bu kararın ardından gereksiz özelliklerin (kapsam genişlemesi) sisteme eklenmesi yerine en az önemdeki özelliklerin seçilerek kapsam dışına alınma zorunluluğunu getirir.

İş planının güncel tutulması işleminin zor olması gerekmez. Çok yararlı iş planlarının nasıl yapılacağını görmek için Sorunsuz Yazılım İş Planları makalemi okuyabilirsiniz.

Belirtim (spec) yazma diş ipi kullanmaya benzer: herkes iyi bir şey olduğu konusunda görüş birliğindedir, ancak kimse kullanmaz.

Bunun neden böyle olduğunu bilmiyorum, fakat bu durum muhtemelen programcıların döküman yazmaktan nefret etmelerinden kaynaklanmaktadır. Sonuçta, problemi çözecek ekip tamamen programcılardan oluşuyorsa, açıklamalarını döküman yerine kaynak kodu içinde ifade etmeyi tercih ederler. Programcı önce belirtim yazmak yerine hemen kodlamaya başlar.

Tasarım aşamasında, bir problem belirlendiğinde, tasarım notlarından birkaç satır değiştirilerek problem çözülür. Kod yazıldıktan sonra, problemlerin düzeltilme maliyeti hem zaman hem de duygusal olarak (insanlar yazdıkları kodu çöpe atmaktan hiç hoşlanmazlar) çok yüksektir. Bu nedenle, gerçekte problemlerin çözülmesine karşı direnç vardır. Belirtim kullanılmadan yazılan yazılımlar genellikle kötü tasarlanmış duruma düşerler ve iş planı kontroldan çıkar. Netscape programında olan durum budur. İlk dört sürüm öylesine karmaşık bir hal aldı ki sonunda yöneticileri aptalca bir kararla kodu tamamen çöpe atarak yeniden yazmaya karar verdiler. Daha sonra aynı hatayı Mozilla ile, alfa aşamasına gelmesi birkaç yıl alan bir çalışma ile kontroldan çıkmış bir canavar yaratarak tekrar ettiler.

Benim bu konudaki basit teorim, programcıları yazma konusunda sıkıştırılmış bir kursa göndererek onların yazmaya karşı daha az dirençli olmalarını sağlayarak problemin çözülebileceğidir. Bir diğer çözüm yazılı belirtimler üreten akıllı program yöneticileri tutmaktır. Her iki durumdada mutlaka uygulanması gereken basit kural “belirtim olmadan kod yazılmamasıdır”.

Belirtim yazmayı ayrıntıları ile öğrenmek için dört kısımdan oluşan makalemiokuyabilirsiniz.

Bilgisayar çalışanlarına sessiz ve kendi başlarına çalışabilecekleri bir ortamı sağlayarak verimliliğin artırılabileceği konusunda yazılmış çok yazı vardır. Klasik yazılım yönetimi kitabı olan Peopleware’de bu verimlilik artışı konusu ayrıntılı olarak yer almaktadır.

Hepimiz bilgisayar çalışanlarının çalışma ortamından tamamen bağımsız işlerine konsantre olduklarında çok iyi çalıştıklarını biliriz. Zamanı unuturlar ve iyi bir konsantrasyon ile mükemmel işler başarırlar.Bu zamanlar onların en verimli oldukları zamanlardır. Yazarlar, programcılar, bilim adamlar ve hatta basketbol oyuncuları aynı süreci yaşar.

Ancak sorun şu ki, “havaya girmek” çok kolay değildir. Ölçmek gerekirse, maksimum verimle çalışmaya başlamak için yaklaşık 15 dakikalık bir süre gerekmektedir. Bazan, çok yorgun iseniz veya o gün için verimli birçok çalışma yaptı iseniz, havaya giremezsiniz ve günün geri kalan kısmını internet’te gezinerek veya tetris oynayarak geçirirsiniz.

Bir diğer sorun ise konsantrasyonun çok kolay bozulabilmesidir. Gürültü, telefon, öğle yemeği için dışarıya çıkma, kahve almak için migrosa 5 dakika için gitme ve çalışma arkadaşları tarafından bölünme – özellikle çalışma arkadaşlarının araya girmesi – gibi nedenlerle konsantrasyon bozulur. Eğer bir çalışma arkadaşı sorusu ile sizi 1 dakika için meşgul ederse bu konsantrasyonunuzu öyle bozar ki,  tekrar verimli olarak çalışmaya dönüş yarım saat alabilir. Bu şekilde genel verimliliğiniz ciddi şekilde düşer. Eğer, kahvehane görünümlü nokta com şirketlerinin çok sevdiği gibi, pazarlama elemanlarının programcıların hemen yanı başında telefonda bağıra çağıra görüşmeler yaptığı bir ortamda iseniz verimliliğiniz bilgisayar çalışanlarının çalışmalarının kesintiye uğradığı ve konsantre olamadıkları oranda tehlikeye girer.

Özellikle programcılar için bu çok zor bir durumdur. Verimlilik, birçok küçük detayın kısa süreli bellekte aynı anda alınıp verilebilmesine bağlıdır. Herhangi bir araya girme bu küçük detayların kaybolmasına neden olur. Çalışmaya yeniden döndüğünüzde, bu detaylardan hiçbirini hatırlamazsınız (kullanmakta olduğunuz bölgesel değişkenler, veya bir arama algoritmasının uygulanmasına geçmek üzere olduğunuz aşama gibi). Tüm bu detayları hatırlamanız, eski verimli çalışma hızınıza erişmeniz içi bir sürü zaman kaybetmeniz gerekir.

İşte size basit bir hesap. Eğer bir programcının çalışmasını sadece bir dakika için dahi bölersek (ki veriler bu yönde) 15 dakikalık bir verimli çalışmayı yok ediyoruz demektir. Bu örnek için Can ile Pınar’ı birbirine komşu iki odacıkta çalışan iki programcı olduğunu varsayalım. Can strcpy rutininin unicode sürümünün adını hatırlamamaktadır. Açıp bakabilir ve bu sadece 30 saniyesini alır, veya Pınar’a sorabilir, bu da sadece 15 saniyesini alır. Pınar hemen bitişiğinde olduğu için ona sorar. Pınar’ın dikkati dağılır ve Can’a 15 saniye kazandırmak için verimli çalışmasından 15 dakika kaybeder.

Şimdi bu iki programcının farklı odalarda olduğunu varsayalım. Can rutinin adını hatırlamadığında açıp bakabilir ve hala bu işlem onun sadece 30 saniyesini alır veya pınara sorabilir ki bu sefer ayağa kalkıp yürümeyi gerektirir (programcıların fiziksel sağlık durumları gözönüne alındığında bu pek de kolay bir faaliyet değildir!) ve 45 saniyesini alır. Can dökümanlara bakmaya karar verir. Sonuçta Can verimliliğinden 30 saniye kaybeder fakat Pınar’ı 15 dakikalık kayıptan kurtarmış oluruz.

Eğer derleme  işleminiz birkaç saniyeden fazla sürüyorsa, en yeni ve en hızlı bilgisayarı almanız size zamandan tasarruf sağlar. Eğer derleme 15 saniye sürerse, programcılar sıkılır ve derleyici çalışırken Soğan’ı okumaya başlarlar ki bu da saatler sürecek verimlilik kaybına neden olur.

GKA (Grafik kullanıcı arayüzü) kodlarında bir ekran ile yanlış ayıklama işlemi imkansız olmasa da çok sıkıntılıdır. Eğer GKA kodu yazıyorsanız iki ekran işleri çok kolaylaştırır.

Birçok programcı eninde sonunda araç çubukları veya simgeler için ikil eşlemli (bitmapped) resimler üzerinde çalışmak zorunda kalır. İkil eşlemli resimleri değiştirmek için Microsoft Paint programının kullanılması kötü bir şaka gibidir, ancak birçok programcı bunu yapmak zorunda kalır.

Son işimde, sistem yöneticisi  bana hard diski gereğinden fazla kullandığımı (dikkat! 220MB) bildiren otomatik mesajlar göndermeye başladı. Hard disk fiyatları gözönüne alındığında kapladığım alanın maliyetinin kullandığım tuvalet kağıdının maliyetinden çok daha az olduğunu belirttim. 10 dakikalik temizlik çalışması bile verimliliğimde önemli bir kayıp olurdu.

Büyük hedefler için çalışan ekipler programcılarına eziyet etmezler. Yetersiz araçların neden olacağı çok küçük sıkıntılar bile programcıları mutsuz ve hırçın yapar. Hırçın programcı verimsiz programcıdır.

Son olarak, programcılar onlara verilecek en son ve en havalı bir araç ile kolayca tav olurlar. Bu onların sizin için çalışmasını sağlamak üzere diğer firmalar ile rekabet edecek yüksek maaş vermekten çok daha ucuz bir yoldur.

Eğer ekibinizde herbir iki veya üç programcı için bir test elemanı yoksa, hatalı ürünleri piyasaya sürüyorsunuzdur veya saat ücreti 30 USD olan test elemanları yerine saat ücreti 100 USD olan programcıları kullanarak paranızı boşa harcıyorsunuz demektir. Test personelinden tasarruf etmek çok berbat bir ekonomik hesaptır ve ne yazık ki giderek daha fazla kişinin bunu farketmiyor olması beni çok şaşırtıyor.

Bu konu üzerine yazdığım, Test elemanına sahip olmamanızın en önemli beş (yanlış) nedeni isimli makalemi okuyun.

Size sihirli numaralar göstermeden bir sihirbazı işe alırmısınız? Tabi ki hayır.

Düğün partisi için yiyeceklerini tatmadan bir yemek firması tutar mısınız? Çok az bir olasılık. (Sözkonusu olan Macide teyze ise, onun meşhur kekinden yapmasına izin vermediğiniz için sizden ömür boyu nefret edebilir).

Ancak, birçok yerde, programcılar etkileyici resume’leri görüşmeyi yapanlar tarafından çok beğenildiği için işe alınmaktadır. Veya “CreateDialog() ile DialogBox() arasındaki fark nedir” gibi, dökümana bakılarak kolayca yanıtlanabilecek saçma sorular sorulmaktadır. Programcının programlama üzerine yüzlerce saçmalığı aklında tutmasının bir önemi yoktur, önemli olan nasıl kod yazdığıdır. Çok daha kötüsü ise  “AHA” tipi sorulardır: bu tip sorular yanıtı bilindiğinde çok basit ancak yanıtı bilmiyorsanız bulunması imkansız sorulardır.

Lütfen bütün bunları yapmaktan vazgeçin. Görüşme süresince ne istiyorsanız yapın, fakat adayın bir miktar kod yazmasını sağlayın. Daha fazla öneri için Görüşme için gerilla taktikleri başlıklı yazımı okuyun.

Koridor kullanım testi, koridordan geçen ilk kişiyi yakalayıp yazmış olduğunuz kodu kullanmasını sağlamaktır. Bu işlemi beş kişide denerseniz, kodunuzun kullanım problemleri hakkında %95’e varan oranda bilgiye sahip olursunuz.

İyi arayüz tasarımı tahmin edildiği kadar zor değildir ve müşterinizin ürününüzü sevmesi ve satın alması açısından çok büyük önem taşır. Programcılar için kısa bir giriş olan, Arayüz tasarımı üzerine ücretsiz online kitabımı okuyabilirsiniz.

Arayüzlerle ilgili en önemli konu, programınızı bir miktar kullanıcıya (aslında beş veya altı kişi yeterlidir) gösterdiğinizde çabucak insanların zorlandıkları yeri farkedersiniz. Bunun nedeni için Jakob Nielsen’in makalesini okuyun. Arayüz tasarım becerileriniz yeterli olmasa dahi, kendinizi hiçbir maliyeti olmayan Koridor kullanım testini yapmaya zorlarsanız, programınızın arayüzü çok daha iyi hale gelir.

1.      Yazılım firmanızın seviyesini ölçün ve bana bildirin. Ben de dedikodusunu yapayım.

2.      Programlama ekibinin yöneticisi iseniz, bu kontrol listesini kullanarak ekibinizin mümkün olduğu kadar iyi çalıştığından emin olun. 12 puan almaya başladığınızda programcılarınızı kendi haline bırakın ve tüm zamanınızı pazarlama elemanlarının onları rahatsız etmesine engel olmaya adayın.

3.      Bir programlama işini almak konusunda karar aşamasında iseniz, müstakbel yöneticinize bu testin sonucunun ne olduğunu sorun. Eğer çok düşük ise, işleri düzeltmek için yetkiniz olduğundan emin olun. Aksi halde hayal kırıklığına uğrarsınız ve verimsiz çalışırsınız.

4.      Eğer bir programlama ekibinin değerini ölçmek üzere yerinde inceleme yapan bir yatırımcı iseniz veya yazılım firmanız bir diğer firma ile ortaklık yapacak ise, bu test sizin pratik tahminler yapabilmenizi sağlar.