“İyi bir programcı vasat olandan 10 kat daha verimli olabilir” [kapalı]

İyi bir programcının röportajını okudum (İngilizce değil) ve “iyi bir programcının vasat bir tanesinin 10 katı kadar iyi olabileceğini” ve iyi bir programcının neden çok iyi para kazandığını ve neden iyi olduğunu belirttiğini söyledi. programlama şirketleri, çalışanları için birçok olanak sağlar. Buradaki fikir, yukarıdaki sebeplerden ötürü, iyi programcılar için çok büyük bir talep olduğu ve bu yüzden şirketlerin onları getirmek için çok para verdikleri idi.

Bu ifadeye katılıyor musunuz? Destekleyebilecek nesnel gerçekleri biliyor musunuz?

Düzenleme: Sorunun deneyim ile ilgisi yok; 1 yıllık tecrübesi olan harika bir programcı hakkında konuşursanız, 1 yıllık tecrübesi olan vasat bir programcıdan 10 kat daha üretken olmalıdır. Yıllar sonra belirli deneyimlerden sonra, her şeyin dağılmaya başladığını kabul ediyorum, ancak sorunun amacı bu değil.

Steve McConnell tarafından yazılan iki makalede, verimlilik farklarıyla ilgili araştırmalara genel bir bakış ve analiz sunulmaktadır :

• Yazılım Geliştiriciler ve Ekipler Arası Verimlilik Değişimleri: "10x" in Kökeni

• 10X'in Kökenleri - Temel Araştırma Ne Kadar Geçerli?

İlk makale ( Verimlilik varyasyonları ... )

... Bireysel programlama verimliliğinde büyük farklılıklar tespit eden orijinal çalışma 1960'ların sonunda Sackman, Erikson ve Grant (1968) tarafından yapılmıştır. Ortalama 7 yıllık deneyime sahip profesyonel programcılar üzerinde çalıştılar ve ilk kodlama süresinin en iyi ve en kötü programlayıcılar arasındaki oranının yaklaşık 20 ile 1 arasında olduğunu; 25 ila 1 üzerindeki hata ayıklama sürelerinin oranı; program büyüklüğü 5 ila 1; ve program yürütme hızı 10 ila 1 arasındadır. Bir programcının deneyim miktarı ile kod kalitesi ya da üretkenliği arasında bir ilişki bulamadılar.

Sackman, Erickson ve Grant'in bulgularının detaylı incelemesi metodolojisindeki bazı kusurları göstermektedir ... Ancak, kusurları hesaba kattıktan sonra bile, verileri hala en iyi programcılar ve en kötü programlar arasında 10 kattan fazla bir fark göstermektedir.

Orijinal çalışmadan bu yana geçen yıllar içerisinde, “Programcılar arasında büyüklük sırası farklılıkları var” genel bulgusu, profesyonel programcıların diğer birçok çalışması ile doğrulanmıştır (Curtis 1981, Mills 1983, DeMarco ve Lister 1985, Curtis ve diğ. 1986). , Kart 1987, Boehm ve Papaccio 1988, Valett ve McGarry 1989, Boehm ve diğerleri 2000) ...

^{Bu makalede ayrıca ilginç bir not var:}

^{Bu değişim derecesi, yazılıma özgü değildir. Norm Augustine tarafından yapılan bir araştırma, yazarlık, futbol, ​​icat, polis çalışmaları ve diğer meslekler gibi çeşitli mesleklerde, halkın ilk yüzde 20'sinin çıktının dokunuşlar ve patentler olup olmadığının çıktısının yüzde 50'sini ürettiğini buldu. , çözülmüş davalar veya yazılım (Ağustos 1979).}

İkinci makale ( ... Altındaki Araştırma Ne Kadar Geçerli? ) Esas olarak Laurent Bossavit’in birincisinin eleştirel incelemesini ele almak için yazılmıştır :

• Fransızca'da orijinal eleştirisi: Folklor, bilimsel birliği bozuyor, yorumu les différencier
• Türkçe çeviri: Yazılım mühendisliğinde gerçek ve folklor .

