ज़्यादा सोच, स्कोप बढ़ाना, और structural diff से प्रोजेक्ट बिगाड़ने के तरीके

 (kevinlynagh.com)
5 पॉइंट द्वारा GN⁺ 5 일 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • प्रोजेक्ट अक्सर तुरंत बनाकर खत्म कर देने वाले flow और ऐसे flow में बँट जाते हैं जहाँ रिसर्च और डिज़ाइन इतना बढ़ जाता है कि मूल समस्या ही छूट जाती है; और वास्तविक प्रगति में कई बार बस करके देखने वाला तरीका ज़्यादा आगे निकलता है
  • Emacs के लिए fuzzy path search बनाते समय भी अच्छी लाइब्रेरी के अतिरिक्त फीचर्स ने नई requirements पैदा कर दीं, डिज़ाइन फूला गया, और अंत में ज़रूरी न होने वाला anchor फीचर वाला सारा कोड फेंककर YAGNI फिर से सही साबित हुआ
  • कोड diff में line-based तुलना function या type जैसी ऊपरी संरचनाओं को ठीक से नहीं पकड़ती, और treesitter-आधारित tools भी entity matching बिगड़ने पर deletion और addition को लंबा दिखा सकते हैं, जिससे पढ़ना कठिन हो जाता है
  • ज़रूरत की दिशा यह है कि LLM output की turn-by-turn review के लिए पहले minimum-scope tool बनाया जाए; Rust के लिए entity extraction और simple matching से शुरू करके high-level change overview जल्दी देखने वाला workflow प्राथमिक होना चाहिए

ज़रूरत से ज़्यादा सोचना और स्कोप बढ़ना

  • प्रोजेक्ट अक्सर तुरंत बनाकर खत्म कर देने वाले flow और ऐसे flow में बँट जाते हैं जहाँ पहले के उदाहरणों में गहराई तक जाने के दौरान स्कोप इतना बढ़ जाता है कि मूल समस्या ही हल नहीं हो पाती
  • वीकेंड में बनाया गया किचन शेल्फ कॉफ़ी पीते हुए डिज़ाइन तय करके, 3D प्रिंटेड hanger को कुछ बार सुधारकर, और बचे हुए material व paint का उपयोग करके उसी वीकेंड में पूरा हो गया
    • Ikea bin hanger के लिए CAD OnShape CAD पर सार्वजनिक है
    • material workshop में बचे हुए सामान से फिर इस्तेमाल किया गया, और किनारों को palm sander से अंदाज़े से घिसा गया
  • इस शेल्फ में सफलता का मुख्य मानदंड किचन के लिए बिल्कुल फिट चीज़ बनाना नहीं, बल्कि दोस्त के साथ बढ़ईगिरी का आनंद लेना था, इसलिए बारीक मानदंडों पर ज़रूरत से ज़्यादा सोचने की ज़रूरत कम हो गई
  • इसके उलट, structural diff tool खोजने की प्रक्रिया में difftastic के नतीजे संतोषजनक नहीं लगे, तो उससे जुड़े tools और workflow पर 4 घंटे शोध किया, लेकिन अंत में Emacs में इस्तेमाल करने लायक बेहतर diff workflow वाले मूल मानदंड पर लौटना पड़ा
  • hardware prototyping interface, Clojure और Rust को मिलाने वाली language, और CAD के लिए language जैसे पुराने रुचि-क्षेत्रों पर background research और छोटे prototypes में सैकड़ों घंटे लगे, लेकिन वे अभी तक शुरुआती प्रेरणा को सीधे हल करने वाले नतीजों में नहीं बदले
  • language और CAD प्रोजेक्ट्स में यह सफलता का मानदंड धुंधला है कि क्या वे Rust या Clojure को replace करेंगे, क्या सिर्फ कुछ समस्याएँ संभालेंगे, क्या learning playground होना काफी है, क्या commercial CAD को बदलना है, या क्या वे दूसरों के लिए भी उपयोगी होने चाहिए
  • ऐसे सवालों पर विचार करना मूल्यवान है, लेकिन बहुत-सी बातों की समीक्षा भर करने से बेहतर है कि वास्तव में अधिक चीज़ें बनाई जाएँ
  • बाद में साफ़ तौर पर खराब दिखने वाला नतीजा ही क्यों न निकले, बस करके देखने वाला तरीका कुल मिलाकर ज़्यादा आगे बढ़ाता है

