कोड की -2,000 लाइनें

• 1982 की शुरुआत में Lisa software टीम 6 महीने के अंदर रिलीज़ करने के दबाव में, हर engineer द्वारा लिखी गई साप्ताहिक कोड लाइनों की संख्या से प्रगति मापने की कोशिश कर रही थी
• Bill Atkinson का मानना था कि लाइनों की संख्या productivity को सही तरह नहीं दिखाती, और यह छोटे व तेज़ program बनाने के लक्ष्य के भी खिलाफ है
• QuickDraw के region calculation engine को अधिक सरल और सामान्य algorithm से फिर से लिखने पर, region operations लगभग 6 गुना तेज़ हो गए और code करीब 2,000 लाइन कम हो गया
• पहले management form में, उस सप्ताह लिखी गई code lines पूछने वाले field में Bill ने -2000 लिखा, जिससे measurement तरीके की खामी साफ़ उजागर हुई
• कुछ हफ्तों बाद managers ने Bill से वह form मांगना बंद कर दिया, और यह किस्सा दिखाता है कि code lines आधारित management असली सुधारों को नज़रअंदाज़ कर सकता है

---

Lisa टीम का code lines measurement

• 1982 की शुरुआत में Lisa software टीम अगले 6 महीनों के भीतर software रिलीज़ करने के लिए काम की रफ्तार बढ़ाना चाहती थी
• कुछ managers हर engineer द्वारा हर सप्ताह लिखी गई code lines की संख्या से progress track करना चाहते थे
• engineers को हर शुक्रवार submit करने के लिए एक form मिला, जिसमें उस सप्ताह लिखी गई code lines दर्ज करने का field था

Bill Atkinson का -2000

• QuickDraw के creator और प्रमुख user interface designer Bill Atkinson, Lisa implementation में अहम भूमिका निभा रहे थे
• Bill का मानना था कि code lines metric productivity को सही तरह नहीं मापता
  • वे सोचते थे कि अच्छे software का लक्ष्य संभव हो तो छोटे और तेज़ programs लिखना है
  • lines बढ़ाने वाला metric ढीला-ढाला, फूला हुआ और टूटने वाला code लिखने को बढ़ावा दे सकता है
• उस समय वे QuickDraw के region calculation engine को optimize कर रहे थे
  • उन्होंने region engine को अधिक सरल और सामान्य algorithm से पूरी तरह फिर से लिखा
  • बदलाव के बाद region operations लगभग 6 गुना तेज़ हो गए
  • साथ ही code करीब 2,000 लाइन कम हो गया
• पहला management form भरते समय, code lines वाले field को कुछ देर देखने के बाद उन्होंने -2000 लिखा
• managers ने कैसे react किया, यह पक्का नहीं है, लेकिन कुछ हफ्तों बाद से Bill से form submit करने को नहीं कहा गया

[GN⁺]

Hacker News की राय

• Microsoft और IBM के बीच कोड की लाइनों की टक्कर वाला मामला याद आता है
  Bob Cringely की Accidental Empires पर आधारित PBS TV सीरीज़ में एक दृश्य है, जहां Steve Ballmer IBM के साथ OS/2 को मिलकर develop करने के अनुभव के बारे में बताते हैं
  Microsoft का रवैया छोटी कंपनी की तरह काम खत्म करने वाला था, जबकि IBM internal metrics, खासकर programmer productivity को KLoC (हज़ार लाइनों में कोड की पंक्तियां) से मापने पर केंद्रित था
  Ballmer ने कहा था, “उन्हें बस KLoC, KLoC, और फिर KLoC की ही पड़ी थी”, और लगता है IBM को इस बात से ज़्यादा फर्क पड़ता था कि कोड अच्छा है या नहीं, उससे अधिक कि मात्रा कितनी है
  https://ubiquity.acm.org/article.cfm?id=1022357

  • सिर्फ IBM ही ऐसा नहीं था। कुछ साल पहले मैं एक बड़े project पर काम कर रहा था, जहां एक बड़ी international consulting company मुख्य contractor थी; codebase 10 लाख लाइनों से ऊपर गया तो पूरी team के लिए party रखी गई
    जो लोग असल स्थिति समझते थे, उन्होंने उस “celebration” को अंतिम संस्कार जैसा माना
  • यहां जिस TV सीरीज़ की बात हो रही है वह Triumph of the Nerds है, और आज भी शानदार है। शायद आज और भी देखने लायक हो

