Eksi 2.000 Satır Kod

• 1982’nin başlarında Lisa yazılım ekibi, 6 ay içinde piyasaya çıkarma baskısı altındayken ilerlemeyi mühendis başına haftalık kod satırı sayısıyla ölçmeye çalıştı
• Bill Atkinson, satır sayısının üretkenliği doğru göstermediğini ve küçük, hızlı programlar üretme hedefiyle de çeliştiğini düşünüyordu
• QuickDraw’un bölge hesaplama motorunu daha basit ve genel bir algoritmayla yeniden yazınca, bölge işlemleri neredeyse 6 kat hızlandı ve kod yaklaşık 2.000 satır azaldı
• İlk yönetim formunda o hafta yazılan kod satırı sayısını soran alana Bill -2000 yazdı; böylece ölçüm yönteminin açığını olduğu gibi ortaya koydu
• Birkaç hafta sonra yöneticiler Bill’den artık bu formu istemedi; bu hikâye, kod satırı sayısına dayalı yönetimin gerçek iyileştirmeleri gözden kaçırabileceğini gösteriyor

---

Lisa ekibinde kod satırı sayısı ölçümü

• 1982’nin başlarında Lisa yazılım ekibi, yazılımı sonraki 6 ay içinde piyasaya çıkarmak için çalışma hızını artırmaya çalışıyordu
• Bazı yöneticiler, ilerlemeyi her mühendisin her hafta yazdığı kod satırı sayısıyla takip etmek istedi
• Mühendislere her cuma teslim etmeleri için bir form verildi; formda o hafta yazdıkları kod satırı sayısını yazacakları bir alan vardı

Bill Atkinson’ın -2000u

• QuickDraw’un yazarı ve başlıca kullanıcı arayüzü tasarımcılarından Bill Atkinson, Lisa uygulamasında önemli bir rol üstleniyordu
• Bill, kod satırı sayısı metriğinin üretkenliği doğru ölçmediğini düşünüyordu
  • İyi yazılımın hedefinin mümkün olduğunca küçük ve hızlı programlar yazmak olduğuna inanıyordu
  • Satır sayısını artırmaya odaklanan bir metrik, özensiz, şişkin ve bozuk kod yazmayı teşvik edebilirdi
• O sırada QuickDraw’un bölge hesaplama motorunu optimize ediyordu
  • Bölge motorunu daha basit ve genel bir algoritmayla tamamen yeniden yazdı
  • Düzenlemeden sonra bölge işlemleri neredeyse 6 kat hızlandı
  • Aynı zamanda kod yaklaşık 2.000 satır azaldı
• İlk yönetim formunu doldururken kod satırı sayısı alanına bir an baktıktan sonra -2000 yazdı
• Yöneticilerin nasıl tepki verdiği kesin bilinmiyor, ancak birkaç hafta sonra Bill’den artık form teslim etmesi istenmemeye başlandı

[GN⁺]

Hacker News yorumları

• Microsoft ile IBM arasındaki kod satırı sayısı çatışması örneği aklıma geliyor
  Bob Cringely’nin Accidental Empires’ına dayanan PBS TV dizisinde Steve Ballmer’ın, IBM ile OS/2’yi birlikte geliştirirken yaşadıklarını anlattığı bir sahne var
  Microsoft işi küçük bir şirket gibi bitirme tavrındaydı; IBM ise iç metriklere, özellikle de programcı üretkenliğini KLoC (bin satır kod) ile ölçmeye odaklanıyordu deniyor
  Ballmer “Onların umursadığı tek şey KLoC, KLoC ve yine KLoC’tu” demişti; IBM de kodun iyi olup olmadığından çok miktarının fazla olup olmadığına bakıyordu gibi görünüyor
  https://ubiquity.acm.org/article.cfm?id=1022357

  • Bunu yapan yalnızca IBM değildi. Birkaç yıl önce ana yüklenicisi büyük bir uluslararası danışmanlık şirketi olan büyük bir projede çalıştım; kod tabanı 1 milyon satırı geçince tüm ekip için parti verdiler
    Durumu bilenler bu “kutlamayı” cenaze töreni gibi karşıladı
  • Burada bahsedilen TV dizisi Triumph of the Nerds; bugün izleseniz de harika. Hatta belki şimdi izlemeye daha da değer olabilir

