धीमी डिप्लॉयमेंट से पैदा होने वाली मीटिंग्स (2015)
(tidyfirst.substack.com)- जब इंजीनियरों को लगता है कि “मीटिंग्स की वजह से कोड शिप नहीं हो पा रहा”, तब असली कारण धीमी डिप्लॉयमेंट क्षमता से पैदा हुआ संगठनात्मक ओवरहेड हो सकता है
- Facebook के Chuck Rossi का मानना था कि एक डिप्लॉयमेंट जितने बदलावों की संख्या संभाल सकता है, वह लगभग स्थिर रहती है, और बदलावों की मात्रा बढ़ानी हो तो डिप्लॉयमेंट की संख्या बढ़ानी पड़ती है
- Facebook ने PHP कोड डिप्लॉयमेंट को साप्ताहिक से दैनिक, फिर दिन में 3 बार तक बढ़ाया, और मोबाइल ऐप डिप्लॉयमेंट चक्र को 6 हफ्तों से घटाकर 4 हफ्ते, फिर 2 हफ्ते किया; इसे मुख्य रूप से release engineering team ने आगे बढ़ाया
- अगर बदलावों का उत्पादन डिप्लॉयमेंट सीमा से आगे निकल जाए, तो प्रति डिप्लॉयमेंट बदलावों की संख्या आसानी से नहीं बढ़ती; इसकी जगह मीटिंग, रिव्यू, हैंडऑफ जैसे ओवरहेड बढ़ते हैं, और संगठन कुल बदलावों की मात्रा घटाने की दिशा में खुद को ढाल लेता है
- ज्यादा बदलावों को पारित कराना हो तो सिर्फ मीटिंग्स कम करना काफी नहीं; डिप्लॉयमेंट चक्र, टेस्टिंग, मॉनिटरिंग, आइसोलेशन, और टीम के भीतर सामाजिक रिश्तों को सुधारकर डिप्लॉयमेंट क्षमता बढ़ानी होगी
मीटिंग्स कारण नहीं, परिणाम भी हो सकती हैं
- “मीटिंग्स बहुत हैं इसलिए हम कोड डिप्लॉय नहीं कर पाते” जैसी आम शिकायत में कारण-परिणाम का रिश्ता उलटा हो सकता है
- संगठनात्मक ओवरहेड जोड़ना या हटाना अपेक्षाकृत आसान है, लेकिन संगठन की कोड डिप्लॉयमेंट क्षमता बढ़ाना ज्यादा कठिन है
- मीटिंग्स और रिव्यू इस बात के संकेत हो सकते हैं कि संगठन ने डिप्लॉयमेंट सिस्टम को ओवरलोड होने से बचाने के लिए खुद को ढाला है
- Chuck Rossi ने देखा कि Facebook में एक डिप्लॉयमेंट जितने बदलाव संभाल सकता है, वह मानो तय-सा होता है
- ज्यादा बदलाव चाहिए हों तो ज्यादा डिप्लॉयमेंट करने होंगे
- PHP कोड डिप्लॉयमेंट साप्ताहिक से दैनिक, फिर दिन में 3 बार तक बढ़ा
- मोबाइल ऐप डिप्लॉयमेंट चक्र 6 हफ्तों से घटकर 4 हफ्ते, फिर 2 हफ्ते हो गया
- यह सुधार मुख्य रूप से release engineering team ने आगे बढ़ाया
डिप्लॉयमेंट क्षमता बढ़ाए बिना ओवरहेड बढ़ता है
- "प्रति डिप्लॉयमेंट बदलावों की संख्या" ऐसा अलोचदार मेट्रिक दिखता है जिसे आसानी से नहीं बढ़ाया जा सकता; इसे सुधारने के लिए बड़े प्रयास की जरूरत होती है
- अगर बनने वाले बदलाव मौजूदा सीमा से आगे निकल जाएँ, तो प्रति डिप्लॉयमेंट बदलाव बढ़ने के बजाय कुल बदलावों की मात्रा घटने का दबाव बनता है
- मीटिंग्स, रिव्यू, हैंडऑफ और अन्य ओवरहेड बढ़ते हैं
- समय के साथ उत्साह और पहल भी कम हो सकती है
- ओवरहेड में बढ़ोतरी positive feedback loop बना सकती है
- पूरा होने वाला काम घटता है
- दबाव बढ़ता है
- गलतियाँ बढ़ती हैं
- प्रति डिप्लॉयमेंट बदलावों की संख्या और घटती है
- ओवरहेड फिर से बढ़ता है
- सिर्फ ओवरहेड घटाने की अलग-थलग कोशिश दबाव बढ़ाकर ओवरहेड को फिर बढ़ा सकती है
- ज्यादा बदलावों को पार कराना हो तो "hose के दूर वाले सिरे" यानी डिप्लॉयमेंट क्षमता को चौड़ा करना होगा
- कठिन तरीका: डिप्लॉयमेंट चक्र घटाना और उससे पैदा होने वाली अव्यवस्था को संभालना
- उससे भी कठिन तरीका: बेहतर टेस्टिंग, मॉनिटरिंग, कंपोनेंट्स के बीच बेहतर आइसोलेशन, और टीम के भीतर बेहतर सामाजिक रिश्तों से प्रति डिप्लॉयमेंट बदलावों की संख्या बढ़ाना
- सिर्फ मीटिंग्स घटाने की कोशिश अंततः “मीटिंग्स कैसे घटाई जाएँ” इस पर मीटिंग्स तक ले जा सकती है
- इसे reverse-causality Thinkie के एक उदाहरण की तरह देखा जा सकता है, जहाँ शुरुआत में गलत लगने वाले विचार को परखा जाता है
2 टिप्पणियां
यह राय अच्छी है
Hacker News की राय
अफसोस, लेकिन इस लेख का निष्कर्ष थोड़ा उल्टा लगता है। टेस्टिंग और संगठनात्मक गुणों को सुधारकर deployment का जोखिम घटाना अहम है, लेकिन यह एकमात्र काम करने वाला तरीका नहीं है
लेखक ने कहा कि प्रति deployment बदलावों की संख्या fixed है और बढ़ाना मुश्किल है, लेकिन यहां जिस “Reversie Thinkie” की बात है, वह बल्कि प्रति deployment बदलावों की संख्या घटाना है। Deployment meeting मौजूद होने की वजह जोखिम है, और एक deployment में जितने ज्यादा बदलाव होंगे, bug या operational issue घुसने की संभावना उतनी बढ़ेगी। छोटे बदलावों को बार-बार deploy करने से value जल्दी पहुंचाई जा सकती है और failure भी छोटे रखे जा सकते हैं
अगर इसमें canary deployment और gradual rollout जोड़ दें, तो deployment अब switch on करके टूटेगा या नहीं वाला मामला नहीं रहता, बल्कि failure को performance degradation या limited impact में बदलने वाली दुनिया बन जाता है। यह approach DORA research[0] और Accelerate[1], The Phoenix Project[2], और उसके वैचारिक पूर्वज The Goal[3] में भी अच्छी तरह covered है
[0] https://dora.dev/
[1] https://www.amazon.co.uk/Accelerate-Software-Performing-Tech...
[2] https://www.amazon.co.uk/Phoenix-Project-Helping-Business-An...
[3] https://www.amazon.co.uk/Goal-Process-Ongoing-Improvement/dp...
असली बात यह है कि संगठन automated testing में कितना समय और संसाधन लगाता है। Release meeting इसलिए बनती है क्योंकि deployment से पहले और बाद में validate करने का infrastructure नहीं है, failed change को rollback करने का infrastructure नहीं है, और automated validation की कमी को अस्थायी manual checks से भरा जाता है। अगर QA organization में technical capability कम हो, तो self-preservation के लिए वह manual process को आगे बढ़ाता है
इससे भी बुरा यह है कि ऐसी meetings से गुजरने को excellence और best practice के संकेत की तरह package किया जाता है। क्योंकि जिस व्यक्ति को problem कम करने के लिए hire किया गया है, उसके पास उस problem को मूल रूप से खत्म करने का incentive नहीं होता। Production में bug leak हो जाए तो बात बनती है कि “developer की बनाई problem QA किसी-न-किसी वजह से पकड़ नहीं पाया”, लेकिन automated tests हों तो PR stage पर उसे miss करना भी मुश्किल होता है
Meetings जोखिम की वजह से नहीं बनतीं; वे इसलिए बनती हैं क्योंकि जोखिम होना उनके existence का कारण देता है, और संगठन में ऐसे roles होते हैं जिनके पास उसे घटाने की technology कम होती है। अगर deployment के बाद change execute हुआ और काम कर रहा है या नहीं, इसकी न्यूनतम checks automate कर सकें और failure पर automatic rollback कर सकें, तो meeting की जरूरत नहीं रहती
ऐसे कई process मुझे तब की rational लेकिन non-technical प्रतिक्रिया लगते हैं, जब मूल समाधान न हो और खराब स्थिति को जितना हो सके सहना पड़े। हालांकि वे पूरी तरह harmless भी नहीं हैं। कुछ organizations में नए projects या मौजूदा inefficiency हटाने वाले projects में भी decision-maker people-centric process को solution के रूप में लगातार आगे करते रहे
यह technical imagination की कमी या existing problem frame में फंस जाने की वजह से होता है, इसलिए जिन लोगों में ऐसी imagination है, उन्हें आगे आकर कहना चाहिए कि जहां संभव हो technical change से human process को minimize किया जाए। हर people process को technology से खत्म नहीं किया जा सकता, लेकिन गैरजरूरी चीजों पर खुद को पतला फैलाना भी नहीं चाहते
किसी अवधि में पूरे process के 2% से ज्यादा को बदलना “बहुत ज्यादा” माना जा सकता है, और इस value को adjust किया जा सकता है। Domain के हिसाब से भी फर्क होगा, इसलिए payment processing code team और HR code team के अलग criteria होने चाहिए, और releases या teams को rotate करना reasonable हो सकता है
जैसे इस अवधि में यह team मुश्किल काम करे, और live जाने के बाद फिर आसान काम पर लौटे। Trench attack, battalion advance, combined-arms operation में भी यही principle लागू होता है
बेशक यह management problem है, लेकिन इसका काफी हिस्सा automate किया जा सकता है, और किस team ने sensitive module में हाल में commit किया है जैसी sensory input भी useful है। आखिर में, यह नजरिया Agile/Scrum के sprint को अजीब बना देता है। जब पता है कि पूरी marathon को full sprint में नहीं दौड़ा जा सकता, तो sprints को rotate करके कैसे prepare किया जाए
Feature flags इस्तेमाल कर सकते हैं, लेकिन तब “inactive features backlog” बन जाता है। आखिरकार features को आम तौर पर लोग consume करते हैं, और लोगों को change पर training चाहिए होती है
वे किसी के The Phoenix Project लिखने से बहुत पहले से flow पर काम कर रहे थे, Toyota Production System principles का translation कर रहे थे, और physics को business processes पर apply कर रहे थे। The Phoenix Project भी मुझे पसंद है, लेकिन The Goal की तुलना में यह IT industry के लोगों के लिए एक सस्ता adaptation जैसा है, ताकि वे production line वाली कहानी पढ़कर “मैं PrOgrAmmEr हूं, इसलिए creative work को factory की तरह optimize नहीं किया जा सकता” कहकर भाग न जाएं
इसलिए The Phoenix Project, The Goal का spiritual successor है, उल्टा नहीं
“सॉफ़्टवेयर लिटरेसी” की अवधारणा समझाने की कोशिश है। मतलब यह कि जैसे आज कोई कंपनी policy documents और email जैसी अंग्रेज़ी लिखावटों से चल सकती है, वैसे ही business को code से भी चलाया जा सकता है
यहीं से ऐसे निष्कर्ष निकलते हैं कि “अगर GPU काम कर रहा है तो coder नया manager है”, या बदलावों का असर साफ़ दिखे इसके लिए पूरी कंपनी का test apparatus चाहिए। यह इस शानदार लेख से भी सीधे जुड़ा लगता है। अगर सभी decision-makers Jira या project plan के बजाय code को change process की first-class object के रूप में नहीं देखते, तो वे decision-makers software के लिहाज़ से literate नहीं हैं
“non-technical executives से इस पर कैसे बात करें” वाला सवाल अक्सर आता है, लेकिन जवाब है कि आप नहीं कर सकते। उन executives को बदलना होगा। यह एक बहुत बड़ा generational barrier है, जिसे 30 साल पहले भी मैं समस्या मानता था, लेकिन भोलेपन में सोचता था कि coders बड़े होंगे तो यह गायब हो जाएगा। लेकिन चूँकि कंपनी को “चलाने” के लिए coding ज़रूरी नहीं है, इसलिए जब तक coding न आना उतना शर्मनाक नहीं बनता जितना किसी newspaper editor का लिख न पाना, इसे पार करना मुश्किल है
मुख्य बात SOP, tests या meetings नहीं, बल्कि communication के रूप में systems जैसे एक-दूसरे को मजबूत करने वाले नए concepts के सेट से चल सकने वाली company की ज़रूरत है
हालांकि समझ नहीं आता कि इसे “literacy” क्यों कहा जा रहा है। Maturana & Varela का autopoiesis शब्द मूल बात के ज्यादा करीब है, और Stafford Beer के Autopoietic Systems भी अच्छा वैचारिक आधार दे सकते हैं
लेकिन किसी बिंदु पर pure software “business” बस SaaS जैसा नहीं दिखने लगता क्या?
संगठन deployment सुधारने की कोशिशों को सक्रिय रूप से रोकेंगे। वे गंभीर चेहरे से कहते हैं, “Jenkins को production environment के आसपास नहीं रखना चाहिए”, “QA के बिना live नहीं कर सकते”, “software quality की पर्याप्त guarantee के लिए इतना समय चाहिए”
और साथ ही production bugs लाखों में हैं, और product users की requirements मुश्किल से पूरी करता है। आखिरकार ज़्यादातर संगठनों में bureaucracy से लड़ना लगभग नामुमकिन है। खासकर अगर आप उन 200 परतों वाले management layers का हिस्सा नहीं हैं जो ऐसी meetings पैदा करते हैं
मन करता है कि बस दो लोग—एक programmer और एक designer—रह जाएँ और बाकी सबको बाहर कर दिया जाए, फिर agile coaches, product owners, scrum masters, product experts के बिना उन्हें खुद निपटने दिया जाए। slow deployment समस्या है, लेकिन वही समस्या का मूल नहीं है
अगर आप बार-बार ऐसी जगहों पर पहुँच रहे हैं जहाँ कुछ बदलना असंभव लगता है, तो interviews में इस बारे में और पूछना चाहिए। छोटी कंपनियों में मेरी पसंद के मुताबिक पागल bureaucracy से मुक्त जगहें बहुत मिलीं, और अब मैं एक बड़ी company में हूँ, लेकिन अगर लगातार और persuasive तरीके से आगे बढ़ें तो बहुत कुछ धीरे-धीरे सही दिशा में जा सकता है
समझना होगा कि चीज़ों में समय लगता है, और पहले यह समझना होगा कि लोगों ने उसे ऐसा क्यों बनाया, फिर उसे बेहतर बनाने के लिए दमदार argument ढूँढना होगा। सचमुच बहुत खराब जगहें भी होती हैं, इसलिए वहाँ न रुकना सही है, लेकिन निराशा ज़्यादा मदद नहीं करती
खोलने-समझने को बहुत कुछ होगा, लेकिन मेरा bias इस दावे की तरफ़ है
Jenkins software development दुनिया का Wordpress है। यह plugins चलाने वाला एक विशाल state loop है, जिसमें permissions separation नहीं होता। Jenkins instance को production admin credentials देना ऐसा हो सकता है जैसे Romania के किसी ऐसे व्यक्ति को root keys दे देना जिसने कोई plugin बनाया है जिसकी आपने audit नहीं की। यह बिल्कुल समझ में आता है कि हर कोई ऐसा न चाहे
“QA के बिना live नहीं कर सकते” भी ऐसा ही है। अगर आप ऐसी चीज़ production में deploy कर रहे हैं जो कभी QA से गुज़री ही नहीं, तो QA है ही क्यों? बाद में ठीक करने के लिए? अगर authority नहीं देंगे तो QA को न अपना काम अच्छी तरह करने का मौका मिलेगा, न अपने काम पर गर्व करने का
किसी भी initiative में पहले दिन से Jenkins production तक जाता था, अक्सर सीधे trunk-based development तक, और quality हर developer की ज़िम्मेदारी थी। individual contributor स्तर पर “bureaucracy से लड़ाई” नहीं थी, लेकिन जहाँ external partners और stakeholders गहराई से जुड़े थे, वहाँ leadership के बीच कभी-कभी तीखी discussions हुई होंगी
सिर्फ programmers और designers छोड़ने वाला तरीका मेरे लिए अच्छा है, लेकिन scale नहीं होता। stakeholder priorities को queue में रखने के लिए कम से कम एक product “owner”, “expert”, “manager” होना चाहिए। इस भूमिका को developers और designers बारी-बारी से पहनने वाली “hat” भी बना सकते हैं, लेकिन कुछ लोग इस skill में खास तौर पर बहुत अच्छे होते हैं
मैं यह भी समझता हूँ कि बहुत से संगठन ऐसे operate नहीं करते। किसी company को इस दिशा में बदलते समय, इन practices के लिए committed volunteers की एक single experimental team बनाना, और ऊपर से मिले authority से उसे protect करना लेकिन direct न करना, मददगार रहा है। बेशक, यह California है
थोड़ा संबंधित बात है, लेकिन मैंने एक ऐसी जगह काम किया था जहाँ CI pipeline में करीब 25 मिनट लगते थे और उसमें से 3000 से ज्यादा unit/integration tests 18 मिनट खा जाते थे
production में जब भी कोई issue आता, हम और tests जोड़ देते, और जाहिर है, अगर चीज़ें बिगड़तीं तो recovery में कम से कम 50 मिनट चाहिए होते। काफी सोच-विचार के बाद हमने recovery पर focus करने का फैसला किया, कुछ tests को loosen और simplify करके पूरा समय 5 मिनट से कम कर दिया, और rolling updates के बजाय canary deployment इस्तेमाल किया
हमारे लिए यह सचमुच ताज़ा अनुभव था, लेकिन कुछ मायनों में गलत भी महसूस हुआ
बेशक उस deployment speed में तरह-तरह के factors उलझे होते हैं, लेकिन उनमें से लगभग ज़्यादातर अच्छे factors होते हैं
थोड़ा विषयांतर है, लेकिन CloudFormation इतना धीमा क्यों है?
VPC के अंदर की Lambda को delete कर EFS से जुड़े एक केस में, deployment अपने-आप में काफ़ी तेज़ था, लेकिन CloudFormation को cleanup करके finish करने में करीब 20 मिनट लगे
state changes को transaction की तरह deploy करते समय हर step पर preconditions और postconditions verify करनी पड़ती हैं। जिन changes के समूह में आपसी dependencies ज़रा भी हों, उन्हें release करने के लिए हर change को sequential steps में deploy करना ही पड़ता है। हर step change apply करने, authentication और state polling के लिए कई network calls करता है, और हर call में करीब 50–200ms लगते हैं, जो जल्दी ही जुड़ते जाते हैं
Terraform या Ansible से किसी दूसरे cloud provider पर वही app deploy करने पर भी मिलते-जुलते नतीजे मिलते हैं। वही change अगर manually deploy करें तो कुछ मिनट का काम पूरे दिन की यातना बन जाता है
IaC की सबसे बड़ी समस्या यह है कि यह बहुत high-level है और अंदर बहुत ज़्यादा काम करता है, जिससे ऐसे लोग पैदा हो जाते हैं जिन्हें पता ही नहीं होता कि कौन-सा change सच में apply हो रहा है या यह कर क्या रहा है। फिर वे शिकायत करते हैं कि इसमें बहुत समय लगता है
कामकाजी जीवन में मेरे साथ व्यक्तिगत रूप से ऐसा हुआ है। Christmas छुट्टियों से पहले एक बड़ा change था और बहुत डर था। संगठन ने test बढ़ाकर response दिया, यानी regression tests बढ़ाकर overhead बढ़ा दिया
इससे dev के changes द्वारा मेरी branch के changes तोड़ने का जोखिम बढ़ गया। यह code merge conflict वाला जोखिम नहीं था, बल्कि complex adaptive system के नज़रिए से जोखिम था। मैंने इस जोखिम से निपटने के लिए meetings बनाईं, और project schedule बताते हुए साथियों को expectations समझाईं कि अगर वे PR पर code style comments छोड़ेंगे, तो उन्हें बाद के PR पर टाल दिया जाएगा और अंततः ignore कर दिया जाएगा
असल ज़रूरत थी components के बीच बेहतर isolation वाले fine-grained tests की। समस्या यह है कि management बहुत high level पर ही देखता है, और meetings को साधन नहीं बल्कि अपने-आप में हासिल करने लायक लक्ष्य मानता है। सोच यह होती है कि meetings ज़्यादा हैं तो collaboration ज़्यादा है, और इसलिए यह अच्छा है। मैं non-technical management के साथ technical change drive करने पर सलाह देखना चाहूँगा
संबंधित लेख: Slow Deployment Causes Meetings - https://news.ycombinator.com/item?id=10622834 - नवंबर 2015, 26 comments
microservices इस्तेमाल करें तो deployment frequency को भी horizontal scale किया जा सकता है
independent modules से बनी monolithic app से भी microservices के बिना उतनी ही deployment की जा सकती है, और infrastructure/CI·CD complexity या app के function calls को unreliable distributed system communication problem में बदलने जैसी मुख्य कमियों से बचा जा सकता है। गैर-ज़रूरी accidental complexity का विरोध करना चाहिए
[1] https://www.fearofoblivion.com/build-a-modular-monolith-firs...
[2] https://ardalis.com/introducing-modular-monoliths-goldilocks...
और deployment planning और feature rollout synchronization जैसी मज़ेदार नई समस्याएँ भी मिलती हैं
वरना आपको distributed data की समस्या और complexity की और भी stages मिलती हैं—यानी monolith से भी ज़्यादा meetings
monolith में SOLID, DRY और दूसरी “clean code” वाली बकवास के बड़े अराजक ढेर में यह जोखिम होता है कि कोई भी कुछ बदलने से डरता है कि कहीं कुछ टूट न जाए। इसका मतलब यह नहीं कि object-oriented principles अपने-आप में सतही तौर पर गलत हैं, लेकिन वे इतने हद तक vague होते हैं कि अक्सर कोई उन्हें ठीक से लागू नहीं कर पाता
Uncle Bob जब भी criticism आता है तो “उन्होंने principles को गलत समझा” कहकर टाल देते हैं, यह देखकर मुझे हमेशा हँसी आती है। अगर इतने लोग गलत हैं, तो क्या principles ही खराब नहीं हो सकते? microservices भी bad governance से नहीं बचाते; समस्या बस दूसरे रूप में सामने आती है। कई microservices बना लेना और फिर किसी change का दूसरी service पर क्या असर होगा, यह किसी को न पता होना बहुत आसान और आम है
अंततः यह team management की समस्या है, और अनुभव के हिसाब से यही वह क्षेत्र है जिसमें हमारी industry सबसे खराब है। “Team Topologies” जैसी नई पीढ़ी आएगी तो सुधार होगा, लेकिन सचमुच खत्म होने में, अगर कभी हुआ भी, दशकों लगेंगे। अगर organizations “IT” को सिर्फ़ cost center मानती रहें और requirements इस तरह न रखें कि वे software engineering best practices की process में शामिल हो सकें, तो मामला अक्सर digitization department के हाथ से भी निकल जाता है
general-purpose language के रूप में Go पसंद करने की मेरी एक वजह यह है कि design के लिहाज़ से यह simple है, इसलिए अक्सर ऐसे codebases बनते हैं जिन्हें change करना आसान होता है। मैंने कुछ online banks और rental/asset management platforms को Go पर migrate करते देखा है, जिससे वे business को जो चाहिए था वह सच में deliver कर पाए और grow हुए। वहीं competitors मुश्किल Java या C# codebases में फँसे रहे, और किस्मत अच्छी रही तो छह महीने में एक बार bugs से भरा feature निकाल पाए
यह Go, Java या C# की अपनी समस्या नहीं है, बल्कि old-school object-oriented architecture और design को बिगाड़ना बहुत आसान है। पहले जहाँ काम किया था, वहाँ C# interfaces एक हज़ार से ज़्यादा थे, लेकिन कोई भी interface दो या अधिक classes द्वारा consume नहीं होता था। दसियों हज़ार interfaces सभी एक ही folder और namespace में थे, और ज़रूरी चीज़ खोजने के लिए किस्मत चाहिए थी। Go या किसी भी language में ऐसा किया जा सकता है, लेकिन अगर आप पुराने object-oriented clean code language culture में नहीं हैं तो इसकी संभावना कम है। खासकर C# में default abstractions culture में इतनी गहराई से बैठे हैं कि उन्हें न करना ही ज़्यादा कठिन है
व्यक्तिगत रूप से मुझे Python organizations से एक गुप्त लगाव है। वे हमेशा तेजी से deliver करते हैं और code भयानक होता है। प्यारा लगता है
कुल मिलाकर सही है, लेकिन उतना ही अप्रासंगिक भी
संक्षेप में, software performance, और इसलिए human performance ही मायने रखती है। Risk management और risk acceptance को numbers में मापा जा सकता है। Software में यह दूसरे पेशों की तुलना में कहीं सरल है, क्योंकि software engineer केवल ज्ञात operational constraints के भीतर ही risk स्वीकार कर सकते हैं और बाकी सब टाल दिया जाता है
अगर आप तेज़ होना चाहते हैं, तो सबसे पहले human iteration frequency को अधिकतम करना होगा। अगर permission का इंतज़ार करते हुए iterate नहीं कर सकते, तो आप blocked हैं; और अगर build या screen refresh का इंतज़ार कर रहे हैं, तो आप धीमे हो गए हैं। इसे भी numbers में मापा जा सकता है
अगर A, B की तुलना में 100 गुना तेज़ iterate कर सकता है, तो correctness secondary हो जाती है। B धीमा है, इसलिए उसे correctness को maximize करना पड़ता है। A के पास सीखने, fail करने और improve करने की जबरदस्त flexibility होती है, ताकि वह और तेज़ और और accurate बन सके
तेज़ी से iterate करते हुए risk कम करने का एक हिस्सा fast test automation है। अगर A, human iterations के 4 rounds के समय में 90% से ज़्यादा test coverage चला सकता है, तो वह test automation अब भी B के एक iteration से 25 गुना तेज़ है और regression risk 90% से ज़्यादा कम है
तेज़ deployment incident response war room बनाता है
उस कमी से भी कहीं ज़्यादा महत्वपूर्ण यह था कि जब समस्या आती थी, तो root cause ढूंढने की speed बहुत बढ़ गई। Rollback होने वाले changes बहुत कम होते थे, इसलिए वापस लौटाना भी कहीं ज़्यादा सुरक्षित और आसान था। कोई भी 3 हफ्तों का काम rollback नहीं करना चाहता। वह तो chaos है