Pascal Z., “I guerrieri del software”

Il “capitalismo della conoscenza”

Il “capitalismo della conoscenza”, di cui la Microsoft costituisce l’ “idealtipo”, è anche “capitalismo coalizionale”, economia fondata sulla geometria variabile delle alleanze e delle committenze più che sulla logica centripeta e monopolistica delle concentrazioni e dell’integrazione verticale, di conseguenza, “capitalismo dell’instabilità”: paradigma produttivo incompatibile con ogni forma di programmabilità di medio o lungo periodo, di pianificabilità strategica, di consolidamento dei propri “vantaggi competitivi”. Sistema di “intelligenze” — dunque prevalentemente “immateriale”: macchina linguistica finalizzata alla “produzione di linguaggi per mezzo di linguaggi”—, destinato a una perenne “navigazione a vista”, al costante riadattamento dei propri prodotti e dei propri programmi aziendali, dei tempi e delle specifiche, alla continua “destabilizzazione” di se stesso in rapporto alla instabilità degli altri, dei partner industriali, da una parte, e delle dinamiche di un mercato volatilissimo (come, appunto, l”’intelligenza” che lo crea e lo alimenta), dall’altra.

Lo testimoniano bene le turbolente vicende del gruppo di programmatori impegnati nell’elaborazione di Windows NT, sempre incerti sul proprio destino, sulla conferma o sulla cancellazione del proprio “programma”, esposti ai colpi d’aria dell’innovazione tecnologica (sarebbe bastata la produzione di un nuovo, rivoluzionario tipo di chip per mandare tutto al diavolo), dei rapporti tra Microsoft e IBM, suo principale “committente”, della disponibilità degli altri “sviluppatori” di software a elaborare programmi per quella specifica piattaforma, oltre che, naturalmente, dei volubili atteggiamenti dei consumatori.

Le stesse anomalie caratteriali di Bill Gates — quella sua perenne instabilità che nel volume viene decodificata come “voglia di scappare” (del tutto impensabile in un imprenditore della generazione precedente); quel nevrotico presagio di catastrofe incombente (“Tutto sta andando a rotoli...”), che potrebbe essere scambiato per una forma di pessimismo infondato (la Microsoft è andata costantemente migliorando le proprie posizioni finanziarie e di mercato), e che comunque è l’esatto opposto dell’ottimismo faustiano di ogni imprenditore “fordista” degno di questo nome — rivelano in realtà questa nuova natura “instabile” dell’impresa. Traducono, sul versante personalizzato della psicologia imprenditoriale, il senso profondo dell’impossibile ricerca di punti fermi e dell’estrema vulnerabilità di un modello di corporation il cui valore è, nella sua stragrande maggioranza, costituito da beni immateriali. La cui ricchezza è, nella sua quasi totalità, “virtuale”, e dunque volatile, reversibile, incerta. L’affermazione secondo cui, nell’ambiente turbolento dell’industria informatica (in particolare in quella del software, a intensa concentrazione di capitale intellettuale), “un intero business può collassare praticamente da un giorno all’altro” o “un’intera categoria di prodotti può diventare obsoleta nel giro di una notte”, di cui la Microsoft fa ampio uso nella propria campagna contro i tentativi dell’antitrust americana di incastrarla in operazioni di tipo monopolistico, contiene una buona misura di verità. La “minaccia dell’innovazione saltellante” (“the threat of leapfrogging innovation”, come immaginificamente è stata definita) è effettivamente un carattere intrinseco di questo inedito tipo di produzione che dalla sua forte implicazione con la dimensione linguistica, con i tratti mobili, relazionali, sistemici tipici appunto del “linguaggio”, trae la propria strutturale instabilità. La propria perenne esposizione alle modificazioni imprevedibili e incontrollabili di un “ambiente” che — contrariamente a quanto avveniva nell”’età del ferro” del capitalismo novecentesco, nell’epoca delle grandi concentrazioni dell’industria pesante e della produzione standardizzata di massa — non può essere facilmente né previsto né tanto meno controllato.

XVII

Una cravatta per la prima volta nella propria vita

Narra una leggenda metropolitana che il giorno in cui doveva avvenire lo storico incontro con la multinazionale dell’hardware, alla fine di settembre del 1980, mentre insieme a Ballmer si dirigeva dall’aeroporto di Miami al quartier generale IBM di Boca Raton, Bill Gates, colto dal panico per il proprio abbigliamento trasandato, avesse fatto arrestare l’auto al di fuori di un grande magazzino per acquistare, forse per la prima volta nella propria vita, una cravatta con cui presentarsi agli impeccabili manager IBM.

XVIII

Un peso economico pressoché irrilevante rispetto al contenuto “immateriale”

Apparentemente, dal punto di vista del prodotto, tra un sistema operativo per computer (e in generale tra un qualunque programma informatico) e un’automobile (o una lavatrice, un frigorifero, uno qualunque dei manufatti di una tradizionale impresa industriale novecentesca), si stende un abisso. L’uno è un “testo”, nel quale il supporto materiale (il floppy, il CD) ha un peso economico pressoché irrilevante rispetto al contenuto “immateriale”, l’altro è, appunto, un oggetto che incorpora ed esaurisce nella propria struttura fisica la maggior parte del proprio valore. L’uno è, a tutti gli effetti, un prodotto “linguistico”, un insieme di parole, di segni, di simboli, coordinati in un ordine dotato di senso convenzionale; l’altro è, al contrario, un prodotto “manifatturiero”, risultato dell’assemblaggio di “cose”. Il primo — prodotto della mente: software nel senso più letterale del termine — è del tutto privo di senso se separato dal proprio supporto materiale (dall’hardware) che gli permette di “agire” nel mondo reale (ha un’operatività esclusivamente relazionale); il secondo ha generalmente una propria unità e autonomia funzionale (“basta a se stesso”) - L’uno, per converso, può facilmente essere duplicato e quindi “appropriato” in brevissimo tempo e con un costo pressoché nullo (può essere “copiato”); l’altro, al contrario, ha generalmente un costo di riproduzione paragonabile al suo intero valore.

XIX

Consustanzialità tra capitale intellettuale dell’impresa e persona fisica del dipendente

A Silicon Valley nella seconda metà degli anni settanta era possibile scrivere un buon software da soli, o in coppia, in pochi giorni, al massimo in poche settimane, esattamente come per scrivere una novella per una rivista letteraria, o un libro breve. La capacità di memoria dei primi Altair non superava i 4 K: 4.000 bytes, l’equivalente di un testo di due cartelle!

Gates e Allen impiegarono sei settimane per produrre — col solo appoggio “esterno” di Marty Davidoff per le subroutines dei calcoli a virgola mobile — il “loro” primo Basic che permise di animarlo e di far uscire miracolosamente dalla stampante la prima scritta: “MEMORY SIZE?”.

Avevano lavorato è vero, giorno e notte, andando avanti a caffè e adrenalina, addormentandosi sulla tastiera e sognando righe di codice, come appunto accade nella fase creativa di ogni scrittore, ma avevano comunque impiegato poco più di un mese.

Poi però i tempi erano cambiati, con la crescita di potenza delle macchine e con la parallela esplosione delle dimensioni delle loro memorie di lavoro progredite entrambe in misura esponenziale (un processore Pentium contiene l’equivalente di circa 10 milioni di transistor, contro gli appena 10.000 del primo processore Intel — il 4004 del 1974 —, utilizzando una memoria di lavoro media di 32 o 64 milioni di bytes contro i 4.000 di quello). E con i tempi è mutato anche il “tempo” di elaborazione, i suoi costi ,e le sfide “logistiche” e “organizzative” connesse a questa inedita complessità: per la programmazione di Windows NT sono stati necessarie circa 2 milioni e mezzo di ore di lavoro, e un investimento di oltre 150 milioni di dollari (quasi 300 miliardi di vecchie lire).

