Programmare il programmatore

Brian Harry, product manager del team che sviluppa Foundation Server per Visual Studio di Microsoft, ce lo presentano come un guru per l’ambiente dotNET. In Italia per una conferenza con gli sviluppatori del Belpaese, ha accettato di fare quattro chiacchiere con Punto Informatico : ne è venuta fuori una discussione sulla vita del programmatore e cosa c’è all’orizzonte per chi fa questo lavoro. Il tutto alla vigilia del rilascio della nuova versione di uno degli IDE più utilizzati in ambiente Windows.

Punto Informatico: Da qualche settimana è disponibile la beta 2 di Visual Studio 2010. Secondo alcuni addetti ai lavori, l’evoluzione di questa versione ricorda vagamente quello che era accaduto agli esordi dell’IDE Microsoft, all’epoca di Visual Basic: non c’è il rischio che la distanza tra il codice vero e il livello a cui si programma si ampli troppo?
Brian Harry: Il lavoro degli sviluppatori si va facendo sempre più sofisticato, le applicazioni diventano sempre più complesse sul piano delle feature e del tipo di dati che devono trattare: video, animazioni e così via. In qualche modo bisogna tentare di aumentare l’astrazione a cui lavorano i programmatori, altrimenti gestire questo tipo di applicazioni rischierebbe di diventare impossibile.

PI: Ad esempio?
BH: Dalle versioni 2000 in avanti, Visual Studio ha sempre offerto diversi livelli di astrazione. Un esempio buono per spiegarsi può essere Silverlight e le applicazioni abbinate: posso decidere di lavorare sulle animazioni, sulle trasparenze e le transizioni senza toccare il codice, oppure posso andare direttamente sul codice stesso per ottimizzare le singole parti. Tutto dipende dal tipo di lavoro che si intende fare. È una questione di essere produttivi ad alto livello mantenendo il controllo a basso livello, evitando che si creino due mondi distinti e scollegati.

PI: Il concetto di ottimizzazione è senz’altro fondamentale: in che modo l’ambiente di sviluppo può aiutare in questo senso? C’è senz’altro una differenza netta tra le prestazioni necessarie per una piccola applicazione o un piccolo sito, e quanto occorra fare per un progetto di grandi dimensioni.
BH: Certo, creare un’applicazione che vada bene per milioni di utenti è molto differente rispetto a crearne una per poche decine. Ci vogliono conoscenze e competenze differenti, creare un’applicazione scalabile e funzionale non è certo un risultato ottenibile partendo unicamente da un template. Per questo abbiamo dei percorsi specifici pensati per creare questo tipo di applicazioni.

PI: Quali sono i fattori da tenere in conto?
BH: Bisogna tenere in conto fattori diversi, non scontati, come ad esempio il caching. Bisogna avere uno sguardo di insieme sull’architettura, per gestirla in modo efficiente. Il programmatore medio spesso non ha bisogno di comprendere queste problematiche fino in fondo, e con gli strumenti che ha difficilmente può riuscirci: in questo senso c’è un punto di rottura oltre il quale gli strumenti standard non bastano per produrre un’applicazione realmente scalabile. Noi però lavoriamo anche per creare gli strumenti che siano in grado di renderlo possibile, anche se per arrivarci occorre un impegno ulteriore da parte dello sviluppatore.

PI: Tra le novità di Visual Studio 2010 ci sono degli strumenti di testing automatici: possono essere un aiuto per ottimizzare ad alto livello?
BH: In quel caso non è questione di ottimizzazione, sono strumenti pensati per garantire la correttezza sintattica del codice. Abbiamo comunque anche dei test di carico che accoppiati a questi nuovi strumenti possono aiutare a simulare il traffico di migliaia di utenti e individuare rapidamente eventuali problemi. Mettendoli assieme si riesce a comprendere facilmente quale sia il comportamento del sistema “sotto sforzo” e come reagisca l’applicazione. PI: L’IDE si evolve a ogni aggiornamento, si arricchisce di nuove funzioni: c’è un limite alla complessità che possono raggiungere questo tipo di strumenti?
BH: No, direi di no. L’unico punto di rottura si verificherebbe se la tecnologia smettesse di evolversi, se non sorgessero nuovi tipi di paradigmi di programmazione, nuove tipologie di servizi, nuove categorie di utenti. Semmai il problema è che ci sono moltissimi strumenti diversi all’interno di Visual Studio, con finalità diverse: occorre trovare il modo di renderle disponibili coerentemente all’utente, e ci sono delle soluzioni specifiche come i Web Express Tools o quella per C++. Abbiamo cercato di ricreare quel tipo di esperienza mirata anche nella versione completa di Visual Studio, per consentire di sfruttare ambienti più “targettizzati” per un singolo tipo di applicazione in via di sviluppo.