स्कोप बढ़ने का संरक्षण नियम

  • बिना सोचे-समझे बना देने के समय की भी सीमा होती है और संतुलन चाहिए; LLM agent से बहुत सारा कोड लिखवाकर अंत में सब फेंक देने के अनुभव ने फिर से YAGNI याद दिलाया
  • Emacs के लिए Finda-स्टाइल पूरा filesystem fuzzy path search बनाना था, और पहले ऐसा feature हाथ से कोड करके बनाया भी था, इसलिए लगा कि LLM को supervise करके यह कुछ घंटों में पूरा हो जाएगा
  • शुरुआत में planning conversation में Nucleo सुझाया गया; यह अच्छी तरह डिज़ाइन और documented था, इसलिए smart case और Unicode normalization पाने के लिए इसे चुना गया
    • उदाहरण के लिए query foo, Foo और foo दोनों से match करती है, लेकिन Foo, foo से match नहीं करती
    • cafe और café का व्यवहार भी इसी संदर्भ में संभाला जाता है
  • समस्या अच्छी लाइब्रेरी में नहीं थी, बल्कि इस बात में थी कि Nucleo anchor फीचर भी सपोर्ट करता है
  • केवल file path वाले corpus में line-start anchor बेकार लगा, इसलिए इसे path segment-आधारित anchor की तरह interpret करने की कोशिश की गई
    • उदाहरण के लिए ^foo को /root/foobar/ से match करना था, लेकिन /root/barfoo/ से नहीं
  • इसे कुशलता से करने के लिए index को segment boundary store करनी पड़ती, और हर segment पर query को तेज़ी से जाँचना पड़ता
  • इसके साथ ^foo/bar जैसी slash वाली anchor query भी संभालनी थी, और सिर्फ segment-आधारित जाँच से /root/foo/bar/baz/ जैसे path को सही match करना मुश्किल हो गया
  • इस डिज़ाइन पर कई घंटे और लगे, LLM से ideas आगे-पीछे हुए, Nucleo types को wrap करने वाला कोड बनाया गया, फिर कोड बहुत फूला हुआ और नापसंद लगा, इसलिए अंत में छोटा wrapper सीधे फिर से लिख दिया गया
  • थोड़ा ब्रेक लेने के बाद याद नहीं आया कि Finda में anchor फीचर की कभी ज़रूरत पड़ी थी, और path corpus में query के आगे या पीछे / जोड़कर ज्यादातर anchor का काम किया जा सकता है
    • सिर्फ filename के अंत वाले anchor का मामला अपवाद रहा
  • आखिरकार anchor से जुड़ा पूरा कोड फेंक दिया गया, और यह कहना मुश्किल है कि LLM या दूसरों से चर्चा किए बिना शुरू से खुद लिखने की तुलना में यह फिर भी फायदेमंद रहा या नहीं
  • लगता है कि programming speed जितनी बढ़ती है, उतने ही अनावश्यक फीचर, rabbit hole, और detour भी साथ बढ़ते हैं—जैसे कोई संरक्षण नियम हो

Structural diffing

  • कोड में diff आमतौर पर किसी file के दो versions के बीच line-based changes का summary होता है, और unified view में additions और deletions को +, - से दिखाया जाता है
  • उसी diff को side-by-side रूप में भी render किया जा सकता है, और बदलाव जितने जटिल हों, यह रूप उतना पढ़ने में आसान हो सकता है
  • line-based diff की समस्या यह है कि वह function या type जैसी ऊपरी संरचनाओं को पहचान नहीं पाती; braces किसी तरह मिल जाने पर अलग-अलग function के हिस्सों में होने पर भी display छूट सकता है
  • difftastic treesitter द्वारा दिए गए concrete syntax tree का उपयोग करके इस समस्या को कम करने की कोशिश करता है, लेकिन versions के बीच entity matching हमेशा सही नहीं बैठती
  • जिस diff ने सीधे यह सोच शुरू कराई, उसमें struct PendingClick दोनों तरफ एक-दूसरे से match नहीं हुआ, और बाईं ओर deletion, दाईं ओर addition के रूप में दिखा
  • matching क्यों फेल हुई, यह गहराई से नहीं देखा गया, लेकिन यह तय किया गया कि भले पूरा diff लंबा हो जाए, PendingClickRequest और PendingClick को दोनों तरफ corresponding entities के रूप में देखना ज़्यादा बेहतर है