Anche in questo caso la creatività individuale delle origini — il puro “genio” dello scrittore — lascia, almeno in parte, il posto al lavoro di squadra, alla gestione di gruppi sempre più ampi e in rapida crescita man mano che l’attività procede: ai 25 componenti del gruppo di base, che aveva iniziato alla fine degli anni ottanta l’avventura di NT, si sostituiranno, ben presto, tre gruppi di codifica di circa 35 persone ognuno, più un gruppo di collaudatori (altri 35) seguito ben presto dal gruppo della grafica (costituito a sua volta da tre unità relativamente autonome) e da una terza sezione impegnata sul networking, fino a un totale di più di 250 persone impegnate direttamente. A cui va aggiunto il gruppo parallelo che si occupava dell’hardware. Un esercito, per certi versi, non paragonabile certo alla massa di lavoro generico impiegato nel modello produttivo “fordista”, ma “sterminato” se confrontato con le dimensioni fino a poco prima artigianali della produzione di software.

Ma la dimensione in valori assoluti dell’organico complessivo — 19.641 dipendenti alla fine del 1997, impegnati nella produzione di programmi software in più di 30 diverse lingue commercializzati in oltre 50 paesi — rivela, in realtà, la struttura di una grande impresa ormai ampiamente massificata.

Per un verso, infatti, è ben visibile l’irriducibilità ai codici consolidati della produzione d’impresa di quel tipo di lavoro svolto da figure del tutto anomale: titolari di Ph. D., geni matematici transitati per i dipartimenti di mezza America, ingegneri informatici dall’esperienza consolidata, giovani talenti naturali della programmazione emersi dal reticolo degli hobbisti, nomadi innamorati della frontiera informatica. La stia incompatibilità con le stesse forme giuridiche del lavoro salariato — che presuppone, pur sempre, un minimo di astrattizzazione dell’attività lavorativa: la possibilità di rendere fungibile, o quanto meno confrontabile il contributo di ognuno —, ben espressa da quella clausola n. 10 del contratto di lavoro con cui la Microsoft impegnava (e probabilmente continua a impegnare) ogni nuovo assunto a non accettare, in caso di licenziamento o comunque di abbandono dell’impresa, un posto presso mina ditta concorrente per almeno un anno. Per il tempo medio in cui il capitale “intellettuale” che ognuno si porta dentro, ben impresso nella “memoria di lavoro” del proprio personale cervello, rimane operativo (mantiene un proprio valore di mercato), e oltre il quale si prevede che diventi “obsoleto” (che cessi di costituire un “vantaggio competitivo”). In quella clausola è infatti visibile, in filigrana, la traccia giuridica dell’inedita consustanzialità tra capitale intellettuale dell’impresa e persona fisica del dipendente che costituisce, appunto, uno dei tratti più nuovi, e sconcertanti, del “capitalismo della conoscenza” dominante in questa fine di secolo. E dichiarata, nero su bianco, l’impossibilità di separare i nuovi, più efficaci mezzi di produzione di questa nuova forma di impresa (il sapere, l’intelligenza, la capacità di ideazione) dalle donne e dagli uomini che li incorporano fisicamente, quasi che, in qualche modo, s’invertisse il tradizionale rapporto tra capitale e lavoro così come da Marx in poi era stato disegnato: non più il “capitale fisso” che incorpora gli uomini nelle proprie strutture meccaniche, ma al contrario gli uomini che incorporano i mezzi di produzione nelle proprie strutture organiche (nei propri corpi). Che fanno delle proprie facoltà mentali, direttamente, uno strumento di lavoro, senza più separazione tra “interno” ed “esterno”, tra “dentro” e “fuori”. E dunque tra vita e lavoro. Tra tempo e luogo della propria attività lavorativa e tempo e luogo della propria esistenza privata.

Di questa vera e propria distruzione del confine tra lavoro e tempo libero che colpisce al cuore il concetto stesso di “giornata lavorativa”, così decisivo per definire i caratteri propri della prestazione “salariata”: l’idea di un tempo “delimitato” oltre il quale l’obbligo a prestare il proprio lavoro decade e inizia il tempo della “riproduzione”; e insieme l’idea di un “luogo” deputato alla produzione — la fabbrica — al di fuori dei quale l’attività lavorativa è impensabile. I creatori di Windows NT sono lavoratori dipendenti, ma in realtà sono trattati e si trattano da lavoratori autonomi, come autonomi sono buona parte dei consulenti esterni chiamati a fornire prestazioni intellettuali nel medesimo processo lavorativo;”’ oltre a un certo numero di sub-fornitori di strumenti informatici sofisticati usati in talune fasi di lavorazione. E in parte come lavoratori autonomi — o soci lavoratori, o co-imprenditori — sono remunerati, secondo quella formula della compartecipazione azionaria che, attraverso la rapida e intensa valorizzazione del titolo, ha reso molti di loro multimilionari. E che, effettivamente, va oltre la forma “salariale” alludendo a un rapporto di lavoro per lo meno in parte “post-capitalistico”.

XXIII

Ford il presidente goffo

Diamond attribuiva l’ostinata animosità di Cutler nel confronti di Whitmer e compagni a quella che chiamava “la sindrome di Gerald Ford”. “All’inizio della sua presidenza, Ford era caduto dalla scaletta dell’aereo presidenziale”, spiegava Diamond. “Alcuni giorni dopo scivolò mentre passeggiava nel prato. Improvvisamente, era diventato il presidente goffo. Non c’era via di scampo. Pur essendo uno dei migliori atleti che mai abbiano occupato la Casa Bianca, Ford non è ancora riuscito a tutt’ oggi a liberarsi di quella fama”. La lezione era chiara: la mente di Cutler lavorava nello stesso modo. “Ci eravamo fatti quella fama. Una volta che sei entrato sulla sua lista nera, è impossibile che si ricreda”.

Pascal Z., “I guerrieri del software”, Utet, pag. 109

Pai Gow, antico gioco cinese di strategia

Per Cutler, il gruppo della grafica era la pietra dello scandalo. “Si preoccupava continuamente per quel gruppo”, disse un suo amico intimo. “Pensava che fossero delle mine vaganti”. Benché eccessiva, la paranoia di Cutler era alimentata da alcuni segni allarmanti. Nonostante l’entusiasmo di Diamond, Walt Moore stava sprofondando sempre più nel malessere che lo affliggeva. Moore era uno dei veterani nell’équipe. Da lui ci si attendeva un bel po’ di codice per i driver della grafica. Le altre componenti di NT avrebbero anche potuto essere straordinarie, ma senza il codice di Moore lo schermo del computer sarebbe rimasto completamente nero. Sebbene fosse un esperto di driver grafici, Moore procedeva con estrema lentezza. Da tempo aveva espresso il desiderio di cercare qualcuno che lo sostituisse consentendogli di fare qualcos’altro, ma non aveva mai fatto nulla in questo senso. Ricordava a menadito i codici che aveva scritto dieci anni prima, ma non gli veniva in mente nulla di nuovo.

Gli amici provarono a fargli coraggio. “Tutti facevano il tifo per Walt”, diceva un collega. “Tutti lo incoraggiavano a fare la sua parte di lavoro e a integrarsi con il resto della squadra. Walt è uno che non può non piacere”.

L’incoraggiamento di tutto il gruppo non bastò a sollevare l’animo di Moore. Chiuso nel suo ufficio, passava ore su una simulazione computerizzata del Pai Gow, antico gioco cinese di strategia. Era stato Whitmer, a cui piaceva scommettere sul Pai Gow, a fargli conoscere quel gioco. Il mazziere mostra quattro tessere del domino a un giocatore, il quale può disporle in tre modi differenti. Ai neofiti il gioco sembrava totalmente casuale, e il risultato completamente dipendente dalle tessere che venivano assegnate. O forse no? In una delle sue gite al casinò, Whitmer si era imbattuto in un libro intitolato: I patimenti del Pai Gow, ove aveva trovato questa osservazione: “Si ritiene che per impiegare una strategia ottimale, un giocatore avrebbe bisogno di un computer nascosto”.

Whitmer prese questa affermazione come una sfida; cercò di dimostrare che poteva giocare a Pai Gow come e forse meglio di un computer.

Pascal Z., “I guerrieri del software”, Utet, pag. 109

Una lunga navigazione sul suo otto metri a vela