İkinci makalede, “10x” Destekleyen Araştırmaya Daha Derin Bir Dalış bölümünde, McConnell, ilk makalede kullanılan referansları daha ayrıntılı olarak gözden geçirmekte ve sonuçlandırmaktadır:

... Bu alıntıyı bir kez daha yazarken, bu alıntıları bir kez daha incelerken, programcılar arasında 10 kat verimlilik farkı olduğunu bulmayı genel olarak desteklediklerini belirttim. Çalışmalar toplu olarak bir dizi programlama etkinliği boyunca yüzlerce profesyonel programcının katılımını sağlamıştır.

... 10x iddiasını destekleyen bir araştırma topluluğu, yazılım mühendisliğinde yapılan herhangi bir araştırma kadar sağlam. 10x iddiasını destekleyen çalışmalar, Şekil 1'de açıklanan metodolojik sınırlamaya tabi değildir, çünkü bireysel değişkenliği kendisi araştırmaktadır (örneğin, şeklin yalnızca sol tarafı). Bossavit, 10x iddiasını geçersiz kılan bir kusurlu ya da başka bir çalışmayı bile belirtmiyor ve ben de böyle bir çalışma görmedim. Hiçbir çalışmanın 10x iddiasına aykırı bulgular üretmemiş olması, 10x iddiasına daha fazla güven vermektedir. Yapılmış olan çalışmaların sayısını düşündüğümde, toplamda araştırmanın yalnızca düşündürücü değil, aynı zamanda sonuçlandırılmış olduğunu düşünüyorum - ki bu da yazılım mühendisliği araştırmalarında nadirdir.

Tamlık adına, Verimlilik varyasyonlarında kullanılan referansların listesi ... ayrıca aşağıda verilmiştir:

Referanslar

Augustine, NR 1979. "Augustine Yasaları ve Başlıca Sistem Geliştirme Programları." Savunma Sistemleri Yönetimi Dergisi: 50-76.

Boehm, Barry W. ve Philip N. Papaccio. 1988. "Yazılım Maliyetlerini Anlamak ve Kontrol Etmek." Yazılım Mühendisliğinde IEEE İşlemleri SE-14, no. 10 (Ekim): 1462-77.

Boehm, Barry ve diğerleri, 2000. Cocomo II, Boston, Mass ile Yazılım Maliyet Tahmini: Addison Wesley, 2000.

Boehm, Barry W., TE Gray ve T. Seewaldt. 1984. "Prototipleme ve Belirleme: Bir Çok Amaçlı Deney." Yazılım Mühendisliğinde IEEE İşlemleri SE-10, no. 3 (Mayıs): 290-303. Ayrıca Jones 1986b'de.

Kart, David N. 1987. "Bir Yazılım Teknoloji Değerlendirme Programı." Bilgi ve Yazılım Teknolojisi 29, no. 6 (Temmuz / Ağustos): 291-300.

Curtis, Bill. 1981. "Önemli Programcı Değişkenliği." IEEE 69'un bildirileri, no. 7: 846.

Curtis, Bill ve diğ. 1986. "Yazılım Psikolojisi: Disiplinlerarası Bir Program Gerekliliği." IEEE 74'ün bildirileri, no. 8: 1092-1106.

DeMarco, Tom ve Timothy Lister. 1985. "Programcı Performansı ve İşyerinin Etkileri." 8. Uluslararası Yazılım Mühendisliği Konferansı Bildirileri. Washington, DC: IEEE Bilgisayar Topluluğu Basını, 268-72.

DeMarco, Tom ve Timothy Lister, 1999. Peopleware: Üretken Projeler ve Ekipler, 2d Ed. New York: Dorset Evi, 1999.

Mills, Harlan D. 1983. Yazılım Verimliliği. Boston, Kütle: Küçük, Kahverengi.

Sackman, H., WJ Erikson ve EE Grant. 1968. "Çevrimiçi ve Çevrimdışı Programlama Performansını Karşılaştıran Keşifsel Deneysel Çalışmalar." ACM'nin iletişimi 11, no. 1 (Ocak): 3-11

