अत्यधिक सोच, scope creep, और structural diff से प्रोजेक्ट को बर्बाद करने के तरीके

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

अत्यधिक सोच और scope creep

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

scope creep के संरक्षण का नियम

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

structural diffing

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

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

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

इच्छित workflow और न्यूनतम-स्कोप योजना

  • मुख्य use case LLM output की turn-by-turn review है, और agent को एक ही बार में 10,000 से अधिक lines का code उगलने नहीं दिया जाता
  • agent को सीमित scope वाले tasks दिए जाते हैं, कुछ मिनट बाद लौटकर पूरे बदलावों का overview देखा जाता है, और फिर Emacs में सीधे edit करना, सब फेंककर दोबारा प्रयास करना, या पूरी चीज़ खुद दोबारा लिखना चुना जा सकता है
  • इच्छित workflow यह है कि पहले देखा जा सके कि कौन से type, function, और method जोड़े गए, हटाए गए, या बदले गए—यानी high-level overview
  • इसके ऊपर हर entity का text diff तेज़ी से expand हो सके, ताकि summary से detailed diff तक स्वाभाविक रूप से पहुँचा जा सके
  • साथ ही, बदलाव को कहीं और ले जाए बिना वहीं तुरंत संपादित किया जा सके; diff screen से file screen में गए बिना inline editing चाहिए
  • दिशा यह है कि Magit के change review और staging workflow को file/line स्तर से entity स्तर पर ले जाया जाए
  • इस बार फिर से याद आए न्यूनतम-स्कोप के सबक के मुताबिक, पहले सिर्फ Rust को लक्ष्य बनाकर treesitter-आधारित entity extraction framework जल्दी से खुद बनाने की योजना है
  • matching के लिए शुरुआत में simple greedy तरीका रखा जाएगा, और diff को command line पर render किया जाएगा
  • यदि इतना करने से किसी विशेष commit पर difftastic से बेहतर परिणाम मिलता है, तो बाद में इसे Magit-जैसे अधिक interactive Emacs workflow से जोड़ा जाएगा
    • संभव हो तो Magit को ही पुन: उपयोग करने की संभावना खुली रखी जाएगी
    • नई language support ज़रूरत पड़ने पर जोड़ी जाएगी
    • बाद में simple greedy के बजाय score-आधारित global matching भी खोजा जा सकता है
  • यदि परिणाम पर्याप्त संतोषजनक हुआ तो इसे सार्वजनिक भी किया जा सकता है, लेकिन 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 कर लो