Le argomentazioni tecniche a favore del NTFS erano alquanto solide. La capacità di ricuperare i file “perduti” sarebbe stata estremamente vantaggiosa per gli utenti. Anche il fatto che OS/2 fosse incapace di gestire grandi repertori di file di dimensioni superiori a quattro gigabyte, contribuiva a far propendere Maritz verso l’ipotesi di Cutler. Se davvero NT doveva essere in grado di gestire le reti informative di intere aziende, c’era la possibilità che esso dovesse gestire file ancor più grandi.

Il capo decise di permettere a Miller di scrivere una specifica per NTFS, ma si riservò la facoltà di bocciare il progetto prima che la codificazione del nuovo sistema di archiviazione avesse effettivamente inizio.

Miller raccolse un po’ di penne e di quaderni, si rifornì di provviste sufficienti per due settimane e si preparò a una lunga navigazione sul suo otto metri a vela. A suo giudizio le specifiche andavano scritte in solitudine, e in mezzo all’oceano di solitudine ce n’era a volontà. Tuttavia aveva sufficiente esperienza per sapere che “i migliori risultati non si ottengono lavorando in assoluta solitudine. Ci vuole qualcuno che sia almeno in grado di darti qualche spunto”. Kimura, che sarebbe stato il compagno di viaggio ideale, non poteva venire: aveva un appuntamento con gli altri sistemi di archiviazione. Deciso a non partire da solo, Miller prese accordi con Perazzoli, che ufficialmente dirigeva la squadra incaricata di preparare il sistema di archiviazione, perché facesse arrivare dalla Svizzera un programmatore che Miller conosceva bene.

Nel mese di agosto, Miller e il suo amico salparono per una crociera di due settimane. A bordo, i due se la prendevano comoda: al mattino lavoravano, scambiandosi idee e prendendo appunti sui quaderni, poi levavano l’ancora per andare da qualche parte, quindi tornavano a discutere e a prendere appunti sui notes; a sera, infine, si gettava l’ancora e ci si rilassava. “Questo genere di lavoro non va fatto con troppa intensità”, sosteneva Miller.

Durante la crociera, Miller aveva riflettuto su decine e decine di questioni tecniche relative al sistema di archiviazione, ma soprattutto aveva riflettuto intensamente sulla possibilità di ricuperare e ricostruire i file perduti a causa di perdite di tensione o malfunzionamenti. Era questa la caratteristica che avrebbe deciso la sorte del sistema di archiviazione di NT. Alcune versioni di Unix, il costoso programma operativo che Cutler intendeva superare con il suo NT, erano già in grado di ricuperare i file in situazioni di quel genere. Ma quando un personal computer perdeva dati contenuti in un file, solitamente quella perdita era definitiva. Infatti, a meno che venisse specificatamente richiesto di memorizzare le nuove informazioni nella memoria permanente dell’hard disk, i computer tendevano a risparmiare tempo memorizzando i dati nella memoria temporanea DRAM, assai più veloce: in caso di malfunzionamento, tuttavia, quella memoria veniva completamente cancellata.

Per risolvere il problema, Miller stabilì che era necessario registrare in duplice copia tutti i dati immessi nel computer. La prima registrazione era quella corrente, che veniva archiviata dapprima nella memoria temporanea, e quindi in quella permanente. La seconda registrazione sarebbe stata destinata a un accesso speciale e quindi inviata separatamente all’hard disk. Quell’accesso non avrebbe consentito di ricuperare i dati immessi nel preciso istante del disastro, ma avrebbe conservato tutto ciò che era stato caricato fino a pochi secondi prima, ossia quello che Miller chiamava “l’ultimo carico utile”. Una volta che il computer avesse ripreso a funzionare, i file sarebbero ricomparsi in quella condizione.

Era un’idea rivoluzionaria, ma poneva un serio problema pratico, dal momento che la necessità di caricare i dati in duplice copia influiva negativamente sulle prestazioni dei computer. Generalmente, la duplicazione dei dati veniva eseguita ricorrendo a due elaboratori che funzionavano in tandem. Gli sportelli automatici delle banche, i mercati azionari e le altre organizzazioni che non avrebbero potuto sopravvivere per più di un secondo senza informazioni aggiornate, ricorrevano a questo metodo basato sul raddoppio dell’hardware per garantirsi una copia di riserva di tutti i dati. Miller voleva giungere a un risultato simile, ma servendosi del software e di un solo computer. Non era certo un’impresa da poco, ma la soluzione andava lentamente prendendo forma nella sua mente. Era necessario predisporre un accesso speciale per scongiurare il pericolo di una perdita di dati. Inoltre, Miller aveva intravisto la possibilità di ridurre il tempo necessario a registrare permanentemente i dati: in questo modo, l’accesso speciale non avrebbe rallentato di molto il computer, forse non lo avrebbe rallentato per nulla.

Pascal Z., “I guerrieri del software”, Utet, pag. 119

una riga di caratteri anomali: 3ffffffffffff7

La scadenza fissata da Thompson era ormai vicina, ma il suo codice di rete si rifiutava oli funzionare quando veniva utilizzato in combinazione con un modello di personal computer della Compaq. Le pagine di testo diffuse dal PC attraverso la rete presentavano, in prossimità del margine superiore, una riga di caratteri anomali: 3ffffffffffff7.

Tutti gli altri dati erano perfettamente nella norma: quella formula misteriosa (che per di più compariva a intervalli irregolari, da tre minuti a venti ore) era l’unico dato corrotto in tutta la pagina. La corruzione dei dati era un peccato mortale, per certi versi ancora peggiore di un’avaria. Se un programma andava in avaria distruggendo dei dati, le perdite potevano essere circoscritte. Con quel genere di errori, era impossibile valutare l’entità dei danni.

Treadwell identificò per la prima volta quell’errore il 26 maggio, una domenica: ben presto, altri colleghi furono attirati nella trappola. Dopo tre settimane di tentativi infruttuosi, Treadwell, Gary Kimura e un altro collega di nome Glass decisero di dedicare il terzo fine settimana di giugno alla risoluzione di quell’errore. Altre quattro persone, tra cui Perazzoli e Havens, si unirono al gruppo.

Durante quel fine settimana Treadwell si convinse che il codice non aveva difetti. Mike Glass, un’autorità in fatto di interazioni tra hardware e software, era dello stesso avviso.

Glass si incontrò segretamente con alcuni ingegneri della Compaq: Cuntler aveva sostenuto che forse poteva esserci un difetto nell’hardware di rete. Trascorsero altre settimane; poi, verso la metà di luglio, Glass si imbatté in quello che sembrava un inizio di soluzione. Un ingegnere della Adaptec, una società che produceva strumenti per il controllo dell’input e delI’output impiegati nei Computer della Compaq e di altre marche prestigiose, gli aveva inviato un foglio di errore di alcuni mesi prima, in cui si descriveva un bug rispondente alle stesse caratteristiche.

E tutto qui! Glass andò su tutte le furie. Nelle ultime sei settimane di caccia all’errore, aveva parlato più volte con quell’ingegnere della Adaptec: una volta gli aveva persino descritto particolareggiatamente il difetto, e quello gli aveva risposto che non ne aveva mai sentito parlare. Glass era imbestialito.

Pascal Z., “I guerrieri del software”, Utet, pag. 136

“Il fatto più importante che si era verificato sul lavoro”

Karen, che non si rassegnava alla silenziosa sofferenza di suo marito, stabili una regola: Horne avrebbe dovuto raccontarle ogni giorno “il fatto più importante che si era verificato sul lavoro”. Rendendosi conto che il suo matrimonio stava andando alla deriva, Horne afferrò prontamente quell’ancora di salvezza. I suoi “aneddoti dal fronte” rimisero Karen di buon umore.

Pascal Z., “I guerrieri del software”, Utet, pag. 146

Le prove da sforzo

Le prove da sforzo consistevano in svariate combinazioni di programmi scritti appositamente per portare alla luce difetti di NT. Solitamente i test venivano eseguiti durante la notte, su oltre un centinaio di computer. Al mattino, i “medici di guardia” controllavano le statistiche di efficienza compilate dagli stessi test. Sulla base di quei dati veniva calcolato il tasso medio di efficienza: in pratica, era come misurare la temperatura di un ammalato.

