-2000 लाइनों का कोड

• 1982 में Apple की Lisa software team ने software रिलीज़ के लिए हर developer की साप्ताहिक code line count ट्रैक करने की नीति लागू की
• Bill Atkinson का मानना था कि code lines की संख्या software productivity का गलत मापदंड है
• उन्होंने QuickDraw के region calculation engine को पूरी तरह फिर से लिखा, जिससे लगभग 2,000 लाइनों का code कम हुआ और performance 6 गुना बेहतर हुई
• Atkinson ने code count रिपोर्ट करने वाले management form में -2000 लिखा
• अंततः managers ने Bill से वह form भरने के लिए फिर कभी नहीं कहा

---

1982 की Lisa software team और code line tracking policy

• 1982 की शुरुआत में, Lisa software team ने अगले 6 महीनों के भीतर software रिलीज़ करने के लक्ष्य के साथ काम तेज़ किया
• कुछ managers ने सोचा कि हर engineer द्वारा हर हफ़्ते लिखी गई code lines को ट्रैक करना प्रगति में मदद करेगा
• इसके लिए हर शुक्रवार engineers द्वारा लिखी गई code lines की संख्या दर्ज करके जमा करने वाला एक form शुरू किया गया

Bill Atkinson की productivity metrics पर राय

• QuickDraw और user interface को डिज़ाइन करने वाले Bill Atkinson का मानना था कि code line count software productivity का सही पैमाना नहीं हो सकता
• उन्होंने ज़ोर दिया कि लक्ष्य program को जितना हो सके उतना छोटा और तेज़ बनाना होना चाहिए
• उनका मानना था कि code line measurement उल्टा अव्यवस्थित और अक्षम code को बढ़ावा दे सकता है

QuickDraw region engine का refactoring और optimization

• Atkinson ने हाल ही में QuickDraw के region calculation engine को एक अधिक सरल और सामान्य algorithm के साथ पूरी तरह फिर से लिखा
• optimization के नतीजे में region operations की speed 6 गुना तक बढ़ गई
• इस प्रक्रिया में 2,000 लाइनों के बराबर code भी स्वाभाविक रूप से कम हो गया

-2000 lines code report और managers की प्रतिक्रिया

• पहले हफ़्ते management form भरते समय, Atkinson ने code lines वाले खाने में -2000 लिख दिया
• managers ने इस संख्या पर कैसी प्रतिक्रिया दी, यह स्पष्ट नहीं है
• कुछ हफ़्तों बाद Bill से कहा गया कि अब उन्हें वह form जमा करने की ज़रूरत नहीं है, और उन्होंने इसे खुशी-खुशी स्वीकार किया

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे जो सबसे बेहतरीन commit याद है, वह लगभग 60,000 lines of code हटाने और उस पूरे “server” को, जो सारी state memory में रखता था, करीब 5,000 lines की हल्की logic से बदल देने का अनुभव है

  • मुझे यह एक algorithmic उपलब्धि लगती है, क्योंकि यह code इतना हल्का था कि इसे दूसरी services में आसानी से integrate किया जा सकता था और इसे memory state की भी ज़रूरत नहीं थी
  • मैंने पता लगाया कि किसी विशेष tree पर guided subgraph isomorphism problem को हल किया जा सकता है, और इसी वजह से एक सामान्य directed multigraph को एक बार traverse करते हुए, शुरुआती root से path को केवल छोटे stack में track करके output graph (tree) बनाया जा सकता था
  • “-60,000 lines commit” सचमुच भुलाया नहीं जा सकने वाला पल था, और उसके बाद से इतना algorithmically प्रभावशाली काम फिर कभी नहीं कर पाया — यह थोड़ा खलता है
    • मैं काम के माहौल में बहुत scripting करता हूँ और खुद को programming के कुछ हिस्सों में अच्छा मानने वाला hobby programmer हूँ, लेकिन ऐसी बातें सुनकर हर बार फिर महसूस होता है कि एक बहुत बड़ी दुनिया है जिसे मैं नहीं जानता, और पूरी ज़िंदगी सीखते रहो तब भी कम है
    • मैं और context सुनना चाहता हूँ। state रखने वाले program को stateless में बदलने की तकनीक जादू जैसी लगती है, इसलिए इसे ज़रूर सीखना चाहता हूँ
    • मेरी पृष्ठभूमि graph theory और algorithms में है और मैं mathematician हूँ, इसलिए जिज्ञासा है कि क्या मेरी skills इस तरह के real-world काम में लागू हो सकती हैं। क्या आप थोड़ा और विस्तार से साझा कर सकते हैं?
    • मुझे नहीं लगता कि target graph का tree होना इतना महत्वपूर्ण है। असली point शायद "guided" हिस्सा है, जो single traversal को संभव बनाता है
      • मान लेते हैं कि मूल graph में किसी खास node से शुरुआत की गई है, और अगर isomorphism मौजूद है तो target tree का root भी उसी node से मेल खाना चाहिए
      • समस्या को ऐसे समझा जा सकता है कि मूल graph को target tree के pattern के अनुसार traverse किया जाए; mismatch मिले तो false, सब match हो जाएँ तो true। इससे यह अनुमान निकलता है कि चाहे tree न भी हो, अगर starting point साफ़-साफ़ तय हो तो यह तरीका किसी भी subgraph पर लागू हो सकता है
    • मज़ाक में कहा गया कि शायद आजकल के “binary tree को invert करो” जैसे coding interview सवालों के असली जनक इसी तरह के programmer होंगे
      • graph theory में रुचि है, लेकिन terminology कठिन लगती है — इसलिए एक सामान्य developer के लिए आसान व्याख्या माँगी गई