Structural diff tools और संदर्भ सामग्री

  • सबसे परिपक्व और सावधानी से पॉलिश किया गया semantic diff tool semanticdiff.com माना गया
    • इसे जर्मनी की एक छोटी कंपनी देती है, और इसके पास मुफ्त VSCode plugin तथा GitHub PR diff दिखाने वाली web app है
    • लेकिन यह उस तरह की code library नहीं देता जिसे इच्छित workflow की नींव बनाया जा सके
    • semanticdiff vs. difftastic लेख में कई उपयोगी विवरण हैं, जिनमें difftastic का Python में अर्थपूर्ण indentation change तक न दिखा पाना भी शामिल है
    • लेखकों में से एक ने HN comment में लिखा कि वे treesitter को semantics के लिए इस्तेमाल करने से आगे बढ़ गए, क्योंकि context-dependent keywords और lexer behavior के कारण parsing फेल हो सकती थी, और async जैसे नाम को parameter के रूप में रखने पर भी tool रुक सकता था
  • diffsitter treesitter-आधारित है और MCP server शामिल करता है
    • GitHub stars काफ़ी हैं, लेकिन documentation उतनी अच्छी नहीं लगी, और यह कैसे काम करता है इस पर सामग्री ढूँढना कठिन था
    • difftastic wiki में लिखा है कि यह tree के leafs पर longest-common-subsequence चलाता है
  • gumtree 2014 के research/academic background से निकला tool है
    • Java की ज़रूरत होने के कारण Emacs में जल्दी इस्तेमाल करने वाले निजी उपयोग के लिए यह उपयुक्त नहीं है
  • mergiraf Rust में लिखा treesitter-आधारित merge-driver है
    • इसका architecture overview अच्छी तरह व्यवस्थित है, और अंदर से Gumtree algorithm का उपयोग करता है
    • docs और diagrams देखकर यह बहुत सोच-समझकर लिखा गया project लगता है
    • semanticdiff.com के लेखक ने HN comment में लिखा कि GumTree जल्दी परिणाम देता है, लेकिन कई follow-up papers के सुधार लागू करने के बाद भी यह अक्सर खराब matching लौटा देता था, इसलिए वे अंत में mapping cost कम करने वाले dijkstra-आधारित approach पर चले गए
  • weave Rust में लिखा एक और treesitter-आधारित merge-driver है
    • इसका flashy landing page, बहुत सारे GitHub stars, MCP server आदि देखकर कुल प्रभाव कुछ बढ़ा-चढ़ाकर पेश किया हुआ लगा
    • इसके entity extraction crate sem को देखा गया
    • core diff code ठीक-ठाक है, लेकिन थोड़ा verbose है, और entity matching में greedy algorithm का उपयोग होता है
    • data model file के भीतर move detect नहीं कर पाता, जबकि ऐसे moves अर्थपूर्ण हो सकते हैं
    • इसमें heuristic-आधारित impact analysis भी बहुत है, जिसे भरोसेमंद बनाने के लिए और मज़बूत language integration चाहिए लगता है
      • sem diff --verbose HEAD~4 चलाते समय एक bug output भी मिला जिसमें जो lines वास्तव में बदली ही नहीं थीं, वे बदली हुई दिखाई गईं
    • 80% तक पूरी हुई hypothetical useful features बहुत ज़्यादा थीं, इसलिए इसे foundation की तरह उपयोग करना सही नहीं लगा, लेकिन 3 महीनों में इतना बना लेना फिर भी प्रभावशाली है
  • diffast 2008 के academic paper के algorithm पर आधारित AST का tree edit-distance निकालता है
    • यह dedicated parser के ज़रिए Python, Java, Verilog, Fortran, और C/C++ को सपोर्ट करता है
    • example AST differences gallery अच्छी तरह व्यवस्थित है
    • यह information को tuple रूप में export करता है, ताकि datalog में उपयोग हो सके
  • autochrome Clojure-only diff tool है और dynamic programming का उपयोग करता है
    • इसकी visual explanation और example walkthrough बहुत अच्छी है
  • Tristan Hume का Designing a Tree Diff Algorithm Using Dynamic Programming and A* tree diff algorithm design पर एक लेख है, जो संदर्भ के तौर पर काफ़ी उपयोगी है

