मेरी washing machine ने `software estimation` के बारे में मेरी सोच बदल दी

 (cosive.com)
25 पॉइंट द्वारा GN⁺ 2025-02-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें

> “इसे बनाने में कितना समय लगेगा?”

  • software developers जिस सवाल से डरते हैं और जिसे नापसंद करते हैं, उस पर मेरी washing machine ने मुझे फिर से सोचने पर मजबूर किया
  • washing machine ने software effort estimation की मुश्किलें समझाईं
    • नए घर में शिफ्ट होने के दौरान washing machine install करते समय उम्मीद से कहीं ज़्यादा समय लगा
    • आमतौर पर 10 मिनट में खत्म हो जाने वाला काम इस बार 4 घंटे ले गया
    • पहले से अनुमान न लगाए गए obstacles (blockers) सामने आए, जिनकी वजह से installation में देरी हुई
    • इस प्रक्रिया से समझ आया कि software development में effort estimation मुश्किल क्यों होता है
  • रुकावटें और समाधान
    • रुकावट 1: power connection के लिए छेद नहीं था, इसलिए washing machine को power से जोड़ना संभव नहीं था
      • समाधान 1: hardware store से 60mm hole saw खरीदकर छेद किया गया
    • रुकावट 2: consumer-grade drill से hole saw इस्तेमाल नहीं किया जा सकता था
      • समाधान 2: ज़्यादा ताकतवर drill उधार लेकर इस्तेमाल की गई
    • रुकावट 3: drainage और water supply hoses नए घर में अपेक्षा से छोटे निकले
      • समाधान 3: नया extension hose खरीदने की कोशिश की, लेकिन पता चला कि मौजूदा hose extend नहीं हो सकता, इसलिए फिर से नया hose खरीदना पड़ा
    • रुकावट 4: faucet पर कसा हुआ metal cap हट नहीं रहा था
      • समाधान 4: बड़ा spanner खरीदकर cap हटाया गया
    • रुकावट 5: drain outlet का spigot PVC wall से बंद था
      • समाधान 5: drill से PVC wall में छेद करके drainage hose जोड़ा गया
    • कुल 5 बार hardware store जाना पड़ा और 4 घंटे के काम के बाद washing machine को सही तरह install किया जा सका
  • software development effort estimation मुश्किल क्यों है
    • कोई काम परिचित हो, तब भी environment बदलने पर अप्रत्याशित variables आने की संभावना बहुत ज़्यादा होती है
    • पुराने अनुभव के आधार पर किया गया estimation अक्सर इसलिए गलत साबित होता है क्योंकि “unknown unknowns” मौजूद होते हैं
    • कुछ उदाहरण:
      • जिस library का इस्तेमाल करना था, वह अब maintain नहीं हो रही, इसलिए उसे खुद patch करना पड़ता है
      • development tools update होने के बाद पुराना तरीका अब काम नहीं करता
      • OS version बदलने पर पुरानी dependencies ठीक से काम नहीं करतीं
      • infrastructure में नया component जोड़ा गया, लेकिन वह उम्मीद के मुताबिक behave नहीं करता
  • निष्कर्ष
    • नए घर का यह अनुभव दिखाता है कि software development में effort estimation कितना मुश्किल है
    • development शुरू करने से पहले requirements की जितनी हो सके उतनी गहराई से जाँच करनी चाहिए, लेकिन अप्रत्याशित blockers का आना लगभग अपरिहार्य है
    • software project भले ही परिचित काम जैसा दिखे, नए environment में बिल्कुल अलग चुनौतियाँ सामने आ सकती हैं
    • इसलिए इन variables को ध्यान में रखते हुए schedule और resources को लचीले ढंग से adjust करना ज़रूरी है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-02-19
