Sulla qualità del software

Di recente 3agle3ye ha, per varie ragioni, interagito con un’azienda di medie dimensioni che fa software. E con “medie dimensioni” si intende “ha più di 2 dipendenti”, e con “software” si intende ovviamente “un catorcio gestionale in VB6”, come praticamente tutte le aziende che fanno software in Italia. Il mercato dei gestionali fatti con i piedi in Visual Basic e mai veramente aggiornati dal 2004 non conosce crisi, a quanto pare.

Il software in questione è un enorme piatto di spaghetti senza commenti e ha un database da migliaia di tabelle completamente privo di ogni forma di documentazione e bisogna scrivere un altro software in grado di interfacciarsi con questo schifo. Fortunatamente il compito non tocca a me, e nemmeno a 3agle3ye.

Ciò che mi sorprende, tuttavia, è che 3agle3ye riesca a difendere questo penoso baraccone pur non avendo vincoli di parentela o amicizia con alcuno che ci lavori: sostiene infatti che è un’azienda seria in quanto è in giro da anni e ha venduto decine di migliaia di licenze per il proprio software, e che tanto “a nessuno importa l’estetica del codice” e “i veri bug fixer [sic] sono gli utenti”. Questo mi ha portato a una riflessione che ritenevo utile scrivere qui.

Innanzitutto, gli utenti non “fixano” i bug, al massimo li trovano. Cioè vedono il problema dall’esterno, ma non conoscendo né potendo vedere il codice non possono identificare esattamente cosa c’è che non va, e allora serve qualcuno che conosca bene il programma per metterci le mani dentro e trovare una soluzione. Una soluzione sensata, stabile, che non introduca altri 15 bug e che non sia solo una pezza superficiale piena di “corner cases” in cui il bug si ripresenta.

Oltre a questo, è una tendenza abbastanza comune, nell’industria del software, buttare giù dal carrozzone il controllo qualità e lasciare che siano gli utenti a trovare i bug, a fare da beta tester: Microsoft, a quanto si dice, ha licenziato in massa i tester e Windows 10 beta viene rifilato agli “insider” che fanno da beta tester gratis, Steam straripa di giochi “early access” che vengono pure fatti pagare, etc…

Dopotutto, all’azienda conviene: si risparmiano un po’ di stipendi e gli utenti sono ormai abituati all’inaffidabilità del software, al fatto che crashi tutto di continuo, al fatto che «bisogna solo ottimizzarlo un po’», al «Gli sviluppatori sono ragazzi come noi [anche se sono centinaia di indiani offshore in outsourcing, ndr], lasciamo loro un po’ di respiro!» e così via. Qualche recensione furente sul Play Store in più o in meno non cambierà nulla, tanto tutte le app sono piene di recensioni furenti da 1 stella, spesso perché altro crapware presente sul telefono le fa crashare nonostante siano impeccabilmente programmate, quindi la qualità reale è totalmente indipendente dalle recensioni.

Ogni software di dimensioni significative (più grande di un “hello world”) è in realtà un sistema complicatissimo composto da librerie, alcune incluse e alcune esterne, che vanno aggiornate di continuo e talvolta contengono bug a loro volta, che deve interagire con altro software (sistema operativo, server, browser, client, etc…) che cambia di continuo in maniera caotica, sono sistemi che vanno ormai oltre la comprensione del singolo sviluppatore, che magari sa esattamente cosa fa ogni parte del suo programma, ma non può materialmente sapere cosa fanno ogni singola libreria o il sistema operativo, internamente, quando interagisce con essi, e nemmeno con i browser che vengono aggiornati di continuo con nuove feature e componenti della “libreria standard” JS e protocolli basati su header HTTP improbabili e nuove regole CSS, con gradi variabili di supporto per tutte queste cose e a volte estensioni e stramberie non standard, bug da aggirare, e in generale molta confusione e anarchia.

Cosa comporta questo? Che i bug aumenteranno a dismisura: gli sviluppatori non possono materialmente sapere come interagirà il loro software con tutto il resto del software esistente, ci saranno sempre leggeri problemi e incompatibilità, che si sommano finché non funziona praticamente più nulla.

È inutile e presuntuoso dare giudizi sull’industria informatica a livello mondiale, quindi concentriamoci su quella italiana: è in larga parte composta da questi baracconi fossilizzati su VB6, o che magari si sono aggiornati a C#, che sfornano deprimenti software gestionali, e che non hanno ridotto la qualità nel corso degli anni… perché non ce l’hanno mai avuta. Zero documentazione, zero test automatizzati, zero tester, zero controllo qualità, zero standard sulla qualità del codice, zero procedure standard, zero beta tester, zero dignità.

Perché? Probabilmente c’entra col fatto che, per ragioni che non ho capito ma in realtà ho capito, i programmatori sono sempre trattati dal capo come dei pezzenti che “fanno un lavoro facilissimo” e addirittura pretendono di essere pagati per il loro lavoro.

Devono fare la cosa in fretta, la cosa deve funzionare, cioè deve sembrare funzionante quando il manager/cliente la guarda di sfuggita, poi non importa cosa c’è sotto. Eppure, per renderla funzionante, ci vogliono sempre cose di complessità spropositata, sotto. Cose che richiedono ore, giorni, mesi di fatiche abnormi, ma sono “nascoste”, non si notano, quindi è come se quel lavoro non ci fosse mai stato…

L’atteggiamento tipico è: sforna il codice, laido dipendente, che sei solo un costo per l’azienda! I test non implementano le feature che il cliente vuole, e il cliente paga anche se il gestionale gli crasha ogni 2 minuti e gli perde tutti i dati “business critical” in copia unica, male che vada gli diciamo con larghi sorrisi «Sì, sì, dobbiamo solo ottimizzare un po’, i nostri sviluppatori altamente qualificati ci stanno lavorando!» e si calma.

