हमारा software development algorithm

• हाल ही में एक प्रसिद्ध tech CEO और एक engineer के साथ बातचीत में software development की एक दिलचस्प methodology के बारे में सुना। इस methodology ने मुझे दूसरी heuristics और generalization के बारे में सोचने पर मजबूर किया.

उनकी विधि

• दिन की शुरुआत में किसी feature पर काम शुरू करें। अगर दिन खत्म होने तक वह पूरा न हो, तो सब कुछ delete कर दें और अगले दिन फिर से शुरू करें। लिखे गए unit tests को रखा जा सकता है।
• अगर कई दिनों बाद भी feature implement न हो, तो उस feature को संभव बनाने वाली foundation, infrastructure या refactoring के बारे में सोचें, उसे implement करें, और फिर feature पर वापस आएँ।
• यह तरीका 90 के दशक के अंत और 2000 के दशक की शुरुआत के extreme programming movement जैसा है।

इस विधि पर विचार

"हर चीज़ को दो बार लिखो"

• junior engineers को दी जाने वाली सलाह: समस्या हल करो, code को branch में save करो, फिर उसे दोबारा लिखो।
• यह तरीका संयोग से तब मिला जब laptop खराब हो गया। दोबारा लिखने में शुरुआती implementation के सिर्फ 25% समय लगा, और नतीजा कहीं बेहतर था।
• 1.25 गुना समय में 2 गुना बेहतर quality का code मिल सकता है। यह लंबे समय तक maintenance वाले projects के लिए उपयोगी है।
• "हर दिन फिर से शुरू करो" तरीका इससे भी अधिक extreme है। हर rewrite के साथ अक्सर अधिक smooth solution मिलता है।

"मात्रा की अपनी गुणवत्ता होती है"

• Stalin का एक उद्धरण software engineers पर भी लागू होता है। junior engineers के लिए शुरुआती 100,000 lines of code लिखना लगभग अनिवार्य है।
• "हर दिन फिर से शुरू करो" तरीका 100,000 lines जल्दी लिखने में मदद करता है।
• एक ही समस्या को बार-बार हल करना patterns को याद रखने के लिए फायदेमंद है।
• 5,000 lines के बेहतरीन code में आप सभी मुख्य patterns देख सकते हैं। बाकी 95,000 lines repetition के ज़रिए neurons को फिर से व्यवस्थित करती हैं।

"सिर पर बंदूक रखकर" heuristic से तुलना

• जब कोई समस्या का समाधान पेश करे, तो पूछें: "अगर इसे 24 घंटे के भीतर खत्म करना ही पड़े, तो आप क्या करेंगे?"
• यह तरीका framing और anchoring bias को तोड़ता है। अक्सर यह कुछ ही मिनटों में ऐसा plan निकाल देता है जिसे एक दिन में पूरा किया जा सके।
• व्यवहार में वह plan सचमुच एक दिन में पूरा होने वाला नहीं होता, लेकिन नया solution अक्सर कुछ दिनों में पूरा किया जा सकता है।
• इस thought experiment का उद्देश्य वास्तविक solution बनाना नहीं, बल्कि solution की lower bound तय करना है।

pathfinding

• समस्या-क्षेत्र में रास्ता खोजना ही मूल बात है। हर path एक solution है, और engineer की भूमिका सबसे अच्छा path ढूँढना है।
• इन heuristics और अलग-अलग pathfinding algorithms के बीच समानताओं पर विचार करना सार्थक है।
• engineering heuristics के साथ भी यही बात लागू होती है: बेहतर engineer बनना मतलब समस्या-क्षेत्र में बेहतर paths ढूँढना।

GN⁺ का सार

• यह लेख software development में प्रभावी methodologies और heuristics की पड़ताल करता है।
• "हर दिन फिर से शुरू करो" और "हर चीज़ को दो बार लिखो" जैसे तरीके code quality बढ़ाने में उपयोगी हैं।
• बार-बार समस्या हल करना pattern recognition और neurons के पुनर्संयोजन में मदद करता है।
• "सिर पर बंदूक रखकर" heuristic solution की lower bound तय करने में उपयोगी है।
• समस्या-क्षेत्र में सबसे अच्छा path ढूँढना engineer की मुख्य भूमिका है।

[ahwjdekf]

पागल हो गए हैं क्या? यह तो वही कर सकते हैं जिन लोगों के पास बेहिसाब फालतू समय हो—क्या यह हकीकत में कोई वाजिब काम लगता है?