Valett, J. ve FE McGarry. 1989. "Yazılım Mühendisliği Laboratuvarı'ndaki Yazılım Ölçüm Deneyimlerinin Özeti." Sistem ve Yazılım Dergisi 9, no. 2 (Şubat): 137-48.

Weinberg, Gerald M. ve Edward L. Schulman. 1974. "Bilgisayar Programcılığının Amaçları ve Performansı." İnsan Faktörleri 16, no. 1 (Şubat): 70-77.

Gerçekten korkunç bir programcı sıfırın altında bir üretkenliğe sahip olabilir (ortaya çıkardıkları hataların düzeltilmesi daha uzun zaman alır, sadece tüm işlerini onlar için yapmaları gerekir).

Gerçekten harika bir programcı, ne kadar zaman verdiğinizden bağımsız olarak, zayıf ve ortalama programcıların asla başaramayacağı şeyleri yapabilir .

Bu nedenle, bu nedenlerden dolayı "10x üretken" veya "100x üretken" hakkında konuşmak zor.

Ancak hatırlanması gereken, çoğu programcının işvereninin, ortalama programcıların yönetemediği zor işleri yapmalarına gerek kalmamasıdır. Yazılan kodların çoğu web siteleri, iş uygulamaları dizileri, intranet uygulamaları vb., Çoğu zaman o kadar da zor değil. Bu ortamdaki üretken programcı, akıllıca kod yazabilen değil, kullanıcıların ihtiyaçlarını anlama ve uygulama konusunda en iyisi olanıdır.

Aslında, programcıların çoğu işverenleri, iyi olanlardan ziyade iyi bir programcıyla daha iyi durumda olacaklardı, çünkü büyük olan sadece sıkılacak ve ayrılacak. Programcılar ve iş arasında iyi bir eşleşme bulmalıyız.

Yazılım Mühendisliği durumlarının Gerçekleri ve Yanılgıları (Gerçek 2, amazon önizlemesinde bulunabilir):

"Bireysel farklılıklar" araştırmasına göre, en iyi programcılar en kötü programcılardan 28 kata kadar daha iyidir. Ücretlerinin asla orantılı olmadığı göz önüne alındığında, yazılım alanındaki en büyük pazarlıklardır.

(araştırma için oradaki kaynaklar listesine bakın)

Elbette, programcı olmayan (ya da çok kötü bir programcı) verimliliğini iyi olanla (deneyim ve bilgi açısından) karşılaştırırsanız, fark sonsuz büyük olabilir ( n/0 == infinityherhangi bir pozitif için n), ancak bu adil değil ne de mantıklı bir karşılaştırma.

Maaşınız birden fazla faktöre bağlı olabilir (rastgele sırayla):

• Kullanılan teknolojiler
• Çalıştığınız ülke / eyalet
• Şirketin serveti
• Şirketin iş türü
• Şirketteki geliştiricilerin sayısı
• Ne kadar süredir şirkette çalışıyorsunuz?
• Ofis kuralları

kişisel ile birlikte ...

• verimlilik
• bilgi ve tecrübe
• şirketin işine katılım (yeni başlayanlar için)
• müzakere becerileri
• cinsel çekiciliği ve becerileri, lol (iyi, zeka seksi)

Cevabım "evet, ama bu metriği nasıl kullandığına dikkat et".

Diyelim ki, en iyi şekilde çalışan bir işlevsellik, işlevsellik için yaratan ve daha düşük performansa sahip olanlardan daha az hataya neden olan bir programcıdır. Bu insanların 10X'te başkalarının üretkenliğini yapabildiğine inanmak zor değil, özellikle de bir saat içinde yapılan tek bir iyi veya kötü seçimin 10 saatlik bir etki yapabileceğini ve programcıların böyle bir seçim yapabileceğini düşündüğünüzde çoğu gün.

Fakat...

Bunu ölçerken dikkatli olmalısın. Üretkenlikle ilgili çoğu ölçüme güvenmiyorum, çünkü neredeyse her bilinen metriğin takım üretkenliği için hayati önem taşıyan bir şey olarak değerlendiremediği sonsuz durumlar gördüm. Bu yüzden genellikle "üretkenlik" için bu kadar zor sayılardan nefret ederim. İşte bazı örnekler:

• Kod satırları (LOC) - genellikle nefretli bir metriktir, çünkü düşüncesiz bir programcı birçok korkunç, ayrıntılı, verimsiz, zor satır kodları hata ayıklayabilirken, iyi bir programcı birkaç, zarif, düzeltmesi kolay, nadiren kırılan kod satırları oluşturur. daha fazla zamanda, ancak genel olarak daha iyi bir seçimdir.
• Üretilen hatalar ve / veya çözme zamanı - herkes bir miktar böcek üretecek ve çoğu zaman en pahalı böcekler, konunun üretecinin yalnızca domino etkisinde sonuncusu olduğu bir dizi kötü kararla üretilir. Ayrıca, büyük hata ayıklayıcılarınız her zaman büyük tasarımcılarınız değildir - ikisine de ihtiyacınız vardır.
• Neredeyse tüm ölçütlere göre, bir ekip için bu kadar acı çeken büyük geliştiriciler var, 1 "süper üretken" geliştirici 10 temelde iyi geliştiriciyi uzaklaştıracak ve nadiren her şeyi iyi yapabilecek birini görüyorum , bu yüzden ihtiyacımız olacak Projede 1'den fazla kişi.
• Sorunları ciddiye almadan önce gelen sorunları gören ve özellikle sorun bir süreçte bir boşluk olduğunda - hatalı CM, verimsiz yapı, testte bir boşluk, bir güvenlik açığı olduğunda - kolaylıkla bu harika insanları hesaba katmanın yolu yok sizi felaketten kurtardıklarını fark edene kadar genellikle büyük bir zaman kaybı gibi görünüyorsunuz - bunu ölçmenin bir yolu yok.
• Ayrıca, "uygunluk geliştiricileri" olarak adlandırdığım belirli bir büyüklükte bir ekipte gerekli gördüğüm insanlar var - nadiren üretkenlik mutlakı, genellikle% 20'nin en üstünde yer alıyorlar ve rampanın üstesinden gelmek için çok değerli bir iş yapıyorlar yeni insanlar, noktaları birbirine bağlar ve doğru soruların sorulmasını ve doğru kişilerin döngüde kalmasını sağlar; herkesin ifade ettiği belgelerin anahtar parçasını yazarlar (çünkü doğru değil!) doğru şekilde bir araya getirilir. Eğer 10 kişinin en yüksek verimlilikle çalışmasını istiyorsanız, kesinlikle bu insanlardan birine ihtiyacınız var ve 10 süper geliştiriciyi bir odaya koyarsanız, elde edemezsiniz.

Birçok ölçüm sistemi bu faktörleri göz önünde bulundurmaya çalıştı, ancak henüz tüm bu hususları hesaba katan bir tane olduğunu görmedim, bu yüzden "iyi bir geliştiriciden 10 kat daha verimli olan" gibi faktörlerden asla fazla etkilenmedim. vasat bir "" çünkü metriğin, devam eden başarılı bir ürüne mi yoksa başarılı ve başarılı bir takıma girmesi gereken tüm işi gerçekten hesaba kattığını merak ediyorum.

Öyleyse benim büyük uyarım - bu ölçümle ne yapacaksın? Doğru araçların ve yeteneklerin işlerin nasıl yapıldığına büyük bir fark yaratabileceğinin farkında olmak için bunun gibi bir şey kullanacağım. bir hayal kırıklığı vakası. Daha iyisi, ekibinizin daha önce birlikte çalışarak daha önce yaptıklarını 2-3X yapmak için bir yol bulmaktır.

Laurent Bossavit , Yazılım Mühendisliğinin Leprikonları adlı kitabında , 10x verimlilik iddiasını araştırıyor. Arkasında sağlam sayılar olmadığını keşfetti - iddia, atıfta art arda daha somut iddialar içeren bir telefon oyunu tarafından yapılan spekülasyondan "yerleşik gerçeğe" geçti . 10x iddia bölümünden oluşan ve ilgili alıntıları ve yanlış alıntıları içeren blog yazısı, yazılım mühendisliğinde gerçek ve folklordur .

