अगर आप खुद नहीं बनाते और सुधारते, तो आप software डिज़ाइन नहीं कर सकते

• बड़े systems में वास्तविक डिज़ाइन में भागीदारी केवल वही engineers कर सकते हैं जो उस code को सीधे संभालते हैं; abstract सलाह ज़्यादातर बेकार होती है
• सामान्य design सलाह (generic design) अक्सर codebase को जाने बिना, सिर्फ domain समझकर दी जाती है
• वास्तविक काम में ठोस constraints और consistency बनाए रखना design principles से कहीं ज़्यादा महत्वपूर्ण होता है, और code की मौजूदा स्थिति को समझना सबसे अहम है
• नए system की design या पूरी company की technical direction तय करने में सामान्य design principles कुछ हद तक उपयोगी हो सकते हैं
• लेकिन मैदान से कटे हुए architect-केंद्रित design ढाँचे आसानी से विफल होते हैं, और design सुझाने वाले व्यक्ति को उसके परिणाम की ज़िम्मेदारी लेनी चाहिए

---

सामान्य software design की सीमाएँ

• बड़े systems की design के लिए code की ठोस बारीकियों की गहरी समझ अनिवार्य है
  • abstract सलाह वास्तविक समस्याएँ सुलझाने में लगभग कोई मदद नहीं करती
  • व्यवहारिक काम में consistency ‘अच्छे design’ से भी अधिक महत्वपूर्ण होती है
• वास्तविक codebase जटिल होती है और अप्रत्याशित परिणाम पैदा करती है, इसलिए सुरक्षित बदलाव के लिए चुने जा सकने वाले implementation तरीके सीमित होते हैं
• बड़े shared codebase हमेशा कई designs के मिले-जुले बीच के state में होते हैं; आदर्श लक्ष्य से अधिक महत्वपूर्ण code की मौजूदा coupling की स्थिति होती है
• अधिकांश systems का पूरा rewrite संभव नहीं होता, इसलिए आंतरिक consistency और engineers की बारीकी पर निर्भर रहना पड़ता है

ठोस software design की विशेषताएँ

• प्रभावी design discussion उन कुछ engineers की बातचीत में होती है जो system के साथ रोज़ काम करते हैं
  • discussion का विषय सामान्य principles नहीं, बल्कि system की संरचना, data flow जैसे ठोस context होते हैं
• उदाहरण के लिए, “क्या DRY अच्छा है?” की जगह “क्या यह feature A subsystem में रखा जा सकता है, क्या B जानकारी C context में accessible है” जैसी सूक्ष्म technical चर्चा होती है
• महत्वपूर्ण योगदान अक्सर छोटी गलतफहमियों या code change के सूक्ष्म प्रभावों को ठीक करने से आता है

जब सामान्य design सलाह उपयोगी होती है

• नए project को पहली बार design करते समय ठोस constraints नहीं होते, इसलिए सामान्य principles उपयोगी होते हैं
• जब कई implementation विकल्पों में से चुनना कठिन हो, तब सामान्य principles decision के tie-breaker की भूमिका निभा सकते हैं
• पूरी company स्तर पर consistency बनाए रखने में भी मदद मिलती है, और यह औपचारिक software architect की भूमिका में से एक है
• cloud vs on-premise, AWS vs Azure जैसे व्यापक technical चुनावों में भी सामान्य principles संदर्भ बन सकते हैं, लेकिन तब भी ठोस constraints को नज़रअंदाज़ नहीं किया जा सकता

architect और ‘local minima’ समस्या

• कई कंपनियाँ मैदान के अनुभव के बिना architect-केंद्रित abstract design structure में फँस जाती हैं
  • यह तरीका ऊपर से efficient दिखता है, लेकिन व्यवहार में ऐसी design पैदा करता है जिसे field engineers लागू ही नहीं कर पाते
• architect खुद implementation नहीं करते, इसलिए नतीजों के प्रति ज़िम्मेदारी (skin in the game) कम होती है
  • design सफल हो तो श्रेय ले सकते हैं, और विफल हो तो execution team को दोष दे सकते हैं
• ऐसी संरचना वास्तविक value से अधिक औपचारिक design गतिविधियों को बढ़ावा देने की ओर झुकती है

निष्कर्ष और सुझाव

