Joel on Software

Joel on Software   Joel sul software

 

Altri articoli da "Joel on Software" in italiano

Altri articoli da "Joel on Software" in inglese

Scrivi all'autore (solo in inglese)

JOEL E IL SOFTWARE

 

Fuoco e Movimento


Di Joel Spolsky
Tradotto da Fulvio Ieva
6 gennaio 2002

Ci sono momenti in cui semplicemente non riesco a fare nulla.

Arrivo al lavoro, giro per l’ufficio, controllo la mia Email ogni dieci secondi, leggo qualche articolo su Internet, arrivo a fare alcune cose che non richiedano il minimo sforzo mentale, come pagare le ricevute della carta di credito. Ma rientrare nuovamente nel ritmo per scrivere codice semplicemente non mi riesce.

Tetris

Questo attacco di mancanza di produttività generalmente dura un giorno o due. Ma ci sono stati momenti nella mia carriera di programmatore in cui ho passato settimane senza essere capace di terminare nulla. Come sono abituato a dire, non sono nel ritmo. Non sono in concentrazione totale. Non sono in nessun posto.

Tutti quanti hanno variazioni di umore; per qualcuno sono lievi, per altri possono essere più forti o anche incapacitanti. I periodi improduttivi sembrano essere in qualche modo relazionati con l’umore. Questo mi fa pensare a quei ricercatori che dicono che le persone basicamente non riescono a controllare quello che mangiano, per cui qualsiasi tentativo di dieta sia stato fatto è destinato ad avere durata limitata e queste persone continueranno sempre a ritornare al loro peso precedente in un effetto yoyo.

Forse come programmatore software non riesco a controllare quando sono produttivo, tendo appena a sopportare la successione di periodi di bassa produttività e periodi di alta produttività e sperare che nella media si abbia come risultato un numero di linee di codice sufficienti a mantenere il mio impiego in azienda.

Go read The Onion for a while.

Quello che mi lascia stupito e che sin dal mio primo impiego come programmatore capii che è abitudine avere una media di due o tre ore di programmazione produttiva. Quando feci uno stage in Microsoft, un collega stagista mi raccontò che stava lavorando solo dalle 12 alle 17 tutti i giorni. Cinque ore, meno il pranzo e tutto il suo gruppo lo stimava perché produceva molto sopra la media.

Scoprii che lo stesso succede a me. Mi sento un po’ in colpa quando vedo, quanto gli altri sembrano lavorare duro, anche perché io riesco a produrre due o tre ore di lavoro di qualità al giorno, e anche cosi sembro uno dei membri più produttivi del gruppo.

Probabilmente è per questo che le persone di Peopleware e XP insistono nell’eliminare le ore extra e lavorare esclusivamente 40 ore settimanali. Loro cosi facendo sono coscienti che non andranno a ridurre la produzione del gruppo. Ma non sono solo i giorni in cui faccio “appena” due ore di lavoro che mi preoccupano. Sono i giorni in cui non riesco a far nulla.

Penso di aver meditato abbastanza su questo argomento. Tentai di ricordare quale fu l’epoca più produttiva della mia carriera. Probabilmente fu quando la Microsoft mi collocò in un ufficio nuovo, bello e lussuoso, con finestre ampie e una vista panoramica su un bellissimo giardino pieno di fiori.

Tutto sembrava andare per il meglio. Per un mese lavorai senza fermarmi, producendo con sforzo la specifica dettagliata dell’Excel Basic. Un pacco monumentale di carta che entrava in un livello di dettaglio incredibile, coprendo un modello di oggetti e ambienti di programmazione gigantesco. Letteralmente non mi fermai. Quando andai a Boston per il MacWorld, portai un laptop con me e documentai una classe Window seduto in un confortevole terrazzo dell’Harvard.

Una volta che tu sei entrato nel ritmo, non è molto difficile continuare. Molti dei miei giorni sono cosi: (1) arrivo al lavoro (2) controllo la posta, navigo in Internet, etc. (3) decido che posso andare a pranzo prima di cominciare a lavorare (4) torno da pranzo (5) controllo la posta, navigo in Internet, etc. (6) finalmente decido che devo cominciare … (7) controllo la posta, navigo in Internet, etc. (8) decido di nuovo che devo davvero cominciare…… (9) carico il maledetto editor e (10) scrivo codice senza fermarmi sino ad accorgermi che sono già le 19.30.

In alcune situazioni tra il passo 8 e o il passo 9 ci può essere qualche intoppo, perché non è che riesca sempre a trasporre questa abitudine.

bike tripPer me, cominciare è l’unica cosa difficile. Un oggetto in riposo tende a rimanere a riposo. Ci deve essere qualche cosa di estremamente pesante nel mio cervello che è estremamente difficile collocare in movimento, una volta che ci si trova alla velocità massima poi, non ci vuole molto sforzo per mantenere il movimento. E’ come una bicicletta equipaggiata per un viaggio indipendente per attraversare il paese – quando cominciate a pedalare con tutto quell’equipaggiamento, è difficile immaginare lo sforzo necessario per metterla in movimento, ma una volta che tu stai andando sembra cosi facile quanto andare in bicicletta senza alcun bagaglio.

Forse questa è la chiave per la produttività: cominciare piano. Forse è per questo che la programmazione in coppia funziona, funziona perché quando si combina una sessione di programmazione in coppia con un collega ognuno forza l’altro a cominciare.

