पहले इसे कर लो, फिर इसे सही करो, फिर इसे बेहतर करो
इंजीनियर लोकप्रिय मंत्र “पहले इसे काम करने दो, फिर इसे सही करो, फिर इसे तेज़ करो” पर बहस करते हैं, rapid prototyping और MVPs को technical debt और architectural गलतियों की दीर्घकालिक लागतों के सामने तौलते हुए। कई लोगों का तर्क है कि performance, accessibility और maintainability पर इस slogan से कहीं पहले विचार किया जाना चाहिए, Electron-आधारित apps और “temporary” hacks के permanent बन जाने जैसे उदाहरण देते हुए। अन्य लोग जवाब देते हैं कि ज़्यादातर commercial settings में कुछ “good enough” को जल्दी ship करना तर्कसंगत है, क्योंकि कई products इतने लंबे समय तक टिकते ही नहीं कि full rewrite या गहरी optimization को उचित ठहराया जा सके।
मंत्र की व्याख्याएँ
- कई रूपांतर सुझाए गए हैं:
- “Make it work, make it right, make it fast.”
- “Make it possible → pleasant/probable → profitable/cheap.”
- “Make it run → make it right → make it fast (if needed).”
- “Make it work → work well → look good.”
- कई टिप्पणीकारों का तर्क है कि “right” और “fast” अक्सर एक-दूसरे से जुड़े होते हैं; core API और data-structure के चुनाव प्रदर्शन को कड़ा-लॉक कर सकते हैं, जिससे बाद में लगभग फिर से लिखना पड़ सकता है।
- अन्य लोग “fast” को एक अलग, बाद का चरण मानते हैं, जिसे एक साफ़, स्थिर API संभव बनाती है, जिससे आप व्यवहार बदले बिना implementations बदल सकते हैं।
सहीपन, प्रदर्शन, और architecture
- कई लोग पहले सहीपन पर जोर देते हैं: जो program तेज़ हो लेकिन गलत परिणाम दे, वह बेकार है।
- कुछ का कहना है कि performance की अधिकांश समस्याएँ local होती हैं (queries, functions) और re-architecture के बिना ठीक की जा सकती हैं।
- अन्य लोग ज़ोर देते हैं कि आधुनिक performance बहुत हद तक architectural होती है; अगर आप शुरू में efficiency के लिए design नहीं करते, तो बाद में “optimization” एक rewrite बन जाती है।
MVP, iteration, और “good enough”
- “launch fast, iterate fast” को मज़बूत समर्थन मिलता है: पहला संस्करण असली समस्या का पता लगाता है; बाद के passes उसे refine और optimize करते हैं।
- आलोचक ध्यान दिलाते हैं कि “prototype” या “temporary” code शायद ही कभी फेंका जाता है; business pressure और prioritization के कारण kludges स्थायी बन जाते हैं।
- कई लोग इस बात पर जोर देते हैं कि software business की ज़रूरतें पूरी करता है; अगर कुछ ग्राहकों और revenue के लिए “good enough” है, तो गहरे rewrites को उचित ठहराना कठिन है।
Electron और resource usage
- Electron को एक केंद्रीय case study के रूप में इस्तेमाल किया गया है:
- Pro-Electron पक्ष: विशाल dev-pool, cross-platform parity, और development की speed अक्सर RAM/CPU लागतों से ज़्यादा महत्वपूर्ण होती है; कंपनियाँ velocity और viability के लिए optimize करती हैं।
- Anti-Electron पक्ष: यह संसाधन-व्ययी है, hardware/energy लागतों को users पर डालता है, और खासकर हमेशा चलने वाले apps (chat, music) के लिए हानिकारक है।
- कुछ का तर्क है कि users के पास बेहतर विकल्प या समझ अक्सर नहीं होती, न कि यह कि उन्हें परवाह नहीं होती।
Process, refactoring, और risk
- कई लोग स्पष्ट cycles का समर्थन करते हैं: prototype, फिर “do it right,” फिर “do it better,” और कभी-कभी जानबूझकर “throw away the first draft” का नियम।
- अन्य लोग चेतावनी देते हैं कि refactor करने के लिए समय, authority, और culture के बिना steps 2 और 3 कभी नहीं होते।
- reversible vs irreversible decisions और “last responsible moment” जैसे concepts को इस बात का फैसला करने के लिए tools के रूप में बताया गया है कि “right” में कब निवेश करना है बनाम “just ship it.”