Codice e società/Capitolo 3/1
 |
Questo testo è completo. | |
| ◄ | Capitolo 3 | Capitolo 3 - 2 | ► |
A noi sembra corretto parlare di produzione di codice, piuttosto che di produzione di software. Così come la qualità, il prodotto finito assume un'importanza certamente rilevante di cui però se ne prende carico la scienza informatica. Il codice rappresenta per noi un artefatto, mentre dal punto di vista industriale e informatico, è un semilavorato. Anche quando (il codice) viene compreso (interpretato) dalle macchine senza essere chiuso e compilato, ma non è ancora stato installato, o “fatto girare” in qualche macchina, come si dice in gergo informatico, da un punto di vista industriale non è ancora un software (prodotto finito). L'informatica chiama questa fase ultima della produzione del software “messa in produzione”. Per cui gli esperti del settore usano spesso espressioni del tipo: “il pacchetto è stato testato, ora viene messo in produzione”.
Abbiamo già visto nelle note introduttive che il codice tecnico, comprensibile da donne e uomini specializzati chiamati programmatori, progettisti e analisti, viene compilato per essere reso comprensibile anche dalle macchine, il che corrisponde allo scopo finale: saranno le macchine ad eseguire il lavoro per nostro conto, noi ci limiteremo a fornire dei comandi intuibili anche da persone non specializzate. Però non è sempre così. A volte accade che le macchine, quindi i computer, vengano resi in grado di comprendere anche il codice tecnico. In questo caso la macchina è fornita di un interprete, a sua volta un software. Ciò non sposta i termini del problema: il software è software quando viene “messo in produzione” e fatto “girare”.
C'è una branca dell'ingegneria informatica che va sotto il nome di “industrializzazione del software” la quale come noi, ma per motivi diversi, è interessata al codice. Per questo settore di studio il codice rappresenta una fase intermedia e critica del processo industriale. La produzione di codice precede la produzione di software ed è anticipata dalla progettazione. Perché il processo sia corretto è necessario poter definire, cioè progettare, il software nel modo più predittivo possibile, e si devono definire tempi certi. Secondo questi assunti il fatto che la “creatività” possa posizionarsi in una fase intermedia del processo industriale è un problema non da poco.
Si pensi, ad esempio, di voler mettere in produzione dei nuovi biscotti, ovviamente industriali. Per avere certezza del rientro degli investimenti fatti bisogna essere sicuri che quei biscotti saranno comprati e quindi verranno fatte diverse prove, verranno assaggiati e fatti assaggiare ai potenziali compratori, si faranno indagini di mercato e via dicendo. Si giungerà quindi ad una ricetta che dovrà essere “eseguita” pedissequamente pena l'invalidazione di tutta la fase progettuale. Potrebbe quindi non essere una bella idea inserire nella fase intermedia del processo uno chef “creativo” in vena di sperimentare varianti. La “creatività” viene quindi posizionata a livello di progettazione, il resto del processo non deve fare deviazioni rispetto al momento creativo iniziale.
[…] Il processo di industrializzazione del software, introduce metodi e standard, riduce i margini di creatività e personalismo e consente i seguenti requisiti: buon livello qualitativo; produttività medio-alta; impiego di personale non troppo specializzato (la specializzazione è fornita dallo standard); riduzione sensibile del costo del prodotto … Ogni modulo deve possedere un singolo e ben precisato compito … Nell'ambito di un progetto software, l'analisi richiede la capacità di acquisire le informazioni necessarie alla comprensione e di strutturarle in un modello che esprima, in un linguaggio adeguato, una rappresentazione coerente e completa di cosa deve fare .. Ma tra gli aspetti o le proprietà degli algoritmi da valutare con più attenzione, sicuramente il più importante è proprio il progetto che si presenta come onerosa attività intellettuale (molto più onerosa di quella di esprimere l'algoritmo con un linguaggio di programmazione) che richiede creatività ed intuito ... ” (Alla scoperta dei fondamenti dell'informatica - Chianese, Moscato, Picariello, 2008, p. 114)
Così come per la qualità, anche la “creatività” è un concetto per noi relativo. I criteri che sottendono alla valutazione della qualità di un software sono relativi perché mutevoli, ma anche perché, umanamente, non si può chiedere agli attori in gioco di mettere in discussione ciò su cui hanno investito per molti anni. È concepibile come a fronte di grossi investimenti intellettivi (e non solo) si tenda ad assolutizzare per difendere la propria esperienza: fa parte del gioco. Fino ad oggi la storia dell'informatica vede diversi paradigmi coesistere: si tratta di diversi punti di vista che spesso non solo coesistono ma sono in relazione tra loro. Nonostante i grossi monopoli e la concentrazione di capitale, i giochi tutto sommato sono ancora aperti.
La creatività è anch'essa, dal nostro punto di vista, un concetto relativo. Il fatto che come già visto nel primo capitolo, il mercato non riesca ad appropriarsi di tutta la tecnologia perché è impossibile risalire ad un autore, e con lui ad un momento “creativo”, sta proprio ad indicare la natura “fuggevole” della stessa creatività. Ancora una volta abbiamo a che fare con un significante, piuttosto che con un significato: la creatività viene ritenuta importante per gli attori in gioco, e di conseguenza lo è anche per noi.
Ovviamente anche per i sostenitori del Software Libero e dell'Open Source il momento creativo è importante. A differenza del punto di vista industriale precedentemente illustrato, riconducibile a una prospettiva chiusa e proprietaria del codice il momento creativo, anziché essere posizionato all'apice della catena produttiva, viene posizionato alla base.
[…] scrivo codice con metodo simile a quello di Richard Stallman, per lui la carta non serve. Se sto lavorando su qualcosa di complicato o devo riflettere su precisi dettagli, raramente prendo appunti. Ma in genere quello che succede è che lavoro direttamente sulla macchina. Se il progetto è complicato, prima di cominciare a elaborare il codice, per qualche settimana mi limito semplicemente a pensare a tutti i possibili aspetti e cerco di trovare la soluzione. E tutto senza scartoffie. (Linus Torvalds in Moody, 2002, p. 54)
L'ingegneria informatica distingue due paradigmi di produzione di software. Il “top-down”, che pone il momento creativo all'apice contestualmente alla progettazione, e il “bottom-up”, che posiziona la creatività nel momento di scrittura del codice. In qualche modo, e con le dovute cautele, il Software Libero Open Source è maggiormente orientato al bottom-up, mentre il software proprietario è orientato al top-down.
Con l'affermarsi del Sofwtare Libero e l'Open Source, e con l'espansione del mercato e dell'industria in questo settore, l'ingegneria informatica produce teorie che diano conto di come viene prodotto software Open Source. L'OSSE (Open Source Software Engeneering) è un campo specializzato dell'ingegneria informatica ormai consolidato. Assieme agli approcci, bottom-up piuttosto che top-down, vengono sistematizzati anche i diversi strumenti utilizzati. Quella che nel software proprietario di tipo top-down è la fase di progettazione, nell'ingegneria di tipo Open Source corrisponde alla fase di sistematizzazione dei repositori che conservano e mettono a disposizione il codice, e gestiscono la comunicazione tra collaboratori.
Il disegno viene sostituito da una lista di priorità (agenda) su cui chi partecipa è invitato a dare la precedenza. Da un tipo di produzione all'altra cambia totalmente la natura degli strumenti. Il software proprietario utilizza strumenti che hanno nomi come UML (Unified Modeling Language) o CASE (Computer Aided Software Engineer) e che servono per disegnare il progetto e predire ciò che tale software farà (stampare etichette piuttosto che filettare delle viti) e ciò che non farà (bloccarsi improvvisamente). L'ingegneria del software open source utilizza invece strumenti come i CVS (Current Version System) che servono a permettere a più persone di lavorare sullo stesso codice senza corromperne l'integrità generale. Si tratta in estrema sintesi di un sistema in grado di gestire quella che in termini informatici si chiama “concorrenza sulle risorse”.
Per gli scopi di questa tesi i CVS sono di estrema importanza. Innanzi tutto, a differenza degli strumenti utilizzati dal software proprietario, i CVS vengono “messi in produzione” nel Web, cioè sono fatti “girare” su cosiddetti Web-servers, mentre gli strumenti per progettare software proprietario si installano su dei personal computers. Questo aspetto, seppur circoscritto al paradigma Open Source istituzionale ingegneristico, ci dice fondamentalmente due cose:
- Il codice libero è strettamente connesso con il Web.
- Il codice libero è prodotto nel Web.