[dlehals2]

कोरियाई SI माहौल में यह शायद मुमकिन नहीं होगा.. haha शायद सिर्फ़ personal project में ही

[kaistj]

यह तरीका वाकई ऐसा है जिसके बारे में मैंने बिल्कुल नहीं सोचा था।
इसे एक बार ज़रूर आज़माना पड़ेगा, हा हा

[eususu]

मैं फिर से लिखने वाली बात से पूरी तरह सहमत हूँ.
पहले एक बार जिस कोड पर काम कर रहा था, उसे गलती से उड़ा दिया था, और जब उसे दोबारा लिखने लगा
तो बीच में डिज़ाइन बदलना झंझट लगे इसलिए जिन चीज़ों को नज़रअंदाज़ कर दिया था, उन्हें ध्यान में रखकर बना पाया,
और नतीजा बल्कि बेहतर रहा.

[GN⁺]

Hacker News राय

• नई feature को दो बार लिखना एक अच्छी strategy है। लेकिन business developer या project manager को यह बेवजह की देरी लग सकती है

  • feature को शुरू से अंत तक लिखना logic को व्यवस्थित करने और refactoring में मदद करता है
  • दोबारा लिखने से logic flow साफ़ होता है और plan को ज़्यादा linear तरीके से follow किया जा सकता है
  • इससे बाद में बड़े पैमाने की refactoring की ज़रूरत कम पड़ती है

• "अगर इसे 24 घंटे में पूरा करना हो तो?" यह वह सवाल है जो project manager नहीं पूछ सकता

  • यह एक व्यक्तिगत सीखने का अभ्यास है, काम को जल्दी खत्म करने का तरीका नहीं

• अच्छा code सही abstraction चुनकर लिखा जाता है

  • सही abstraction चुनने के लिए पूरे सिस्टम को समझना ज़रूरी है
  • दूसरी engineering fields में CAD layout जैसे अच्छे blueprint paradigm इस्तेमाल होते हैं
  • software में ऐसे blueprint की कमी है
  • experience इसलिए महत्वपूर्ण है क्योंकि वही संतुलन बनाने में मदद करता है

• अगर सक्षम सहकर्मी हों, तो वे दिखा सकते हैं कि कम समय में क्या किया जा सकता है

  • तेज़ी से काम करना महत्वपूर्ण होने के कई कारण हैं
  • car repair की तरह, जितना ज़्यादा समय लगेगा, दोबारा assemble करते समय कुछ भूलने की संभावना उतनी बढ़ेगी
  • अगर एक दिन में feature implement कर लिया जाए, तो risk कम होता है
  • इसके लिए tools की पक्की समझ और भरोसेमंद CI/CD process चाहिए

• software को दो बार लिखना अच्छा है, इस बात से सहमत हूँ

  • लेकिन एक बार लिखा हुआ code खो देने के बाद उसे फिर से लिखने का मन नहीं करता
  • दोबारा लिखने बैठो तो focus नहीं बनता, और approach भी याद नहीं रहती

• अगर कुछ दिनों बाद भी feature implement नहीं हो पा रहा है, तो पहले ज़रूरी infrastructure या refactoring कर लेनी चाहिए

  • tools की 'vocabulary' बनाना और उसे बनाए रखना महत्वपूर्ण है

• "24 घंटे में" और "हर चीज़ दो बार लिखो" आपस में जुड़े हुए हैं

  • अगर code को जल्दबाज़ी में लिखा जाए, तो अंत में उसे फिर से लिखना ही पड़ता है

• यह post बेहतरीन "programming advice" में से एक है

  • यह grug brained developer की सलाह जैसी लगती है

• कभी-कभी समस्या सुलझाने के लिए background thread चलने देना ज़रूरी होता है

  • ज़्यादा अनुभवी लोग ऐसी समस्याओं को जल्दी पहचान लेते हैं
  • कभी-कभी समस्या को थोड़ी देर के लिए छोड़कर कोई और काम करना बेहतर होता है

• नीचे दिया गया approach उपयोगी है

  • समस्या हल करने के कई ideas पहले लिख लो
  • काम को ऐसे हिस्सों में बाँटो जिन्हें 'एक session के भीतर पूरा किया जा सके'
  • हर session के अंत तक code हमेशा 'working' स्थिति में रहे, ऐसा implement करो
  • हर session के अंत में comments या README में brain dump लिखो