इस ऐप को बनाने की प्रक्रिया में किसी भी कुत्ते को नुकसान नहीं पहुंचा

• 2016 में React Native मोबाइल ऐप के location-info photo upload feature के Android beta में ही fail होने और local Android व iOS पर reproduce न होने वाली समस्या को एक हफ्ते तक trace किया गया
• Android beta में image upload fail होने पर भी error feedback नहीं मिलता था, और Play Store पर हर नया build डालने में लगभग 1 घंटा लगने से hypothesis verify करना धीमा हो गया
• Embedded, hardware, chemistry और veterinary medicine के उदाहरणों से तुलना करने पर दिखता है कि software debugging कहीं ज्यादा तेज और observable होती है
• असली कारण image MIME type को "jpg" लिखने का एक अक्षर का फर्क था; file extension .jpg होने पर भी MIME type "jpeg" होना चाहिए था
• logs, real-time observation, debugger और repeat experiments को सस्ते में इस्तेमाल कर पाने वाला development environment, दूसरे पेशों के feedback loops की तुलना में एक बड़े privilege जैसा है

---

Android beta में ही fail हुआ photo upload

• React Native मोबाइल ऐप का geolocated photos feature सोमवार को release के लिए तैयार लगता था, लेकिन Android beta rollout के बाद images upload नहीं हुईं
• local Android test और iOS beta में यह ठीक चल रहा था, इसलिए failure का कारण तुरंत सामने नहीं आया
• error handling बेहतर करने वाला version फिर से upload करने पर भी upload failure अब भी बिना feedback के होता रहा
• नया iteration Play Store पर डालने में लगभग 1 घंटा लगता था, और अगली hypothesis तैयार करते हुए build deploy होने का इंतजार करना पड़ता था

दूसरे पेशों के लंबे feedback loops

• Embedded engineer ने remote equipment पर firmware update deploy करने के बाद node के response न देने की स्थिति झेली
  • कारण समझने के लिए equipment वापस मंगाकर analysis करना पड़ता है
  • कुछ मामलों में क्या गलत हुआ यह पता लगाने में कई महीने लग जाते हैं
• Hardware engineer मानता है कि remote में deploy किया गया नया hardware कई मौसम झेलने के बाद ही design flaws दिखा सकता है
  • पुराने equipment को डाक से वापस लेकर अगली generation के product में fixes शामिल किए जाते हैं
  • heat कम करने के लिए vents जोड़े गए, लेकिन holes इतने बड़े थे कि उनमें ततैया घोंसला बना सके, जिससे यह और भी खराब bug बन गया—ऐसा एक मामला भी था
  • lab testing संभव है, लेकिन final validation आखिरकार field में ही होता है

failure को स्वीकार करने का तरीका

• CEO ने याद किया कि PhD thesis की तैयारी के दौरान chemist रहते हुए उन्होंने महंगे chemicals के लिए बड़े research grant से experiment किया, लेकिन कई हफ्तों बाद result experimental error के कारण fail हुआ लगता था
• वे यह पता नहीं लगा पाए कि क्या गलत हुआ, और यह पूछे जाने पर भी जवाब नहीं दे पाए कि वही error दोहराने से बचने के लिए वे क्या अलग करेंगे
• फिर भी उन्हें दूसरा research grant मिला, और यह अनुभव failed व्यक्ति को फिर खड़ा करने वाली empathetic leadership का उदाहरण बना

Veterinary medicine का उदाहरण, जिसमें risk ज्यादा था

• veterinarian दोस्त एक बूढ़े और बीमार कुत्ते का इलाज कर रहा था और owner को X-ray की सलाह दी, लेकिन cost के कारण उसने मना कर दिया
• X-ray के बिना सबसे अच्छा जो किया जा सकता था, वह था बाहर से कुत्ते का पेट टटोलना, और एक बड़ी चीज महसूस हुई
• surgery से निकाली गई चीज corn cob थी, लेकिन X-ray न होने के कारण यह पक्का नहीं कहा जा सकता था कि समस्या बस वही थी
• अगले दिन वह कुत्ता मर गया, और mobile app release की समस्या के उलट, दूसरे पेशों की failures में सचमुच जिंदगी और मौत दांव पर हो सकती है