Uno dei test fondamentali, cui era stato dato il nome di “Tilt”, prevedeva l’esecuzione di cinque operazioni sempre uguali:

1.         Crea un file,

2.         Apri il file,

3.         Scrivi le lettere da A a Z nel file,

4.         Controlla che il file sia corretto,

5.         Chiudi il file.

Tilt girava per tutta la notte: una volta creato un certo numero di file, questi venivano cancellati e l’intero processo ricominciava daccapo. Abbinato ad altri test, Tilt poteva durare giorni interi.

S. Somasegar, l’autore di Tilt, era uno dei primi collaudatori del progetto, e ora ricopriva l’incarico di responsabile delle prove da sforzo. Coscienzioso e preciso. Somasegar si sforzava di capire in che modo si potesse mandare un avaria un programma, ma soprattutto si domandava dove cercare i punti deboli.

Pascal Z., “I guerrieri del software”, Utet, pag. 151

Somasegar preferiva davvero scrivere codice per i collaudi piuttosto che per il programma vero e proprio: riesco a vederlo tutto intero

Mentre altri collaudatori erano afflitti da un complesso di inferiorità per il loro lavoro, Somasegar preferiva davvero scrivere codice per i collaudi piuttosto che per il programma vero e proprio. “Il vantaggio è che posso lavorare con diverse componenti di NT: riesco a vederlo tutto intero”. La maggior parte dei programmatori erano immersi un piccoli frammenti del programma e non avevano la possibilità di comprendere le interazioni tra le varie parti. Erano specialisti in campi assai ristretti; i collaudi, viceversa, generavano un numero impressionante di esperti a tutto campo. “Quando fai i collaudi”, diceva Somnasegar, “ti capita spesso di imbatterti in problemi che sono al di fuori della tua area di competenza, ma dei quali ti devi comunque occupare; in questo modo finisci per imparare tutto di NT, persino i dettagli più intimi”.

Pascal Z., “I guerrieri del software”, Utet, pag. 152

Risparmiare sul personale

Anche tenendo conto delle decine e decine di consulenti esterni assoldati per incarichi specifici e di breve durata, l’organico del gruppo era ampiamente insufficiente. Tutti sembravano avere un carico di lavoro superiore a quello che poteva essere svolto nell’arco di una settimana di quaranta ore lavorative, ma si trattava di una condizione imposta dai dirigenti della società. La loro teoria era: “Se hai bisogno di due persone per fare un lavoro, assumine una”, spiegava Shannon. “E una strategia esplicitamente dichiarata. Ho visto dei promemoria che ne parlavano: la chiamano politica dell’N meno uno”.

Se all’epoca la Microsoft guadagnava 25 centesimi su ogni dollaro di vendite, ciò si doveva non soltanto all’ottima posizione che si era conquistata su un mercato in costante espansione, ma anche alla sua capacità di tirare sulle spese. I salari erano generalmente piuttosto bassi, compreso quello di Gates: per ripagare i lavoratori delle enormi quantità di lavoro straordinario non retribuito e non riconosciuto, la Microsoft faceva affidamento sul crescente valore dei suoi titoli azionari. Molti dipendenti scoprivano che lavorare in maniera produttiva e per un numero di ore maggiore gli fruttava di più in termini di assegnazioni di titoli della società.

Pascal Z., “I guerrieri del software”, Utet, pag. 181

Scrivere software è un’attività che richiede grandi quantità di tempo. Scrivere software è un’attività che richiede grandi quantità di tempo. Dopo averla lungamente sottovalutata, molti ingegneri considerano oggi la programmazione come una tra le attività umane più complesse. La vera e propria stesura del codice è un’attività solitaria, ma progettare e far combaciare le diverse parti di un programma è un’impresa che si basa sulla cooperazione e sul compromesso. Una volta che un’équipe di programmatori si divide in gruppi più piccoli, la comunicazione tra i gruppi e all’interno di essi comporta un gran numero di movimenti oscillatori, verso l’esterno e quindi verso l’interno. Il ricorso alla posta elettronica riduce, una non abolisce totalmente la necessità di contatti faccia a faccia, che richiedono tempi più lunghi rispetto ai messaggi scritti. D’altra parte, compiti di importanza cruciale come l’individuazione e la correzione degli errori di programmazione presuppongono l’apporto di più persone. Il lavoro dei programmatori è frequentemente interrotto: anche i più disciplinati dedicano circa la metà del loro tempo alla programmazione vera e propria, mentre il resto delle ore vengono impiegate per scrivere promemoria, rispondere alle domande dei colleghi, controllare il lavoro fatto in precedenza e acquisire nuove competenze.

La programmazione, naturalmente, è l’attività che richiede maggiore attenzione. Infatti, benché semplificata dall’impiego di diversi strumenti, essa si sottrae all’automazione: in un certo senso è il residuo di una fase precedente dello sviluppo, l’epoca in cui ogni artigiano imprimeva il suo marchio particolare su prodotti che, dal punto di vista funzionale, erano identici ad altri. Inoltre, sebbene sia generosamente ricompensato, il lavoro del programmatore è spesso giudicato con severità. “Un computer è un critico spietato”, osservava Joseph Weizenbaum, uno dei pionieri dell’informatica. Mentre i progettisti vengono giudicati da pari, il valore dei programmatori viene stabilito, in ultima analisi, da una macchina.

I misteri del codice, a volte, restavano impenetrabili anche per i professionisti più esperti e scaltri. Non era facile stabilire perché certi programmatori programmassero meglio di altri. I migliori erano quelli che avevano grande familiarità con il ragionamento astratto e sapevano analizzare i problemi in termini di simboli. Quando non avevano una formazione specifica nei campi della matematica formale e della logica, dimostravano un’istintiva capacità di comprendere i principi di quelle discipline. Erano in grado di parlare il linguaggio segreto che soltanto il loro computer capiva alla perfezione.

Pascal Z., “I guerrieri del software”, Utet, pag. 183

I migliori programmatori come pittori di fronte alla tela

I migliori programmatori si sforzavano caparbiamente di risolvere i problemi, cercando di raggiungere la soluzione anche se ciò interferiva con la loro vita quotidiana. Indipendentemente dal grado di esperienza o dalle ambizioni di carriera, tutti riconoscevano che nel loro lavoro vi era un elemento di casualità, e tendevano a considerare se stessi più come artisti che come artigiani. Spesso li sì vedeva immobili davanti alla tastiera in cerca di un’ispirazione, come pittori di fronte alla tela. I collaudatori, dal canto loro, vivevano nella costante angoscia che, per quanto tentassero di far emergere tutti gli errori nascosti, qualche difetto veramente grave restasse nascosto sotto la superficie. La loro unica difesa era non smettere mai di collaudare.

Alcuni trascorrevano le vacanze programmando, oppure dedicavano i fine settimana a pasticciare su programmi mai terminati. A volta, quell’esercizio serviva a prendere dimestichezza con nuove tecniche o nuovi strumenti; spesso, tuttavia, i programmatori non potevano proprio fare a meno di programmare. “E’ una specie di dipendenza fisica: come potrei definirla altrimenti?” confessava un programmatore.

Nei casi estremi, il richiamo del computer era più forte del bisogno di cibo o di affetto. Bob Day, che tutti consideravano il collaudatore più dotato della squadra, amava troppo programmare. Sua moglie Terri faticava alquanto a separarlo dai computer portatile che si portava costantemente appresso in ogni stanza della casa. Appena giunto a casa dopo la consueta mezz’ora di viaggio, a volte Bob si precipitava direttamente nella stanza degli ospiti, ove troneggiava un computer da tavolo nuovo di zecca. Altre volte cercava di fare le cose di nascosto, facendo credere a sua moglie di essere impegnato in qualcos’altro. Poi, quando Terri decideva di leggere un libro, guardare un film o semplicemente andare in bagno, si accorgeva improvvisamente che suo marito se l’era svignata rifugiandosi nella stanza degli ospiti. “Anche un solo quarto d’ora di lavoro può valere la pena”, diceva Bob.

