मैं low-code को लेकर संशय में हूँ

 (nick.scialli.me)
13 पॉइंट द्वारा GN⁺ 2023-12-31 | 5 टिप्पणियां | WhatsApp पर शेयर करें
  • low-code के प्रति मेरा रुख़ संशयपूर्ण है
  • software consulting करते समय अक्सर ऐसे clients मिलते हैं जो low-code के तेज़ development time और कम maintenance cost के वादों वाले विज्ञापनों से आकर्षित हुए होते हैं
  • clients के असंतुष्ट रहने के कुछ कारण होते हैं

कस्टम फीचर्स की सीमाएँ

  • low-code solutions किसी enterprise की requirements का लगभग 80% पूरा कर देते हैं, लेकिन बाकी 20% को base functionality से हल नहीं किया जा सकता
  • low-code tool के marketers दावा करते हैं कि बाकी 20% भी आसानी से हल हो जाएगा, लेकिन वास्तव में काफ़ी customization की ज़रूरत पड़ती है और कभी-कभी यह असंभव भी होता है
  • enterprise को यह चुनना पड़ता है कि tool की base functionality काफ़ी क़रीब है या फिर वे tool को hack करके उसे अपने exact use case के मुताबिक़ बनाने की कोशिश करेंगे

developer pool की सीमाएँ

  • enterprise कभी-कभी low-code tool को hack करके requirements का 100% पूरा करने की कोशिश करते हैं
  • नतीजतन, किसी specific tool या proprietary language में बहुत सारा custom code लिखना पड़ता है, जिसे समझने वाले developers बहुत कम होते हैं
  • अब company व्यापक रूप से इस्तेमाल होने वाली open source languages के developer pool से hiring करने के बजाय, इस tool में बेहद specialized maintainer ढूँढने को मजबूर हो जाती है

platform upgrade की समस्या

  • software को upgrade करते समय यह सुनिश्चित करना मुश्किल होता है कि integrations टूटें नहीं
  • low-code tools को ऐसे use cases के लिए arbitrary code संभालना पड़ता है जिनके लिए वे मूल रूप से design नहीं किए गए थे
  • सख़्त API contracts के ज़रिए यह संभव होना चाहिए, लेकिन व्यवहार में अक्सर देखा जाता है कि custom code अंदर ही अंदर तरह-तरह की चालें चलता रहता है

database structure की अव्यवस्था

  • ऐसी कंपनियाँ भी देखी गई हैं जो उन processes में low-code tools का उपयोग करती हैं जहाँ सटीक analysis बेहद ज़रूरी होता है
  • लेकिन underlying data model को देखें तो वह समझ से बाहर होता है: user_attribute_47 का क्या मतलब है? application के page 1 से page 2 पर field ले जाने से data किसी अलग field में चला जाता है?

GN⁺ की राय

  • low-code development speed बढ़ाने और maintenance cost घटाने वाला एक promising tool हो सकता है, लेकिन वास्तविक उपयोग में अप्रत्याशित समस्याएँ सामने आ सकती हैं।
  • खासकर जब custom functionality की ज़रूरत हो, या किसी विशेष low-code tool पर निर्भर development language इस्तेमाल की जाए, तो developer pool सीमित हो जाता है और maintenance कठिन हो जाती है।
  • low-code tools के upgrades और database structure की जटिलता, long-term project management में महत्वपूर्ण विचारणीय बिंदु हैं।
  • यह लेख low-code tools का उपयोग करते समय सावधानी बरतने वाले बिंदुओं को रेखांकित करता है और उपयुक्त use cases का सोच-समझकर मूल्यांकन करने की सिफ़ारिश करते हुए रोचक insight देता है।

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

5 टिप्पणियां

 
ats62 2024-01-02

मुझे low-code को लेकर संदेह है.

अब तक मुझे लगता है कि no-code की अवधारणा केवल कुछ खास क्षेत्रों में सीमित रूप से लागू होती है.

अगर LLM का उपयोग करने वाली अच्छी तरह से बनी सेवाएँ सामने आती हैं, तो no-code का trend? flow? tendency? खैर, पहले उस अवधारणा का बदलना ज़्यादा ज़रूरी लगता है.
 