• कोड की लाइनों को productivity metric के रूप में गिनना वाकई बेवकूफी है
  मैंने एक 20 साल पुराने, हल न हो सकने वाले bug को कोड की एक लाइन से ठीक किया था, और याद है कि 3 साल पुराना bug एक order by से सुलझ गया था। कोड की एक लाइन का असर कैसे मापा जा सकता है? मेरे अनुभव में खराब programmers कहीं ज़्यादा कोड लिखते हैं
  यह कहानी[1] भी भूलना मुश्किल है कि Microsoft के एक developer ने IBM के 33 हज़ार characters वाले code को फिर से लिखकर 220 characters में घटा दिया। कहा जाता है कि नतीजतन Microsoft का workload “negative” हो गया और युद्ध छिड़ गया
  [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up पेज 101

  • Productivity metrics का इस्तेमाल करना ही आम तौर पर बेवकूफी है, और यह developers को अच्छे काम की बजाय metric optimization करने पर मजबूर करने का आसान तरीका है
    आजकल का एक उदाहरण “impact” है, यानी कुछ companies में promotion का आधार नए product launch को बनाना। इससे ऐसे failed products की भरमार होना आसान है जिन्हें कोई maintain नहीं करता
  • ऐसे engineers ज़रूर होंगे जो कुछ महीनों में एक बार critical bug ठीक करके लाखों dollars की value बना देते हैं, लेकिन सामान्य तौर पर बेहतरीन engineers का output ज़्यादा होता है, और जिन engineers का output कम होता है, वे अक्सर उतने बेहतरीन नहीं होते
  • लंबी अवधि में देखें तो code lines और engineering output के बीच कुछ हद तक संबंध है, ऐसा मुझे लगता है
    महान computer scientists और engineers में ऐसे लोग रहे हैं जिन्होंने भारी मात्रा में code output दिया, और मेरा मानना है कि वह किसी न किसी तरीके से सीधे impact में बदलता है। समस्या तब शुरू होती है जब code lines performance measurement metric बन जाती हैं
    उस समय Goodhart का नियम लागू होता है: “जिस क्षण कोई measurement target बन जाता है, वह अच्छा measurement नहीं रह जाता”
  • उदाहरणों से जैसा दिखता है, code lines खराब productivity metric होने का एक कारण यह है कि वे codebase maintainers पर पड़ने वाले बोझ के आकार को काफी अच्छी तरह दिखाती हैं
    Productivity metric के नजरिए से code को asset माना जाता है, लेकिन वास्तविकता के ज्यादा करीब नजरिया यह है कि feature asset है और code खुद debt है

• यह विषय अक्सर उठता रहता है। पिछली discussions ये हैं
  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)

• करियर की शुरुआत में विरासत में मिले 10 हज़ार लाइनों से बड़े C program को optimize करके 500 lines से कम कर दिया था। यह Sybase database में SQL calls करने वाला C program था
  इसकी वजह कोई महान insight नहीं थी, बल्कि बस यह साधारण assumption था कि शायद मेरे predecessor को functions इस्तेमाल करना नहीं आता था, या SQL queries में variable data डालने के लिए parameters का इस्तेमाल करना नहीं आता था। सच में, वही SQL statements बस कुछ values बदलकर हर बार inline लिखे हुए थे
  मैंने SQL call code को function calls के रूप में फिर से लिखा, और bind variables को function parameters के रूप में pass कराया। दोहराए गए inline code की जगह array से बदलने वाली bind values लेकर loop के अंदर function call करने का तरीका लगा दिया गया

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