• कॉलेज के दिनों में मैंने ऐसी company के लिए काम किया था जिसकी management policy यह थी कि freshers भी अच्छा code लिख सकते हैं, और आख़िरकार वे इसे गलत साबित करने वाले case बन गए

  • code में bug fix करने के बाद भी वही bug बार-बार आता रहा, तो जाँच करने पर पता चला कि वे मौजूदा function में parameter जोड़ने के बजाय उसकी copy बनाकर उसमें थोड़ा-थोड़ा बदलाव करते थे। नतीजा यह हुआ कि मैंने codebase का 3/4 से ज़्यादा हिस्सा, यानी हज़ारों lines का Turbo Pascal, हटा दिया
  • project का customer Energy department था, और यह nuclear material inventory manage करने वाला program था, इसलिए कई रातें नींद उड़ गई थी
    • मौजूदा code को copy करने का एक “फ़ायदा” व्यंग्य में बताया गया: इससे पुराने code की stability भी नहीं टूटती और manager के ‘contribution’ metrics भी पूरे हो जाते हैं। revert भी आसान — बस copy delete कर दो
    • हमारी team में भी एक सहकर्मी अक्सर ऐसा code duplication करता है; मेरा मानना है कि यह जल्दी result देने की आदत है, खासकर urgent requests या ऊँची आवाज़ में माँग करने वालों के लिए। असली समस्या यह है कि shared function refactoring और पर्याप्त testing में समय लगाना कोई नहीं चाहता
    • पहले जिन contractors के साथ मैंने काम किया, उनमें भी यही आदत थी। जब मैंने कहा कि इससे confusion हो सकता है, तो उनका जवाब था, “ऐसे समय Ctrl+F इस्तेमाल कर लीजिए”
    • किसी ने पूछा कि क्या यह मामला Blacksburg क्षेत्र का था
    • मेरा अनुभव भी ऐसा ही रहा। मैं एक ऐसी company में काम करता था जो Southeast Asia के कई देशों में लगभग एक जैसे portals चलाती थी। हर portal का source अलग Git repository में रखा गया था, और हर common feature या bug fix को source code की कई copies में हाथ से backport करना पड़ता था
      • मैंने पूछा, “क्या सबको एक ही repository में रखकर feature flags से portal-specific customization नहीं किया जा सकता?” लेकिन इसे नामुमकिन कहकर मना कर दिया गया
      • आख़िरकार दो-तीन महीनों में मैंने 4–5 portals के code को एक repository में मिला दिया, feature flags और framework upgrade लागू किए, और deployment भी smoothly पूरा हुआ। अब सभी portals में एक साथ bug fixes हो सकते थे, इसलिए दोहराए जाने वाले manual काम की पीड़ा से मुक्ति मिली