इच्छित workflow और minimum-scope plan

  • मुख्य use case LLM output की turn-by-turn review है, और agent को एक ही बार में 10,000 से ज़्यादा lines का कोड बेहिसाब generate करने नहीं दिया जाता
  • agent को scope-defined काम दिया जाता है, कुछ मिनट बाद लौटकर पूरे changes का overview देखा जाता है, फिर Emacs में सीधे edit किया जाता है, या सब फेंककर फिर कोशिश की जाती है, या सीधे खुद फिर से लिखा जाता है
  • वांछित workflow यह है कि पहले यह high-level overview दिखे कि कौन-से type, function, और method add, delete, या change हुए हैं
  • इसके ऊपर हर entity के text diff को तेज़ी से expand किया जा सके, ताकि summary से detailed diff तक स्वाभाविक रूप से जाया जा सके
  • साथ ही, changes को कहीं और ले जाए बिना वहीं तुरंत edit किया जा सके, और diff screen से file screen पर जाए बिना inline editing मिले
  • लक्ष्य Magit के change review और staging workflow को file/line unit के बजाय entity unit पर ले जाना है
  • इस बार फिर याद आए minimum-scope lesson के हिसाब से, पहले सिर्फ Rust को target करते हुए treesitter-आधारित entity extraction framework खुद जल्दी-जल्दी बनाने की योजना है
  • matching अभी simple greedy तरीके से शुरू होगी, और diff को command line पर render करने का इरादा है
  • अगर इतना भी किसी खास commit पर difftastic से बेहतर नतीजा देता है, तो आगे इसे Magit जैसे अधिक interactive Emacs workflow से जोड़ने की योजना है
    • संभव हो तो Magit को ही reuse करने का विकल्प भी खुला रखा जाएगा
    • नई language support ज़रूरत पड़ने पर जोड़ी जाएगी
    • बाद में simple greedy के बजाय score-आधारित global matching भी खोजी जा सकती है
  • अगर यह पर्याप्त संतोषजनक हुआ तो इसे public भी किया जा सकता है, लेकिन GitHub stars या HN karma जमा करना लक्ष्य नहीं है; यह सिर्फ अकेले चुपचाप इस्तेमाल होने वाला tool भी रह सकता है
  • कभी-कभी इंसान को बस एक शेल्फ चाहिए होती है—इस वाक्य के साथ ज़्यादा विस्तार के बजाय ज़रूरत की चीज़ बनाने के रवैये को फिर से जोड़ा गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 일 전
