- तकनीकी काम को फैक्टरी की तरह standardize करके दोहराए जा सकने वाले outputs में बदलने की management और vendors की उम्मीदें बड़ी हैं, लेकिन कई workplaces अभी भी इस तरीके से भरोसेमंद रूप से productized नहीं हो पाए हैं
- McDonald's-शैली का संचालन quality से ज्यादा उस discipline के बारे में है जिससे अलग-अलग जगहों और लोगों से एक ही output निकलता है, और कई management books भी IT operations को इसी production flow की तरह देखती हैं
- Enterprise software sales अक्सर इस वादे जैसी होती है कि SQL, data और development work को drag-and-drop और consistent interfaces से replace करके people को interchangeable बनाया जा सकता है
- वास्तविक organizations में खराब software licenses और गलत abstractions तकनीकी समस्याएं हल नहीं कर पाते, और आखिरकार अक्सर बेहतरीन engineers को खराब data models और technical decisions खुद ठीक करने पड़ते हैं
- जिन कामों में creativity, taste, expertise और लोगों के बीच connections चाहिए, उन्हें Jira board या Agile scores में पूरी तरह घटाया नहीं जा सकता, और बड़े production infrastructure के अंदर भी अलग-अलग लोग ही system को चलाते हैं
McDonald's standardization की कठिनाई दिखाता है
- पहले manager, जो एक बेहतरीन data engineer थे, cooking में गहराई से डूबे हुए व्यक्ति थे और उन्होंने कई बार McDonald's operations की complexity की बहुत सराहना की
- McDonald's की value output quality से ज्यादा उस optimization और discipline में है जिससे अलग-अलग education levels और regions के employees एक जैसा burger बनाते हैं
- अलग-अलग जगहों पर कम-skilled workforce से consistent result निकलवाना simple नहीं है, और यही example technical work के commodification पर चर्चा की ओर ले जाता है
Management books IT को factory की तरह treat करती हैं
- The Phoenix Project IT operations को manufacturing factory work जैसी problem मानती है, और organization के अंदर work flow और communication management को केंद्र में रखती है
- इसी तरह की भावना वाली books में The Unicorn Project, Investments Unlimited, The Goal शामिल हैं
- The Goal असली factory operations बदलने की कहानी है, और इसे दूसरी books को inspire करने वाला work माना जाता है
- High Output Management भी restaurant में काम कैसे flow करता है, इसे example बनाकर work flow समझाती है—जैसे गलत timing पर egg boil करने से customer तक पहुंचते-पहुंचते toast ठंडा हो जाता है
- इस तरह की सोच में economies of scale, throughput और work flow जैसे topics बार-बार आते हैं
Vendor pitches का core technology से ज्यादा replaceability है
- एक vendor conference के कई product pitches technical details की बजाय इस वादे पर focus करते हैं कि वे काफी अच्छे work outputs को repeatable तरीके से deliver कर सकते हैं
- एक specific product खुद SQL लिखे बिना drag-and-drop editor से dependencies set करने की बात promote करता है
- असल में application Postgres से connect होता है, इसलिए SQL गायब नहीं होता; बल्कि license वाला abstraction layer SQL को उसकी जगह लिखता है
- ऐसे pitches management को यह message दे सकते हैं कि “slow और problem-heavy SQL” को consistent interface और market के tool experts से replace करके organization में data delivery को smooth बनाया जा सकता है
- Average dysfunctional organizations में Agile जिस तरह implement होता है, वह भी इसी तरह की problem दिखाता है
- Engineers को machines, outputs को parts, और story points को production units की तरह count करके अगले हफ्ते के लक्ष्य की achievement rate check करने का तरीका
कई technical work अभी commodify क्यों नहीं हो पाए हैं
- McDonald's आम तौर पर 5 मिनट के अंदर एक certain quality की fries दे देता है, लेकिन कई technical organizations value वाली चीज deploy किए बिना खराब software licenses खरीदते हैं
- Technical problems और खराब data models को पैसे से हल करने का रास्ता असल में ऐसे बेहतरीन engineers को हासिल करने जैसा है जो problem-solving पर ही focus करते हैं
- कई areas commodification के लिए possible दिखते हैं, लेकिन असल में अक्सर यह non-working products बेचने वाली companies और उन्हें खरीदने वाले ignorant decision-makers का combination होता है
- कुछ decision-makers legal compliance पूरा करने के नाम पर low-wage regions की phone support का इस्तेमाल करते हैं, और cancel करना चाहने वाले customers की परवाह न करने वाला तरीका भी चुन सकते हैं
- यह अनुभव भी बताया गया है कि support representative से संपर्क करना हो तो पहले sales line पर call करके यह try किया जाता है कि क्या किसी authorized local representative से जल्दी connect हो सकते हैं
Creative technical work में human element बचा रहता है
- Rich Hickey का Hammock Driven Development research को unconscious mind में डालने, meditation करने और सोते हुए design answers पाने जैसे workflow पर बात करता है
- Programmers अक्सर experience करते हैं कि problem से दूर होने पर answer दिमाग में आता है, और यह सिर्फ widgets को ज्यादा तेजी से produce करने वाले work से अलग है
- Society में तेजी से produce करने वाली kinds of work बहुत हैं, लेकिन कई valuable outcomes उस point से निकलते हैं जहां define करना मुश्किल creativity और production reality मिलते हैं
- Books, food और restaurant operations जैसे examples में भी mass production या delivery systems को refine किया जा सकता है, लेकिन beautiful outcomes के लिए taste और care चाहिए
- Feature development को Jira board और Agile stories तक reduce करने की कोशिश करें, तब भी लोगों से connected न हो तो valuable result पाना मुश्किल है
- iPhone में इस्तेमाल होने वाले chips design करने वाले एक acquaintance के example की तरह, testing और mass-production infrastructure होने के बावजूद अगर कोई specific individual बीमार पड़ जाए, तो next release delay हो सकती है—इतना अहम role individual people निभाते हैं
- Reality यह है कि society commodification पर चलती है, लेकिन किसी specific craft की समझ और लोगों की complexity, needs और vulnerabilities को ignore करने वाली pure commodification से technical work operate नहीं किया जा सकता
1 टिप्पणियां
Hacker News की राय
लगता है लेखक यह बात चूक गए कि पहले जिसे तकनीकी काम कहा जाता था, उसका बड़ा हिस्सा अब general-purpose commodity बन चुका है
पहले mail merge का मतलब सचमुच ढेर सारे address labels प्रिंट करके उन्हें हाथ से चिट्ठियों और लिफाफों पर चिपकाना होता था, और Word 2.0 के आसपास 1990s में वह समस्या हल हुई, फिर MailChimp ने 21वीं सदी में उसे productize कर दिया
double-entry bookkeeping भी कभी बहुत प्रशिक्षित व्यक्ति का तकनीकी काम था, लेकिन अब दुकान का मालिक barcode scan करता है और customer tap-to-pay कर देता है
Scratch से ज़्यादा जटिल चीज़ों के लिए इस्तेमाल हो सके ऐसा drag-and-drop interface अभी नहीं है, लेकिन मुश्किल हिस्सा libraries जोड़ने वाला technical work नहीं, बल्कि requirements gathering है
high-quality encryption library जोड़ना, website में interactive map लाना, या website को WYSIWYG में edit करना पहले से कहीं आसान हो गया है
लेखक इस बात में सही हैं कि किसी ऊबे हुए 18 साल के व्यक्ति को IDE के सामने बैठाकर ERP नहीं बनवाया जा सकता, लेकिन IT के बहुत सारे छोटे-मोटे काम अब निश्चित रूप से commodity बन चुके हैं
मुझे लगता है tech industry में ये छोटे-मोटे काम घटने के बजाय बढ़ रहे हैं: अभी छोटे-मोटे काम X मात्रा में हैं, नई technology Z आती है और X को 0.1X तक घटा देती है, लेकिन साथ ही Z काम करने के नए तरीके संभव बनाती है और उसके byproduct के रूप में और छोटे-मोटे काम पैदा होते हैं। तब मौजूदा छोटे-मोटे काम Y हो जाते हैं, और Y लगभग X के बराबर रहता है
अगर 2000s में तकनीकी विकास रुक गया होता, तो 90s से निकले छोटे-मोटे काम आज लगभग 0 हो गए होते, लेकिन नई technology automation और छोटे-मोटे काम दोनों साथ लाती है
हालिया उदाहरण AI tools हैं। sound, images, video, text generate करने के tools हैं, लेकिन differentiated product या experience बनाने के लिए ChatGPT, Stable Diffusion जैसे tools को मिलाने-जुलाने वाले छोटे-मोटे काम की जरूरत होती है
जितना ज़्यादा आप commoditize करते हैं, समस्या उतनी ही higher-level पर चली जाती है, और आप जिन specialist engineers को hire करते हैं वे भी stack में और ऊपर चले जाते हैं
हाल के SaaS बने startup products में ऐसे products का अनुपात ज्यादा दिखता है जो अभी असल में वह काम कर ही नहीं पाते जो आप चाहते हैं। वे पैसे लेकर service इस्तेमाल करवाते हैं, फिर customers के use cases को implementation targets के रूप में collect करते हैं और उन्हें दूसरे customers को commoditize करके बेचने की कोशिश करते हैं; इससे lead time लंबा होता है और intellectual property भी leak होती है
SQL को template में बदलना management के लिए हमेशा गलतफहमी का विषय रहता है। SQL industry में हैरान करने वाली हद तक लंबे समय से बचा हुआ है और सच में काफी अच्छा काम करता है। उसके ऊपर रखे wrappers या DSLs में से 99% उसे कहीं खराब बना देते हैं, और ज़रा सा भी non-standard काम आखिरकार SQL तक नीचे उतरना ही पड़ता है। SQL expert hire करने के बजाय ऐसी स्थिति बनती है कि आपको किसी अस्तित्वहीन SaaS-style DSL SQL wrapper X के experts तैयार करने पड़ते हैं
मूल समस्या शायद यह है कि ऐसे products को उस domain में काम न करने वाले buyers को “खरीदकर लगा दो और समस्या हल — ऐसे appliance” की तरह दिखाने के लिए design किया जाता है
बहुत से products असल में समस्या हल नहीं करते, वे सिर्फ इसलिए हल करते हुए दिखते हैं क्योंकि बाकी लोग भी उन्हें खरीद रहे हैं। और implementation सफल हुआ है, यह झूठ बोलना पड़ता है तभी promotion संभव होता है। mail merge जैसी चीज़ सचमुच kettle की तरह पहले से हल समस्या है, और ऐसी समस्याओं को खुद try करके solve किया जा सकता है
बड़ी समस्या यह है कि मेरे employer ने Workday को kettle जैसी चीज़ मानकर खरीदा, लेकिन यह ठीक नहीं कर पाया कि हमारा organizational structure इतना भयानक है कि उसे model ही नहीं किया जा सकता
इस साल पहली बार मुझे एहसास हुआ कि बड़ी कंपनियों में पर्याप्त खराब organizational structure एक तरह का technical debt है। कौन किसके नीचे काम करता है, या यह user इस database में क्या देख सकता है, यह पता लगाने के लिए तरह-तरह के अजीब काम करने पड़ते हैं
1994 या 2004 की तुलना में आज business चलाना, website बनाना, travel plan करना, और bills pay करना कितना आसान हुआ है?
कभी-कभी लगता है पिछली पीढ़ियों की जिंदगी की रफ्तार धीमी थी और इसलिए वे ज्यादा भरपूर जीवन जीती थीं। अब समय बहुत तेज़ी से निकलता है और stress भी ज्यादा है
कुछ समय पहले मैंने bank में कम से कम तीन 60+ उम्र के लोगों को देखा जो आसान काम भी नहीं कर पा रहे थे और staff से मदद मांग रहे थे। काम online banking से आसानी से हो जाना चाहिए था, लेकिन exception cases के कारण system support नहीं करता था, आखिरकार appointment लेनी पड़ी और सबसे जल्दी slot 3–4 महीने बाद का था
उनमें से एक को लकड़ी खरीदकर घर गरम करने के लिए blocked account से पैसे निकालने थे, लेकिन bank employee ने बस 3 महीने इंतज़ार करने को कहा
2 साल पहले मेरे पिता Sicily से घर पर एक साधारण phone call करने का तरीका नहीं ढूंढ पाए। अगर 1970s होता तो पास के bar में जाकर कुछ coins डालते और काम हो जाता
पहले आम आदमी electric lights, cars, heating, और automatic door नहीं बल्कि सामान्य door जैसी चीज़ें खुद ठीक कर लेता था, लेकिन अब expert बुलाना पड़ता है
तकनीकी काम को पूरी तरह commodity बनाने की कोशिश बुरा विचार है, और उम्मीद है आगे भी असफल होगी
हालांकि मैंने The Phoenix Project दो बार पढ़ी है और Scrum की ज़्यादातर चीज़ें मुझे पसंद नहीं हैं, लेकिन मुझे नहीं लगता कि वह किताब ऐसा दावा करती है
उससे मैंने जो मुख्य बात ली, वह यह थी: दोहराए जा सकने वाले काम को करने और manage करने के लिए स्पष्ट system रखना और जहाँ संभव हो automate करना; work in progress घटाना ताकि लोग ढेर सारे tasks में बंधे न रहें; जानकारी व्यापक रूप से share करना और कई team members को वही काम कर पाने लायक बनाना; यह सुनिश्चित करना कि असल में business के लिए ज़रूरी काम हो रहा है; शोर और unplanned work घटाना ताकि कर्मचारी अव्यवस्थित दलदल में भटकने के बजाय ऐसा high-value काम कर सकें जिसका वे आनंद ले सकें
The Phoenix Project का सार लोगों को replaceable automaton बनाना नहीं है, बल्कि ऐसा system बनाना है जो उन्हें automation या systematization से परे, सचमुच मूल्यवान काम करने की गुंजाइश और समय दे
मैंने factory भी चलाई है और developer भी रहा हूँ, इसलिए दोनों पक्ष देखता हूँ; developers को production factory workers बनाना बेमानी है, लेकिन जो काम known tasks और repeatable steps जैसे factory work जैसा दिखता है, उसे उसी तरह handle किया जाना चाहिए
s/manufacturing/IT/gकरने और उसे modern references से update करने जैसा ही हैइसका मतलब यह नहीं कि मुझे किताब नापसंद है। मैंने लगभग आधी पढ़ी है, और हर team को system-centric सोच की ओर मोड़ने के लिए उसे पढ़वाने की कोशिश की। लेकिन मैं यह नहीं कह सकता कि यह The Goal से कहीं ज़्यादा गहरी या insightful है
मैंने उसकी writing style का मज़ाक उड़ाया था, लेकिन वह सच में पढ़ने लायक थी। known work या repeatable steps में लोग जो बहुत सारी गलतियाँ करते हैं, उनका दोष Phoenix Project-style thinking पर नहीं डाला जा सकता
लेकिन programming में known work को repeatable steps के रूप में करना दुर्लभ है। अगर ऐसा होता है, तो अक्सर stakeholder management में tactical गलती की वजह से automation के लिए समय नहीं बचा होता
ध्यान से पढ़ें तो निष्कर्ष आखिरी paragraph जैसा निकलता है, लेकिन मैं यह पक्के तौर पर जानता हूँ कि जिन managers से मेरा सामना होता है, उनमें से ज़्यादातर widget production और system design का फर्क नहीं समझते
continuous learning, automation और instrumentation ऊपर के 1–5 को संभव बनाने वाले tools हैं
The Phoenix Project से मुझे “और मेहनत करो ताकि और ज़्यादा काम और तेज़ी से करो” वाला संदेश नहीं मिला
https://scrumguides.org/scrum-guide.html
आम तौर पर भयानक वे तमाम चीज़ें होती हैं जिन्हें लोग Scrum कहकर उसके ऊपर लाद देते हैं। खराब Scrum से निपटने का सबसे अच्छा तरीका लड़ना नहीं था, बल्कि असली doctrine के प्रति purist loyalty दिखाने का नाटक करना था। इससे आप कम rebel दिखते हैं और influence डालना भी आसान होता है
Title ने मुझे confuse किया। “commodify” का मतलब “बेचने योग्य बनाना”, यानी commercialization करना नहीं है? Technology तो पहले ही अरबों डॉलर कमा चुकी है, है न?
लेखक शायद commoditization की बात कर रहे हैं, यानी technical work को ऐसा generic work बना देना जिसे कोई भी replaceable employee कर सके
https://en.wikipedia.org/wiki/Commoditization के अनुसार, commoditization का मतलब proprietary चीज़ का सामान्य commodity बन जाना है, और commodification का मतलब ऐसी चीज़ का sellable बन जाना है जो पहले sellable नहीं थी
क्या मैं ज़्यादा nitpick कर रहा हूँ? मुझे लगा दोनों के अर्थ अलग हैं
Edit: Wiktionary देखा तो https://en.wiktionary.org/wiki/commodification में लिखा है कि इन्हें कभी-कभी interchangeably भी इस्तेमाल किया जाता है। शायद यह बस आम confusion है
https://www.merriam-webster.com/dictionary/commodify
इसका मतलब “intrinsic value या art work जैसी किसी चीज़ को commodity में बदलना” है, इसलिए commodify ज्यादा हद तक commoditization से जुड़ा शब्द है
Oil commodity इसलिए है क्योंकि producers बहुत हैं और सब वही चीज़ बनाते हैं, इसलिए आप किससे खरीदते हैं, इससे फर्क नहीं पड़ता
McDonald’s वाली उपमा में डेवलपर मशीन के सामने काम करने वाला किशोर नहीं, बल्कि मशीन डिज़ाइन करने वाला इंजीनियर है। उस उपमा में कंप्यूटर ही वह किशोर है
प्रोग्रामिंग काम नहीं, बल्कि मेटा-वर्क है। एक बार निर्देशों की सूची बना दी, तो कंप्यूटर वह काम 24 घंटे करता रहता है, और मैं किसी दूसरे काम के लिए निर्देशों की नई सूची लिखने चला जाता हूँ
अगर वही निर्देशों की सूची दोबारा लिखनी पड़ रही है, तो मूल रूप से आप कुछ गलत कर रहे हैं। इसलिए हमेशा नया काम करना पड़ता है, और क्योंकि वही काम दो बार नहीं करते, यह जानना मुश्किल होता है कि कितना समय लगेगा
IT फैक्टरी नहीं, बल्कि फैक्टरी बनाने का काम है
मुझे लगता है कि डेवलपर और मैनेजर के बीच कई टकराव इस वजह से आते हैं कि “मैनेजर” शब्द बहुत ही व्यापक ढंग से इस्तेमाल होता है। McDonald’s का मैनेजर यह देखता है कि कर्मचारी उत्पाद बनाने की प्रक्रिया का पालन कर रहे हैं या नहीं। प्रक्रिया का पालन न होना स्पष्ट होता है, यह मान लिया जाता है कि प्रक्रिया वैध है, और यह भी स्पष्ट होता है कि आउटपुट आया या नहीं
इसके उलट, प्रोग्रामर को वह प्रक्रिया विकसित करने के लिए रखा जाता है जिसका मशीन पालन करेगी। इस कर्मचारी को मैनेज करने वाले व्यक्ति के पास भी ऐसी प्रक्रिया हो सकती है जिसका प्रोग्रामर पालन करे, और उसका पालन हो रहा है या नहीं यह स्पष्ट हो सकता है, लेकिन वह प्रक्रिया वैध है या नहीं, कोई खास क्रिया तय परिणाम तक ले जाएगी या नहीं, और परिणाम खुद स्पष्ट है या नहीं—ये सब अनिश्चित हैं
फिर भी दोनों भूमिकाओं को “मैनेजर” कहा जाता है
इस मशीन वाली उपमा में प्रोग्रामर लोगों को मैनेज करने वाला नहीं, बल्कि मशीनों को निर्देशित करने वाला अलग किस्म का मैनेजर है। बस वे मशीनें दुनिया में छोड़ दी जाती हैं, और प्रोग्रामर लगातार उनकी निगरानी नहीं करता
बेशक, दूसरे कमेंट की तरह यह अवधारणा पूरी बकवास भी हो सकती है। लेकिन अगर कुछ साल बाद यह समझ आया कि यह मूर्खतापूर्ण विचार था, तो अकेले शर्मिंदा होने से बेहतर है कि कोई और भी साथ में शर्मिंदा होने वाला हो
करीब 10 साल पहले मेरे कुछ मैकेनिकल इंजीनियर दोस्तों को यह देखकर हैरानी हुई कि मैं software development पढ़ रहा हूँ
उन्होंने कुछ ऐसा कहा, “क्या अभी भी बहुत काम बचा है? जो चाहिए वह मौजूदा systems से नहीं हो जाता?”
गलतफहमी यह है कि नई समस्याएँ हल करने वाले systems बनाना आसान है और पहले से ही commoditize हो चुका है, इसलिए अब code लिखने की जरूरत नहीं
असलियत में software बनाना शायद ही कभी UI settings जितना आसान होता है। logic rules और flows व्यक्त करने के लिए text चाहिए, system changes को track और rollback करने के लिए version control चाहिए, और आखिरकार programmers चाहिए
coding गायब नहीं होती, बस abstraction level ऊपर चला जाता है
tech industry लंबे समय से developers को commoditize करने की कोशिश करती रही है, और मुझे लगता है COBOL और Java भी उसी प्रवाह का हिस्सा थे
लेकिन आप चाहे जो भी abstract करें, कुछ मूलभूत गुण फिर उभर आते हैं। requirements सरल दिखें और high-level framework मौजूद हो, तब भी हमारे software का बड़ा हिस्सा अभी भी ठीक से काम नहीं करता
लेखक के मुताबिक असली समाधान कुशल और ध्यान देने वाले developers हैं। इसी से career बनाया जा सकता है
एक ही क्षेत्र में लंबे समय तक काम करने पर patterns मिलते-जुलते दोहराते हैं, लेकिन हर किसी की business requirements थोड़ी अलग होती हैं। stack की हर layer पर यह अंतर बढ़ता है, और कुल मिलाकर non-commodity और custom काम बहुत ज्यादा हो जाता है
इसलिए दो products बिल्कुल एक जैसे नहीं होते, और सब कुछ बनाने वाली सिर्फ एक विशाल वैश्विक company मौजूद नहीं है
खुद को Taylorism की तरह टुकड़ों में बाँटने वाली self-commoditization का मौका आते ही developers को उत्साहित होते मैंने अनगिनत बार देखा है
medical industry automatic commoditization की चर्चा में मेरा counterexample है। भावनात्मक रूप से इसके दो आकर्षण हैं। मरीज doctors के बीच इधर-उधर भेजे जाना पसंद नहीं करते। वे समझते हैं कि commoditization के साथ कुछ हद तक specialization बढ़ती है, और हर handoff के साथ failure point भी एक बढ़ जाता है
दूसरा यह है कि status और काम करने के तरीके को ऊँचे status जैसा दिखाया जा सकता है। पहले को आगे रखकर और दूसरे को subtext के रूप में पढ़ने दें, तो आम तौर पर यह अच्छा काम करता है। workers अधिक general capabilities बनाए रखते हैं, और handoff के बजाय एक-दूसरे से consult करने के तरीके पर निर्भर होते हैं
assembly line क्रमबद्ध specialization है; medical residents के working hours से जुड़ी handoff errors को देखिए
operations, innovation, maintenance। इन तीन में से कोई भी तीन चुन लीजिए
बेहतर है कि इन्हें वही team करे, या बहुत करीबी teams करें
आदर्श रूप में team के हर व्यक्ति को अलग-अलग स्तर पर ये तीनों functions करने चाहिए। सुधार की प्रेरणा वहीं से आती है
इन तीन functions को तीन groups और तीन management layers में बाँटा जा सकता है, लेकिन नतीजे आम तौर पर साधारण होते हैं और लोग दुखी हो जाते हैं। खासकर maintenance team में फँसे लोग, जिन्हें सराहना नहीं मिलती लेकिन वे बेहद अहम काम करते हैं
team को तीनों functions की जिम्मेदारी भी दी जा सकती है, लेकिन अक्सर ऐसे manager रख लिए जाते हैं जो किसी एक खास चीज़ के लिए overfit होते हैं। संयोग से वही एक चीज़ अगले quarter में बेहतर reward दिलाने वाला function होती है
एक ही culture के भीतर operational excellence, ईमानदार maintenance, और गहराई से सोचने के समय—तीनों की एक साथ वकालत करना मुश्किल है। यह मुश्किल होना स्वाभाविक है
बिज़नेस इंटेलिजेंस/एनालिस्ट भूमिका को देखें, तो industry SQL इस्तेमाल करने वाले व्यक्ति को Tableau जैसे tools इस्तेमाल करने वाले व्यक्ति से बदलने की कोशिश कर रही है
सोच कुछ ऐसी है कि “किसी भी data store से connect कर दो, फिर non-technical लोग drag-and-drop से कर लेंगे”
समस्या कुछ हैं। पहली, वे यह भूल जाते हैं कि output केवल linear तरीके से बढ़ता है, इसलिए और ज्यादा कम-तनख्वाह वाले लोगों को hire करना पड़ेगा। सब कुछ UI-based काम है, इसलिए इंसान को हाथ से crank घुमाना पड़ता है
दूसरी, बहुत जटिल और साफ-सुथरा न किया गया business logic transformation code फिर भी बनता है, बस अब वह UI के अंदर दबा होता है। वह logic क्या है, यह सिर्फ PM या business team को पता होता है
engineering संगठन business सवालों के जवाब देने के लिए काफी primitive, high-quality tested datasets देता है। कठिन हिस्सा source data से अजीब तरीकों में business outputs निकालने की समस्या हल करना था
अब वह solution Tableau workbook में store होता है और दूसरे input के रूप में इस्तेमाल नहीं किया जा सकता। उसे नए Tableau workbook में UI से copy-paste करना पड़ता है
चूंकि Tableau cloud service खरीद ली है, BI team SQL extracts को ज्यादा सख्त बना और maintain कर सकती है। Tableau ऐसा लगता है जैसे Databricks के business का एक हिस्सा लेना चाहता है, लेकिन अब वह काम non-engineering team कर रही है। पता नहीं यह ठीक चलेगा या नहीं
उदाहरण के लिए “हमारे users किस देश से हैं?” जैसा typical सवाल है। क्या इसका मतलब sign-up form में लिखा देश है, अभी service access कर रहा देश है, payment method का देश है, जन्म का देश है, citizenship वाला देश है, वर्तमान निवास देश है, shipping address है या billing address—ये सब अलग-अलग हैं
dataset पर्याप्त बड़ा हो तो हर एक का जवाब अलग निकलेगा। “global fintech” क्षेत्र में ऐसे अजीब cases सामान्य बन जाएंगे
typical कम-तनख्वाह वाला Tableau user दिख रहे country code को खोजकर count चलाएगा और उसे सच घोषित कर देगा
थोड़ा ज्यादा समझदार Tableau user engineer से SQL लिखने के लिए कहेगा
ऐसा व्यक्ति होना चाहिए जो dataset और source systems को जानता हो, ताकि business से उल्टा सवाल कर सके और सही सवाल व context लागू कर सके
Tableau जैसे tools हर दिन वही SQL query pgAdmin में paste करके CSV email करने जैसे “technical work” को replace करने के लिए अच्छे हैं, लेकिन UI-centric low-skill worker को बेहतर सोचने वाला नहीं बनाते
cost के मुकाबले output की linear scaling को spreadsheet में model किया जा सकता है और customer पर pass on या bill किया जा सकता है। business layer में हर कोई इस dynamics के साथ comfortable महसूस करता है
इसके उलट, dedicated expert थोड़ी मेहनत से 1000x output बना सकता है, लेकिन एक दिन लगेगा या एक हफ्ता, यह निश्चित न हो—ऐसी स्थिति सबको uncertainty में डालती है और leader को बेचैन करती है। अगर हर कोई आरामदायक mediocrity चाहता है, तो इसे बेचना मुश्किल है
नंबर 2 irony से और ज्यादा experts की जरूरत पैदा करता है, बस वे अलग किस्म के experts होते हैं। क्योंकि वह सारा logic maintain करना पड़ता है
आखिर में यह jobs program की तरह चलेगा और ज्यादा महंगा होगा, लेकिन politically influential जागीरों को proportionate value बांटेगा, इसलिए सफल होगा
पहले backend लोगों को यह कहकर निकाल दो कि उन्हें business नहीं पता, और Tableau को नया backend बना दो। यह तथ्य ignore कर दिया जाता है कि backend लोग business requirements को absorb और refine करते आए थे
बाद में जब business लोग अपनी बनाई गड़बड़ मकड़ी-जाल में उलझेंगे, तो Tableau consultants को बुलाएंगे, और वे पैसे चूसते रहेंगे जबकि कोई valuable चीज नहीं बनाएंगे
मैं structural engineering से आया हूं, और software दूसरे engineering fields की तुलना में urban planning के ज्यादा करीब लगता है
यह बहुत विशाल है। समय के साथ backend, frontend, firmware, machine learning engineer, data scientist, security analyst, kernel developer जैसी specific work types को describe करने वाली अलग-अलग roles का बढ़ना आश्चर्यजनक नहीं है
standards विकसित होंगे तो किसी समय ऐसे पदों पर काम करने के लिए बहुत specific certification की जरूरत पड़ सकती है। यह किसी और रूप में बदल सकता है, लेकिन crystallization effect साफ दिखता है
software को factory की तरह सोचना भी संभव है और उपयोगी हो सकता है। लेकिन हर चीज उस analogy में fit नहीं होती। जैसे product integration के बारे में सोचें, या जब यह app नहीं बल्कि service हो
factory का मतलब implied होता है कि कोई चीज बनाई जा रही है, लेकिन कई मामलों में software final output नहीं, बल्कि अपने-आप में enable करने वाला माध्यम होता है
software में ज्यादातर काम asymptotically automate होते आए हैं। इसलिए हम भूल जाते हैं कि वह काम कभी labor हुआ करता था
साधारण file copy को सोचिए। एक तरह से यह “automatic scribe” है
copying इतनी automate हो चुकी है कि हमारे systems द्वारा की जाने वाली भारी मात्रा की copying दिखाई भी नहीं देती, और economic differentiation point के रूप में भी गायब हो चुकी है
ऊपर से meta स्तर पर भी उपयोगी है। copy program खुद भी उसी algorithm से आसानी से copy हो जाता है
मुद्दा यह है कि software लिखना, mathematics की तरह, हमेशा known और unknown की सीमा पर समय बिताता है। क्योंकि जो क्षेत्र पूरी तरह known और characterized हो जाते हैं, वे सबके लिए समस्या हल करते हुए उस activity की economic जमीन को जला देने वाले तरीके से automate हो जाते हैं
software work में किसी भी domain में unknown territory में जाकर wealth खोजने वाली exploration, यानी research का element हमेशा रहता है। वह नया क्षेत्र glorious हो या tragically ordinary, फर्क नहीं पड़ता
software expertise न रखने वाला manager जिन क्षेत्रों को automatically करवा सकता है, वे ऐसे फलदार पेड़ों जैसे हैं जिन्हें आसान फल तोड़ने के लिए पालतू बना दिया गया हो। लेकिन ऐसे पेड़ों पर अब फल बचे नहीं हैं
अगर उस manager की problem definition फिर से ऐसे difficult-to-automate क्षेत्र में नहीं उठती, जहां परेशान करने वाली creativity और expertise चाहिए, तो वह अब differentiated या valuable काम नहीं कर रहा होगा