डिज़ाइन डॉक्यूमेंट्स की जगह Throwaway Code को तरजीह देने की वजह
(softwaredoug.com)- सॉफ्टवेयर डेवलपमेंट में डिज़ाइन डॉक्यूमेंट से सीधे साफ-सुथरे PR तक पहुँचना मुश्किल होता है, और असल coding के दौरान assumptions बदल जाती हैं, इसलिए फेंक देने वाले code के जरिए design explore करना ज्यादा तेज हो सकता है
- merge न किए जाने वाले draft PR में prototype या proof of concept बनाकर, शुरुआती दौर में review लेकर approach की दिशा align करने और फिर उसे design ideas के record के रूप में छोड़ने का flow सुझाया गया है
- इस तरीके की बुनियादी शर्त पहली solution को बेझिझक छोड़ पाने वाली organizational maturity है, और एक ही समस्या को 2–3 तरीकों से implement करके देखने का रवैया seniority का संकेत माना जाता है
- PR किसी खास समय पर implementation intent और discussion को समेटने वाला discoverable document बन सकता है, लेकिन design document अगर अक्सर update न हो तो reality से कटे हुए “undead documentation” में बदलने की संभावना रहती है
- design document अब भी कई stakeholders से feedback整理 करने, long-term North Star document बनाने, अभी code करना मुश्किल शुरुआती ideas के लिए, और उन organizations में जरूरी हैं जहाँ prototype के सीधे deploy हो जाने का जोखिम होता है
Throwaway PR के जरिए design explore करना
- ideal development flow कुछ ऐसा दिखता है: design document लिखना, छोटे PRs को क्रम से merge करके feature deploy करना, और Git history को साफ रखना
- हकीकत में अक्सर coding शुरू करने के बाद ही design document की assumptions डगमगाती हैं, और किस क्रम में release करना है, इसका दोबारा आकलन करना पड़ता है
- इसलिए पहले एक बड़ा code experiment बनाना और उसके result के आधार पर असल plan तैयार करना ज्यादा efficient हो सकता है
-
सुझाई गई प्रक्रिया
- merge करने का इरादा न रखते हुए draft PR के रूप में prototype या proof of concept implement करें
- बड़े refactoring या feature approach पर शुरुआती stage में दूसरों की नजर लेकर direction alignment हासिल करें
- draft PR के भीतर approach को document करके design idea का historical record छोड़ें
- जितनी जल्दी हो सके, पूरे draft PR को फेंक देने के लिए तैयार रहें
- draft PR से धीरे-धीरे असल deployable PRs निकालें, और लगभग एक हफ्ते में उन्हें साफ deploy-ready PRs में बाँटें
- हर PR को stages में बाँटते हुए tests और robustness की कमियों को क्रमिक रूप से भरें
-
इस तरीके के लिए टीम की शर्तें
- सबसे अहम शर्त अपने लिखे पहले coding idea को छोड़ पाने की maturity है
- एक ही समस्या को 2–3 तरीकों से code करके देखने में सहजता seniority का महत्वपूर्ण संकेत मानी जा सकती है
- value delivery production में गए code की lines की संख्या में नहीं, बल्कि organization को मिली knowledge में होती है
- critical हिस्सों पर शुरुआती alignment मिल जाए तो बाद की prototyping केवल waste बनकर नहीं रह जाती
- codebase के core parts को तेजी से जोड़ पाने लायक familiarity होनी चाहिए, और senior staff से ऐसी comfort level अपेक्षित होती है
- यह तरीका सिर्फ individual नहीं, team level पर भी अपनाया जा सकता है
PR documentation और design document की असल भूमिका
- PR developers के लिए उपयोगी documentation formats में से एक है
- किसी specific implementation को वैसा क्यों बनाया गया, यह समझने के लिए पहले देखी जाने वाली जगहों में से एक है
- यह current state को reflect करने का दावा नहीं करता, बल्कि किसी खास समय की state को समेटने वाले historical artifact के रूप में रहता है
- design document अगर अक्सर up-to-date न रखा जाए तो पुराने reality को reflect करने वाले undead documentation में बदलने की संभावना रहती है
- prototype “बताने से ज्यादा दिखाने” के लिए उपयुक्त होता है, और बदलाव लाते समय documents की तुलना में code ज्यादा effective हो सकता है
- लेकिन discipline के बिना चलने वाली organizations में prototype के “question” के बजाय “answer” के रूप में स्वीकार किए जाने का जोखिम होता है
- मूल intention “क्या हमें यह करना चाहिए, या कुछ और करना चाहिए?” के ज्यादा करीब होता है
- अगर organization इसे “हमें यही करना चाहिए” के रूप में ले ले, तो समस्या पैदा होती है
-
design document अब भी कब सही है
- कई stakeholders, managers और external teams के feedback को整理 और store करना हो, तब उपयोगी होता है
- सिर्फ GitHub से ऐसे collaboration को संभालना मुश्किल हो सकता है
- अगर idea बहुत conceptual और long-term है और उसे तुरंत code करना मुश्किल है, तो कुछ हद तक North Star document मददगार होता है
- जब लिखकर व्यक्त करना पहले code draft से ज्यादा efficient हो, या अभी codebase onboarding पर्याप्त न हो और feedback के लिए draft छोड़ना हो, तब उपयोगी है
- अगर company पहली solution को छोड़ने के discipline के बिना सीधे production deployment push करती है, तो prototype जस का तस “solution” बनकर जम सकता है
- जहाँ junior staff के लिए senior developer के idea implementation पर सवाल उठाना मुश्किल हो, वहाँ ज्यादा सुरक्षित तरीके से सवाल पूछने के लिए soft artifact की जरूरत हो सकती है
-
design document गलत वजहों से कब इस्तेमाल होता है
- discipline या skill की कमी वाली teams में process को धीमा करने का साधन बन सकता है
- documentation के उद्देश्य से इस्तेमाल होने पर भी यह आम तौर पर जल्दी outdated हो जाता है
- सभी design questions का पहले से जवाब देना मुश्किल है, और असली समस्याएँ code लिखने के बाद ही सामने आती हैं
- अगर team पर्याप्त discipline रख सके, तो “design” की तुलना में hack करके सीखने का तरीका ज्यादा efficient हो सकता है
1 टिप्पणियां
Hacker News की राय
इसे प्रोटोटाइपिंग कहा जाता है, और यह design process का एक मूल्यवान हिस्सा है; कुछ लोग इसे “pathfinding” भी कहते हैं
ये सब design के input हैं, लेकिन सही आकार का design फिर भी ज़रूरी है। वरना आप बस उस समय जो चल जाए वैसा बना रहे होते हैं। आपको परिभाषित करना होगा कि आप कौन-सी समस्या हल कर रहे हैं और समाधान क्या है। कभी-कभी formal review के बिना 1 पेज का document काफी होता है, और कभी-कभी कई पेज का document चाहिए होता है जिसमें कई हफ्तों की review और feedback iterations शामिल हों
याद रखें: “कुछ हफ्तों की coding से कुछ घंटों की planning बचाई जा सकती है” ;)
असल में उलटा कहीं ज़्यादा बार सही निकला है। लोग planning पर planning करते रहते हैं, और वह plan सिर्फ बेकार होने से आगे बढ़कर productivity को सक्रिय रूप से नुकसान पहुँचाने लगता है
कुछ हफ्तों की coding कुछ घंटों की planning बचा सकती है, लेकिन कुछ हफ्तों की planning भी बर्बाद हो सकती है। कागज़ पर ऐसी चीज़ें लिखना आसान है जो बेतुकी या असंभव हों। जैसे “unicorns के बेड़े को आधे उदास रंग में रंगना”
आदर्श रूप से design और prototype साथ-साथ evolve होने चाहिए, जहाँ एक तरफ की iteration दूसरी तरफ की अगली iteration को आगे बढ़ाए और DNA की double helix की तरह spiral में विकसित हो। Prototype बनाने की तरफ झुकने का बड़ा फायदा यह है कि एक round खत्म होने पर आपके पास ऐसा software बचता है जो सच में कुछ करता है। Design round खत्म होने पर व्यावहारिक रूप से बहुत कम बचता है
और implementation phase तक code की throwaway-ability को प्राथमिकता देते रहना चाहिए। जितना आसान उसे मिटाना हो, उतना बेहतर
लेकिन design documents या किसी भी तरह की specification के बिना software engineering, चाहे कितनी भी संक्षिप्त क्यों न हो, engineering नहीं बल्कि पेड़ पर झोंपड़ी बनाने जैसी है
Project का size और importance जितना बढ़ता है, problems और technical debt उतनी ही जल्दी दिखने लगते हैं
लिखना problem space को explore करने में सचमुच बहुत उपयोगी है
कई बार लगा कि मैंने problem को पक्के तौर पर समझ लिया है, लेकिन जैसे ही लिखना शुरू किया, नए और महत्वपूर्ण सवाल सामने आ गए। ये चीज़ें आमतौर पर abstract view से बेहतर दिखती हैं, या शुरुआती कुछ release milestones में सामने नहीं आतीं
करियर की शुरुआत में मिले एक mentor याद आते हैं। उन्होंने payment gateway के लिए active/active configuration को बाद में design किया था, और Lucidchart खोलकर कहा था, “यह diagram मेरी ज़िंदगी के 6 महीने दिखाता है”
यह हमेशा ज़रूरी या मददगार नहीं होता, लेकिन जब ज़रूरत हो, तो कुछ दिनों की planning कई हफ्तों की coding बचा सकती है
वे बहुत पहले से अंदाज़ा लगा लेते थे कि problem कहाँ आएगी, इसलिए projects हमेशा smooth रहते थे। अगर कोई problem या uncertainty दिखती, तो सिर्फ उसी हिस्से को model करते और फिर whiteboard पर लौटकर आगे बढ़ते
उपमा दें तो यह map से road trip plan करने जैसा था। आजकल design documents सिर्फ रास्ता दिखाते हैं और तुरंत driving शुरू कर देते हैं, जबकि उनके whiteboard map में कहाँ fuel भरना है, tourist spots के opening hours, border crossing documents, total budget, emergency kit, Plan A और Plan B तक “over-plan” किया जाता था
यह बेहद boring था, लेकिन throwaway code से कहीं बेहतर था। अब over-plan न करना आलसीपन जैसा लगता है
बेशक “हर किसी के पास plan होता है, जब तक उसे एक घूँसा नहीं पड़ता” वाली बात सही है, लेकिन वह war, politics, negotiation पर लागू होती है, coding पर नहीं
आखिर अच्छे PR में भी बहुत writing होती है और वही असर देता है। अच्छी तरह documented draft PR मुझे pure design proposal से बेहतर लगता है। क्योंकि सिर्फ लिखने पर आप उन महत्वपूर्ण constraints को भूल जाते हैं जो code के अंदर रहते हुए ही याद आते हैं
-- Dick Guindon
Design documents के साथ मेरी सबसे बड़ी समस्या यह रही कि उन्हें कोई पढ़ता ही नहीं। Employer माँगे तब भी यही होता है
Prototyping के साथ मेरी सबसे बड़ी समस्या यह रही कि लोग उसे “release code” मान लेते हैं और उसे final code के रूप में इस्तेमाल करने के लिए दबाव डालते हैं
इसलिए mixed approach सबसे सही रही। Planning और documentation पर काफी समय लगाएँ, लेकिन मूल रूप से इसे अपने लिए करें, और release-quality prototype code लिखें ताकि बाद में final product में इस्तेमाल करना भी ठीक रहे
Design document लेखक के अलावा किसी और के लिए ठीक से समझ न आने वाले raw notes के ढेर में बदल जाता है, और लोग ऐसे notes पढ़ने से डरने लगते हैं
लेकिन अगर design document लिखने वाले को बताया जाए कि यह school में grade मिलने वाली final report जैसा है, तो कुछ बार rewrite करने के बाद writing काफी बेहतर हो सकती है। Symptom prototyping जैसा ही है। लोग draft-quality design documents लिख देते हैं और उम्मीद करते हैं कि वे जादुई रूप से wider audience के लिए अच्छी writing बन जाएँगे। जैसे prototype code को कई बार refactor करना पड़ता है, वैसे ही design document को भी कई rounds की editing चाहिए
contract renewal से बचने के लिए deadline तक कुछ बनाकर launch करना था, और उस contract पर लाखों डॉलर खर्च होने वाले थे। लेकिन समझ आ गया कि planned resources और approach से समय पर पूरा नहीं हो पाएगा
इसलिए temporary, partial और non-optimal version जल्दी बनाने की approval मिली, और इसकी वजह से हम समय पर उड़ान भर पाए
इससे, जब तक दूसरे लोग wing के उस हिस्से का permanent और सही version पूरा कर रहे थे, हम कुछ समय तक उड़ते रह सके
असल में उड़ान के दौरान original design में छूटी requirements भी मिलीं। इससे proper version की production release delay हुई, लेकिन मेरे hacky version में उन्हें जल्दी जोड़कर flight जारी रखी जा सकी
मेरा hacky version production support tool का काम भी करता है। permanent version में bug हो और उसे रोकना पड़े, तो यह alternate path भी बन जाता है। partial और incomplete hack है, लेकिन इसके फायदे हैं
कुछ लोगों ने शिकायत की कि इस्तेमाल की गई language कम common है। लेकिन याद रखना चाहिए कि existing resources और approach से शुरुआत में उड़ान भरना ही संभव नहीं था
deadline meet करने के लिए preferred language में ज़्यादा या तेज़ developers चाहिए होते। अगर current staff में किसी के पास, मुझे मिलाकर, preferred language में मेरे niche-language hack जितनी productivity की capacity और capability होती, तो उसे permanent solution समय पर बनाने के लिए assign किया गया होता। ऐसा option था ही नहीं
वैसे भी अगर existing production support tool है, तो वह prototype features के कुछ समय टिके रहने की जगह भी हो सकता है
यह भी एक opinion piece है, लेकिन इसमें data नहीं है और कोई ठोस example तक नहीं है
मुझे पता है कि हर software engineer की strong opinions होती हैं, लेकिन यह weak argument है। अगर आपको लगता है कि क्या सही है यह देखने के लिए बहुत सारा code लिखना ही आपका job है, तो आप जल्द ही GPT से replace हो जाएंगे। क्योंकि वह यह काम ज़्यादा तेज़ और सस्ते में कर सकता है। मुश्किल हिस्सा हमेशा इस पर consensus बनाना होता है कि क्या बनाया जाना चाहिए, और coding करके आप उस problem से बाहर नहीं निकल सकते
अगर requirements clear हैं और मुझे क्या deliver करना है यह भी सभी के लिए clear है, तो इसकी जरूरत नहीं। सीधे prototyping पर जा सकते हैं। लेकिन serious projects में ऐसा rarely होता है। stakeholders से निकालनी पड़ने वाली unknown unknowns हमेशा होती हैं, और technical analysis इसे करने का अच्छा तरीका है
rectangles और dotted lines की अपनी limit है। असली code से दूर हों तो real constraints भूल जाते हैं। सच में speed कम करने वाली चीज़ें Google Docs में दिखाई नहीं देतीं। मेरे experience में “मैं यह सोच रहा हूं” कहते हुए draft PR की ओर इशारा करना ज़्यादा आगे ले जाता है
और हां, यह 100% opinion है। personal blog है, peer-reviewed paper नहीं :) गलत होना भी ठीक है
code जैसा बातचीत को पकड़कर रखने वाला कोई वास्तविक आधार न हो, तो abstract design पर discussion आखिर में “मेरी कल्पना की रस्सी तुम्हारी कल्पना की रस्सी से लंबी है” जैसी बिना निष्कर्ष वाली बहस में बदल जाती है
मेरे experience में code पर feedback और design पर feedback की किस्में बेहद अलग होती हैं
design document “क्यों” वाले सवालों को प्रेरित करता है, जिससे सब लोग problem space पर सोचते हैं। उदाहरण के लिए, “company में अभी Rust में proficient लोग नहीं हैं, फिर Rust web server क्यों propose कर रहे हैं?” जैसी comment संभव है
prototype के चलने लगने के बाद ऐसे subtle सवाल उठाना बहुत मुश्किल हो जाता है। आसानी से बात “team का experience क्यों मायने रखता है? यह तो इतना अच्छे से चल रहा है! अगर आप रोकें नहीं, तो prototype को polish करके एक हफ्ते में production में डाल सकते हैं!” जैसी हो जाती है
खासकर जब working code के बजाय सिर्फ design review किया जा रहा हो
हम imagine करते हैं कि software work एक साफ-सुथरे और orderly flow से गुजरता है
design document लिखते हैं, PR में feature release करने के लिए छोटे incremental changes बनाते हैं, और Git history साफ और व्यवस्थित रहती है। यह steady progress जैसा दिखता है
ऐसा कौन imagine करता है? Software engineering classes पढ़ाने वाले professors?
यह मुझे उन लोगों की याद दिलाता है जो सोचते हैं कि prose, essays, stories, novels वगैरह outline लिखने के बाद उसे prose से “fill” करके लिखे जाते हैं। मानो इस process में ऐसी कोई discovery नहीं होगी जिसके लिए document को फिर से लिखना या restructure करना पड़े। कोई भी ऐसे नहीं लिखता। drafts हमेशा खराब होते हैं, और अच्छी writing लगभग हमेशा बड़े revisions का परिणाम होती है
code लिखना घर या पुल बनाने की तुलना में writing के कहीं ज़्यादा करीब है
new logic को line by line follow करना और variables व memory देखना code improve करने में सच में मदद करता है। “अरे, यह local variable जरूरी नहीं”, “यहां debugging आसान करने के लिए temporary variable add करना चाहिए”, “अगर iterate की जा रही collection खाली हो तो यह code अजीब है” जैसी बातें मिलती हैं
उम्र कितनी भी हो जाए, कितना भी code लिख चुका होऊं, नए लिखे code को debug करते समय हमेशा कुछ नया discover होता है। इसे ऐसे compare कर सकते हैं जैसे writer draft लिखने के बाद उसे दोबारा पढ़ता है, या खुद को या किसी और को जोर से पढ़कर सुनाता है
design decisions को किसी एक document में formalize करने की कोशिश करने के बजाय, उन्हें चल रहे comment thread में record करने की यह process मुझे बहुत पसंद है
मैं GitHub issues को इसी तरह use करता हूं, लेकिन functionally यह PR use करने जैसा ही है। PR असल में code branch जुड़ा हुआ GitHub issue ही है
अपने तरीके के बारे में मैंने यहां और लिखा है: https://simonwillison.net/2022/Jan/12/how-i-build-a-feature/...
दूसरे शब्दों में, उस thread को final document में कैसे summarize करते हैं?
मुझे नहीं लगता कि ये दोनों एक-दूसरे से mutually exclusive हैं
design document एक व्यापक concept है, और लक्ष्य communication है
कभी-कभी बात code के अलावा दूसरे तरीकों से पहुंचानी पड़ती है। diagrams, images, text वगैरह की जरूरत होती है
जो व्यक्ति author नहीं है या code से बहुत परिचित नहीं है, उसके लिए changes को एक नज़र में समझना बेहद मुश्किल होता है। reader जल्दी से सही mental model बना सके और change को context में समझ सके, इसके लिए high-level explanation और documentation चाहिए
अगर आप 1000-line diff देखकर ठीक-ठीक बता सकते हैं कि वह क्या करता है, और उससे भी अहम यह कि upstream और downstream पर उसका क्या असर पड़ेगा, तो या तो आप झूठ बोल रहे हैं या फिर ऐसे पूरी तरह closed और verifiable environment में काम कर रहे हैं जिससे मुझे सच में जलन होगी
design document संभावित options में से prototypes की संख्या 2–3 तक घटाने में मदद करता है। पूरी तरह नई चीज जोड़ने के लिए exploration करते समय यह खास तौर पर उपयोगी होता है
मुझे लगता है कि दिखाना, बताने से बेहतर है, लेकिन नई join करने वाले व्यक्ति के लिए code की तुलना में design document के जरिए समझना ज्यादा आसान होता है