Ho letto un articolo su impactmybiz.com che mostra un’infografica per paragonare la programmazione tradizionale con quella lowcode. Mi è piaciuta molto l’identificazione di cinque categorie su cui fare il paragone, ma più lo uso e più mi sembra che si rischia di entusiasmarsi troppo per i vantaggi del lowcode fino al punto di non voler considerare gli svantaggi. Anzi ormai è una religione e guai ad ipotizzare eventuali svantaggi. Ma vediamo il paragone fatto nell’infografica, che per comodità riporto qui sotto.
Le proprietà prese in esame sono:
- Skill richiesti
- Costi
- Velocità
- Scopo
- Messa in produzione (Deployment)
Lo skill richiesto
Il lowcode, secondo loro, è vincente. Perché può essere realizzato anche da “citizen developers” in quanto è facile ottenere risultati con interfacce drag-and-drop.
Io penso che questa sia una mistificazione.
Sono d’accordo che l’uso di interfaccie visuali non richiede la conoscenza di linguaggi specifici e facilita le attività di costruzione di un’applicazione. Facilita anche la collaborazione tra più persone che si confrontano con il problema e la soluzione espressi in modo visuale. Ma almeno la conoscenza di come analizzare e strutturare i dati non si può ignorare. Tutte le piattaforme che ho visto fin’ora permettono di costruire in modo semplice la struttura dati a supporto, ma costruirla senza nessuna idea di tabelle e relazioni può andar bene solo per applicazioni piccole.
Il Costo
Qui il terreno si fa scivoloso. L’infografica dice che per il low-code
le piattaforme richiedono di pagare per l’accesso per fare l’applicazione, permettendo delle significanti riduzioni di costo sulla manodopera, la manutenzione e l’infrastruttura IT
Qui siamo nel far-west dei modelli di pricing di queste piattaforme, che spesso permettono di partire con pochi soldi ma poi diventano esose con il crescere. Infatti non è una verità assoluta che si paga per sviluppatore (pay access to make apps), le dimensioni che influenzano sul prezzo spesso sono il numero di utenti finali, il numero di record, il numero di tabelle, lo spazio occupato e chi più ne ha più ne metta.
Ad esempio Airtable ad oggi pubblica un listino dove il primo piano a pagamento è di 120€/anno/utente, dove per utente si intende chi è in grado di modificare i dati. Perché se si devono solo leggerli Airtable rende molto facile l’iserimento in un sito web goià esistente. Quindi se devo fare un’applicazione per un ufficio con 5 impiegati dovrò pagare 600€/anno. Si vero ma solo se ho meno di 5000 record e non supero i 5GGB di allegati! Che succede se i miei 5 impiegati, nel tempo superano questi limiti? Devo cambiare piano, il successivo, che mi porta a 50000 record e 20GB di allegati, mi costerà 1200€/anno. Se poi le dimensioni della mia utenza crescono cresce il costo in momdo lineare. Far usare la mia app a 50 impiegati siamo a 12000€/anno, sicuri che non conviene un VPS per ospitare un’app PHP?
Poi in questo esempio non si affrontano minimamente problematiche di backup e restore…..
La Velocità
Si dichiare che il low-code ci permette una rapidità di sviluppo dieci volte superiore ad uno sviluppo normale. Qui non c’è scampo, questo è il punto forte, anzi fortissimo del low code.
Non solo il drag-and-drop, ma il poter vedere subito l’effetto che fa insieme agli utenti e fare le correzioni necessarie, è un vantaggio innegabile e insuperabile.
Lo Scopo
Viene affermato che il low-code è visto più per esigenze specifiche, mentre per investimenti a lungo termine e full-scale l’approccio tradizionale è preferibile anche per piccole aziende.
Qui mi confondo io. Questo mi sembra lapidario come parere, che significano i termini Full-scale e long-term? Per un’applicazione che sono certo mi servirà per i prossimi 3 anni e viene utilizzata da 20 persone in una ditta con 250 impiegati, lo uso o no il low-code?
Letta così sembra che il low-code si possa utilizzare sono per applicazioni non business-critical. Il che non è vero.
La messa in produzione
Di sicuro il low-code, con la velocità dalla sua parte, rende rapidi i tempi per la prima messa in produzione (deployment). Suggerisco sempre di fare una valutazione di quanto, e sopratutto come, si deve fare successivamente il passaggio in produzione delle modifiche.
Quanto l’app che stiamo costruendo sarà suscettibile di modifiche e di nuove implementazioni? La risposta a questa domanda ci può far scegliere una piattafroma che dispone di ambiente di staging, o permette di realizzarlo semplicemente ed economicamente, piuttosto che un’altra che non lo ha.
E allora? Buttiamo via il low-code?
Assolutamente no. L’idee che mi sono fatto sono:
- NON ESISTE UN LOW-CODE – ce ne sono a centinaia, è imposrtante scegliere la piattefroma giusta per l’applicazione che si deve sviluppare.
- NON SI DEVE USARE SEMPRE E SOLO IL LOW CODE – in molti casi le piattaforme low code dirette ad un aspetto specifico portano dei risultti migliori. Ad esempio usare una piatteforma di low-code per il backend ed adottare uno sviluppo più tradizionale pre la User-Interface ed il Front-end.
- GLI UTENTI PESANO – sotto i 10 utenti è difficile battere il low-code. Ma è una regola del tutto arbitraria, sia perchè anche per centinaia di utenti il low-code è interessante e sia perché dire solamente che gli utenti pesano significa legare agli utenti lo spazio di memoria utilizzato. Non sempre è così.