• उपयोगी design discussion code-level की ठोस बातचीत में होती है, और designer को codebase से भली-भाँति परिचित होना चाहिए
• सामान्य architecture principles को नए system की design, मौजूदा system में सूक्ष्म निर्णयों की सहायता, और company-स्तरीय technical दिशा तय करने तक सीमित रखना चाहिए
• जो व्यक्ति project design का प्रस्ताव रखता है, उसे उसकी सफलता और विफलता दोनों की ज़िम्मेदारी लेनी चाहिए, और वास्तव में code संभालने वाले engineers ही design के मुख्य पात्र होने चाहिए
• इससे वही व्यक्ति सच्चा designer माना जा सकेगा जो वास्तविक system को समझता हो और उसे deploy कर सकता हो

[cshj55]

इसीलिए आजकल गुरु लोग कहते हैं कि नए लोग agents को कहीं बेहतर इस्तेमाल करते हैं। जो चीज़ उन्हें लंबे समय तक पैसे कमाने देती रही, उसे वे unlearn ही नहीं कर पा रहे हैं।

[khris]

वास्तविक काम में ठोस सीमाएँ और एकरूपता बनाए रखना डिज़ाइन सिद्धांतों से कहीं ज़्यादा महत्वपूर्ण होता है, और कोड की मौजूदा स्थिति को समझना सबसे अहम है

यह मेरी भी हमेशा की मान्यता रही है, इसलिए दिल गर्म हो गया।

[coremaker]

अगर हम आर्किटेक्चर को पूरा करने वाली प्रक्रिया में सुधार करें, तो क्या उससे उठाई गई समस्याओं का पर्याप्त समाधान नहीं हो सकता?

[GN⁺]

Hacker News की राय

• टीम मीटिंग में “DRY बेहतर है या WET” जैसी बात नहीं, बल्कि “क्या इस फीचर को subsystem A में डाल सकते हैं? नहीं, वहाँ B की जानकारी नहीं है, और उसे expose करना हो तो D को फिर से लिखना पड़ेगा…” जैसी जटिल dependency पर चर्चा चलती रहती है
  इसे एक परिचित दृश्य बताते हुए मज़ाक में कई काल्पनिक सिस्टम नाम गिनाए गए, और आखिर में YouTube लिंक जोड़ा गया

  • “Wingman” नाम काफ़ी मज़ेदार है। लेकिन अभी भी ऐसे software की संख्या बहुत ज़्यादा है जो ISO8601 को support नहीं करते। Git भी पूरी तरह compatible नहीं है
  • यह बहुत ही वास्तविक व्यंग्य लगता है। आदर्श रूप में, मेरा मानना है कि एक टीम को सिर्फ़ एक service की ज़िम्मेदारी लेनी चाहिए। लेकिन आजकल हर developer पर चार-चार microservices आ जाते हैं, इसलिए थकान बहुत होती है
  • ऐसी स्थिति अक्सर तब बनती है जब programmer business system design तक संभालते हैं। design को system analyst को lead करना चाहिए

• मैंने 30 साल development किया है, लेकिन वास्तव में design और architecture पर लगातार मेहनत लगाई जाती हो, ऐसा बहुत कम देखा है
  ज़्यादातर ‘architect’ खुद design नहीं करते, बल्कि senior developer design करते हैं और बाद में बस feedback लिया जाता है
  औसत tenure 2 साल हो तो लोग system का सिर्फ़ एक हिस्सा समझकर design करने लगते हैं, और architect अक्सर सिर्फ़ approval देने वाला बन जाता है

  • John Ousterhout ने इस समस्या पर बात की है, Stanford में इस पर पढ़ाया भी है, और इसे 『A Philosophy of Software Design』 नाम की किताब में विस्तार दिया। लेक्चर वीडियो भी है
  • मैंने पहले एक ऐसे project में काम किया था जहाँ ‘architect’ था, लेकिन असल में वह सिर्फ़ मीटिंग करने वाला व्यक्ति था। सच में design सलाह देने वाला कोई नहीं था
  • 2 साल किसी subsystem को पूरी तरह बदल देने या बर्बाद कर देने के लिए काफ़ी समय है। आज का software इतनी तेज़ी से बदलता है
  • 2~3 साल में 50~100 लोगों वाले codebase को काफ़ी गहराई से समझा जा सकता है। उसके बाद अगर architecture सुधार lead करने का मौका दिया जाए, तो कंपनी तकनीकी रूप से बढ़ सकती है। architect की भूमिका ऐसे ideas को समन्वित करना और consistency बनाए रखना होनी चाहिए