quack337 2024-01-02

करीब 10 साल पहले का एक मामला मुझे पता है, जहाँ MS Access का उपयोग काफ़ी उपयोगी तरीके से किया गया था.

एक संगठन की information system में, काफ़ी अच्छी तरह डिज़ाइन किया गया और MS Sql Server पर implement किया गया database था,
और रोज़मर्रा के OLTP काम भी काफ़ी अच्छी तरह implement किए गए थे.

लेकिन गैर-रोज़मर्रा के data query और report output की माँगों पर IT विभाग की धीमी और अनिच्छुक प्रतिक्रिया को लेकर असंतोष जमा हो रहा था.

MS Excel और Access को अच्छी तरह चलाने वाला एक business department कर्मचारी information system से download किए गए Excel data को Access में import करके, ज़रूरी data query और report output features बिना coding के सिर्फ़ कुछ घंटों में Access से implement कर सकता है, यह उसने दिखाया.
 
quack337 2024-01-02

बिज़नेस विभाग ने अनुरोध किया कि वे Access से सीधे DB से कनेक्ट कर सकें, लेकिन IT विभाग ने information system DB को बाहरी नेटवर्क पर expose करने का विरोध किया। फिर भी, क्योंकि बिज़नेस विभाग की मांग बहुत मज़बूत थी, इसलिए सिर्फ कुछ डेटा को mirror करके एक अलग DB बनाया गया और उसे expose किया गया.

Excel के data features अच्छी तरह संभालना जानने वाले कर्मचारियों ने कुछ ही दिनों की ट्रेनिंग के बाद Access को अपने काम में इस्तेमाल करना शुरू कर दिया।
 
tequila 2024-01-02

मुझे यह लेख काफ़ी relatable लगता है। यह मेरी निजी राय है,
अगर इसमें special syntax इस्तेमाल होता है -> तो learning curve की ज़रूरत पड़ती है, और maintenance मुश्किल हो जाता है
अगर यह सिर्फ UI से code को replace करता है -> तो कई बार सीधे coding करना ज़्यादा आसान होता है
अगर यह पूरी तरह no-code tool बन जाता है -> तो constraints बहुत हो जाते हैं, और users को hacking-जैसे workaround करने के लिए उकसाता है। इरादे से अलग तरह से काम करने वाले users की संख्या काफ़ी बढ़ जाती है
नतीजा: यह ऐसा tool बन जाता है जिससे कोई भी संतुष्ट नहीं होता।
लगता है कि planning, development, और users के बीच का gap बहुत बड़ा होता है, इसलिए यह क्षेत्र सोच से ज़्यादा अच्छी तरह बनाना मुश्किल है।
 