• संबंधित विषय पर, “-2000 lines of code” से जुड़ी लोकप्रिय Hacker News threads को लिंक की तरह संकलित किया गया है

  • यह कहा गया कि समय-समय पर पुराने महान posts का repost होना नए और पुराने दोनों तरह के users के लिए उपयोगी परंपरा है
    • मैं ऐसा सरल इंसान हूँ कि “-2k lines of code” दिखते ही अपने आप vote कर देता हूँ
      • productivity को एक ही axis वाले metric से manage करना चाहने वाले clients को मैं अक्सर Atkinson का उदाहरण सुनाता हूँ। असली productivity metric utility पर आधारित होना चाहिए, और अगर कोई सच में इसे quantify कर पाए तो वह Nobel economics prize का दावेदार हो सकता है

• जिस web UI project पर मैं काम कर रहा था, उसमें backend को छोड़कर 250,000 lines of code थीं

  • पिछला developer स्मार्ट था, लेकिन JS में नया था, और सारी state DOM के custom attributes में store करता था, साथ ही addEventListener हर जगह भरे हुए थे। मैं मज़ाक में कहता था, “अगर किसी साधु को JavaScript की एक किताब और 10 साल की एकांत कैद दे दो, तो शायद ऐसा code निकले”
  • कई महीनों तक web components में structure बदलते हुए मैंने 50,000 lines हटा दीं, फिर full rewrite शुरू की। अभी functionality का लगभग 80% ही वापस आया है, लेकिन पूरा codebase अब केवल 17,000 lines के आसपास है (Vue/pinia जैसी libraries को छोड़कर)
  • जल्द ही 200,000 से ज़्यादा lines delete हो जाएँगी, और शायद इससे बड़ा अनुभव मुझे फिर कभी नहीं मिलेगा — अब तो रिटायर होने का मन करता है
    • मेरा भी ऐसा ही अनुभव रहा। मूल लेखक लगभग junior स्तर का था, लेकिन company का founder था और productivity के मामले में बहुत तेज़। team work या दूसरों के code के साथ collaborate करने का अनुभव न होने से, कल्पना की जा सकने वाली हर code smell उस structure में घुस गई थी
      • एक function में हज़ारों lines, switch/case/if/else/ternary operator की 10 परतें, SQL statements के साथ JS/HTML/JS-inserted HTML का मिश्रण, और automated tests बिल्कुल नहीं — PHP/Dojo दौर के frontend की यही कहानी थी
    • किसी ने pointed out किया कि “सिर्फ 80% functionality वाले हल्के code” का वर्णन ही इस तुलना की कमज़ोरी दिखाता है। अगर पूरी functionality का केवल हिस्सा implement हुआ है, तो स्वाभाविक है कि उतनी lines की ज़रूरत नहीं पड़ेगी

• Dilbert comic में infinite reward structure का एक चित्र है, जहाँ Dilbert का boss कहता है कि हर bug fix पर पैसे मिलेंगे, तो Wally बोलता है, “आज तो मैं भी एक minivan भर code लिखूँगा!”

  • इस तरह की स्थिति को “Perverse incentive(विकृत प्रोत्साहन)” कहा जाता है, और संदर्भ लिंक दिया गया
  • मेरे manager ने भी यह comic ( छवि ) break room की दीवार पर लगा रखी थी
  • किसी ने व्यावहारिक जिज्ञासा से पूछा: ‘minivan’ का मतलब क्या है?

• dotnet/runtime repository में 64,000 lines delete करने का एक वास्तविक उदाहरण साझा किया गया

  • built-in C# + WinRT interop support को source generation tool से replace किया गया; यह एक ऐसा structural बदलाव था जिसमें एक बार में निर्णायक switch करना ज़रूरी था। PR लिंक देखें

• जब भी मैं LLM से developer productivity बहुत बढ़ जाने वाले आँकड़े देखता हूँ, मुझे यह पुरानी कहानी याद आ जाती है

  • जवाब में किसी ने कहा कि AI code delete करने में भी काफ़ी अच्छा है, और Cursor से जुड़ा यह मज़ेदार community उदाहरण साझा किया, जहाँ “AI ने सब delete कर दिया”
  • आजकल “हमारे नए code का X% AI लिखता है!” industry का पसंदीदा catchphrase बन गया है
  • अगर नए nuclear power plant के निर्माण और maintenance cost भी जोड़ दी जाए, तो developer productivity के ये आँकड़े कितने अवास्तविक रूप से बढ़ा-चढ़ाकर पेश किए गए हैं, यह व्यंग्य में कहा गया

• मैं CS का छात्र नहीं था; मैं काम करते-करते सीखी गई practical knowledge के आधार पर काम करता हूँ

  • हमारा project live objects को इंसानों के लिए पढ़ने लायक रूप में reconstruct करने का था
    • final representation में कई बहुत जटिल types चाहिए होते थे, जबकि शुरुआती representation अपेक्षाकृत सरल थी
    • जब मिलते-जुलते data nodes होते थे, तो readability बेहतर बनाने के लिए उन्हें compare करके merge करना पड़ता था — यानी methods निकालना और parameters पहचानना जैसा काम
      • शुरुआती दिनों में हम पहले final types में convert करते थे और फिर compare करते थे, जिससे type combinations विस्फोटक रूप से बढ़ गए और system लगभग असंभव रूप से जटिल हो गया; कई सालों तक engineers structure को समझ ही नहीं पाए
    • बाद में hashmap-आधारित approach का पता चला, जिसमें एक जैसे skeleton वाले nodes को hash values से पहचानकर compare और merge किया जाता था, और उसके बाद final types में convert किया जाता था — यानी दो-स्तरीय structure
    • type-status के बजाय data-centered abstraction अपनाने से अजीब class hierarchies भी simple properties के रूप में आसानी से manage होने लगीं
    • संक्षेप में कहूँ तो यह एक बेवकूफ़ाना multi-stage decompiler structure था, लेकिन processing speed और readability दोनों में बड़ा सुधार हुआ। हर स्थिति के लिए कोई silver bullet नहीं होती, लेकिन हमारे लिए ‘types’ ही मुख्य समस्या थे, और यह तरीका बहुत मददगार साबित हुआ

• साल के अंत की performance review से पहले मैंने company के monolithic repository में अपने आँकड़े देखे और पाया कि net code के हिसाब से मैं negative contributor बन चुका हूँ

  • API code और types की autogenerated files हटाना, पुराने API versions हटाना आदि इसके कारण थे, लेकिन रोज़ दफ़्तर आकर सिर्फ code delete करने वाला आदमी होने का एहसास अजीब तरह से सुखद था

• बहुत पहले एक बड़े project में मैंने यह भयावह KPI देखा था कि PL लोग हर developer के bugs की संख्या — किसने fix किए, किसने पैदा किए — offline हाथ से लिखकर दीवार पर चिपकाते थे

  • मैं related project में था इसलिए बच गया, लेकिन एक सहकर्मी ने Lars von Trier के उस किस्से से प्रेरणा ली, जिसमें उसने Danish flag के cross वाले हिस्से को काटकर लाल communist झंडे जैसा सिलकर लौटा दिया था और इस वजह से वह किसी नौकरशाही ‘authors list’ से बाहर कर दिया गया था। उसी तरह उसने अपनी bug count वाली पंक्ति काटकर फिर से चिपका दी और सार्वजनिक विरोध दर्ज किया। अगले ही दिन वह सूची हमेशा के लिए गायब हो गई — मेरी यादों में यह बहुत कीमती घटना है
    • मेरे सहकर्मी का सीधा-सादा जवाब था: “क्योंकि मैं इस list का हिस्सा नहीं बनना चाहता!” — और यही इस पूरी स्थिति का सबसे अच्छा सार है
    • किसी ने यह भी साझा किया कि झंडे और list को visualise करना थोड़ा कठिन है