• सबसे बड़ा असर कभी-कभी सरल सवाल पूछने से आता है, जैसे “X को कैसे handle करेंगे?”, जिससे कोई चीज़ बनाई ही नहीं जाती
  अगर उस चीज़ को सही से काम करने का मौका भी नहीं मिलता, तो उसे बनाने की कोशिश की पूरी लागत बच गई
  ऐसी चीज़ों को numeric metrics से मापना असंभव ही नहीं, बल्कि इससे दुश्मन भी बनते हैं। फिर भी जो लोग हिम्मत करके ऐसा करते हैं, उन्हें सलाम

  • इसलिए नए लोगों को सिखाता हूँ कि दिमाग में ऐसा loop रखें, और सीधे keyboard पर तेज़ी से टाइप करना शुरू न कर दें
    जो लोग programming को तेज़ typing जैसा मानते हैं, वे LLMs से दिलचस्प समानता दिखाते हैं। वे poorly used code सारा लिखते हैं, फिर मिटाते हैं, फिर दोबारा लिखते हैं और फिर मिटाते हैं
  • एक बड़ी कंपनी में software manage करते समय मेरी desk पर pencil box रखा रहता था
    department में आने वाली information requests में से लगभग आधी हमेशा ऐसी होती थीं कि “बहुत ज़रूरी है, अभी चाहिए, और इससे बहुत पैसा कमाया या बचाया जा सकता है”, लेकिन साफ़ जवाब था: “जो information आपके पास पहले से है उससे calculate करिए। calculator और spreadsheet तो हैं ही। pencil दूँ?”
    system से X handle करवाने से बेहतर है उससे बचना। एक-दो बार इस्तेमाल होने वाले special cases system को फुला देते हैं, और किसी को पता नहीं होता कि ऐसे special cases या programs मौजूद भी हैं या वे असल में करते क्या हैं। documentation अच्छी हो तब भी लोग यह सीखने में समय नहीं लगाते कि क्या-क्या संभव है। इसलिए ऐसी special features में से ज़्यादातर असल में समय की बर्बादी बन जाती हैं

• इसके matching thought experiment के तौर पर उलटी स्थिति सोच सकते हैं। अगर कोई manager यह लेख पढ़कर सरलता से deleted code lines की संख्या से मापने का फैसला करे, तो चीज़ें बेहतर होंगी या बदतर?

  • कंपनी और measurement method पर निर्भर करते हुए इसे और आसानी से game किया जा सकता है। llama से plausible code बनवाइए, थोड़ा code जोड़कर commit कर दीजिए ताकि कोई वास्तविक असर न हो, और बाद में उसे delete कर दीजिए
    इस तरह की measurement, कुल मिलाकर, तब तक लगभग बेकार है जब तक मजबूत code review practices न हों। यहाँ लोग जो मानना चाहते हैं उसके उलट, ऐसी practices दुर्लभ हैं। लेकिन अगर अच्छी review हो, तो low performance या metric gaming भी पकड़ में आ जाएगा, इसलिए शुरुआत में ही ऐसे metrics लाने की वजह कम हो जाती है
  • थोड़ा ज़्यादा खराब होगा, लेकिन शायद उतना विनाशकारी नहीं जितना लगता है। क्योंकि industry में उसी दिशा की short-sighted impulse पहले से ही कुछ वैसी ही मौजूद है
    उदाहरण के लिए, software engineers और मुश्किल code text को पूरी तरह हटाकर, product managers से special diagrams या flowcharts बनवाकर “low-code” या “no-code” outputs तैयार करवाने से replace करने का पुराना विचार है
  • line-count based metrics सब संदिग्ध हैं, लेकिन ΔSLOC शायद उनमें कम खराब है
    added lines और deleted lines को अलग-अलग गिनकर +50,-150 patch को 200 ΔSLOC माना जाएगा
    यह productivity मापने का अच्छा पैमाना नहीं है, खासकर अकेले तो बिल्कुल नहीं। फिर भी change volume का rough napkin-math metric मानें तो यह reasonable है। high ΔSLOC वाला developer, 1–2 हफ्तों तक बिल्कुल ΔSLOC न रखने वाले colleague से ज़्यादा productive है या नहीं, यह इस पर निर्भर करता है कि वह colleague क्या कर रहा है, लेकिन measurement period में पहला व्यक्ति codebase को ज़्यादा बदल रहा है, यह पक्का है
  • चीज़ें और खराब होंगी। पूरे codebase को code golf का target बनाना desirable नहीं है
  • नई features तो निश्चित रूप से नहीं होंगी
    अगर product “complete” हो चुका है, तो यह उतना ही अच्छा या बेहतर भी हो सकता है। नहीं तो negative code-line changes deploy तक नहीं पहुँचेंगे
    लेकिन ज़्यादातर products लगातार evolve होते रहते हैं। इसलिए हम एक ही project में सालों तक रह पाते हैं, और सिर्फ delete करने वाला contribution अंततः कुछ जोड़ता ही नहीं