Terri cercava di convincersi che nella travolgente passione di suo marito non c’era nulla di personale, ma nonostante ciò dubitava di se stessa e attribuiva al computer la colpa delle scarse attenzioni che Bob le dedicava. “Provavo ostilità verso il computer”, afferma. “Era come se il computer fosse un’altra domina. Avevo proprio quella sensazione”. Il sabato pomeriggio, Terri proponeva al marito di fare una gita in automobile; lui le rispondeva che preferiva programmare. “Bob, ma tu non hai altri interessi?” domandava lei. “No”. “Ma perché ti sei sposato?” “Perché ti amo”, era la risposta.

Pascal Z., “I guerrieri del software”, Utet, pag. 185

Prima dei computer erano gli animali, pensiero mortale non senziente, i nostri vicini più prossimi nell’universo noto

L’incessante picchiettare sui tasti, ora per motivi seri, ora per gioco, dimostrava come per molti lavorare al computer fosse puro e semplice divertimento. Johanne Caron amava risolvere problemi, e si sentiva perduta se non aveva qualche enigma da risolvere; Wood si dilettava delle infinite possibilità di scelta offerte dal suo gioco; Culter, sebbene vedesse la programmazione come un’attività a scopo puramente economico, trovava sfogo al suo straordinario perfezionismo. Lucovsky, dal canto suo, si meravigliava di come il computer fosse in grado di por fine alle discussioni astratte sui metodi di programmazione. Come ha osservato Gerald Weinberg nel suo studio dedicato alla programmazione, gli effetti pratici di una determinata parte di codice rappresentano un criterio di valutazione assoluto. “Il meno che possiamo fare è immettere il programma nella macchina e vedere che cosa ne viene fuori”, sostiene Weinberg nei saggio intitolato The Psychology of Computer Programming. “Un artista può ricusare il parere dì un critico se questo non gli aggrada, ma come può un programmatore respingere il giudizio di un computer?”

In un mondo di ambiguità e di opinioni contraddittorie, in cui le risposte definitive sono merce assai rara, il potere del computer di separare il software buono (che funziona) da quello cattivo (che non funziona) esercita un potere ipnotico sui programmatori. Non sorprende, dunque, che la creazione di programmi (messaggio diretto da una persona a una macchina) diventi per alcuni una sorta di santuario. La psicologa sociale Sherry Turkie ha scritto: “Prima dei computer erano gli animali, pensiero mortale non senziente, i nostri vicini più prossimi nell’universo noto. Ora sono i computer; con la loro capacità di interagire, la loro) psicologia, i loro frammenti dì intelligenza, a pretendere quel posto”.

Pascal Z., “I guerrieri del software”, Utet, pag. 186

la creazione del profilo utente

Johanne Caron faceva buoni progressi con il Progam Manager, e all’inizio di marzo 1992 si offrì volontariamente di scrivere una parte supplementare al suo codice, chiamata Group Editor. Il suo capo stava pensando di affidare il compito a qualcun altro, ma prima che lo potesse fare Johanne annunciò che aveva già finito. “Rimasero sbigottiti”, raccontò lei, sentendosi per una volta impertinente.

Non contenta delle pressioni che doveva sopportare, Johanne assunse un altro incarico gravoso, ovvero la creazione del profilo utente. Questa parte dei programma definiva e memorizzava le varie impostazioni (colori dello schermo, velocità della tastiera, connessioni con la rete e le stampanti, e così via) selezionate dall’utente. NT era in grado di memorizzare un gran numero di profili utente, cosicché più persone potessero utilizzare la stessa macchina e avere immediatamente disponibili le loro personalizzazioni preferite. Mentre lei si occupava di questo, tutti gli altri strapazzavano il suo Program Manager, importunandola con mille problemi. Poiché la sua parte di codice era responsabile del lancio di NT, era sempre tra i primi a essere interpellata quando qualcuno non riusciva ad avviare il sistema operativo. Spesso si scopriva che lei non aveva alcuna responsabilità, ma tutti quei falsi allarmi la irritavano. Giunse al punto in cui, ogni volta che un collega la criticava, lei provava l’istinto di “saltargli alla gola”.

Pascal Z., “I guerrieri del software”, Utet, pag. 188

ordinare i documenti secondo i criteri adottati da ciascuna lingua

Nel frattempo, i collaudatori si davano da fare, individuando decine e decine di errori. Kimura, Mìller e Andrew si sentivano sopraffatti. “È difficile arginare i collaudatori”, diceva Kimura. “Ti sommergono, ti seppelliscono errori da correggere, e a sentir loro tutti dovrebbero essere corretti immediatamente. In particolare, il gruppo di Kimura era tormentato da un collaudatore estremamente zelante, che lui chiamava “la sventura della nostra vita”.

Non passava giorno che i tre non si trovassero alle prese con qualche nuovo mistero. Una questione particolarmente spinosa riguardava il modo di ordinare alfabeticamente i file in modo da tenere conto delle differenze esistenti tra l’inglese e le altre lingue supportate dal programma. Dopo aver sperimentato diverse soluzioni, Kimura, MiIler e Andrew decisero di memorizzare all’interno dei programma l’ordine alfabetico di ciascuna lingua, in modo che il sistema di archiviazione potesse ordinare i documenti secondo i criteri adottati da ciascuna lingua.

Pascal Z., “I guerrieri del software”, Utet, pag. 195

Impossibile affiancare degli aiuti

Era un impegno gravoso, che di fatto aveva trasformato Miller e Kimura in una sorta di squadra di riparatori in servizio ventiquattr’ore su ventiquattro. “E’ facile dare la colpa al sistema di archiviazione quando praticamente non c’è nulla che funzioni a dovere in NT”, aveva ammesso qualcuno. “Non potevano di certo chiudere a chiave la porta e occuparsi soltanto del nuovo sistema di archiviazione. Tutte quelle interruzioni logoravano i nervi”.

Alla fine Kimura riuscì ad affidare buona parte del lavoro di manutenzione a un quarto programmatore che fino a quel momento li aveva aiutati a prendersi cura dei vecchi sistemi di archiviazione. Ma a quel punto, la domanda era: Come diavolo facciamo a finire il lavoro se siamo soltanto in tre?

Perazzoli decise che non era il caso di coinvolgere altre persone. Miller, Kimura e Andrew erano i soli depositari di un sapere così arcano da far pensare che l’aggiunta di due o tre persone nuove potesse addirittura far arenare il progetto. “Probabilmente finirebbero per accumulare un ritardo ancora maggiore “, sosteneva Perazzoli.

I veterani avrebbero dovuto dedicare così tanto tempo alla formazione dei nuovi arrivati da perdere di vista il loro lavoro. E quando finalmente le nuove leve fossero state in grado di dare effettivamente una mano, il gruppo non avrebbe più potuto rispettare la scadenza prefissata. “Non è che avendo due persone che la aiutano, una donna potrebbe fare un bambino in tre mesi” diceva Perazzoli.

Pascal Z., “I guerrieri del software”, Utet, pag. 195

Nella sua casa non c’era l’acqua corrente

Trascorrendo così tanto tempo in ufficio, era costretto a trascurare la vita domestica. Siccome non aveva neppure il tempo di aprire la posta le bollette non pagate si accumulavano l’una sull’altra. Tornato a casa una sera di aprile, si accorse che la sua casa era senz’acqua: l’acquedotto municipale di Beilevue aveva interrotto la fornitura a causa dei ritardi nel pagamento delle bollette precedenti. Era assurdo: possedeva un’automobile da cinquantamila dollari, una piccola fortuna in azioni della Microsoft, ma nella sua casa non c’era l’acqua corrente. Un mese dopo, e sempre per lo stesso motivo, gli venne quasi sospesa l’erogazione dell’energia elettrica.

Pascal Z., “I guerrieri del software”, Utet, pag. 197

Ognuno pensa che avrebbe rimediato l’altro

Perazzoli diede origine a “un bel mucchio di errori”, pensando che Miller si sarebbe preoccupato di sincronizzare le chiamate tra il sistema di archiviazione e il gestore della memoria. Miller; dal canto suo, pensava che ne sarebbe incaricato Perazzoli. Il risultato finale fu che quelle due importanti componenti di NT risultarono scarsamente congeniali l’una all’altra.