एक-अक्षर का bug और debugging tools का privilege

• शुक्रवार सुबह Android docs और codebase के बीच mismatch दिखा, और पूरे हफ्ते समस्या पैदा करने वाला कारण सिर्फ एक character था
• image MIME type "jpg" set था, लेकिन असल में वह "jpeg" होना चाहिए था, जबकि file .jpg के रूप में save थी
• Software developers complex processes के भीतर गहराई से देख सकते हैं, real-time behavior monitor कर सकते हैं, logs रख सकते हैं, और debugger से execution रोककर inspect कर सकते हैं
• यह capability सस्ती और तेज है, और कुछ clicks में एक ही दिन में कई बार experiments repeat किए जा सकते हैं
• Software भी दूसरे पेशों जितना महत्वपूर्ण और प्रभावशाली हो सकता है, लेकिन developers ऐसे environment में काम करते हैं जहां अपने मौजूदा debugging tools के लिए आभारी होना बनता है

[GN⁺]

Hacker News की रायें

• यह लगभग एक दृष्टांत जैसी कहानी है कि software engineering दूसरे पेशों से, मज़ाक में कहें तो ‘असली’ पेशों से कैसे अलग है
  मुझे इसका छोटा और चतुर version भी पसंद है: एक software engineer, एक hardware engineer और एक department head Switzerland में meeting के लिए जा रहे थे, तभी एक खड़ी पहाड़ी सड़क पर brakes fail हो गए, कार guardrail से टकराती हुई नीचे जाने लगी और चमत्कारिक रूप से रुक गई
  department head कहता है कि meeting बुलाकर vision, mission और goals तय करें और continuous improvement से core problem हल करें; hardware engineer कहता है कि Swiss Army knife से brakes खोलकर ठीक कर देते हैं
  software engineer कहता है, “कुछ भी करने से पहले कार को वापस ऊपर धकेलते हैं और देखते हैं कि क्या यह फिर से reproduce होता है”

  • software engineering का बड़ा फायदा यह है कि यह abstractions से काम करती है। यह बादलों पर महल बनाने जैसा है, जहाँ foundation तक सब कुछ फिर से गढ़ा जा सकता है
    साथ ही software engineering की बड़ी कमी भी यही है कि यह abstractions से काम करती है। foundation तक सब कुछ हिलता रहता है
    http://thecodelesscode.com/case/154
  • क्या इस कहानी की सीख बस यह है कि hardware engineer सही है?
  • mechanical engineer है
  • अगर ‘run again’ दबाने पर कार चमत्कार की तरह पहाड़ी के ऊपर फिर से आ जाए, वही घटना दोहराए, और जिस पल brakes fail होते हैं उस समय को रोककर कार के हर हिस्से को खोलकर real-time, slow motion और reverse playback में ठीक-ठीक देखा जा सके कि समस्या कहाँ है, तो कैसा हो
    ऐसी क्षमता होने का मतलब यह नहीं कि software engineer हास्यास्पद या अवास्तविक है
    digital space की engineering ऐसी debugging क्षमताएँ देती है जो physical क्षेत्रों में लगभग चमत्कार जैसी हैं। अगर एक जैसी 10 चीजें बनाकर 10 तरीकों से test करना चाहते हैं, तो सचमुच CTRL+C, CTRL+V करना है। मैं किसी mechanic को ऐसा करते देखना चाहूँगा
  • सिर्फ brakes काम नहीं कर रहे, engine तो ठीक है। कार को पहाड़ी पर ऊपर धकेलने की ज़रूरत ही क्यों है?
  • मैं सारी windows बंद करके restart करूँगा

• मैं इस शिकायत से सचमुच थक चुका हूँ कि software engineers ‘real engineers’ नहीं हैं और समाधान के लिए और ज्यादा बड़े pre-design meetings और भारी planning करनी चाहिए
  दूसरे engineering fields ऐसे काम इसलिए नहीं करते कि वे हमसे कहीं ज्यादा professional हैं, या वह तरीका बेहतर है, बल्कि इसलिए कि उनके पास यही एक तरीका है। hotel पूरा बन जाने के बाद अगर पता चले कि ceiling को 6 inch ऊँचा होना चाहिए था, तो वे सब कुछ गिराकर फिर से नहीं बनाते
  अगर ceilingHeight += 6 चलाकर “Rebuild” दबाने पर hotel फिर से बन जाए, automated unit tests accessibility तक check कर लें और कुल खर्च 2.82 dollar हो, तो वे भी बेशक वही करते
  inferiority complex छोड़ना होगा। हम ऐसी tools से engineering कर रहे हैं जिनके बारे में real-world civil और mechanical engineers सपने में भी नहीं सोच सकते, और इसके चलते process का बहुत अलग होना स्वाभाविक है
  बेशक कभी-कभी हम problem पर पर्याप्त process लागू नहीं कर पाते। लेकिन अगर आपको लगता है कि यह सिर्फ programming की समस्या है, तो मैं https://www.imdb.com/title/tt4788946/ कुछ घंटे देखने की prescription देना चाहूँगा

  • लगता है आपने मुख्य बात छोड़ दी। असली मुद्दा upfront planning या meetings नहीं हैं; वे पहले के criteria के परिणाम हैं। engineering practical problems को scientifically solve करना है, जहाँ safety, repeatability और solution के principles की समझ non-negotiable हों; solver ethics और scientific rigor में engineer की qualification रखता हो; और उसी qualification के कारण approve किए गए solution के fail होने पर liability से बच न सके
    यह superiority complex नहीं है; आपके criteria में से कोई एक भी गायब हो तो आप engineering नहीं कर रहे। मेरे अनुभव में अधिकांश software development में चारों चीजें गायब होती हैं। यह ज़रूरी नहीं कि बुरा हो, लेकिन ज़्यादातर software development engineering नहीं है
    इसका मतलब बिल्कुल नहीं कि engineering, development से superior है
  • पूरी तरह सहमत। अलग-अलग mediums के लिए अलग-अलग optimized processes और techniques होती हैं
    यह clay sculpture और marble sculpture के फर्क जैसा है। clay में गलती हो जाए तो जल्दी से फिर से shape दे सकते हैं, लेकिन marble में अगर वह हिस्सा काट दिया जिसे नहीं काटना था, तो नया marble block order करना पड़ेगा
    marble sculpting method को clay की दुनिया में लाएँगे तो आप बस खराब, या कम से कम बहुत inefficient, clay sculptor बनेंगे
    clay और marble में कौन-सी sculpture ज्यादा valuable है, यह मुकाबला भी खास meaningful नहीं है। समाज में दोनों की अपनी जगह है
  • पूरी तरह अलग बात है, लेकिन 3D printing पसंद आने की एक वजह यह है कि real world में यह ceilingHeight += 6 के सबसे करीब का अनुभव देती है
    आज भी मैंने एक चीज model करके print की, और समझ आया कि एक हिस्सा करीब 1mm और मोटा हो तो अच्छा होगा। 30 seconds बाद version 2 printer को जा रहा था
    वाकई कमाल है। ऐसी चीजों के paper printer जितना mainstream होने का इंतज़ार करना मुश्किल है
  • जो लोग सोचते हैं कि software engineering असली engineering नहीं है, उन्हें यह जानकर आश्चर्य होगा कि ‘real’ engineering का काफी बड़ा हिस्सा बस software में numbers डालना है
  • CAD से पहले design किए गए airplanes और jets देखें तो engineering design भी field में काफी सुधार किया जा सकता है। वे ऐसे फिट बनते थे कि बनाने वाले और ठीक करने वाले लोगों के दिमाग में know-how बसा होता था
    https://www.youtube.com/watch?v=NPVT2lvMvOk

• अपने पूरे career में कई बार ऐसा हुआ कि कोई error आ रही थी, लेकिन सब कुछ पूरी तरह silent था, इसलिए सभी अटक गए। कोई error output नहीं, कुछ भी नहीं
  ऐसे मामलों में से काफी में वजह यह निकली कि कोई low-level third-party library catch (e) {} कर रही थी। career के शुरुआती दिनों का पहला ऐसा case अच्छा सबक बना, और अब मैं किसी भी error को casually ignore नहीं करता। कम से कम log तो करता हूँ
  जो software आप अभी बना रहे हैं, वह 5 साल बाद ऐसे environment में इस्तेमाल हो सकता है जिसकी आपने कल्पना भी न की हो

  • “यह function टीम के सभी लोगों के लिए इतना clear है कि comment की ज़रूरत नहीं” ऐसा सोचते हैं
    30 साल बाद:
    /* X systems I modul body I 14.09.1990 */