Hacker News राय

  • software estimation एक मज़ाक जैसा है। क्योंकि कम आकलन करने पर कोई सज़ा नहीं होती

    • इसकी तुलना फिल्म प्रोडक्शन estimation से की जा सकती है। ऐसी कंपनियाँ होती हैं जो फिल्म निर्माण के लिए completion bond बेचती हैं
    • completion bond की लागत प्रोडक्शन लागत का लगभग 2% होती है। आमतौर पर यह 30 लाख डॉलर से 7 करोड़ डॉलर के बजट वाली indie फिल्मों में इस्तेमाल होता है
    • bond कंपनी कुछ अतिरिक्त लागत वहन करती है, लेकिन अगर वह बहुत बढ़ जाए तो निर्देशक को हटा देती है और प्रोडक्शन अपने हाथ में ले लेती है। इस तरह का तरीका वास्तविक असर पैदा करता है
    • bond कंपनियाँ पिछले डेटा के आधार पर estimation करती हैं। उनके पास बहुत-सी फिल्मों की वास्तविक लागत का डेटा होता है
    • वे हर scene की लागत का विस्तृत रिकॉर्ड रखती हैं। उदाहरण के लिए, car chase scene के मामले में वे database में मौजूद पिछले 100 car chase scenes की लागत देखती हैं
    • उनके पास निर्देशक, producer और actors की जानकारी भी होती है, और वे तुलना करती हैं कि इनके साथ scene शूट करने की लागत उनके साथियों की तुलना में कितनी है
    • यह rocket science नहीं बल्कि insurance underwriting है

  • बढ़िया लेख है, लेकिन software experience से एक मुख्य अंतर छूट गया है

    • हो सकता है ग्राहक को वास्तव में यह पता ही न हो कि वह क्या चाहता है। पहले से कितनी भी पूछताछ कर लें, यह जानकारी नहीं मिल सकती
    • hourly billing करें और project-based billing से हमेशा इनकार करें

  • DIY projects हमेशा ऐसे ही होते हैं

    • अपनी चीज़ों पर बहुत चर्चा होती है, लेकिन tools और parts बहुत जगह घेरते हैं
    • लेखक के पास पहले से बहुत सारे tools थे, फिर भी कुछ की कमी थी
    • आखिरकार hardware store के चक्कर कम हो जाते हैं, लेकिन workshop सामान से भर जाती है

  • drilling के बाद 25 मिनट तक सीधा बनाए रखने का तरीका सीखा और noise-cancelling earphones का आश्चर्य भी जाना

    • noise-cancelling headphones hearing protection device नहीं हैं। hearing protection devices शोर के स्रोत और कान के बीच एक भौतिक अवरोध बनाते हैं
    • noise-cancelling headphones आसपास की आवाज़ सुनते हैं और विपरीत ध्वनि तरंग बनाते हैं। यह पूरी तरह सटीक नहीं होता, इसलिए ये कानों की पर्याप्त सुरक्षा नहीं करते

  • कहानी अच्छी है। लेकिन मेरा अनुभव लगभग बिल्कुल उल्टा है

    • 90% हिस्सा आसान काम नहीं बल्कि 90% भटकने में जाता है
    • अक्सर वही product कई कंपनियों में बार-बार बनाया जाता है

  • "वास्तविकता में चौंका देने वाली बारीकियाँ होती हैं" यह बात याद आती है

    • जिन चीज़ों को आप नहीं जानते, वे तब तक वैसी ही रहती हैं जब तक आप किसी नई चीज़ के क़रीब नहीं पहुँचते

  • जब लेखक ने power cable के लिए छेद किया, तो उसने साफ-सुथरे ढंग से plastic insert फिट किया

    • builders पानी की hose के लिए छेद को बस मोटा-मोटा काटते हैं और फिर सिगरेट पीने चले जाते हैं
    • यह मेरे पिछले अनुभव से मेल खाता है

  • ज़्यादातर सहकर्मी हैरान होते हैं जब मैं कहता हूँ कि project शुरू होने से पहले research और inventory में बहुत समय लगता है

    • ज़्यादातर सहकर्मी project जल्दी खत्म कर देते हैं, और फिर aftercare में बहुत समय लगता है
    • मैं project की शुरुआत में बहुत समय लगाता हूँ ताकि बाद में aftercare की ज़रूरत न पड़े

  • अगली बार जब किसी technician की कीमत देखकर हैरानी हो, तो यह दिलचस्प बात सोचने लायक है

    • plumber washing machine जोड़ने के कुछ ही मिनटों के लिए 300 डॉलर इसलिए लेता है क्योंकि उसे पता है कि drain में छेद कैसे करना है

  • software project शुरू करने से पहले अगर यह ही न पता हो कि कौन-से सवाल पूछने चाहिए, तो क्या करना चाहिए?

    • exploratory work को requirements gathering exercise की तरह देखने पर मुझे कोई आपत्ति नहीं है
    • hardware store की एक यात्रा करके अगर आपके पास बड़ी shopping list और खुले सवालों का एक सेट हो, तो काम ज़्यादा प्रभावी और सरल तरीके से किया जा सकता है