Crisis

Secondo questo interessante articolo di SmartOffice News, il codice di Longhorn è stato buttato alle ortiche da Allchin, co-direttore della divisione Prodotti Platform e servizi, per ripartire da uno stile di programmazione davvero nuovo per Microsoft: invece di sviluppare parti di codice separate, create da programmatori diversi e poi assemblate in un nuovo programma, si è deciso di partire alla “Linux way”. Come? Iniziando da un kernel minimale e aggiungendo di volta in volta le funzioni necessarie.

Riporto solo alcuni estratti dall’articolo:

Gli ingegneri di microsoft lo stavano costruendo (Longhorn, ndr.) proprio nel modo in cui avevano sempre creato programmi. Ogni singolo programmatore fra le migliaia (impiegate da Microsoft, ndr.), creava il proprio pezzo di codice, che veniva assemblato (insieme agli altri, ndr.), in un programma raffazzonato. Ma Longhorn/vista era troppo complesso: Microsoft doveva iniziare da capo, disse Allchin a Gates.

E quale è stato questo “nuovo inizio”?

Quindi, secondo (quanto riportato da, ndr.) il Wall Stret Journal, Microsoft percorse la strada di Linux, sviluppando prima un kernel solido per ciò che ora viene chiamato Vista. Ora, sta aggiungendo le funzionalità che desidera, una per una

E che dire di WinFS, il rivoluzionario filesystem di Windows prossimo venturo, che aiuterà a organizzare e recuperare le informazioni salvate nei supporti?

WinFS era così problematico che gli ingegneri iniziarono a discutere se fossero in grado di fa “volare il maiale”. Immagini di maiali con le ali iniziarono ad apparire nelle presentazioni e negli uffici.

Questo nuovo inizio potrebbe spiegare anche la riorganizzazione in seno a Microsoft…

La crisi di Longhorn aiuta a spiegare la radicale ristrutturazione che il CEO di Microsoft Steve Ballmer ha annunciato recentemente per riorganizzare la società in tre grandi unità aziendali. Un obbiettivo fondamentale è di forzare Microsoft a essere più agile nel produrre e distribuire il software.

Ma perché Microsoft incorre in questo genere di problemi? Possibile che si renda conto solo dopo averci messo mano che un programma è diventato ingestibile?

Le riforme di Allchin si rivolgono a un problema che Microsoft si porta dietro dagli inizi. La vecchia scuola di computer science poneva richiedeva pratiche di scrittura di codice metodiche per assicurarsi che i grandi computer usati dalle banche, dai governi e dagli scienziati non si bloccassero. Ma quando i personal computer spiccarono il volo negli anni ’80, le aziende come Microsoft non avevano tempo per tutto questo (per le pratiche di scrittura metodiche, ndr.). Gl utenti PC volevano delle funzionalità belle e utili in fretta. Tolleravano — o non notavano — i bachi che affliggevano il codice. I problemi potevano sempre essere corretti con una patch. Con ogni patch e ogni miglioramente, divenne più difficile allegare nuove funzionalità al software dato che il nuovo codice aveva effetti imprevedibili su tutto il resto.

Non male vero? Pigia e ripigia, il codice esplode…