void xxvcda(int *addr, int sizeof)
  • सच में ऐसा ही है। अभी जिस code को देख रहा हूँ, उसमें पहले थोड़े समय के लिए आए author ने lower library exception को निगल लिया है, और उसकी जगह पूरी तरह बेकार exception throw कर रहा है
    उन्हें यह language feature भी नहीं पता था कि पुराने exception से नया exception उठाकर stack trace का context preserve किया जा सकता है। मज़ेदार मामला है। कम से कम यह मेरे day job का code नहीं है, लेकिन day job में भी अपनी अलग मज़ेदार चीजें हैं
  • हाल में DRF और JWT के साथ भी ऐसा ही हुआ। intermittent timing problem की वजह से JWT valid नहीं था और login नहीं हो पा रहा था
    DRF ने validation error निगल लिया और सिर्फ generic error return किया, इसलिए कोई clue नहीं था; आखिरकार खुद नीचे तक जाकर logging जोड़नी पड़ी ताकि पता चले कि क्या हो रहा है

• मेरे एक physicist दोस्त अक्सर Rutherford की यह बात उद्धृत करते थे: “सारा विज्ञान या तो physics है या stamp collecting”
  उनका मतलब यह था कि mathematics या computer science के उलट, physics के पास भौतिक वास्तविकता से verify होने का एक तरीका होता है
  उनका क्षेत्र extreme magnetic fields था, और उनके प्रयोग कुछ ऐसे होते थे: विशाल copper coils बनाना, उनमें इतना current डालना कि वे पिघलने लगें, फिर coil के आसपास explosives फोड़कर बहुत ही छोटे पल के लिए केंद्र का magnetic field मानव-निर्मित चीज़ों में सबसे शक्तिशाली बना देना, और फिर हजारों डिग्री तापमान वाला liquid copper उछलता हुआ पूरे apparatus को नष्ट कर देता
  ऐसे काम के माहौल में गलती या miscalculation का मतलब था कि लोग बहुत जल्दी और भयानक तरीके से मर सकते हैं। इसलिए वे उन math PhD छात्रों से सहमत नहीं होते थे जो खुद को scientist कहते थे, जबकि उनके लिए अधिकतम नुकसान sweater पर chalk dust लगना होता था

  • उस quote की यह काफ़ी अजीब interpretation है। कई किताबों के मुताबिक उसका मतलब यह है कि विज्ञान या तो mathematical/quantitative होता है, या फिर descriptive
    यानी या तो आप किसी subject की dynamics समझने की कोशिश कर रहे होते हैं, या बस दिलचस्प facts इकट्ठा कर रहे होते हैं और जिन चीज़ों में रुचि है उन्हें नाम दे रहे होते हैं
  • Explosively pumped magnetic flux compression generator[1] मज़ेदार चीज़ है
    जो लोग supervillain career में रुचि रखते हैं लेकिन समझ नहीं पा रहे कि शुरू कहाँ से करें, उनके लिए बता दूँ: असली EMP ऐसे ही बनाया जाता है
    [1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
  • मैं सोचता था Dijkstra इतने arrogant क्यों थे, फिर पता चला कि उन्होंने theoretical physics पढ़ी थी, तो समझ आ गया
  • मैंने mathematicians को खुद को scientist कहते हुए ज़्यादा नहीं देखा। उल्टा, वे आम तौर पर यह brag करते हैं कि वे scientist नहीं हैं और reality की छोटी-मोटी सीमाओं से बंधे नहीं हैं
  • एक physicist की तरह उन्होंने उस quote को गलत समझा है

• ऐसी घटना के बाद हमेशा लगता है कि upstream corrective action होना चाहिए। अगर proper logging और error reporting होती, तो इसे ठीक करने में एक हफ्ता नहीं लगता
  जिस library को गलत image/jpg MIME type मिला, उसे exception throw करना चाहिए था, crash करना चाहिए था, या कम से कम ज़ोरदार तरीके से log करना चाहिए था। सोच रहा हूँ कि original author ने उस library में bug file किया था या नहीं

  • लेख के अंत में मुझे यह जानने की उत्सुकता हुई कि Shawn किस तरह के environment में काम कर रहे थे कि diagnosis में इतना समय लग गया
    क्या उनके पास यह confirm या deny करने की access थी कि server पर image uploads सच में आ रहे थे? Test environment में upload हो रहा था लेकिन app release version में क्यों नहीं हुआ? Test environment में क्या अलग था?
    सिद्धांत रूप में Shawn के पास इतनी access होनी चाहिए थी कि वे या तो server खुद चला सकें, या upload के चुपचाप fail होने की वजह diagnose करने वाले किसी व्यक्ति से मदद मांग सकें, और “upload सफल है तो दिख क्यों नहीं रहा?” का जवाब काफ़ी जल्दी पा सकें
    मेरे हिसाब से “image MIME type jpg था और jpeg होना चाहिए था” से ज़्यादा महत्वपूर्ण सीख यह है कि test में काम कर रहा था लेकिन production में नहीं, ऐसा क्यों हुआ। bug से भी बड़ा मुद्दा यह है कि environment ने bug ढूँढना इतना मुश्किल क्यों बना दिया
    मेरे मामले में एक desktop app बुरी तरह malfunction कर रहा था, लेकिन error logs में नहीं आ रहा था। कई दिनों बाद पता चला कि file handles खत्म हो गए थे, और log4net भी file handle न मिले तो log नहीं लिख पाता। एक छोटे bug fix को revert करना आसान solution था, लेकिन असली fix यह था कि log4net को customize करके log file हमेशा open रखवाई जाए। तब app सारे file handles खत्म कर दे, फिर भी error record हो जाता
  • लेख का संबंधित paragraph थोड़ा खटका: “मैंने improved error handling वाला version दोबारा upload किया, लेकिन image upload बिना किसी feedback के fail हुआ। आम तौर पर code लाल text में error चिल्लाकर दिखाता है, और silence लक्ष्य होता है। यहाँ silence समस्या थी।”
    silence लक्ष्य नहीं है। बहुत सारे developers silence को लक्ष्य समझते हैं, लेकिन असली लक्ष्य correctness है। अगर errors नहीं हैं तो शांत रहना चाहिए, लेकिन अगर user को प्रभावित करने वाला error है तो बड़ा लाल warning box होना चाहिए
    मुझे लगता है developers को error messages पसंद करना सीखना चाहिए। अच्छी तरह लिखा error message कारण को जल्दी सामने ला देता है और सभी का बहुत समय बचाता है
    अगर इस developer ने आगे से error messages ज्यादा बार दिखाना सीख लिया, तो यह बहुत अच्छा परिणाम है

• मुझे एक पुराने colleague की बात याद आती है जो अक्सर कहते थे, “हम कोई air traffic control system तो बना नहीं रहे।” उनका मतलब था कि गलती होने पर जान पर नहीं बनेगी
  उस समय हम games बना रहे थे, लेकिन यह बात लगभग हर CRUD app पर भी लागू होती थी जो मैंने लिखी
  अलग से, मैं दूसरे senior tech leaders, खासकर Director, VP, CTO से अक्सर पूछता हूँ: “आपकी सबसे महंगी गलती क्या थी?” अगर आप junior engineer हैं तो किसी दिन यह ज़रूर करें
  कई senior tech leaders के पास 100,000 से 1 million dollar तक की कहानियाँ होती हैं। मैंने ऐसे लोगों को भी देखा है जिन्होंने project में कई million dollars डुबो दिए और तुरंत promote हो गए। यह समझना महत्वपूर्ण है कि ऐसा कैसे संभव है, और यहाँ तक कि यह अच्छी बात क्यों हो सकती है

  • असहमत हूँ। failure शायद आग के गोले में मौत तक न ले जाए, फिर भी नुकसान पहुँचा सकता है। छोटा नुकसान भी scale पर जमा होता जाता है
    bug वाले game से होने वाली frustration असल दुनिया में road rage या चिल्ला-चिल्लाकर झगड़े तक पहुँच सकती है। computers ने गलत bills भेजे और लोगों ने suicide किया है। software ने कीमती data खो दिया और companies बर्बाद हुई हैं
    मामूली लगने वाले social media apps की वजह से भी लोगों की हत्या हुई है, और Twitter पर नरसंहार भड़काने की organizing हुई है। Pokemon Go द्वारा leak की गई जानकारी से लोगों का stalking और assault हुआ है
    software में वास्तविक शक्ति होती है। ऐसा न होता तो software लिखने की कोई वजह भी नहीं होती
  • “हम कोई air traffic control system तो बना नहीं रहे” वाला रवैया मुझे भी असहज करता है
    मैंने ऐसा software बनाया है जिससे कीमती data खो सकता था, और अब ऐसा software बना रहा हूँ जो malfunction करे तो flooding कर सकता है
    अपने काम पर थोड़ा और pride होना चाहिए

• software engineer के तौर पर मुझे debugging काफ़ी पसंद थी। क्योंकि यह design बनाने और implement करने से अलग skills और सोचने का तरीका इस्तेमाल करवाती थी
  बेशक, इसका मतलब यह नहीं कि debugging stress नहीं देती। AT&T के 5ESS telephone switch software को develop करते समय एक demo था, और test lab में हमारी feature के लिए configured सिर्फ़ एक phone line थी
  कई बार कोशिश करने पर भी software काम नहीं कर रहा था, और मुझे पूरा यक़ीन था कि software ठीक है, इसलिए possible हर चीज़ check करते हुए stress हो रहा था। आखिर में lab technician से line check करने को कहा, तो पता चला कि इकलौती configured line किसी तरह disconnect हो गई थी। बेवकूफ़ी भरी hardware problem थी

  • मेरे साथ भी ऐसा ही है। खासकर complex systems में debugging की चुनौती मुझे हमेशा पसंद आई है
  • Tools हों तो debugging मज़ेदार होती है, लेकिन अगर choices के नतीजे में सब कुछ, metaphorically या literally, बहुत दूर-दूर हो जाए तो अच्छा नहीं लगता
    Cloud में distributed systems की debugging, सभी services को local पर चला पाने की तुलना में exponentially ज़्यादा भयानक होती है, और वह local distributed system भी किसी problem को एक ही program के अंदर debug कर पाने से कहीं ज़्यादा खराब होता है
    असली debugger भी debugging को बहुत बेहतर बना देता है। मैं उन लोगों को कभी समझ नहीं पाया जो printf debugging या real debugger में से सिर्फ़ एक पर अड़े रहते हैं। दोनों इस्तेमाल करने में बहुत बड़ा फायदा है। अच्छी tracing भी, अगर possible हो, printf debugging से कहीं बेहतर होती है, इसलिए यहाँ इसे highlight करना बनता है
    Programming के शुरुआती दिनों में, “यह क्यों हो रहा है” न जानने की स्थिति से मैंने बहुत सारी unnecessary emotions जोड़ ली थीं, लेकिन धीरे-धीरे “रुको, ऐसा क्यों है? पता नहीं… अरे, एक मिनट… वाह, इसके fail होने की वजह सच में समझ आती है!” वाले loop को accept कर लिया, और यह भी internalize कर लिया कि अंत तक पहुँचने पर अच्छा महसूस होता है
    अब “न जानने” की स्थिति अपने आप में सिर्फ़ दूसरे लोगों की expectations और behavior की वजह से खराब हो सकती है। समय के साथ मैंने सीखा कि language choice, architecture choice वगैरह को बहुत दृढ़ता से manage करना चाहिए ताकि यह process आसान और तेज़ बने
    Career के इस stage पर AWS Lambda को performance, total cost, debuggability और development speed के लिहाज़ से अच्छा choice नहीं है—यह पहले से समझा देना, बाद में “उस एक problem को fix करने में इतना time क्यों लग रहा है” के लिए valid वजह है—यह समझाने से कहीं आसान है

• आख़िर में हँसी आ गई। कल ही, company में 3 साल से परेशान कर रही problem solve की, और हमारे लिए उसकी वजह letter A था
  पिछले 3 सालों से कोई व्यक्ति data डालने और निकालने का manual fix करता आ रहा था, और वह उसके काम का हिस्सा बन गया था। उसने regular cleanup के लिए calendar में recurring schedule तक लगा रखा था। लाखों customers इस एक व्यक्ति पर निर्भर थे ताकि उनकी mobile phone line पर सही data plan लागू रहे
  वह भूल जाए या छुट्टी पर चला जाए तो कैसी अफरा-तफरी मचेगी, कल्पना कर सकते हैं
  आखिर में वजह if $line->status == STATUS_ACTIVE निकली, और एक Active था, दूसरा active। कोई कुत्ता घायल नहीं हुआ, लेकिन कई सालों में अनगिनत पैसा गायब हो गया

  • अगर यह कोई legal case होता तो joke ऐसा होता: “तुमने क्या कर दिया? तुमने वह case solve कर दिया जिसने हमारे पूरे परिवार को law school भेजना था!”
    वह बेचारा अब indispensable नहीं रहा। आधा मज़ाक है। Software का काम चीज़ों को ज़्यादा efficient बनाना है, लेकिन इंसानी motivations पर भी नज़र रखनी पड़ती है
  • मैंने ऐसे tricky cases देखे हैं जहाँ spaces या newlines जैसे invisible characters ने नुकसान किया
    खासकर Mac पर HL7 fields भरते समय बहुत दर्द झेलना पड़ा। लगता है Mac keyboard से type किया गया ’ character HL7 के सभी versions के साथ compatible नहीं था, या जिस target को HL7 pass किया गया था उसके साथ match नहीं करता था
    पुरानी याद है, लेकिन o’clock और o′clock जैसे words के difference की वजह से radiology reports की distribution टूट गई थी। पकड़े जाने से पहले यह कई साल चला
    HN मेरे type किए हुए से अलग तरह से ’ दिखा रहा है, लेकिन फिर भी वही character है। Debugging करते समय difference दिखाई नहीं दे रहा था, यही problem का आधा हिस्सा था, इसलिए यह काफ़ी मज़ेदार है
  • क्या code के किसी हिस्से में STATUS_ACTIVE गलत define था?
    हमेशा यह risk रहता है कि कोई “मदद” करते हुए HttpHeader::REFERRER में referer typo को referrer में सुधार दे। लेकिन वह typo HTTP standard में स्थायी रूप से दर्ज है, इसलिए ऐसा करने पर software पूरी तरह टूट जाएगा। CERN के दिनों के Phillip Hallam-Baker की जिम्मेदारी

• ततैयों के छत्ते वाली कहानी अजनबी नहीं लगती
  हमारे office building के landlord ने building के बाहर touchscreen interface लगाया था, जिससे हर front desk पर call किया जा सके और door unlock कराया जा सके। ऐसा इसलिए किया गया क्योंकि door देख सकने वाला receptionist नहीं था
  वह device 6 महीने चला और फिर बुरी तरह malfunction करने लगा। वजह यह थी कि interface, जो असल में एक बड़ा काला Android tablet था, building की east-facing wall पर लगाया गया था
  Spring के बीच तक, उसे हर दिन पर्याप्त धूप मिलती थी, जिससे वह overheat हो गया, और touch electronics तथा screen hardware के कुछ हिस्से खराब हो गए
  जिस तरह का software मैं बनाता हूँ उसमें heat load की चिंता नहीं करनी पड़ती

  • इससे sunlight से train रुकने वाली कहानी याद आती है। Southeastern के मुताबिक south-east London के Lewisham में services ‘low winter sun’ के angle की वजह से delay हुई थीं
    Railway company ने Twitter पर लिखा था कि “तेज़ धूप के कारण dispatch problems की वजह से Lewisham से गुजरने वाले section में भारी congestion था”
    उन्होंने यह भी कहा कि low winter sun dispatch monitor पर पड़ रही थी, जिससे driver उसे देख नहीं पा रहा था

• “आखिरकार solve कर लिया। वजह letter ‘E’ था” वाला message मज़ेदार है
  सबसे simple और छोटे bugs ही अक्सर सबसे मुश्किल से मिलते हैं। आज सुबह भी off-by-one error ढूँढने में एक-दो घंटे गंवा दिए
  Refactoring के दौरान बदलना भूल गया एक index + 1 ही वजह था

  • जैसा अक्सर कहा जाता है, computer science में दो मुश्किल problems हैं: cache invalidation, naming things, और off-by-one errors