Pascal Z., “I guerrieri del software”, Utet, pag. 197

L’eliminazione degli errori

A dispetto della lenta maturazione del sistema di archiviazione, l’affidabilità di NT faceva costanti progressi. Ormai la squadra addetta al progetto era composta da ben duecentocinquanta persone, alcune delle quali assunte con incarichi temporanei nel preciso intento di aiutare il programma a superare la china. Ogni notte, l’assemblaggio più recente veniva sottoposto a prove da sforzo su duecento computer.

Nei mesi immediatamente precedenti la scadenza, i risultati delle prove da sforzo migliorarono sensibilmente, dal momento che i membri del gruppo si erano concentrati sull’eliminazione degli errori di codifica. Ogni giorno ne venivano eliminate decine e decine, e le modifiche erano tempestivamente riunite in un nuovo assemblaggio. Le cifre parlano da sole: il 3 giugno, circa la metà dei computer avevano superato lo sbarramento di test cui era stato sottoposto l’ultimo assemblaggio. Una settimana più tardi, le percentuali ammontavano rispettivamente al 68 e al 79 per cento.

Pascal Z., “I guerrieri del software”, Utet, pag. 197

La “scrittura pigra”

Poiché il sistema di archiviazione aveva un ruolo cruciale nel determinare la velocità di NT, Linn lo passò al vaglio. Lo fece senza alcun sentimentalismo nei confronti di Miller e Kimura: lavorava per un altro capo, e pensava che “non fosse il caso di essere troppo teneri” con i programmatori. Pensava che la scarsa efficienza del sistema fosse dovuta a qualche difetto, e scoprì che NTFS era qualitativamente inferiore ai vecchi sistemi di archiviazione soprattutto nell’esecuzione di operazioni banali quali la memorizzazione e il ricupero di nuovi dati nei documenti. La differenza era “allarmante”. Linn si domandò: “Siamo più lenti per un motivo intrinseco o semplicemente perché abbiamo sbagliato qualcosa?”

Linn stabilì che Miller aveva involontariamente creato una strozzatura nelle procedure per la registrazione dei dati sull’hard disk, il principale dispositivo di memorizzazione del computer. Si trattava di un effetto collaterale, del tutto accidentale, della passione di Miller per l’affidabilità. Miller aveva cercato di porre un limite alle operazioni di trasferimento dei dati dalla memoria temporanea cache alla memoria permanente del disco rigido. Aveva scelto questa soluzione perché sapeva che collocare i dati nell’hard disk era un processo relativamente più lungo, dal momento che si trattava di un dispositivo elettromeccanico: ogni volta che il sistema di archiviazione “scriveva” sul disco, era necessario individuare uno spazio vuoto sul disco girevole.

Miller si era servito di una tecnica piuttosto diffusa, detta “scrittura pigra”. In questo modo era possibile conservare i dati nella memoria cache, limitando il numero di operazioni di scrittura sul disco rigido. Diversamente dalla memoria su disco, che rimaneva intatta per anni, la memoria cache veniva completamente cancellata ogni volta che il computer perdeva improvvisamente energia o veniva spento; d’altro canto, la scrittura sulla cache era un processo molto rapido, perché interamente elettronico. Il funzionamento del sistema di scrittura pigra era semplice: ogni volta che la memoria cache aveva accumulato una quantità sufficiente di dati, lo scrittore pigro inviava un blocco di dati alla memoria permanente. Quel sistema consentiva pertanto di ridurre il numero degli invii di dati e rendeva più efficiente il sistema di archiviazione

La scrittura pigra, tuttavia, poteva risultare controproducente ai fini dell’affidabilità del sistema. Ogni volta che lo scrittore pigro scaricava la sua infornata di dati, qualche evento accidentale avrebbe potuto cancellare i dati. Per cautelarsi contro la perdita dei dati Miller aveva fatto sì che quando lo scrittore pigro era pronto a trasferire i dati nella memoria permanente, il sistema di archiviazione di NT non potesse registrare altri dati in nessun’altra collocazione, neppure nella memoria cache. In questo modo, tuttavia, il sistema di archiviazione risultava considerevolmente più lento, talora fino a venti volte.

Nell’arco di alcuni mesi Linn riuscì a convincere Miller della necessità di modificare il suo sistema di protezione in modo che i file potessero essere aperti, modificati e memorizzati più rapidamente. Sulle prime Miller si era opposto, ma alla fine era riuscito a trovare una soluzione efficace, predisponendo un piccolo test che domandava al sistema di archiviazione se un dato momento era possibile sospendere la protezione. Se il sistema di archiviazione avesse risposto affermativamente, sarebbe stato possibile memorizzare dati nella memoria temporanea anche durante le operazioni di scarico effettuate dallo scrittore pigro.

Linn formulò altri suggerimenti, definendoli “piccoli espedienti che ci avrebbero reso molto”. La modestia di Linn e la grande acutezza di alcuni dei suoi consigli persuasero Miller ad accettarli di buon grado. A volte Miller si dava pacche sulla testa e bestemmiava a voce alta perché le modifiche proposte da Linn erano così semplici che non riusciva a capire come mai non ci avesse pensato lui stesso. Era proprio vero che uno sguardo dall’esterno, a volte, faceva miracoli. “Conoscevamo così bene il nostro codice”, disse poi Miller “che ci sembrava coerente anche quando non avrebbe dovuto sembrarci tale. Linn lo aveva esaminato con occhio critico”.

Pascal Z., “I guerrieri del software”, Utet, pag. 217

Saper parlare. Le sue spiegazioni estemporanee erano assai eleganti

Abrash era un abilissimo programmatore: un collega lo aveva definito “con ogni probabilità, il miglior programmatore Intel sulla faccia della terra”. Abrash era assai rapido nell’identificare i problemi e abilissimo nell’escogitare soluzioni; inoltre, dimostrava un talento tutto speciale nel descrivere ai colleghi le operazioni da compiere per rendere più rapido il sistema. Le sue spiegazioni estemporanee erano assai eleganti, segno di una straordinaria consapevolezza delle sue capacità. La maggior parte dei programmatori, al contrario, erano come atleti di talento: imparavano le cose nel momento in cui le facevano, e non erano in grado di spiegare le loro azioni. Semplicemente, facevano così. Quel metodo, spesso utile nelle fasi iniziali di un lavoro, si rivelava tuttavia controproducente nel momento in cui bisognava rendere più veloce il programma, poiché ciò richiedeva una straordinaria capacità di autoanalisi. “Il segreto per ottimizzare la velocità”, diceva Abrash, “sta nel domandarsi: ‘Che cosa deve fare esattamente questa parte di codice? Qual è il meno che posso fare per risolvere il problema?’

Assai spesso i programmatori non erano in grado di rispondere a quelle domande. “Pressati dalla necessità di svolgere compiti nei quali si è ancora inesperti, tendiamo ad accontentarci delle approssimazioni, non siamo in grado di capire tutto ciò che accade”, sosteneva Abrash. “Diciamo a noi stessi: “D ‘accordo, non so esattamente come funzioni questa subroutine (una parte di codice che compie una specifica operazione) però funziona, e non è il caso di fare pasticci.”

Farsi domande cruciali su questa o quella parte di codice, di solito, non portava da nessuna parte; a volte, però, anche quell’espediente era di grande beneficio.

Pascal Z., “I guerrieri del software”, Utet, pag. 219

L’adattatore grafico o Super VGA, in grado di produrre duecentocinquantasei colori

A un certo punto, Abrash si domandò come sarebbe stato possibile sveltire il funzionamento di un pilota di dispositivo di cruciale importanza, ovvero la parte di codice che controllava l’adattatore grafico chiamato Super VGA, in grado di produrre duecentocinquantasei colori diversi sullo schermo del computer.