Hacker News की राय

  • मुझे लगता है कि यह PhD research की सबसे बड़ी मुश्किल को बहुत अच्छी तरह दिखाता है
    कोई दिलचस्प topic पकड़कर उससे जुड़ा prior research जितना हो सके उतना पढ़ते-पढ़ते यह एहसास होने लगता है कि जो मैं करना चाहता था, वह पहले से कितनी बार किया जा चुका है, और फिर scope creep बहुत आसानी से बढ़ जाता है
    शुरुआत की सारी energy और excitement खर्च हो जाने के बाद, बचे हुए 20~30% को किसी तरह धक्का देकर publishable state तक ले जाना पड़ता है

    • दिन 1 पर शुरुआत इस सोच से होती है कि existing industrial catalyst को नए use case में लगाकर essential medicine precursor की production cost कम की जाए
      दिन 400 पर लगभग theory of everything समझाने के बाद, ज्ञात ब्रह्मांड की सारी शक्तियों को मध्यस्थता करने वाले universal particle को detect करने के लिए Lagrange point orbital experiment apparatus बनाने की कोशिश चल रही होती है
    • यह एहसास बहुत ज़्यादा real लगा
      इसे कम कैसे किया जाए, यह जानने की उत्सुकता है
    • मेरा मानना है कि ज़्यादातर PhD programs में ऐसा इसलिए होता है क्योंकि PhD का उद्देश्य आखिरकार यह साबित करना होता है कि आप normal science कर सकते हैं
      असलियत में यह अक्सर किसी system की observability को 1% से 1.001% तक बढ़ाने जैसा काम होता है, और academic career में घुसने के gatekeeping step के ज़्यादा करीब है
      इसलिए सच में रोमांचक, बेहद नया, या science में सीधे लागू होने वाला dissertation बहुत कम देखने को मिलता है
    • और इसके ऊपर, शुरू से ही PhD शुरू करने के फैसले पर पछतावा भी धीरे-धीरे भारी होता जाता है, उसी हालत में यह सब झेलना पड़ता है
    • जितना हो सके उतना सारा prior research पढ़कर शुरू करना निश्चित रूप से गलत approach है
      मैंने वास्तव में बहुत कम लोगों को इस तरह research करते देखा है; आम तौर पर दो-तीन papers पढ़कर वहीं से build करना ज़्यादा सही रहता है
      literature को गहराई से खंगालना तब बेहतर होता है जब कुछ results आने लगें और आप लिखकर उसे organize करना शुरू करें

  • मेरे दिमाग में बार-बार यही बात आती है कि better होना ही काफी है
    छोटे improvements भी समय के साथ accumulate होते हैं, और शुरू से बिल्कुल perfect कुछ नया शायद ही होता है, इसलिए बैठकर perfect design निकालने की कोशिश उल्टा नुकसान कर सकती है
    "The obstacle is the way" वाली बात यहां बहुत फिट बैठती है

    • यह बात बिल्कुल सही है कि perfect को good enough का दुश्मन नहीं बनने देना चाहिए
      मेरे साथ काम करने वाला एक colleague code changes की आलोचना करते समय भी, अगर उसे लगता कि वह बहुत मामूली बात पकड़ रहा है, तो कहता था, "पहले से बेहतर है"
      इससे improvement points भी सामने आ जाते थे, और साथ ही यह इजाज़त भी मिलती थी कि छोटी कमियां रह जाने पर भी आगे बढ़ा जा सकता है; मैं इस attitude का ज़ोरदार समर्थन करता हूं
    • आखिरकार यह perfectionism ही है
      पहले मैं perfectionism को सिर्फ बहुत ऊंची उपलब्धि के पीछे खुद को ज़रूरत से ज़्यादा धकेलना समझता था, लेकिन अगर कोई चीज़ perfect न हो तो उसे स्वीकार न कर पाना और बिना प्रगति के छोड़ देना भी perfectionism हो सकता है
      बड़े कामों को टालने वाली procrastination भी अक्सर इसी जड़ से आती है

  • Rec Room के CEO की एक बात मुझे पसंद आई
    teams हमेशा यह कहती हैं कि project छोटा होना चाहिए था; शायद ही कोई कहता है कि release और देर से होना चाहिए था, ज़्यादा complex होना चाहिए था, या और polish किया जाना चाहिए था
    हर situation में यह 100% सही नहीं होगा, लेकिन अगर गलती करनी ही है, तो बहुत बड़ा बनाकर समय बर्बाद करने से बेहतर है छोटा बनाकर जल्दी release करना

  • इंसान की फितरत ऐसी है कि मिलते-जुलते ideas सोचना आसान होता है, इसलिए अगर बिना जाने कोई project पूरा किया जाए तो कुछ हद तक reinvention होना लगभग तय है
    उल्टा अगर पहले research कर लें, तो यह देखकर उत्साह ठंडा पड़ सकता है कि उसका कुछ हिस्सा पहले से मौजूद चीज़ों की पुनरावृत्ति है
    फिर भी, अपनी learning के लिए उसे आखिर तक बनाना ही शायद सबसे अहम हो सकता है
    हां, अगर आपको नया academic result निकालना हो या किसी unique project से कमाई करनी हो तो मामला मुश्किल होता है, लेकिन उन क्षेत्रों में भी अक्सर existing चीज़ को थोड़ा मोड़ देने भर पर surprisingly काफी छूट मिल जाती है

  • मैं अभी बिल्कुल यही स्थिति एक side project में झेल रहा हूं
    field Information Retrieval की है, इसलिए अनुभव कम है और सीखने या integrate करने लायक prior art स्वाभाविक रूप से बहुत है
    इसलिए यह पढ़ने के बाद मेरा मन इस तरफ और गया कि पहले अपनी चीज़ बनाऊं, और सिर्फ जब अटकूं या ideas की ज़रूरत हो तभी prior examples देखूं
    दूसरी तरफ, हाल में आई Clojure documentary देखने पर लगा कि Rich Hickey ने तो उल्टा लंबे समय तक prior research, papers, और दूसरी languages को गहराई से समझने के बाद काम किया
    लेकिन उसने भी उससे पहले दूसरी languages बना रखी थीं, तो बड़ी तस्वीर में शुरुआत तो सीधे बनाते हुए सीखने से ही हुई थी
    शायद बहुत देर तक सिर्फ सोचते रहने के बजाय पहले बना लेना चाहिए, real-world practice से lessons इकट्ठा करने चाहिए, दीवार से टकराना चाहिए, और फिर जब ज़रूरत पड़े तब गहरी research करनी चाहिए

  • Deadline तय कर देने से मेरी ज़्यादातर scope creep problems हल हो गईं
    महसूस यह हुआ कि game jam या programming contest जैसे hard deadline वाले projects को खत्म करना आसान होता है, जबकि open-ended projects को पूरा करना कहीं ज़्यादा मुश्किल होता है
    यह कुछ वैसा ही लगता है जैसे C++ standard भी हर wanted feature तैयार होने तक इंतज़ार नहीं करता, बल्कि हर 3 साल में release कर देता है
    https://news.ycombinator.com/item?id=20428703

  • लेख दिलचस्प था, लेकिन लेखक की सोच कुछ बिखरी हुई लगी

    • यहां असली core मुझे scope creep ही लगता है
    • यह किसी एक specific topic को sharply explore करने वाला blog post कम, और इसे follow करने वाले readers के लिए भेजा गया newsletter update ज़्यादा लगता है

  • जो व्यक्ति कहता है कि वह scope creep से दब जाता है, उसके हिसाब से लेख के अंत में हर तरह के topics के ढेर सारे links लगे हुए थे, यानी वह वास्तव में बहुत कुछ कर लेने वाला इंसान लगता है
    आख़िरकार वह शायद सीखना और तरह-तरह की चीज़ें आज़माना सच में पसंद करता है, और rabbit hole में उतरने की पूरी प्रक्रिया ही उसके दिमाग को मज़ेदार stimulation देती है

  • अकेले बनाने वाले के रूप में एक realization मेरे लिए बहुत मददगार रही
    जो चीज़ें essential abstraction जैसी लगती थीं, उनमें से ज़्यादातर बस नाम बदलकर आया हुआ scope creep थीं
    हर नई feature पर flag जोड़ते-जोड़ते code में pattern दिखने लगा, तो मैंने एक नियम बना लिया
    अगर किसी feature के लिए flag-off behavior का test नहीं है, तो उसे ship नहीं करना है
    इसके बाद flag मुझे escape hatch नहीं, बल्कि product का हिस्सा दिखने लगे, और backlog में पड़े तीन features को इस नज़र से देखते ही वे अपने-आप गायब हो गए

  • यह सही है कि overplanning और scope creep problem हैं, लेकिन दूसरी तरफ बहुत ज़्यादा improvised development की ओर झुकने से भी बचना चाहिए
    मेरे कुछ सबसे सफल projects वे थे जिनमें actual working software बनाने से पहले data modeling करते हुए ज़्यादातर features को पहले से plan और review किया गया था
    उस stage पर अक्सर यह साफ नहीं होता कि क्या ज़रूरत से ज़्यादा है, और अगर मैं या user जो features चाह सकते हैं उन्हें हटा दिया जाए, तो बाद में code के core को बड़े पैमाने पर फिर से design करने में बहुत समय लग जाता है
    उल्टा अगर अंदाज़ा गलत निकले, तो project इतना बड़ा हो जाता है कि उसे scope creep कहना पड़ता है
    आखिरकार यह फैसला इस बात पर निर्भर करता है कि आप domain को कितना अच्छी तरह जानते हैं
    अगर domain को आप अपनी सोच से कम जानते हैं, तो rework बढ़ता है; और अगर अपनी सोच से ज़्यादा जानते हैं, तो शायद आप बड़ा कदम ले सकते थे लेकिन baby steps में समय गंवा देते हैं
    किसी भी दिशा में जाएं, पछतावा रह ही जाता है, इसलिए यह अंततः एक बड़ा judgment का सवाल लगता है

    • ideal तरीका शायद यह है कि analysis phase में इतना समय दिया जाए कि दिमाग में सही context भर जाए, लेकिन जब actually बनाना शुरू करें तो overengineered solution को छोड़कर जो practical लगे उसे तुरंत implement करने के लिए तैयार रहें
      sunk cost fallacy में नहीं फंसना चाहिए, और सिर्फ इसलिए कि आपने किसी PhD-level topic पर कुछ घंटे research की है, इसका मतलब यह नहीं कि उसे project में ज़रूर इस्तेमाल करना ही पड़े
      अगर वह अभी की problem पर ठीक से fit नहीं बैठता, तो उसे बेझिझक छोड़ देना चाहिए
    • बहुत गलत हो जाने की चिंता मत करो; पहले करके देखो, फिर ज़रूरत हो तो adjust कर लो