• असली बात यह है कि project शुरू करते समय कभी-कभी ठीक-ठीक पता नहीं होता कि जाना कहाँ है
  आगे बढ़ते हुए आप समस्या और desired answer को कहीं बेहतर समझते हैं, और तब बड़े हिस्सों को हटाकर उनकी जगह कुछ छोटा और बेहतर ला सकते हैं
  और यह भी नहीं भूलना चाहिए कि इन लोगों को -2000 lines of code, वह भी assembly code सहित, सब कुछ 64KB ROM में fit करना था। छोटा बनाने का दबाव बहुत ज़्यादा था

  • QuickDraw ज़्यादातर Pascal में लिखा गया था, और सिर्फ critical loops assembly में थे[1,2]
    यह भी पक्का नहीं है कि वह सच में ROM में था या boot floppy में। साथ ही, Wikipedia के अनुसार Lisa का ROM 16KB था
    [1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
    [2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/

• यह Bill Atkinson हैं, जो Atkinson Dither के लिए मशहूर हैं। https://beyondloom.com/blog/dither.html

  • Bill Atkinson ने QuickDraw, MacPaint और HyperCard बनाए; QuickDraw वह graphics library थी जो Lisa और Mac UI की बुनियाद बनी।
    इस प्रक्रिया में उन्हें लगातार user interface के काम करने के नए तरीके, और उन्हें हल करने के लिए software लिखने के तरीके ईजाद करने पड़े। उन्होंने इसे एक साथ “Mac hardware पर तेज़ चलने योग्य” और “बेहतरीन user experience देने वाला” बनाने के लिए optimize किया, और उस synergy ने पुराने black-and-white Mac की पूरी aesthetics पर उनकी छाप छोड़ दी। वह dithering style भी algorithmic प्रतिभा और सौंदर्यबोध के मेल का एक और उदाहरण है।
    यह समझ “marching ants” selection border (https://en.wikipedia.org/wiki/Marching_ants) जैसी चीज़ों में भी दिखती है। classic Mac UI में बहुत-सा feedback pixel inversion के रूप में दिखाया जाता था। जैसे text selection, menu highlight, mouse button दबाए रखने के दौरान button का दिखना, window drag करते समय boundary line वगैरह; और XOR mode में ऊपर से draw करना ऐसे effects बनाने का बहुत अच्छा तरीका था।
    QuickDraw में इन tools को जिस तरह जोड़ा गया, उससे Steve Jobs के साथ हुई मशहूर rounded rectangles वाली बातचीत (https://www.folklore.org/Round_Rects_Are_Everywhere.html) का नतीजा यह हुआ कि QuickDraw में rectangles जितनी आसानी से rounded rectangles भी draw किए जा सके, और operating system में हर जगह rounded rectangles दिखने लगे।
    Mac UI की सफलता सिर्फ इसलिए नहीं थी कि वह देखने में अच्छा था। बड़ी वजह यह थी कि Bill Atkinson ने ऐसे चतुर, छोटे tools का सेट बनाया था जिनसे अच्छी दिखने वाली चीज़ें बनाना आसान हो गया।
    Susan Kare के शानदार icons भी शायद इतनी आत्मीयता से याद न किए जाते, अगर Bill ने 32x32 pixel mask bitmap को UI में आसानी से डालने और click पर invert करने वाले tools न बनाए होते।

• सीख यह है कि Einstein जितने भी होशियार हों, आखिरकार वे employee ही हैं, और employee के तौर पर जो काम करना चाहिए वह करना पड़ता है।

  • अगर Einstein पर metrics का दबाव रहा होता, तो शायद हमने उनका नाम कभी सुना ही नहीं होता।

• जब लोग लिखी गई code lines की बात करते हैं, तो वे हमेशा “जोड़ी गई lines - हटाई गई lines” के रूप में ही क्यों गिनते हैं, यह मुझे कभी समझ नहीं आया।
  अगर मैं 10km run करके starting point पर वापस आ गया, तो इसका मतलब यह नहीं कि मैंने 0km दौड़ा।

  • इसका एक कारण यह भी हो सकता है कि बेवकूफ diff tools functionality में सीमित बदलाव होने पर भी lines को इधर-उधर move करने को बड़े difference के रूप में record कर लेते हैं।
    उदाहरण के लिए if cond { ... return; } ... वाले रूप को if cond { ... return; } else { .... } में बदलना।
    फिर भी यह explanation पूरी बात को cover नहीं करता।