• ‘Generic Software Design’ implementation की दिशा तय करने में उपयोगी है। यह एक common language और framework देता है, जिससे problem solving आसान होती है
  लेकिन वास्तविक implementation plan से अलग जा सकती है। Naur की programming theory की तरह, system की असली समझ developer के दिमाग़ में होती है

• “बड़े codebase में अच्छी design से ज़्यादा consistency महत्वपूर्ण है” — यह उसी सामान्यीकृत सलाह का जाल है
  अगर सिर्फ़ consistency पर ज़ोर दिया जाए, तो बुरी आदतें भी वैसी की वैसी बनी रहती हैं

  • हमारी company में उल्टा समस्या है: बहुत ज़्यादा आज़ादी। हर कोई अपनी तरह बनाता है, इसलिए कहीं Redux, कहीं कोई दूसरी query library मिली हुई है। आखिरकार maintenance और मुश्किल हो जाता है
  • यह सिर्फ़ code quality का मामला नहीं, बल्कि पूरे organization की efficiency का प्रश्न है। consistency हो तो development तेज़ होता है, review और onboarding आसान होते हैं। bugs भी एक साथ ठीक किए जा सकते हैं
  • वह वाक्य पढ़कर मैं भी चौंक गया था। लेकिन लेख पूरा पढ़ने पर पता चलता है कि consistency का असली अर्थ एकरूपता और शुद्धता में है
  • consistency बनाए रखते हुए क्रमिक सुधार ज़रूरी है। जब भी code छुएँ, छोटा-सा सुधार कर दें — ऐसे ‘easy wins’ जमा करना अच्छा तरीका है
  • “अच्छी design से consistency अधिक महत्वपूर्ण है” — यह Boy Scout Rule के ख़िलाफ़ जाता है। अगर सिर्फ़ consistency के पीछे भागें, तो बात पूरे refactoring तक पहुँच सकती है, जो ख़तरनाक है

• एक तरफ़ ऐसे ‘architect’ हैं जिन्हें वास्तविकता का पता नहीं, और दूसरी तरफ़ ऐसे Real Programmer हैं जो सिर्फ़ detail optimization में डूबे रहते हैं
  दोनों छोर समस्याजनक हैं, और निर्णय लेने वाले को detail और context दोनों समझने चाहिए
  इससे जुड़ी बात के रूप में The Story of Mel का उल्लेख किया गया

• “जिसने design किया है, उसी को project की सफलता और असफलता की ज़िम्मेदारी लेनी चाहिए” — इससे सहमत हूँ
  यह बात development methodology चुनने वाले व्यक्ति पर भी लागू होनी चाहिए। Scrum master आम तौर पर lead engineer जितनी ज़िम्मेदारी नहीं लेता

• जिन सबसे बेहतरीन apps पर मैंने काम किया, उनमें ये तीन विशेषताएँ थीं

  1. सरल और प्रभावी system को महत्व दिया जाता था
  2. developer खुद वास्तविक user की तरह सभी use cases समझते थे
  3. मिली हुई समस्याओं को तुरंत ठीक कर सकने की स्वायत्तता थी
     इस आज़ादी ने developer satisfaction और product quality, दोनों को बेहतर बनाया

• मेरे अनुभव में, बड़े codebase में consistency के प्रति अति-आसक्ति उल्टा गलती हो सकती है
  हर module की requirements अलग होती हैं, इसलिए test strategy और naming भी अलग होनी चाहिए

• आदर्श स्थिति में developer खुद अपने बनाए software का वास्तविक user भी होना चाहिए
  तभी वह errors या असुविधाओं को सीधे महसूस करेगा और सुधार की प्रेरणा मिलेगी

  • developer के पास ऐसा रास्ता होना चाहिए जिससे वह customer support के चरण से गुज़रे बिना user problems सीधे देख सके। tickets, forums, SNS आदि से मिलने वाली insight बहुत मूल्यवान होती है
  • XP में customer को team का हिस्सा बनाना शानदार विचार था। उसे business representative से बदल देना Scrum के मूल पापों में से एक है

• maintenance में भाग नहीं लेने वाला अलग software architect अवास्तविक है
  project लगातार बदलते रहते हैं, इसलिए दूर बैठकर सिर्फ़ निर्देश देने वाली भूमिका उपयोगी नहीं होती

  • मैंने कभी ऐसी company में काम नहीं किया जहाँ यह भूमिका वास्तव में हो। जटिल software चल रहे chess match की तरह होता है। रणनीतिक सिद्धांत ज़रूरी हैं, लेकिन board की वास्तविक स्थिति जाने बिना दी गई सलाह अर्थहीन है