PI: In effetti capita spesso, però, di lavorare con una versione dell’IDE e del runtime che non sia l’ultima disponibile. Magari non è necessario. Oppure si lavora con un sottoinsieme delle possibilità del runtime utilizzato. Verrebbe da citare di nuovo il caso di Visual Basic: la sua sparizione in qualche modo rappresenta una certa evoluzione delle esigenze degli sviluppatori e degli utenti?
BH: Interessante l’esempio di Visual Basic. Non abbiamo abbandonato Visual Basic perché pensavamo di averlo portato al suo sviluppo massimo, abbiamo pensato piuttosto che il percorso tecnologico di Visual Basic non era la visione giusta da portare avanti, che cioè fosse in grado di resistere altri 20 anni sulla piazza. Quindi è venuto dotNET, il runtime: un cambio notevole nel modo di intendere e costruire le applicazioni, ma un cambio necessario.

PI: Un cambio necessario?
BH: C’erano tante applicazioni lato client in Visual Basic, ma abbiamo percepito un graduale spostamento verso il concetto di web application. Abbiamo scelto una piattaforma che giudicavamo giusta per quel cambiamento. C’è un altro cambiamento interessante in atto, quello della cloud, che sarà affascinante capire come influenzerà i nostri strumenti: quello che facciamo oggi è costruire applicazioni tradizionali in grado di sfruttare la cloud, ma cosa succederà quando saranno gli strumenti stessi per creare le applicazioni a risiedere nella nuvola? Come si fa un debug nella cloud? Non so dire cosa succederà esattamente, ma credo che quello sarà il nuovo mondo da esplorare per lo sviluppo a lungo termine nei prossimi anni.

PI: Si parla molto di cloud computing, ci sono molte iniziative anche commerciali al riguardo, ma pare che nell’attuale comunicazione su Visual Studio ci si concentri maggiormente su Silverlight che su Azure.
BH: Molti annunci per Azure sono stati fatti al PDC ( da Ray Ozzie , ndr), ed è passato solo un anno da quando è stato annunciato. Prima di passare alle applicazioni stiamo lavorando sulla piattaforma, e gli strumenti per Azure saranno comunque rilasciati al di fuori del normale ciclo di sviluppo proprio per accelerarne l’uscita. PI: A proposito di cicli di vita delle applicazioni, si stanno facendo davvero brevi: in alcuni casi sono addirittura di sei mesi. Come ci si confronta con queste novità, anche Visual Studio andrà incontro a questo tipo di accelerazione?
BH: Lo faremo dove e quando avrà senso: in generale agli addetti ai lavori non fa piacere dover procedere agli upgrade, e in certi ambiti – come la cloud – occorre garantire almeno un paio d’anni di stabilità per riuscire a “stare sui server”. In altri casi, come Silverlight, il ciclo di vita è sceso ormai sotto l’anno: per i device tool, che prima erano inglobati nel ciclo di sviluppo di Visual Studio, abbiamo deciso di adottare un approccio differente e abbinarli all’uscita di nuovi prodotti. Dove ha senso, aggiusteremo il life cycle per adattarlo al tipo di ambiente in cui ci si muove.

PI: Qual è il ciclo di vita ideale, se ne esiste uno?
BH: Il life cycle ideale è probabilmente attorno ai due anni. Abbiamo pensato anche a fare release più piccole molto frequenti, come nel caso dei power tool che vengono pubblicati ogni tre o quattro mesi e che praticamente implementano feature in tempo reale. Pensiamo spesso a queste problematiche, e la risposta vera è che probabilmente dipende dalle esigenze specifiche.

PI: È uno scenario accattivante per uno sviluppatore?
BH: Se mi piace? Sì, mi piace, ma è complicato: ci sono cose che non si possono fare in temi ristretti. La mia idea è che ci sia bisogno di un modello con life cycle concorrenti, dove ci siano progetti che vanno avanti per qualche anno, anche quattro o cinque, così da avere il tempo di incubare e sviluppare novità importanti. Nel frattempo ci saranno altri progetti sviluppati con passo più rapido: ad ogni rilascio ci sarà l’occasione per confrontarsi con il proprio pubblico, anche per raccogliere un feedback utile a capire se ci si sta muovendo nella direzione giusta.