• Kod satırı sayısını üretkenlik metriği olarak kullanmak gerçekten aptalca
  20 yıllık çözülemeyen bir hatayı tek satır kodla düzelttiğim oldu; 3 yıllık bir hatayı da tek bir order by ile çözdüğümü hatırlıyorum. Bir satır kodun etkisini nasıl ölçebilirsiniz? Deneyimlerime göre kötü programcılar çok daha fazla kod yazar
  Bir Microsoft geliştiricisinin 33 bin karakterlik IBM kodunu yeniden yazıp 220 karaktere indirdiği hikâyeyi[1] de unutamıyorum. Bunun sonucunda Microsoft’un iş miktarı “eksi”ye düşmüş ve savaş çıkmış deniyor
  [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up s. 101

  • Üretkenlik metriği kullanmanın kendisi çoğu zaman aptalcadır ve geliştiricileri iyi iş yapmaktan çok metrik optimizasyonu yapmaya itmenin kolay bir yoludur
    Günümüzden bir örnek olarak, terfi ölçütü olarak “etkiyi”, yani yeni ürün çıkarmayı alan şirketler var. Bu da kimsenin bakımını yapmadığı başarısız ürünlerin yığılmasına çok elverişli
  • Birkaç ayda bir kritik bir hatayı düzeltip milyonlarca dolar değer yaratan mühendisler elbette vardır; ama genel olarak iyi mühendislerin çıktısı fazladır, çıktısı az olan mühendisler de çoğu zaman iyi değildir
  • Uzun vadede kod satırı sayısı ile mühendislik çıktısı arasında bir ölçüde ilişki olduğunu düşünüyorum
    Büyük bilgisayar bilimcileri ve mühendisler arasında muazzam kod çıktısı ortaya koymuş kişiler var; bunun bir şekilde doğrudan etkiye dönüştüğüne inanıyorum. Sorun, kod satırı sayısının performans ölçütüne dönüştüğü an başlıyor
    O noktada Goodhart yasası, yani “bir ölçüt hedef haline geldiğinde iyi bir ölçüt olmaktan çıkar” devreye giriyor
  • Örneğin de gösterdiği gibi, kod satırı sayısının kötü bir üretkenlik metriği olmasının nedenlerinden biri, kod tabanının bakımını üstlenenlerin sırtındaki yükün büyüklüğünü oldukça iyi yansıtmasıdır
    Üretkenlik metriği açısından kod bir varlık olarak sınıflandırılır; ama gerçeğe daha yakın bakış, özelliğin varlık, kodun kendisinin ise borç olduğu yönündedir

• Bu konu sık sık gündeme geliyor. Önceki tartışmalar şöyle
  https://news.ycombinator.com/item?id=33483165 (2022)
  https://news.ycombinator.com/item?id=26387179 (2021)
  https://news.ycombinator.com/item?id=10734815 (2015)
  https://news.ycombinator.com/item?id=7516671 (2014)
  https://news.ycombinator.com/item?id=4040082 (2012)
  https://news.ycombinator.com/item?id=1114223 (2010)
  https://news.ycombinator.com/item?id=1545452 (2010)

• Kariyerimin başlarında devraldığım 10 bin satırdan uzun bir C programını 500 satırın altına optimize etmiştim. Sybase veritabanına SQL çağrıları yapan bir C programıydı
  Büyük bir içgörüden değil; önceki kişinin fonksiyon kullanmayı ya da SQL sorgularına değişken veri koymak için parametre kullanmayı bilmemiş olabileceği gibi basit bir varsayımdan yola çıktım. Gerçekten de aynı SQL ifadeleri, yalnızca birkaç değer değiştirilerek her seferinde satır içine yazılmıştı
  SQL çağrı kodunu fonksiyon çağrıları olarak yeniden yazdım ve bind değişkenlerini fonksiyon parametresi olarak geçirttim. Tekrarlanan satır içi kod, değişen bind değerlerini bir diziden alıp döngü içinde fonksiyonu çağıran bir yapıyla değiştirildi

  • https://www.folklore.org/Discovered_Loops.html?sort=date?sort=date

• En büyük etki bazen “X’i nasıl ele alacağız?” gibi basit bir soru sorup bir şeyin hiç yapılmamasını sağlamaktan gelir.
  O şeyin düzgün çalışma şansı bile olmayacaktıysa, onu yapmaya çalışmanın tüm maliyetinden tasarruf etmiş olursunuz.
  Böyle şeyleri sayısal metriklerle ölçmek imkânsız olmakla kalmaz, düşman edinmenize de yol açar. Yine de bunu yapmaya cesaret edenleri alkışlıyorum.

  • Bu yüzden yeni gelenlere kafalarında böyle bir döngü bulundurmalarını ve işe klavyeye hızlı hızlı basarak başlamamalarını öğretiyorum.
    Programlamayı hızlı yazı yazmaya benzetenler, LLM’lerle ilginç bir paralellik gösteriyor: İyi yazılmamış kodun tamamını yazıp siliyor, sonra yeniden yazıp yeniden siliyorlar.
  • Büyük bir şirkette yazılım yönetirken masamın üzerinde bir kalem kutusu tutardım.
    Bölüme gelen bilgi taleplerinin yaklaşık yarısı hep “çok önemli, hemen şimdi gerekiyor ve çok para kazandırabilir ya da tasarruf ettirebilir” türündendi; oysa bariz cevap şuydu: “Elinizdeki bilgilerle hesaplayın. Hesap makineniz ve elektronik tablonuz var. Kalem ister misiniz?”
    Sistemin X’i işlemesini sağlamaktansa bundan kaçınmak daha iyidir. Bir ya da iki kez kullanılıp kullanılmayacağı bile belli olmayan özel durumlar sistemi şişirir; kimse de böyle özel durumların ya da programların var olup olmadığını, gerçekten ne yaptığını bilmez. Dokümantasyon iyi olsa bile insanlar nelerin mümkün olduğunu öğrenmeye zaman ayırmaz. Bu yüzden bu özel işlevlerin çoğu pratikte zaman kaybına dönüşür.

• Buna karşılık gelen bir düşünce deneyi olarak ters durumu düşünebiliriz. Bir yönetici bu yazıyı okuyup basitçe silinen kod satırı sayısı ile ölçmeye karar verirse işler daha iyiye mi gider, daha kötüye mi?

  • Şirkete ve ölçüm biçimine bağlı olarak çok daha kolay manipüle edilebilir. llama’ya makul görünen kod ürettirir, gerçek bir etkisi olmayacak şekilde biraz kod ekleyip commit eder, sonra da daha sonra silersiniz.
    Bu tür ölçümler, genel olarak sağlam kod inceleme uygulamaları yoksa neredeyse işe yaramaz. Buradaki insanların inanmak istediğinin aksine, bu tür uygulamalar nadirdir. Ama iyi bir inceleme varsa düşük performans ya da metrik manipülasyonu da yakalanacağından, zaten böyle bir metriği devreye alma gerekçesi azalır.
  • Biraz daha kötü olurdu, ama düşünüldüğü kadar felaket olmayabilir. Çünkü sektörde zaten bu yönde benzer bir dar görüşlü dürtü var.
    Örneğin yazılım mühendislerini ve anlaşılması güç kod metinlerini tamamen ortadan kaldırıp, ürün yöneticilerinin özel diyagramlar ya da akış şemaları çizerek “low-code” veya “no-code” çıktılar üretmesiyle değiştirme yönünde eski bir fikir var.
  • Satır sayısına dayalı metriklerin hepsinden şüphe etmek gerekir, ama ΔSLOC muhtemelen bunların arasında daha az kötü olanıdır.
    Eklenen ve silinen satırları ayrı ayrı sayıp +50,-150 yamasını 200 ΔSLOC olarak hesaplardım.
    Bu, üretkenliği ölçmek için iyi bir ölçek değildir; özellikle tek başına hiç değildir. Yine de değişiklik miktarını kabaca hesaplamak için peçete hesabı düzeyinde makul bir metriktir. ΔSLOC’u yüksek bir geliştiricinin, 1–2 hafta boyunca hiç ΔSLOC’u olmayan bir iş arkadaşından daha üretken olup olmadığı, o iş arkadaşının ne yaptığına bağlıdır; ama ölçüm süresi boyunca ilkinin kod tabanını daha fazla değiştirdiği kesindir.
  • Daha kötü olur. Tüm kod tabanını code golf nesnesine çevirmek iyi bir fikir değil.
  • Yeni özellik kesinlikle olmaz.
    Ürün “tamamlanmışsa” aynı ya da daha iyi olabilir. Aksi halde negatif kod satırı değişiklikleri dağıtıma kadar ulaşamaz.
    Ama çoğu ürün sürekli evrilir. Bu yüzden aynı projede yıllarca kalabiliriz; yalnızca silmeye dayalı katkılar ise sonunda hiçbir şey eklememeye başlar.

• Asıl mesele, bir projeye başlarken tam olarak nereye gidildiğinin bazen bilinmemesidir.
  İlerledikçe problemi ve istenen cevabı çok daha iyi anlarsınız; o zaman büyük parçaları söküp daha küçük ve daha iyi olanlarla değiştirebilirsiniz.
  Ayrıca bu insanların -2000 satır kodu, üstelik assembly kodu da dahil olmak üzere her şeyi 64KB ROM içine sığdırmak zorunda olduğunu unutmamak gerekir. Daha küçük hale getirme baskısı çok güçlüydü.

  • QuickDraw’ın büyük kısmı Pascal ile yazılmıştı; yalnızca kritik döngüler assembly idi[1,2].
    Gerçekten ROM’da mıydı yoksa önyükleme disketinde mi, bundan da emin değilim. Ayrıca Wikipedia’ya göre Lisa’nın ROM’u 16KB idi.
    [1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
    [2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/

• Atkinson Dither ile tanınan Bill Atkinson. https://beyondloom.com/blog/dither.html

  • Bill Atkinson, Lisa ve Mac UI’sinin temelini oluşturan grafik kütüphanesi QuickDraw’ı, MacPaint’i ve HyperCard’ı yaptı.
    Bu süreçte kullanıcı arayüzünün çalışmasına dair yeni yolları ve bunları çözmek için yazılım yazma biçimlerini sürekli icat etmek zorunda kaldı. Hem “Mac donanımında hızlı çalışabilecek” hem de “harika bir kullanıcı deneyimi sunacak” şekilde aynı anda optimize etti; bu sinerji, eski siyah-beyaz Mac estetiğinin geneline onun izini bıraktı. O dithering stili de algoritmik deha ile estetik duyarlılığın birleştiği bir başka örnekti.
    Bu duyarlılık, “marching ants” seçim kenarlığı (https://en.wikipedia.org/wiki/Marching_ants) gibi şeylerde de görülür. Klasik Mac UI’sindeki pek çok geri bildirimin piksel tersine çevirmeyle ifade edilmesi de aynı şekildeydi. Metin seçimi, menü vurgusu, fare düğmesi basılıyken düğmenin görünme biçimi, bir pencere sürüklenirken görünen sınır çizgileri gibi; XOR modunda üstüne çizmek bu tür efektleri üretmek için çok iyi bir yöntemdi.
    QuickDraw’da bu araçların bir araya getiriliş biçimi, Steve Jobs’la yapılan meşhur yuvarlatılmış dikdörtgen konuşmasının (https://www.folklore.org/Round_Rects_Are_Everywhere.html) gerçekten de QuickDraw’da yuvarlatılmış dikdörtgenleri normal dikdörtgenler kadar kolay çizebilir hâle getirmesiyle sonuçlandı ve işletim sisteminin her yerinde yuvarlatılmış dikdörtgenlerin görünmesini sağladı.
    Mac UI’sinin başarısı yalnızca güzel görünmesinden ibaret değildi. Büyük ölçüde Bill Atkinson’ın güzel görünen şeyleri yapmayı kolaylaştıran akıllı ve küçük bir araç seti oluşturmasından kaynaklanıyordu.
    Susan Kare’in harika ikonları da Bill, 32x32 piksel maske bitmap’lerini UI’ye kolayca koymayı ve tıklandıklarında ters çevirmeyi sağlayan araçlar yapmamış olsaydı, muhtemelen bu kadar sevgiyle hatırlanmazdı.

• Çıkarılacak ders şu: Einstein kadar zeki olsan bile sonuçta bir çalışansın ve çalışan olarak yapman gereken işi yapmalısın.

  • Einstein metrik baskısı altında kalsaydı, bugün onun adını duymamış olabilirdik.

• İnsanların yazılan kod satırı sayısından bahsederken neden bunu hep “eklenen satır - silinen satır” diye hesapladığını hiç anlamadım.
  Ben 10 km koşup başlangıç noktasına döndüm diye 0 km koşmuş olmuyorum.

  • Bunun bir nedeni de aptal diff araçlarının, işlevsel değişiklik sınırlı olsa bile satırların oradan oraya taşınmasını büyük bir fark olarak kaydedebilmesi olabilir.
    Örneğin if cond { ... return; } ... biçimindeki bir yapıyı if cond { ... return; } else { .... } biçimine çevirmek gibi.
    Yine de bu açıklama her şeyi kapsamıyor.