I membri del gruppo erano già soddisfatti per essere riusciti a inserire quel tipo di driver, dal momento che il progetto originale prevedeva che NT supportasse semplicemente l’adattatore VGA a sedici colori, delegando ai costruttori di hardware la responsabilità di far funzionare il programma con altri monitor. Ma quando Abrash era diventato membro a tempo pieno del gruppo, aveva stabilito che NT doveva essere provvisto di un driver Super VGA. “In caso contrario”, diceva, “la nostra credibilità ne avrebbe sofferto. Seguendo i consigli di Abrash, il novellino che era stato incaricato di scrivere il codice necessario riuscì a portare a termine l’incarico in sole sei settimane, e con pochissimi errori.

Ma Abrash non era ancora soddisfatto. Normalmente, un monitor Super VGA disegnava due pixel, cioè due puntini di colore, contemporaneamente. Era venuto il momento di collaudare il “trucchetto” che aveva escogitato alcuni anni prima, grazie al quale, sperava, sarebbe stato possibile tracciare otto  pixel per volta.

Ma c’era un ostacolo. Ad Abrash era stato consigliato di non fare nulla per accrescere l’efficienza del nuovo driver di visualizzazione, dal momento  che si trattava di un’aggiunta recente e non ancora collaudata. Piuttosto che apportare modifiche che avrebbero rischiato di produrre errori, era meglio stabilizzare il nuovo driver così com’era.

Senza curarsi di quel saggio consiglio, Abrash decise che avrebbe tentato di migliorare il codice a suo rischio e pericolo, lavorando di notte. Se l’esperimento fosse fallito, nessuno avrebbe potuto accusarlo di sottrarre impegno ad altri lavori. Il “trucchetto” consisteva nell’escludere il funzionamento normale dell’hardware Super VGA, creando condizioni speciali che acceleravano il processo di visualizzazione dei duecentocinquantasei colori. Successivamente, Abrash modificò il codice che controllava la visualizzazione del testo sullo schermo, in modo da sfruttare nel modo migliore la possibilità di disegnare otto pixel contemporaneamente.

Improvvisamente, il testo cominciò ad apparire sui monitor alla velocità del fulmine. E finalmente, dopo tanto tempo, il gruppo della grafica ebbe qualcosa di cui vantarsi. Per mesi e mesi, mentre gli altri membri dell’équipe si lamentavano degli scarsi progressi compiuti sul fronte della velocizzazione della grafica, il gruppo aveva continuato a sperare in un improvviso rovesciamento della situazione. Poi finalmente, come qualcuno aveva detto, “era giunto il miracolo, e quel miracolo era Mike Abrash”.

Pascal Z., “I guerrieri del software”, Utet, pag. 219

La velocità del testo

L’oggetto del contendere era la velocità del testo. Perché i caratteri si formavano così lentamente sulla videata di NT? Il problema riaffiorava continuamente, dal momento che la scrittura di testi era l’attività più comune per chiunque possedesse un personal computer. Il gruppo della grafica aveva una buona parte di responsabilità, ma Butzi era convinto che alcuni elementi basilari di NT contribuissero ad aggravare il problema. La sua attenzione si diresse in particolare verso il codice console scritto da Therese Stowell.

Butzi non era stato troppo diplomatico nell’esprimere il suo punto di vista: “Il tuo codice è troppo lento”, aveva detto alla Stowell.

Therese aveva reagito con prevedibile veemenza: “No, è il tuo codice che è lento, e poi tu non sai nulla della console”.

Wlutmer si senti offeso, considerò l’ipotesi di rassegnare immediatamente le dimissioni. Ormai era uno dei programmatori più ricchi del gruppo, e continuava a lavorare per puro piacere personale.

La controversia sfumò poi in toni meno accesi, finché a un certo punto i compagni del gruppo suggerirono alle due parti di collaborare, definendo una serie di criteri per la valutazione del problema. In tal modo fu possibile accertare che tanto la Stowell quanto Butzi erano ugualmente responsabili per la lentezza del testo. Placati gli animi, il lavoro di perfezionamento procedette a ritmi sostenuti. In seguito entrambe le parti avrebbero ammesso che, benché il loro amor proprio ne fosse uscito un po’ scosso, l’efficienza delle rispettive parti di codice era notevolmente migliorata.

Le tensioni createsi tra la Stowell e Butzi dimostrano l’importanza dei Conflitti personali nel mondo della cultura tecnica: le diatribe sui principi e sui metodi di lavoro sono la linfa vitale dell’innovazione. Poiché nel progettare le loro parti di codice i programmatori facevano affidamento soprattutto sulla logica e sulla matematica, essi tendevano a sottovalutare il peso delle opinioni personali in tutte le decisioni di carattere tecnico. E tuttavia, il senso di inevitabilità che si tende ad attribuire a tutte le grandi intuizioni non è che un’illusione. Per ottenere gli stessi fini tecnici si possono applicare diversi mezzi, e spesso le scelte di carattere tecnico sono altamente personali. Benché condizionate dalle finalità di tipo commerciale, le decisioni tecniche sono comunque un riflesso dei valori e della psicologia dell’uomo.

Pascal Z., “I guerrieri del software”, Utet, pag. 219

Soltanto negli ultimi dodici mesi, il gruppo aveva eliminato qualcosa come trentamila errori

Gli errori erano inevitabili: erano conseguenza delle imperfezioni nascoste in ogni essere umano. Per evitare di commettere errori, “bisognava lavorare alla perfezione”, ma nessuno ci riusciva mai. A proposito degli “incerti del mestiere” di programmatore, Frederick Brooks ha scritto: “Se un solo carattere, una sola pausa della formula magica non sono esattamente come dovrebbero essere, l’incantesimo non funziona. Gli esseri umani non sono abituati alla perfezione. Del resto, sono pochi gli ambiti dell’attività umana che la richiedono. Adeguarsi all’esigenza di perfezione è, a mio parere, la cosa più difficile da fare quando si impara a programmare”.

Pascal Z., “I guerrieri del software”, Utet, pag. 244

Parlare degli errori in tono sommesso, quasi religioso

Cutler e i suoi luogotenenti aggiornavano il conteggio totale degli errori con la stessa attenzione con cui si analizza l’entità delle perdite umane in una guerra. “Ogni giorno facevamo la conta degli errori”, racconta David Thompson, il responsabile delle reti. “Se il loro numero continuava a crescere troppo a lungo, la nostra sorte era segnata”. Persino i programmatori più esperti non potevano escludere la possibilità di restare intrappolati in una sorta di circolo vizioso in cui le correzioni degli errori generavano altri errori. Era già accaduto ad altri: la storia del software era disseminata di grandi e piccoli progetti abbandonato per pura e semplice stanchezza, compromettendo onorate carriere. Ciò induceva anche i tecnici più intransigenti come Thompson a parlare degli errori in tono sommesso, quasi religioso. Era quello il linguaggio dell’umiltà, della consapevolezza che il nemico era una forza elementare che era il caso di affrontare ponendosi sul suo stesso piano. Gli errori di codifica erano l’insidia più grave in ogni grande programma, sosteneva Thompson, perché “sono il problema per eccellenza, e per di più sono invisibili. Nessuno sa mai quanti errori ci sono”.

Pascal Z., “I guerrieri del software”, Utet, pag. 245

Un programmatore si occupava personalmente di correggere i propri errori

Era assolutamente normale che un programmatore si occupasse personalmente di correggere i propri errori. A volte i collaudatori cercavano di rimediare alla meglio, ma le modifiche scorrevano più lisce quando venivano dallo stesso autore del codice. “Quando sei tu ad aver costruito la struttura, i presupposti ti sono più chiari”, spiegava un programmatore. “Un estraneo può leggere i commenti, ma non può sapere che cosa in particolare preoccupasse l’autore del codice. Una modifica che l’autore avrebbe fatto in dieci secondi richiede a volte mezza giornata di lavoro”.

Pascal Z., “I guerrieri del software”, Utet, pag. 249

Raggiungere la “quota zero” errori