GN⁺ 2023-12-31
Hacker News राय
  • low-code पर अलग-अलग नज़रिए

    • low-code प्लेटफ़ॉर्म डेवलपर का नज़रिया

      low-code को बेचना आसान होता है। इसमें अक्सर IT विभाग को समस्या की तरह पेश किया जाता है और मौजूदा असंतोष का इस्तेमाल किया जाता है। डेमो में सरल कामों को तेज़ी से दिखाया जाता है। लेकिन core business logic को low-code में शामिल न करना बेहतर है। यह मानकर चला जाता है कि जटिल काम specialist systems को offload किए जाएंगे। बड़ी कंपनियों में यह उन टीमों के लिए उपयोगी हो सकता है जिनके पास technical knowledge तो है, लेकिन IT authority कम है। low-code सरल टूल्स से कई समस्याएँ हल कर देता है, लेकिन इसकी scalability कम होती है और इसे मज़बूत central systems के साथ मिलकर काम करना पड़ता है.

    • SRE (site reliability engineer) का नज़रिया

      low-code को लेकर संदेह है। source code management कमज़ोर होता है और documentation भी ठीक से नहीं होती। बहुत-सा custom code चाहिए होता है, लेकिन उसकी reusability कम होती है। proprietary runtime की ज़रूरत पड़ती है और monitoring मुश्किल होती है। व्यवहार में इंजीनियर ही काम करते हैं, और non-engineers सिर्फ़ उसका उपयोग करते हैं — ऐसा मॉडल शायद ही देखने को मिलता है। Looker जैसे टूल source code integration दे सकते हैं, लेकिन उनका उपयोग भी इंजीनियर ही करते हैं। यह complexity को compress तो करता है, लेकिन फिर भी ऐसी platform बेहतर लगती है जिसे ज़रूरत के मुताबिक customize और extend किया जा सके.

    • Microsoft low-code प्लेटफ़ॉर्म पर नज़रिया

      MS low-code प्लेटफ़ॉर्म में दिलचस्पी थी, लेकिन यह O365 और Azure के ऊपर काफ़ी जटिल तरीके से बना हुआ लगता है। user interface कमज़ोर है, और लंबे समय में cost saving से ज़्यादा usability समस्याओं से नुकसान हो सकता है.

    • MS-Access database/form solution को migrate करने का व्यावसायिक अनुभव

      non-developer/end-user द्वारा IT विभाग से गुज़रे बिना बनाए गए MS-Access solutions को असली .net client/server applications में बदलने का बिज़नेस बनाया गया। low-code solutions कुछ समस्याएँ हल करने या POC चलाने में उपयोगी हो सकते हैं, लेकिन जब scale या adaptation की ज़रूरत पड़ती है, तब दिक्कतें आ सकती हैं.

    • SQLPage website builder डेवलपर का नज़रिया

      low-code solutions में बाहरी "high-code" API के साथ interact करने का escape hatch होना चाहिए। SQLPage में यह sqlpage.exec के ज़रिए दिया गया है। low-code प्लेटफ़ॉर्म के upgrades custom implementations को तोड़ सकते हैं — यह एक समस्या है। ज़्यादातर low-code टूल्स data को बंधक बना लेते हैं, लेकिन SQLPage database के ऊपर सिर्फ़ एक layer जोड़ता है, जिस पर user का पूरा control बना रहता है.

    • enterprise स्तर के low-code टूल्स के ख़िलाफ़ राय

      बड़ी कंपनियों द्वारा इस्तेमाल किए जाने वाले low-code टूल्स का विरोध। बड़ी कंपनियाँ सही development team, planning और organization वहन करने में सक्षम होनी चाहिए। लागत code पैदा नहीं करता; लागत तब पैदा होती है जब खराब डेवलपर खराब टूल्स के साथ खराब फ़ैसले लेते हैं.

    • low-code और abstraction layer पर नज़रिया

      "low-code" में उस code की सतह कम दिखती है जिससे आप सीधे interface कर सकते हैं, लेकिन असल में उसके पीछे बहुत-सा code छिपा होता है। abstraction layer तब बहुत शक्तिशाली होती है जब वह उद्देश्य के अनुकूल हो, लेकिन leak होने या अनुपयुक्त होने पर समस्या पैदा कर सकती है। आम तौर पर low-code किसी खास use case के लिए बने code को abstract करता है, लेकिन व्यवहार में फिर भी domain-specific अनुभव की ज़रूरत होती है.

    • Bubble/Airtable का उपयोग करके MVP बनाने का अनुभव

      यूक्रेन की एक टीम से MVP development का quote मिला था, लेकिन एक intern को रखकर Bubble/Airtable से दो महीने में product बना लिया गया और 6 महीनों के भीतर paying customers भी मिल गए। लगभग दो साल तक traditional stack पर जाने की कोई वजह नहीं मिली.

    • low-code learning course development की horror story

      एक महत्वपूर्ण कंपनी ने low-code learning course generation software package का उपयोग करके marketing और sales कर्मचारियों के लिए internal learning courses बनाए। कुछ साल बाद courses को update करने की ज़रूरत पड़ी, लेकिन development में इस्तेमाल किया गया software या उस काम को करने वाले tools उपलब्ध नहीं थे, जिससे समस्या खड़ी हो गई.

    • low-code implementation की version control क्षमता पर सवाल

      यह सवाल उठाया गया कि क्या low-code implementation को version control में रखा जा सकता है, समस्या होने पर root cause ढूँढा जा सकता है, और free tools से किसी specific commit तक rollback किया जा सकता है। ज़्यादातर मामलों में ये सुविधाएँ नहीं होतीं, इसलिए गंभीर उपयोग के लिए यह उपयुक्त नहीं माना जाता.