E se c’è un bug, beh, «fixalo, tanto ci vogliono 5 min :DDDDDD», e magari ci vogliono 5 giorni e una totale conoscenza di ogni singola parte del codice, quindi non si potrebbe nemmeno farlo fare a un altro (senza chiedergli prima di ottenere la totale conoscenza del codice, che richiede 5 mesi magari…), eppure il programmatore di turno continua a essere visto come un elemento praticamente inutile per l’azienda, facilmente rimpiazzabile con qualche stagista o con qualche perito neodiplomato, tanto tutti sanno pesticciare sulla tastiera come scimmie, no? Il lavoro è solo pesticciare sulla tastiera e il magnifico codice perfettamente funzionante fluisce dalle loro mani, no? Dietro non ci sono assolutamente esperienza e conoscenze non banali né la profonda conoscenza del programma in questione, no? Chiunque potrebbe farlo, no?
Dopotutto, anche in altri settori è opinione comune, in Italia, che l’esperienza non conti nulla per le aziende, che rimpiazzano veterani con 30 anni di esperienza con stagisti neolaureati e sperano di poter essere operativi a regime immediatamente senza perdere qualità nei prodotti. Ma questo è un altro discorso, anche perché non trovo né motivazioni razionali né irrazionali per questa follia…

In ogni caso, software così scadente non funziona. Chiaro e semplice. Non è qualche bug a caso ogni tanto, che capita in tutto il software esistente tranne quello realizzato con tecniche di programmazione formali, è un problema strutturale che si manifesta in una mole di bug senza pari e nell’incapacità di arginarla efficacemente. Se clicco troppo in fretta qualche bottone dell’interfaccia grafica non devono succedere cose strane, altrimenti c’è qualche race condition! Se cade la connessione a internet mentre il software dialoga con un computer remoto, non deve restare fermo lì a vita anche quando torna la connessione, né perdere tutto il lavoro fatto fino a quel momento! È inaccettabile fornire all’utente messaggi come “Errore non specificato”, l’utente deve sapere cos’è andato storto, cosa fare per riprovare, o se non ha senso riprovare!

Perché? Perché la qualità a nessuno importa. Perché? Beh, se c’è da scegliere tra “software di qualità completato in tempi lunghi e con costi esorbitanti” e “software scadente pronto dopo 2 minuti e di qualità inesistente”, quale scelgono tutti? Sì, ma perché?

E se fosse che il software costa troppo poco? Siamo abituati al fatto che, essendo immateriale, debba anche costare poco. Non vediamo le ore, i giorni, i mesi, gli anni di lavoro altamente qualificato che sono stati necessari per creare quell’interfaccia grafica con 2 bottoni che funzionino sempre, nella maniera prevista, e che non si pianti nemmeno nei corner cases più assurdi e improbabili che immancabilmente avvengono, e che sia compatibile con plurime versioni del sistema operativo e delle librerie che potrebbero esserci installate, e che sia veloce, e che interagisca correttamente con tutto il resto del sistema. Anche perché spesso ci sono 2 minuti di lavoro fatto “come viene, viene” perché il dipartimento vendite ha già venduto, con i soliti larghi sorrisi, a un prezzo irrisorio, un software che ancora non esiste e deve essere pronto entro ieri.

L’intero sistema mi fa profondamente schifo, ma d’altra parte il mercato vuole questo. Vuole spazzatura usa e getta, vuole teste di legno che sfornino spazzatura il più velocemente possibile. La parola d’ordine è “doveva essere pronto entro ieri”, tagliamo su documentazione, test, qualità, tutto, basta che ci sia qualcosa da mostrare al cliente. E le aziende che cercano di fare meglio di così, costando di più e mettendoci di più a produrre software di qualità (e la qualità non è apparente a prima vista, e nemmeno a seconda, si percepisce forse nel lungo termine), sono destinate a morire all’istante perché i clienti si riversano sul baraccone che continua a fixare 1 bug e introdurne 15 sul proprio gestionale VB6 del 2004.

…3agle3ye, sottopostagli questa riflessione, si è mostrato in netto disaccordo, sostenendo che le competenze di solito sono riconosciute (nel senso di “un ingegnere è superiore a un altro laureato”… sì, ma già lo sappiamo che gli ingegneri prendono stipendi da ingegnere anche se fanno lavori che di ingegneristico non hanno nulla, e indipendentemente da quanto bene ed efficientemente fanno il proprio lavoro), che un programma per “funzionare” deve “rispettare la spec”, che fixare i bug richiede tempo e fatica, che a nessuno viene in mente di subappaltare tutto al miglior offerente.

Non mi ha convinto e io non ho convinto lui… e voi, cari lettori (anche se nessuno leggerà mai l’articolo), cosa ne pensate?

Annunci

2 pensieri su “Sulla qualità del software

  1. Donato Silvestri

    é la prima volta che leggo il tuo blog e lo trovo molto strano, forse perché mi sono allontanato dalla programmazione da qualche anno (non essendo programmatore di professione ma hobbier).
    Comunque il tua articolo è molto interessante e rispecchia in toto una tendenza che, e questo ti potrebbe stupire maggiormente, è anche in altri settori (esclusi quelli dove l’utilizzatore potrebbe morire).
    Così, per consolazione, vedila così: se avessi fatto un altro mestiere in ingegneria, probabilmente non sarebbe cambiato nulla.

    Donato

    Rispondi

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...