Gli errori di Johanne, frattanto, nomi smettevano di tormentarla. Poteva essere una telefonata o una visita di Esti Mintz, il collaudatore assegnato al suo codice. O forse un messaggio di posta elettronica. Lo stupore e la curiosità che la coglievano all’arrivo di ogni nuova segnalazione lasciavano ben presto spazio all’irritazione e allo stordimento, non appena Johanne si rendeva conto che non poteva trovar pace finché l’errore non era eliminato”. A volte riusciva a disfarsene prima di sera. La mattina del 3 maggio, Minta le aveva segnalato un errore importante nel Program Manager: l’icona relativa a un’applicazione in DOS occupava l’intero schermo invece che una piccola finestra. Mezz’ora dopo, Johanne aveva già individuato l’errore: con poche parole fuori posto, aveva involontariamente ordinato al suo Program Manager di fare la cosa sbagliata. Contava di riuscire a consegnare la modifica agli assemblatori entro l’una del pomeriggio.

Le modifiche, frattanto, scorrevano a fiumi. Una settimana più tardi, Johanne era sul punto di raggiungere la “quota zero”. Domenica 9 maggio ne aveva eliminati due, e ora non glie ne restava che uno: l’errore numero cinquecentosessantanove, un autentico killer che aveva colpito indisturbato per settimane intere e si verificava ogni volta che certi database venivano installati su NT. Normalmente il codice di Johanne creava un gruppo separato per i nuovi programmi, ma in quel caso, invece, si comportava come se il nuovo gruppo esistesse già. Prima di addormentarsi, quella notte, aveva immaginato se stessa intenta a correggere quell’errore, e poi aggirarsi trionfante per i corridoi dell’Edificio numero due indossando la maglietta del club “quota zero”. Ne mancava soltanto uno...

Pascal Z., “I guerrieri del software”, Utet, pag. 249

I rapporti tra collaudatori e programmatori rimasero tesi finché David Wild non riuscì a superare l’impasse

All’epoca, “i programmatori erano convinti che i collaudatori fossero degli idioti, e i collaudatori pensavano che i programmatori fossero totalmente imbecilli. Ovvio che questo non fosse il clima ideale per una collaborazione fattiva”, racconta un osservatore neutrale.

Il conflitto nasceva sostanzialmente dalle diverse priorità dell’una e dell’altra parte. Preoccupati di definire il modello generale, i programmatori non intendevano perdere il loro tempo per correggere gli errori di programmazione. I collaudatori, dal canto loro, volevano collaudare, ma ciò non aveva alcun senso quando gli stessi errori si ripresentavano settimana dopo settimana.

I rapporti tra collaudatori e programmatori rimasero tesi finché David Weld, il program manager, non riuscì a superare l’impasse. Profondo conoscitore della politica delle organizzazioni, Weld aveva riunito i due gruppi in un’unica stanza (cosa mai avvenuta prima) e aveva cercato di convincere i presenti a pensare a se stessi come a membri di un unico gruppo. In seguito, aveva organizzato una serie di incontri informali tra collaudatori e programmatori. Aveva funzionato: di lì a poco i collaudatori avevano cominciato a sentirsi parte della famiglia, e i programmatori erano diventati “schiavi degli errori”, come qualcuno aveva detto.

Pascal Z., “I guerrieri del software”, Utet, pag. 253

Una copia di tutte le “chiamate” dall’applicazione Windows al sistema operativo

In seguito, sarebbe stato Bob Day a compiere un altro gesto decisivo che avrebbe dissipato gli ultimi dubbi sull’importanza dei collaudatori per il gruppo di Felton. Day aveva trovato il modo di aggirare un problema che minacciava di rallentare il cammino verso la compatibilità. Dal momento che il modello di compatibilità di Felton non era ancora in grado di far funzionare a lungo un gran numero di applicazioni Windows, come era possibile collaudare il modello generale e metterne in luce le carenze? Per risolvere il problema, Day aveva inventato un registratore di software che faceva una copia di tutte le “chiamate” dall’applicazione Windows al sistema operativo. La registrazione delle chiamate effettuate, ad esempio, dai foglio di calcolo Excel, consentiva ai programmatore di individuare un obiettivo specifico. Per mettere alla prova le proprie capacità, il modello di Felton non doveva fare altro che duplicare quelle chiamate.

Per comprendere meglio il funzionamento dei registratore di Day, consideriamo ad esempio “MoveWindow”, una delle circa novecento chiamate che un’applicazione Windows è in grado di fare. MoveWimmdow serve a guidare da una parte all’altra dello schermo il movimento di una finestra che potrebbe contenere, diciamo, un documento, un’immagine o una serie di icone. Affinché l’ordine venga eseguito correttamente, la chiamata viene corredata di una serie di coordinate matematiche che rappresentano la destinazione della finestra e le sue dimensioni. Lo strumento ideato da Day serviva per l’appunto a registrare quei valori impressi nella struttura della chiamata MoveWindow.

La cosa più difficile, aveva scoperto Day, era registrare tutte le chiamate. In soli due minuti Excel era in grado di fare ben cinquecentomila chiamate diverse, che dovevano essere captate nella giusta sequenza e conservate, in modo da poterle analizzare in seguito. A dire il vero, il registratore di Day era talmente abile nei captare e registrare le chiamate, che il vero problema consisteva nei trovare uno spazio di memoria sufficiente per conservarle. Ma Day, alla fine, era riuscito a risolvere anche quel problema.

Anche con l’aiuto del registratore di Day, il gruppo di Felton era comunque in netto ritardo rispetto al resto della squadra. La versione di NT presentata nei luglio del 1992 alla conferenza di San Francisco era completamente priva della caratteristica di compatibilità. Di li a poco il gruppo avrebbe terminato il suo modello generale, ma raggiungere il traguardo finale era comunque “un’impresa disperata”, aveva detto Weld. Il guaio era che le applicazioni Windows non seguivano regole precise. Capitava spesso che un programma di largo uso facesse le sue chiamate al DOS secondo modalità dei tutto peculiari. Il modello di NT avrebbe dovuto in qualche modo rispecchiare le stesse peculiarità. Quando il numero delle applicazioni funzionanti superava di poco la decina, “eravamo convinti di aver insegnato a NT a far girare soltanto quelle”, racconta Weld, “perché giravano alla perfezione, ma quando provavamo con un’applicazione nuova, non funzionava mai al primo tentativo”.

Weld cercò di appianare l’ostacolo interpellando decine e decine di programmatori di applicazioni e facendosi spiegare i trucchi di cui si erano serviti nei loro programmi Windows. Dalle loro risposte era emerso uno schema ricorrente. “Benché molte applicazioni presentassero problemi specifici, vi erano indubbiamente delle caratteristiche comuni”, spiega Day.

Pascal Z., “I guerrieri del software”, Utet, pag. 253

Un esempio di formula magica

Abrash stava controllando riga per riga tutto il codice della grafica, con l’aiuto di un debugger. Snipp e Wong si scambiavano pareri.

Nell’ufficio, frattanto, Snipp si chinò verso Wong. Erano le dieci di sera passate. Ridendo, Snipp suggerì che forse Pagemaker stava semplicemente sbagliando nel calcolare le dimensioni dei caratteri, e che il suo consumo esagerato dì memoria dipendeva dal fatto che il programma si comportava come se i caratteri fossero molto più grandi di quanto erano in realtà. Nella mente di Wong si aprì un varco. Lanciò un urlo: Snipp aveva quasi colto nel segno. C’erano due errori, e quello nel codice della grafica ne portava alla luce un altro in Pagemaker.

Wong impiegò dieci minuti a correggere l’errore nella grafica: la memoria riservata ai caratteri per la stampa era insufficiente. Quattro righe di codice eliminarono l’inconveniente, provvedendo una quantità di memoria appropriata:

prfnt->cache.pjAuxCacheMem =

(PBXTE) PVALLOCMEM (cjMaxBitmap + sizeof( GLYPHDATA));

prfnt->cache.cjAuxCacheMem =

(cjmaxBitmap + sizeof(GLYPHDATA));

Mentre attendeva che il compilatore trasformasse il suo codice in un testo leggibile da un computer, Wong si domandava: “Se andiamo avanti e introduciamo questa modifica, quali saranno gli effetti? Quante applicazioni andranno in avaria  per colpa della mia modifica a Pagemaker? Stiamo forse mettendo in pericolo la stabilità dell’intero sistema?”

Pascal Z., “I guerrieri del software”, Utet, pag. 267