PI: Non è la prima volta che ci si misura con queste problematiche.
BH: Bisogna andarci coi piedi di piombo. A metà degli anni ’90 abbiamo fatto delle sperimentazioni con il C++ e con release ogni tre mesi, ma poi ad ogni trimestre non c’era molto da rilasciare visto che la maggior parte del tempo veniva speso nel rifinire il codice in vista della release imminente invece di implementare nuove feature.

PI: Ci sono scenari recenti che possano cambiare la prospettiva?
BH: Facciamo un esempio: se mi chiama un cliente per chiedermi qualcosa, e io gli rispondo che per implementare quelle funzioni nel mio ciclo di sviluppo mi servono due anni e mezzo, probabilmente quel cliente me lo perderò. Due anni e mezzo sono un’eternità. C’è una soluzione possibile, ovvero l’hosting di servizi: anche noi ne gestiamo uno interno. Consente di patchare un servizio in un giorno invece che in settimane, come accade quando si deve affrontare uno sviluppo per una applicazione esterna, e diventa possibile combinare programmi a breve termine e in piccolo con altri a lungo termine e di grande respiro. PI: Parliamo di device, un settore dove altri concorrenti come la piattaforma Java hanno un ruolo diverso da dotNET. Ci sono strade diverse che potrebbero essere imboccate?
BH: Fino a oggi c’è stata una stretta correlazione tra la versione di Visual Studio e la versione di runtime utilizzata: con il 2010 stiamo cambiando alcune cose, e con lo stesso codice sarà possibile compilare per diverse versioni di runtime.

PI: In ogni caso dotNET resta un ambiente pensato quasi esclusivamente per il mondo dei PC, se così si può dire.
BH: Ci abbiamo pensato, ma prendiamo il caso dei cellulari: dotNET già funziona su quelle piattaforme. Silverlight è un pezzo di dotNET che funziona in molti ambienti diversi: certo, non siamo ancora in grado di far funzionare un aspirapolvere e una lavatrice, ma potenzialmente siamo in grado di arrivare su parecchi dispositivi. Non abbiamo mai raggiunto un livello di ricchezza di device di Java, ma è anche una questione di livello di costo: Linux, Java sono praticamente gratuiti e hanno un’incidenza diversa su piattaforme più economiche.

PI: È possibile quindi che, nonostante il discorso sulla complessità degli strumenti che facevamo prima, dentro Visual Studio prima o poi si facciano strada strumenti per altre piattaforme? Magari iPhone, o Android.
BH: Visual Studio è una piattaforma: non tutto quello che c’è dentro Visual Studio, come ad esempio gli strumenti per la gestione di SQL, è realizzato dal team di Visual Studio. In effetti, la lista di parti che si integrano dentro l’IDE è molto lunga. iPhone in Visual Studio? Non saprei, non ho idea di quel potrebbe voler fare Microsoft. Se qualcuno lo facesse, però, ci sarebbero molti vantaggi per tutti: sarebbe uno strumento utile alla portata di molti, sarebbe senz’altro interessante.

Un’altra questione riguarda il numero di linguaggi gestiti da Visual Studio: sono molti, in qualche modo forse anche troppi. Microsoft non potrebbe concentrare gli sforzi nel creare una piattaforma trasversale per tutti gli ambienti nei quali opera, dalla robotica ai personal computer?
BH: dotNET è la nostra piattaforma di programmazione e lo resterà ancora per un bel pezzo. È in grado di funzionare in tutti gli ambienti nei quali Microsoft opera, ed è ovviamente il risultato di un compromesso tra diverse esigenze. In generale, non parlo di Visual Studio, negli ultimi anni c’è stata una proliferazione di linguaggi di ogni tipo, linguaggi per domini specifici, con librerie diverse ed espressività differenti, creati magari per risolvere problemi particolari o soddisfare particolari esigenze: è una cosa ottima, significa che c’è movimento nel settore, ma pone anche alcuni interrogativi. dotNET per il momento resta il nostro ambiente multilinguaggio: ma non è escluso che in futuro in questo senso cambi qualcosa.

PI: Questo conduce a un’altra domanda: come si fa a decidere quali cose devono cambiare in questo tipo di strumenti? Ad esempio: qual è e come si determina il corretto compromesso tra sviluppo visuale e del codice?
BH: È una parte molto complessa del nostro lavoro. Parliamo moltissimo coi clienti, cercando di capire cosa vogliono davvero: alla fine cerchiamo di intuire quale sia il desiderio della “maggioranza”, perché includere tutto non sarebbe pensabile. Cerchiamo anche di tener conto degli investimenti, nostri e altrui, per garantire che le risorse impiegate in una direzione non vadano perdute.

