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.