Bulduğu şey şunun gibi: 1968'de biri, insanları belirli bir hata ayıklama problemini çözen karşılaştıran bir çalışma yaptı ve bazılarının bunu diğerlerinden 10 kat daha hızlı yaptığını buldu. Bundan, bazı insanların bu problemi çözmede 10 kat daha iyi olduğu sonucuna varabiliriz veya bazı insanların şanslı olduğu veya çok çeşitli farklı şeyler olduğu sonucuna varabiliriz . Bazı insanlar bunu (“hepsi paraphraslardır)” olarak seçmeyi seçti. Sonra “çalışmalar iyi programcıların ortalamanın 10 katından daha iyi olduğunu gösterdi” ve “son olarak” programcı verimliliğinin bireyler arasında 10 kat değiştiği yaygın bir bilgidir ”oldu. Sonra birisi bütün bu alıntıları toplar , bir orijinal kaynağı yanlış yönlendirir "birçok araştırmacı inanıyor ..." demek için.

Tabii ki, sadece iddianın doğruluğu değiştiyse, telefon oyunu olmazdı: çarpan da 11 yaşına kadar gider .

“ Bu ortamdaki üretken programcı, en akıllı kodu yazabilen değil, kullanıcıların ihtiyaçlarını anlama ve uygulama konusunda en iyisi olanıdır ” ( Carson63000 yanıtından)

Bu kilit nokta bethlakshmi ile birleşti'nin noktaları büyük bir noktaya değindi. Harika bir geliştirici, bir gerçeklik diliminde harika olabilir, ancak dünya değiştikçe parçalanabilir. İşletmenin ihtiyaçlarına ayak uydurabilmek her şeyden çok daha önemlidir. Günün sonunda, eğer işletmeniz teknoloji değilse, işletme teknolojiyi önemsemez; çözümlere ihtiyaçları var. Bu nedenle, tasarım desenleriyle mükemmel olmak, web sayfasında göstermesi gereken veri dökümü ihtiyacı duyan son kullanıcılar için kesinlikle sakat kalmaz. Vasat geliştiricilerin, kendilerini destekleyen işlere hitap ederek kendilerini geliştiren işlerini güvence altına aldıklarını gördüm. Kuruluşunuza ve projelerinize bağlı olarak, bu açlığa meydan okuyan geliştiricileri beslemek mümkündür, ancak büyük olasılıkla, henüz yapmadığınız bir nokta olacaktır. Bu miktarda işlem gücüne ihtiyaç duymaz. Bu geliştiriciler sadece bir işlemci gibi boşta oturmaktan hoşlanmıyor. Kapanacak ve başka bir yerde yeniden başlayacaklar.

Son olarak, "anahtar" performansçılarınızın kim olduğunu bilmenin sorun olmadığını söyleyebilirim, ancak bir gelişim "takımı" hala bir takım. Bethlakshmi'yi tekrarlamak için, " bu metrikle ne yapacaksın?“Takım gibi davranan bir takıma ihtiyacın olursa, bunlar gibi ölçütlere odaklanmam. En küçük oyuncuların bile hala takımın önemli bir parçası olduğunun farkındayım. Anahtarınızın verimliliğinin% 60'ında bile Bir oyuncunun ekibine ihtiyacı olan bir şey verebileceğini söyleyebilecek oyuncu, ne olduğunu bulup çoğaltmaya çalışın.Tekeri yönetmesi gerektiğini düşünerek kilit oyuncunuzu yakmayın, çıktısını da arttırmanın yollarını bulun. Diğer oyuncuları bu büyüklükle kirleterek… Bu, sadece sayılar için değil, biraz da yaratıcılık gerektirir… Sonunda, iyi bir programcı yapan şeyin o programcı bile olmadığını, meslektaşları, işyerindeki fırsatları olduğunu öğrenebilirsiniz. ya da sen bile olabilirsin.