Quando ero un paracadutista Israeliano, Joel in the Armyun generale ci fece visita per tenere un piccolo discorso sulla strategia. In battaglia di fanteria, ci disse, esiste solo una strategia: Fuoco e Movimento. Tu ti muovi in direzione del nemico mentre spari. Il fuoco costringe il nemico a rimanere con la testa abbassata, in modo che non ti possa colpire. (è questo che i soldati vogliono dire quando gridano “coprimi”. Vuol dire “spara al nemico perché non possa alzare la testa e non mi possa colpire quando attraverso la strada”. Funziona.).

Il movimento ti permette di conquistare terreno e di avvicinarti di più al nemico, dove la tua visuale di tiro avrà una probabilità maggiore di centrare il bersaglio. Se tu non sei in movimento il nemico riesce a decidere ciò che accade, il che non è una bella cosa. Se tu non spari, il nemico ti colpirà.

Mi ricordai di questo discorso per lungo tempo. Percepii come quasi tutti i tipi di strategia militare, dalla battaglia aerea alle manovre navali in grande scala, sono basate sull’idea del Fuoco e Movimento. Impiegai altri 15 anni per capire che il principio di Fuoco e Movimento è come affrontare le cose nella vita. Tu devi avanzare un poco, tutti i giorni. Non importa se il tuo codice è amatoriale, pieno di bug e nessuno vuole. Se tu avanzi, scrivendo codice e correggendo bug costantemente, il tempo sta dalla tua parte. Presta attenzione quando la concorrenza ti prende di mira. Sarà che loro solo vogliono forzarti ad essere occupato reagendo al loro tiro perché tu non possa avanzare ? Pensa alla storia della strategia dell’accesso ai dati che viene dalla Microsoft.

ODBC, RDO, DAO, ADO, OLEDB e adesso ADO.NET - tutte nuove! Queste tecnologie sono necessarie ? Sono il risultato di un gruppo di progetto incompetente che ha bisogno di re-inventare l’accesso ai dati ogni benedetto anno ? (In verità, probabilmente lo è.) Ma il risultato finale è solo fuoco di copertura. La concorrenza non ha nessuna scelta oltre che perdere tutto il suo tempo portando e mantenendo, tempo che non riesce ad impiegare per sviluppare nuove funzionalità per i suoi prodotti. Guarda con attenzione allo scenario dello sviluppo del software. Le imprese che vanno bene sono quelle che dipendono meno dalle grandi compagnie e non hanno bisogno di sprecare tutti i loro cicli aggiornando, re-implementando e correggendo bug che accadono solo in Windows XP.

Le compagnie che inciampano sono quelle che sprecano molte tempo leggendo le foglie del te tentando di scoprire in quale direzione va la Microsoft. Le persone si preoccupano con .NET e decidono di riscrivere tutta la loro architettura per .NET perché pensano che bisogna farlo. La Microsoft ti sta sparando addosso, e è solo fuoco di copertura perché tu non possa avanzare, sono queste le regole del gioco, Amico. Tu vai a offrire supporto per Hailstorm? SOAP? RDF? Tu vai a offrire supporto perché i tuoi clienti ne hanno bisogno o perché qualcuno ti sta sparando addosso e tu pensi che devi rispondere al fuoco? I gruppi di vendita delle grandi compagnie estendono il fuoco di copertura. Loro vanno dai loro clienti e dicono “Va bene, voi non siete obbligati a comprare da noi. Comprate dal fornitore migliore. Ma state attenti che il prodotto supporti (XML / SOAP / CDE / J2EE) in caso contrario finirete bloccati totalmente”. Cosi quando le piccole imprese tentano di vendere a loro volta, tutto quello che si sentono sono CTOs e direttori obbedienti che ripetono come pappagalli “Voi usate J2EE ?” E cosi si spende una montagna di tempo sviluppando in J2EE anche se non risulta vantaggioso e non sia vantaggioso per il mercato. E’ una funzionalità del tipo “checkbox” – tu la fai perché bisogna cliccare sul checkbox dicendo che è necessario, ma nessuno lo userà o ne sentirà il bisogno. Questo è il fuoco di copertura.

Fuoco e movimento, per le imprese piccole come le mie, significano due cose: Tu hai bisogno di avere il tempo dalla tua parte e devi avanzare comunque ogni giorno. Ma presto o tardi vincerai. Tutto quello che io riuscii a fare ieri fu di migliorare un pochino lo schema dei colori nel FogBUGZ . Tutto bene. Sta migliorando ogni giorno che passa. Ogni giorno il nostro software migliora e abbiamo sempre più clienti, questa è la cosa importante. Finchè non saremo un’impresa del calibro di Oracle, noi non abbiamo bisogno di concepire grandi strategie. Noi dobbiamo solo arrivare la mattina e in qualche modo aprire l’editor.

It's getting better all the time... o/~

 

 

 

 

 

 

 



Traduzione dell'articolo originale inglese dal titolo Fire and Motion  

Joel Spolsky è il fondatore della Fog Creek Software, una piccola ditta di software a New York. Laureato alla Università di Yale, ha lavorato come programmatore e manager presso Microsoft, Viacom e Juno.


I contenuti di queste pagine esprimono opinioni personali dell'autore.
I contenuti sono Copyright  ©1999-2005 di Joel Spolsky. Tutti i diritti riservati.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky