-2000 लाइन्स ऑफ कोड (2007)
LOC एक KPI और Goodhart का नियम
- इस बात पर व्यापक सहमति है कि प्रदर्शन मापदंड के रूप में लाइन्स ऑफ कोड (LOC/KLoC) का उपयोग हानिकारक है: यह वर्बोसिटी, डुप्लिकेशन और जटिलता को पुरस्कृत करता है।
- इसे Goodhart के नियम के एक पाठ्यपुस्तक उदाहरण के रूप में देखा गया है: जैसे ही LOC एक लक्ष्य बनता है, डेवलपर बेहतर कोड के बजाय अधिक कोड के लिए अनुकूलन करने लगते हैं।
- कई लोग ध्यान दिलाते हैं कि LOC औपचारिक KPI न होने पर भी भ्रामक है; यदि मैनेजर परोक्ष रूप से “अधिक कोड” को महत्व देते हैं, तो यह फिर भी प्रोत्साहनों को प्रभावित करता है।
LOC वास्तव में क्या संकेत देता है (यदि कुछ भी)
- कुछ का तर्क है कि LOC और कमिट वॉल्यूम कई संकेतों में से एक कमजोर संकेत हो सकते हैं: महीनों तक बहुत कम, तुच्छ लगने वाले कमिट यह दिखा सकते हैं कि कोई व्यक्ति अटका हुआ है या कम प्रदर्शन कर रहा है।
- दूसरे इसका विरोध करते हैं कि हर महत्वपूर्ण मामला—कठिन बग, आर्किटेक्चरल काम, मेंटरिंग, अनावश्यक फीचर्स से बचना—उस संबंध को तोड़ देता है, इसलिए वर्क और परिणामों की सीधी समीक्षा के अलावा LOC कोई अनूठी उपयोगिता नहीं जोड़ता।
- ΔSLOC (जोड़ा गया + हटाया गया) को “परिवर्तन” का थोड़ा बेहतर प्रॉक्सी सुझाया गया है, लेकिन “उत्पादकता” के लिए यह अभी भी खराब है।
नकारात्मक LOC और कोड एक दायित्व के रूप में
- कई लोग बड़े पैमाने पर कोड हटाने या हजारों लाइनों को छोटे, स्पष्ट फ़ंक्शनों से बदलने को उच्च-मूल्य वाला काम मानकर सराहना करते हैं।
- कोड को बार-बार लागत या दायित्व कहा गया है; संपत्ति कार्यक्षमता है। सबसे अच्छा कोड अक्सर वह कोड है जो लिखा ही नहीं गया।
- कई किस्से: विशाल डुप्लिकेटेड ब्लॉकों को छोटे पुन: प्रयोज्य फ़ंक्शनों में समेटना; बड़े स्नैपशॉट टेस्ट या बोइलरप्लेट हटाना; लंबे समय से चले आ रहे बगों को छोटे बदलावों से ठीक करना।
प्रबंधन, प्रक्रिया, और संस्कृति
- ऐसे प्रबंधन की कड़ी आलोचना की गई है जो काम को समझने के बजाय आसान, सतही मेट्रिक्स (LOC, “impact launches”) पर निर्भर करता है।
- अच्छे प्रबंधन का वर्णन इस तरह किया गया है: तकनीकी रूप से सक्षम, कोड पढ़ने वाला, अवरोधों में मदद करने वाला, इंजीनियरों की रक्षा करने वाला, और उत्पादकता को बहु-आयामी रूप में देखने वाला।
- डेली स्टैंडअप्स पर बहस है: कुछ इन्हें समन्वय के लिए उपयोगी मानते हैं; दूसरे इन्हें “कार्गो-कल्ट” स्टेटस रिचुअल्स मानते हैं जिन्हें बेहतर सहयोग और कोड रिव्यू से बदला जाना चाहिए।
सत्ता, यूनियन, और कारीगर-सॉफ्टवेयर
- कहानी इस बात को उजागर करती है कि केवल उच्च-प्रतिष्ठा वाले लोग ही खराब मेट्रिक्स को खुलेआम नजरअंदाज कर सकते हैं; बाकी लोगों को दंड का जोखिम रहता है।
- प्रदर्शन मेट्रिक्स के प्रतिशोधात्मक उपयोग से सुरक्षा के लिए यूनियनों का प्रस्ताव किया गया है, हालांकि यूनियन की कमियों और राजनीति को स्वीकार किया गया है।
- कुछ लोग अफसोस जताते हैं कि बड़े कॉरपोरेट वातावरण ने “कारीगर” सॉफ्टवेयर शिल्प को दबा दिया है, जबकि अन्य कहते हैं कि यह अभी भी ओपन सोर्स और छोटे स्टार्टअप्स में फल-फूल रहा है।
AI और कोड की मात्रा
- प्रतिभागी LOC चर्चा को AI कोड जनरेशन से जोड़ते हैं: ऐसे टूल जो सस्ती कीमत पर मध्यम गुणवत्ता वाले कोड की भारी मात्रा पैदा करते हैं, “जितना अधिक कोड = उतना अधिक मूल्य” वाली भ्रांति को ठीक करने के बजाय और खराब कर सकते हैं।