PI: Esiste un metodo per fare tutto questo?
BH: Mettiamola così: per la prossima versione di Visual Studio passeremo almeno quattro mesi a fare “data gathering”, parlando con clienti e partner, osservando i trend di ambienti come la cloud e i device. Non faremo altro che “imparare”, capire cosa stanno facendo gli sviluppatori in questo momento. Poi ci saranno altri due mesi di brainstorming: tireremo fuori idee che potranno concretizzare le tendenze che abbiamo visto all’opera. E poi, per un altro mese affineremo i concetti, chiarendo quello che sarà o non sarà possibile realizzare nell’arco di tempo prestabilito dal progetto. Direi che questa fase terminerà nella prima metà del 2010. PI: Com’è lavorare sugli strumenti che altri useranno per lavorare? Sviluppare un IDE è un po’ come realizzare dei mattoni che verranno costruiti per costruire una casa: occorre tentare di prevedere tutte le esigenze che gli sviluppatori avranno nel loro lavoro?
BH: Credo che il mio sia il lavoro più facile che uno sviluppatore possa affrontare: costruisco gli strumenti che a mia volta utilizzerò per lavorare. Il mio primo lavoro è stato per un’azienda che sviluppava applicazioni per l’email, molto tempo prima che Internet diventasse di uso comune: la posta elettronica era uno strumento ad uso interno per contabili e avvocati, ma non essendo mai stato io un contabile o un avvocato non avevo idea di quali fossero le loro esigenze. Il bello di sviluppare strumenti per sviluppatori è proprio questo: sono uno sviluppatore anch’io! So di cosa ho bisogno, so se qualcosa è fatto bene o è fatto male: mi piace molto fare questo lavoro.

PI: È mai capitato di rilasciare qualcosa che fosse “fatto male”?
BH: Certo, capita a tutti.

PI: E cosa è successo?
BH: Ho cercato di sistemarla prima che ho potuto. (sorride)

PI: Prendiamo il caso di un’interfaccia: come si fa a decidere quale sia quella giusta per un IDE? Nel corso degli anni stanno anche cambiando le dimensioni dei monitor in uso negli uffici.
BH: Può sembrare banale, ma non c’è niente di più importante che ascoltare i propri utenti. In particolare bisogna ascoltare due cose: quali siano i loro problemi, e quali siano i loro suggerimenti per superarli.

PI: E cos’è più importante tra le due?
BH: Bisogna porre molta attenzione: ascoltare i suggerimenti non aiuta a trovare nuove strade per risolvere i problemi. Il nostro compito, invece, è ascoltare i problemi e fare un passo indietro: cercare di rivedere l’intero processo che ha condotto a quell’impasse per tentare di risolvere il problema alla radice.

PI: È un processo simile a quello di un prodotto come Office?
BH: Nel caso di Office, il problema era che c’erano molte feature e le persone ne utilizzavano un piccolo sottoinsieme: l’interfaccia Ribbon (quella di Office 2007, ndr) aiuta a semplificare il meccanismo di selezione. Visual Studio ha un problema simile, ma anche differente: offre un range di funzionalità anche superiore a Office, ma nel nostro caso gli utenti usano una grossa fetta degli strumenti a loro disposizione. Per questo abbiamo un team che si occupa specificamente del problema: prendono in esame ogni tipo di soluzione, dal 3D a rappresentazioni grafiche del progetto in via di sviluppo.

PI: Scoperto qualcosa di utile?
BH: In effetti è interessante, ci hanno spiegato che la maggior parte delle persone ha una memoria che funziona in modo particolare: se gli mostri una foto, dopo qualche minuto non sono in grado di ricordare in tutto e per tutto cosa vi fosse mostrato. Ma se gli chiedi di alcuni dettagli, magari dov’era un particolare oggetto, allora sono in grado di recuperare quella informazione in un batter d’occhio. È partendo da questo tipo di riflessione che ci muoviamo: adottiamo una strategia fatta di tanti piccoli ma significativi “passetti”, che ci permettono di gestire e superare questo tipo di problemi complessi.

PI: Un commento di Brian Harry su Visual Studio 2010. A proposito, quando esce?
BH: La data ufficiale di rilascio è il 22 di marzo. Ci sono molte novità in questa release, alcune come IntelliTrace (un nuovo meccanismo per il debugging, ndr) stanno ricevendo commenti entusiasti: ma ci sono altre feature interessanti, per esempio è la prima versione di Visual Studio a includere strumenti specifici per SharePoint. Chiaramente ciascun sviluppatore avrà motivazioni diverse che lo spingeranno ad upgradare: la cloud potrebbe essere una di queste. Sarà una bella sfida convincerli, speriamo bene.

a cura di Luca Annunziata