Architects: Paul Allen – Software Architect, Microsoft (1971-1983)

Questa è una storia che se non fosse realmente accaduta nessuno ci crederebbe.
Sembrerebbe una leggenda …ed in effetti è assolutamente indubitabile che molto di quello che racconteremo a breve ha i toni del leggendario… e ciò malgrado il fatto che il personaggio, Paul Allen, essendo uno dei 10 uomini più ricchi del mondo, è ovviamente, e rappresenta, di certo, qualcosa di molto concreto …
…e nel caso in cui ce lo dimenticassimo ci sono i suoi 30 miliardi di dollari di patrimonio stimato a tutt’oggi a ricordarcelo.
Altra cosa che dovremo avere sempre presente, nel raccontare la storia di Paul Allen, il vero ed unico numero due della Microsoft di tutti i tempi, ed il suo primo Software Architect, è il fatto che lui e Bill Gates sono amici da sempre, ed hanno condiviso la loro passione per l’informatica da quando erano due giovanissimi teen agers.
L’informatica è la loro passione comune …ed è una passione che traspare tutta anche dalla foto seguente... una rarissima foto del 1968 in cui Bill ha 13 anni (Gates è nato nel 1955) e Paul ne ha 15 (Allen è del 1953)…

Aspetto da sottolineare e che traspare tutto … ed è cosa ed atteggiamento ben noto a chi lavora nel settore del software developing … (pair programming, programmazione in coppia, eccoli lì… anche Bill&Paul lavoravano con questa metodologia!!!), c’è Paul alla tastiera che scrive il codice…
Ed in effetti il primo vero Software Architect, di quella che, al momento della fondazione, si chiamava Micro-Soft, è stato Paul Allen…
L’unica persona, oltre alla madre, che ha avuto anche lei un ruolo fondamentale nella creazione di quel colosso che è oggi la Microsoft, di cui si dice che Gates si sia mai fidato in vita sua…
Paul Allen … forse l’unico vero e solo amico di Bill Gates… ed il suo primo Architect …
Allen ha avuto un ruolo chiave nella scalata di Microsoft al successo… e non ha mai creato problemi di leadership a Gates.
Problemi di leadership, per inciso, che sono molto sentiti nel mondo dell’informatica, per il particolare tipo di personalità che hanno e devono avere sempre e necessariamente i buoni programmers…
Allen ha sempre accettato la leadership di Gates… ciò malgrado sia più grande di età di due anni rispetto a Bill…ad Allen, in fondo, forse interessava solo l’aspetto tecnico-creativo ed in effetti tra Allen e Gates c’è stato, probabilmente, lo stesso tipo di simbiosi tecnica e capacità commerciali e di raiders delle trattative che vi è stato per un'altra coppia storica dell’informatica, Steve Jobs e Paul Wozniak (Apple).
Allen è colui che quando fondò, insieme a Gates, la Micro-Soft, ed erano poco più che ventenni entrambi, accettò senza fiatare il diktat di Gates che, su consiglio della madre modificò, prima di trascrivere gli atti formali dinanzi ai notai, la ripartizione percentuale delle quote della società.
Le quote iniziali della Micro-Soft erano 50% Gates e 50% Allen.
Quando la madre di Gates (che si intendeva di affari ed era membro influente di molte potenti associazioni in ambito cittadino a Seattle, la loro residenza) vide la ripartizione fatta dal figlio gli impose di cambiarla…
Disse a Bill che non esistono società al 50% …disse, sempre al figlio, rimproverandolo duramente di non capire nulla, che sarebbe prima o poi arrivato un momento, nell’ambito della vita societaria, di decidere qualcosa di estremamente importante … ed in quel caso doveva essere chiaro chi aveva l’ultima parola e chi no…
Bill capì e torno da Paul dicendogli che lui, Bill Gates, aveva deciso che le quote dovevano essere cambiate…51% riservate a lui stesso, Gates, e 49% per Paul…
Prendere o lasciare… si guardarono negli occhi mentre Paul prendeva la sua decisione… poche persone al mondo possono reggere lo sguardo di Bil Gates … e Paul accettò…
E fu l’inizio di qualcosa che adesso è, di fatto, leggenda…
Non la ripercorreremo tutta… solo alcuni aspetti cruciali, anche per capire meglio il ruolo di un Architect, quale era ed è Allen, e di quanto tale ruolo sia spesso decisivo…
Una buona scelta tecnica di un buon Architect può salvare una situazione grave ed apparentemente irrecuperabile…
Una cattiva scelta, oppure peggio ancora, l’assenza di un Architect e la situazione da critical diviene vero e proprio collasso tecnico …
Allen è la persona che indirizzò Gates, dopo che lo stesso aveva concluso l’affare con IBM, alla scelta di acquistare la code – base di ciò che poi diverrà il DOS http://it.wikipedia.org/wiki/MS-DOS, da un programmatore che aveva strutturato, senza alcun successo commerciale, qualcosa di simile a ciò che occorreva loro, un clone del C/PM di Gary Kildall (Digital Research)
Lo comprarono per 40.000 dollari!!!
Fu Allen ad estenderlo, lavorando come un matto sui terminali dell’università, e fu lui soprattutto che compì un vero e proprio miracolo tecnico quando, la mattina in cui stava partendo per la sede IBM per consegnare il prodotto (e ci andò solo Allen perché stavano risparmiando anche sui soldi dei biglietti aerei) si accorsero, troppo tardi, Gates ed Allen, che si erano dimenticati di scrivere la sequenza di bootstrap.
Lavorando sui terminali universitari (avevano scroccato anche questo!) il bootstrap lo realizzava il mainframe centrale…Ma il DOS doveva essere auto partente!!!
Se lo erano semplicemente … dimenticato !!!
Allen allora realizzò un vero e proprio capolavoro tecnico… Gates stava già pensando a manovre e telefonate dilatorie ad IBM… ma erano già al terzo rinvio…avrebbero quasi certamente perso la commessa più importante della loro vita…
Allen prese allora la decisione… disse a Gates di non preoccuparsi… avrebbe scritto lui, la sequenza di bootstrap… e lo doveva fare… accidenti… da solo in aereo con carta e matita ed in 3 ore circa!!!
Gates lo guardò partire incredulo ma Allen era convinto di potercela fare … e Paul scrisse in aereo, su fogli rimediati all’ultimo momento, incredibilmente a memoria, il codice della sequenza di bootstrap…
Arrivato per il test nella sede IBM trascrisse con calma, mentre i tecnici presenti lo scrutavano scettici, il codice nel PC prototipo che IBM gli mise a disposizione e … tutto funzionò … assurdamente senza errori!!!
Non si diventa a caso uno dei dieci uomini più ricchi del mondo!!!
E la storia andò avanti sino al 1983 …la Microsoft è già una potenza del settore ICT negli Stati Uniti e nel mondo e sotto la guida di Gates si muove con una spregiudicatezza che è indicativa delle modalità aggressive con cui intendono sopraffare il mercato
Sono, infatti, già di quel periodo le denunce per approcci di marketing assai discutibili, utilizzati da Microsoft, (ma tipici ancor oggi di molti ambienti ICT!!!) secondo il metodo F.U.D. Fear - Uncertainy - Doubt, - e cioè sostanzialmente diffondere notizie, prevalentemente false, sull’incapacità tecnica o su gravi problemi tecnici dei software dei concorrenti per impedirgli di conquistare mercato…
Nel 1983 accade qualcosa di imprevisto, qualcosa che non ti aspetti…qualcosa che però ci ricorda che siamo uomini… tutti uomini…
Paul Allen si ammala… e gravemente…un cancro, il morbo di Hodgkin…
Dura due anni la lotta di Allen contro la malattia… intanto Gates è vicino all’amico e gli dice di non preoccuparsi… che ci penserà lui alla società…sono i due anni più duri per Gates e per Allen…anni in cui Allen la sfanga nella sua lotta per la vita …e Gates stravince contro tutti gli avversari…
Dopo due anni così Gates è ben felice di riaccogliere il suo Architect, che torna dopo aver vinto la sua lotta contro la malattia…
Ma Allen, che possedendo il 49% è già ricchissimo oltre l’immaginabile, da al suo amico una risposta inaspettata… gli dice che non ha più voglia di lavorare!!!
Che, avendo affrontato la morte, ha imparato il valore della vita ed adesso vuole godersela…vuole spendere tutti soldi guadagnati, ha le sue passioni (basket, football, donne, viaggi…) e non gli frega più nulla del lavoro!!!
…e quindi prega Bill di liquidarlo e di lasciarlo andare!!!
Per Gates è un brutto colpo… pensa inizialmente che il suo vecchio amico sia impazzito e prende tempo… anche perché liquidare il 49% di Microsoft non è una operazione economicamente tanto fattibile nel breve…
Ma poi passa il tempo e Gates capisce che il suo amico fa sul serio, che davvero ha staccato la spina… quindi si passa al piano B orchestrato da Gates… che è la parte finale della nostra storia come vedremo…
Nel frattempo, negli ultimi 20 anni, Allen ha realizzato e sta realizzando tutti i suoi capricci… compra squadre di basket (i Portland Trailblazers) ed una di football, i Seattle Seahawks.
Edifica e fonda un museo dal costo complessivo di 500 mil. di dollari dedicato ad uno dei suoi idoli Jimi Hendrix, finanzia cospicuamente, tra l’altro, la ricerca di forme di vita extraterrestri (23 mil di lire al Seti Institute di Carl Sagan) ed una misteriosa società ICT, Transmeta, che è anch’essa una leggenda come il suo fondatore e vedremo poi perché…
Peraltro Allen è personaggio molto discreto che non ama far parlare di sé e lo dimostra, circa 10 anni fa, quando suo malgrado incappa in un guaio giudiziario… una sua segretaria lo denuncia per violenza sessuale… è il periodo in cui negli States sembra facile ottenere (vedi caso Mike Tyson) cospicui risarcimenti con denunce del genere…
Ma Allen è uomo pubblico e si ritiene che andrà, con il suo stuolo dei migliori avvocati, sino in fondo… senza patteggiare come è sempre possibile nel sistema americano di Common Law…
Ne sono convinti tutti i media americani e mondiali che cominciano a seguire morbosamente la vicenda…
Si arriva alla data dell’udienza preliminare dove, secondo la prassi americana, il magistrato chiede alle parti di, eventualmente, chiudere la partita con una cifra a risarcimento di tutto… è la prassi… ma Paul Allen è uomo pubblico… rifiuterà senz’altro per proteggere il suo buon nome.
I difensori della segretaria sparano, senza convinzione, una cifra pro-forma….5 milioni di dollari … è appunto un pro forma…
Si attende l’ovvio NO dei difensori di Paul Allen, i migliori d’America…
Ed a questo punto accade qualcosa che si è visto e si vedrà raramente nelle sedi giudiziarie… gli avvocati di Paul Allen aprono una valigetta, tirano fuori un assegno, compilano la cifra e lo consegnano al magistrato che, incredulo, legge l’importo!!!
Quindici milioni di dollari!!!
Si pensa ad un errore ma gli avvocati di Allen chiariscono…
Essi hanno avuto esplicito mandato, da parte del loro cliente Paul Allen, di pagare 3 volte qualsiasi fosse la somma richiesta dalla controparte per chiudere, definitivamente, la questione lì.
Perché il loro cliente non avrebbe avuto il tempo di dedicarsi alla vicenda!!! Aveva ed ha di meglio da fare…
Il sottoscritto estensore di questo post seguì la vicenda, all’epoca 10 anni fa, sui notiziari web e sui giornali come Corriere e Repubblica che dedicarono… e lo ricordo bene davvero… più di un reportage dall’udienza in cui accade quanto descritto
Uno, molto bello, da parte anche di uno dei loro migliori giornalisti, Vittorio Zucconi, scritto davvero bene…
Di quella notizia oggi, e la cosa è abbastanza inquietante, non vi è più alcuna traccia sul web…
Provate a cercare…
Allen è un personaggio molto discreto ed anche i motori di ricerca lo sono…
E veniamo a Transmeta http://www.transmeta.com/ …la società più importante di Paul Allen che continua pur avendo ufficialmente lasciato Microsoft, a tenere un piede nel mondo ICT…
Per anni, prima di annunciare al pubblico di produrre microprocessori a basso consumo e quotarsi al NASDAQ, Transmeta rimane un segreto impenetrabile intorno al quale si accumulano rumours e misteri.
E' la società dove lavora, ma guarda un po’ i casi della vita, e sin dal 1997, Linus Torvalds, si proprio quel Linus Torvalds, l’Architect (un altro ancora!!!) di Linux per intenderci, assunto dall’Architect Paul Allen con un contratto di milioni di dollari.
Transmeta si dice sia la società che assume programmatori e tecnici di altissimo livello togliendoli prevalentemente ai concorrenti di Microsoft.
E’ la società che sfoggia per anni una home page che è un capolavoro di anti-marketing.
E’ la società che, come il suo principale finanziatore Allen, non ama far parlare di sé sul web…
Tra le leggende che girano nei meandri della rete ve n’è una veramente incredibile… forse la più incredibile di tutte… e ciò la dice lunga sul fatto che le informazioni contenute sul web e nel web chissà cosa siano in realtà…
…comunque, si diceva, la leggenda più paradossale che circola sulla rete è che chiunque scriva di Paul Allen, del suo incidente giudiziario, di Transmeta, di Linus Torvalds che lavora per Transmeta … riceverà una telefonata da un qualche emissario misterioso… che pagherà 3 volte qualsiasi cifra per far sparire la notizia, oppure lo assumerà in Transmeta a peso d’oro!!!
E questo è veramente davvero incredibile…
Oops… scusate se interrompo adesso questo post …ma mi squilla il cellulare…

Do you wanna be an Architect when you grow up?

From - Is Design Dead?
Martin Fowler Chief Scientist, ThoughtWorks

Do you wanna be an Architect when you grow up?
For much of the last decade, the term "software architect" has become popular. It's a term that is difficult personally for me to use. My wife is a structural engineer. The relationship between engineers and architects is ... interesting. My favorite was "architects are good for the three B's: bulbs, bushes, birds". The notion is that architects come up with all these pretty drawings, but it's the engineers who have to ensure that they actually can stand up. As a result I've avoided the term software architect, after all if my own wife can't treat me with professional respect what chance do I stand with anyone else?
In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in "I'm not just a mere programmer - I'm an architect". This may translate into "I'm an architect now - I'm too important to do any programming". The question then becomes one of whether separating yourself from the mundane programming effort is something you should do when you want to exercise technical leadership.
This question generates an enormous amount of emotion. I've seen people get very angry at the thought that they don't have a role any more as architects. "There is no place in XP for experienced architects" is often the cry I hear.
Much as in the role of design itself, I don't think it's the case that XP does not value experience or good design skills. Indeed many of the proponents of XP - Kent Beck, Bob Martin, and of course Ward Cunningham - are those from whom I have learned much about what design is about. However it does mean that their role changes from what a lot of people see as a role of technical leadership.
As an example, I'll cite one of our technical leaders at ThoughtWorks: Dave Rice. Dave has been through a few life-cycles and has assumed the unofficial mantle of technical lead on a fifty person project. His role as leader means spending a lot of time with all the programmers. He'll work with a programmer when they need help, he looks around to see who needs help. A significant sign is where he sits. As a long term ThoughtWorker, he could pretty well have any office he liked. He shared one for a while with Cara, the release manager. However in the last few months he moved out into the open bays where the programmers work (using the open "war room" style that XP favors.) This is important to him because this way he sees what's going on, and is available to lend a hand wherever it's needed.
Those who know XP will realize that I'm describing the explicit XP role of Coach. Indeed one of the several games with words that XP makes is that it calls the leading technical figure the "Coach". The meaning is clear: in XP technical leadership is shown by teaching the programmers and helping them make decisions. It's one that requires good people skills as well as good technical skills. Jack Bolles at XP 2000 commented that there is little room now for the lone master.
Collaboration and teaching are keys to success.

Chris Peters: Microsoft Office Architect, Synchronize and Stabilize!

Vi è da anni nel settore delle metodologie relative allo sviluppo software un gran parlare e discutere su quale sia il processo più efficace o più adatto …
Nell’ambito delle tecnologie web (che sono oramai le tecnologie di punta per tutte le software farm, o quanto meno quelle su cui vi è maggior aspettativa) ormai si è di fatto affermato il concetto di perpetual beta (beta perenne)… il software cioè si evolve così velocemente e così agganciato al business da non consentire di arrivare ad una versione stabile del prodotto. Il paradosso è che la versione Online del software web, pur essendo sempre in versione beta, ha un suo livello di stabilità intrinseca dato anche dalla capacità e dall’abitudine mentale dei developer che lo evolvono e lo mantengono in esercizio di aggiornare progressivamente e fixare i bug e le nuove funzionalità con continuità… Essi sincronizzano e stabilizzano il software praticamente ogni giorno…
In effetti, e pochi lo sottolineano, tale metodologia di prassi oramai nell’ambito web (vedi Google e la sua consolidata filosofia di always in beta version) ha un suo precursore nel lavoro e nella teorizzazione realizzata in Microsoft a partire dalle prime versioni di Windows (anni '80) mediante un processo definito come Synchronize-and-Stabilize.

Synchronize-and-Stabilize è un processo di sviluppo software assai efficace ed orientato principalmente alla realizzazione del prodotto… come dicono gli americani focalizzato fortemente quindi unicamente to ship products.
Ecco di seguito le parole, che descrivono con efficacia tale filosofia di sviluppo software, di Chris Peters, l’Architetto Microsoft che guidò il team che integrò, in modalità Synchronize-and-Stabilize, le prime versioni di Microsoft Office :

“Everybody in a business unit has exactly the same job description and that is to ship products. Your job is not to write code. Your job is not to test. Your job is not to write specs.

Your job is only to ship products....

When you wake up in the morning and you come to work, you say what is the focus? Are we trying to ship? Are we trying to write code? The answer is we are trying to ship.... You're trying not to write code.

If we could make all this money by not writing code, we'd do it.”

Best Practices: Thinking in C++ di Bruce Eckel

Tra le letture che consigliamo vi è Thinking in C++ di Bruce Eckel. La prima edizione è del 2000 ma i concetti espressi sono ancor oggi molto moderni. Vi sono elencate una serie di best practices fondamentali per chi scrive codice e ciò indipendentemente dalla piattaforma tecnologica utilizzata.
Di seguito una serie di spunti di riflessione tratti e tradotti (molto!) liberamente dal testo originale... e per non prenderci troppo sul serio lasceremo la parola a Dilbert, mitico personaggio di Scott Adams che tutti i developer per la loro sopravvivenza tecnica e non solo (altra lettura consigliata è The Career Programmer: Guerilla Tactics for an Imperfect World) dovrebbero tener in gran conto... forse ancor più di Bruce Eckel!!!

1. Prima fatelo funzionare, poi rendetelo veloce! Questo è vero anche se siete certi che un qualsiasi frammento di codice sia realmente importante e che diverrà esso il collo di bottiglia principale del vostro sistema. Non toccate quel frammento per ottimizzarlo. Prima di tutto cercate di ottenere un sistema funzionante con un progetto il più semplice possibile. Soltanto dopo, se non è abbastanza veloce, lo analizzerete. Quasi sempre scoprirete che il vero problema non è il "vostro" collo di bottiglia. Risparmiate tempo per le cose veramente utili.

2. L'eleganza nella scrittura del codice paga sempre. Non è un'attività frivola. Avrete in mano un programma non solo più facile da compilare e testare, ma anche più semplice da comprendere e da manutenere: ed è qui che si ritrova il valore economico del vostro lavoro. Potrebbe servire un po' di esperienza prima di comprendere questo dato, in quanto potrebbe apparire che, mentre cercate di rendere elegante un frammento di codice, non siete in realtà produttivi. La produttività emergerà poi quando il codice si integrerà perfettamente nel vostro sistema, ed ancor più quando il codice o il sistema verrà modificato.

3. Ricordatevi del principio "divide et impera". Se il problema che state affrontando è troppo complesso, cercate di immaginare quali potrebbero essere le operazioni basilari del programma. Magari immaginando un "qualcosa" che si occupi delle parti più difficili!
Questo qualcosa è un oggetto e quindi scrivete il codice che utilizza quell'oggetto. Successivamente analizzate l'oggetto ed incapsulate le sue parti complicate all'interno di altri oggetti, e così via.

4. Se avete un grosso blocco di codice che ha bisogno di modifiche, cominciate ad isolarne le parti che non verranno modificate, eventualmente inglobandole in una"classe API" come metodi statici. Successivamente, focalizzate la vostra attenzione sul codice che verrà modificato, ristrutturandolo in classi. In tal modo renderete agevoli le modifiche man mano che la vostra attività di manutenzione procederà.

5. Tenete ben distinti il creatore della classe dal suo utilizzatore (il programmatore client). Chi utilizza la classe è il "cliente", e non ha bisogno né vuole sapere cosa accade dietro le quinte. Chi crea la classe dev'essere l'esperto di progettazione di classi e deve scriverla in modo che possa essere usata anche dal più principiante dei programmatori, continuando a comportarsi in maniera robusta nell'applicazione. L'utilizzo di una qualsiasi libreria è semplice soltanto se è trasparente.

6. Quando create una classe, usate una nomenclatura il più chiara possibile. Il vostro obiettivo è quello di rendere l'interfaccia di programmazione concettualmente semplice. Cercate di rendere i vostri nomi talmente chiari da rendere superflui i commenti. A tal fine, sfruttate l'overloading delle funzioni e gli argomenti di default per creare un'interfaccia intuitiva e facile da usare.

7. Il controllo dell'accesso consente a voi (creatori della classe) di fare in futuro estese modifiche che saranno quindi possibili senza danneggiare il codice client nel quale la classe è utilizzata. In questa prospettiva, mantenete tutto il più private possibile, e rendete public solo l'interfaccia della classe, utilizzando sempre le funzioni anziché i dati. Rendete i dati public solo quando siete costretti. Se gli utilizzatori di una classe non hanno bisogno di richiamare una funzione, dichiaratela private. Se una parte della vostra classe deve restare visibile alle classi eventualmente ereditate come protected, fornite un'interfaccia a funzioni piuttosto che esporre direttamente i dati. In questo modo, le modifiche di implementazione avranno un impatto minimo sulle classi derivate.

8. Prima di tutto e se possibile scrivete il codice di test. Ancor prima di scrivere la classe e poi tenetelo in evoluzione insieme alla classe. Rendete automatica l'esecuzione dei vostri test magari tramite un makefile oppure mediante uno strumento similare. In questo modo, qualunque modifica potrà essere controllata automaticamente lanciando il codice di test, e gli errori verranno immediatamente scoperti. Sapendo di avere la rete di sicurezza dell'ambiente di test, sarete più propensi ad effettuare modifiche consistenti quando ne sentirete il bisogno. Ricordate che i maggiori miglioramenti nei linguaggi di programmazione vengono dai controlli interni forniti da controllo del tipo, gestione delle eccezioni e così via, ma queste caratteristiche servono fino ad un certo punto. Dovete arrivare in fondo alla strada che porta alla creazione di sistemi robusti introducendo i test che verificano le caratteristiche specifiche della vostra classe o del vostro programma.

9. Ricordate una regola fondamentale dell'Ingegneria del Software: tutti i problemi di progetto del software possono essere semplificati introducendo un ulteriore livello di dereferenziamento concettuale. Quest'idea sta alla base dell'astrazione, la caratteristica primaria della programmazione orientata agli oggetti.

10. Rendete le classi le più atomiche possibile; in altri termini, date ad ogni classe un unico scopo chiaro. Se le vostre classi o il vostro progetto del sistema diventano troppo complicati, suddividete le classi complesse in classi più semplici. Il segnale più ovvio di questo fatto è proprio la stessa dimensione: se una classe è grande, c'è la possibilità che stia facendo troppo e che quindi è necessario scomporla.

11. Guardatevi dalle definizioni dei metodi lunghe. Una funzione lunga e complicata è difficile e costosa da mantenere, e probabilmente sta cercando di fare troppo da sola. Se vi trovate a maneggiare una funzione del genere, significa che, quanto meno, andrebbe suddivisa in alcune funzioni più piccole. Potrebbe anche suggerire la creazione di una nuova classe.

12. Guardatevi dalle liste di argomenti lunghe. Le chiamate di funzione diventano difficili da scrivere, leggere e manutenere. Piuttosto, cercate di spostare il metodo in una classe nella quale sia più adatto, e/o a passargli un oggetto come parametro.

13. Non ripetetevi. Se un pezzo di codice compare in molte funzioni nelle classi derivate, spostate quel codice in un'unica funzione nella classe base e chiamatelo dalle funzioni delle classi derivate. Non solo risparmierete spazio, ma consentirete un'agevole propagazione delle modifiche. Potete utilizzare una funzione inline perl'efficienza. Talvolta, la scoperta di questo codice comune porta considerevoli benefici alla funzionalità della vostra interfaccia.

14. Guardatevi dalle istruzioni switch o dagli if-else concatenati. Tipicamente, questo è un chiaro indicatore della programmazione di tipo type-check.
Programmazione type - check significa che state scegliendo quale codice eseguire in base ad un qualche genere di informazione sul tipo (il tipo esatto potrebbe non esservi immediatamente chiaro). Solitamente, potete rimpiazzare questo genere di codice sfruttando ereditarietà e polimorfismo; la chiamata ad una funzione polimorfica eseguirà il controllo di tipo per voi, e consentirà un estensibilità più affidabile e semplice. [N.d.T. - In realtà il controllo sui tipi è caratteristico del C++ che è un linguaggio fortemente tipizzato, ma il principio è comunque valido come punto di attenzione di ordine generale, nel senso che un eccesso di if-else nidificati è sicuramente indice di entropia elevata che state inserendo nel codice.]

15. Guardatevi dalle limitazioni nell'ereditarietà. I progetti più puliti aggiungono nuove funzionalità a quelle ereditate. Diffidate di un progetto che rimuove le vecchie funzionalità (mentre state ereditando) senza aggiungerne altre. Ma le regole sono fatte per essere infrante, e se state lavorando con una vecchia libreria di classi potrebbe essere più efficiente restringere una classe esistente nelle sue sottoclassi, piuttosto che ristrutturare la gerarchia in modo che la vostra nuova classe si vada ad inserire dove dovrebbe, al di sopra della vecchia classe.

16. Non estendete le funzionalità fondamentali nelle sottoclassi. Se un elemento dell'interfaccia è fondamentale per una classe si dovrebbe trovare nella classe base, e non essere aggiunto nel corso delle derivazioni. Se state aggiungendo dei metodi tramite l'ereditarietà, forse dovreste ripensare il progetto.

17. Meno è più. Iniziate da un'interfaccia minimale per la classe, semplice e piccola quanto basta per risolvere il vostro problema corrente, ma non cercate di anticipare tutti i modi nei quali la vostra classe potrebbe essere usata. Al momento del suo utilizzo, scoprirete il modo nel quale dovrete espandere l'interfaccia. Comunque, una volta che la classe è in uso, non potete modificarne l'interfaccia senza disturbare il codice client. Se avete bisogno di aggiungere più funzioni, va bene; non creerà problemi al codice, se non la necessità di una ricompilazione. Ma anche se i nuovi metodi rimpiazzano le funzionalità di quelle vecchie, lasciate da sola l'interfaccia già esistente (se volete, potete combinare le funzionalità nell'implementazione sottostante). Se avete bisogno di espandere l'interfaccia di una funzione esistente aggiungendo nuovi argomenti, lasciate gli argomenti già esistenti nel loro ordine, ed assegnate dei valori di default a tutti quelli nuovi; in questo modo, non creerete problemi a nessuna chiamata già esistente a quella funzione.

18. L'overloading degli operatori è soltanto "zucchero sintattico": un modo diverso per chiamare una funzione. Se l'overloading di un operatore non rende l'interfaccia della classe più chiara e semplice da usare, non fatelo. Per una classe create solo un operatore per la conversione automatica di tipo.

19. Non preoccupatevi di un'ottimizzazione prematura. È pura follia. In particolare, non preoccupatevi di forzare il codice ad essere efficiente quando state appena costruendo il sistema. Il vostro scopo principale è di verificare il progetto, a meno che lo stesso richieda una certa efficienza.

20. Mantenete gli scope più piccoli possibile, in modo che la visibilità e la vita dei vostri oggetti siano le più ridotte possibile. In questo modo, si diminuisce la possibilità di utilizzare un oggetto in un contesto sbagliato e di nascondere un bug difficile da trovare.

21. Evitate, evitate, evitate il più possibile... non ci stancheremo mai di ribadirlo, le variabili globali. Cercate sempre di inserire i dati all'interno delle classi. È più probabile imbattersi in funzioni globali piuttosto che in variabili globali, sebbene potreste rendervi conto in seguito che una funzione globale troverebbe una collocazione più consona come metodo static di una classe.

22. Sfruttate a vostro vantaggio il controllo degli errori effettuato dal compilatore. Compilate il vostro codice abilitando tutti i warning, e correggete il vostro codice inmodo da eliminarli tutti. Scrivete codice che utilizza gli errori ed i warning al momento della compilazione, piuttosto che codice che provochi errori di runtime. Utilizzate assert per il debug, ma a runtime usate le eccezioni.

23. Preferite gli errori di compilazione agli errori di runtime. Cercate di gestire un errore il più vicino possibile al punto in cui si è verificato. È preferibile gestire l’errore in quel punto piuttosto che lanciare un eccezione. Catturate le eccezioni nel gestore più vicino che abbia informazioni sufficienti per gestirle. Fate il possibile con l’eccezione al livello corrente; se in questo modo non risolvete il problema, rilanciatela nuovamente.

24. Non create una vostra notazione “personalizzata” per i nomi delle variabili membro (underscore, prefissi, variazioni fantasiose della notazione ungherese e così via), a meno che non abbiate una gran quantità di variabili globali preesistenti; se così non è, lasciate che le classi ed i namespace svolgano il lavoro per voi.

Architects: John Von Neumann, l'Architetto Supremo

E' difficile, molto difficile, scrivere di John Von Neumann... In realtà dovrebbe esserci tanto materiale in rete su questo mito dell'informatica da rendere pressochè inutile aggiungere nulla. E nulla di ulteriore...
Ci si immagina che, essendo John Von Neumann l'Architetto Supremo, colui che ha reso di fatto possibile tutto ciò che possiamo definire come "mondo digitale", Internet compresa, niente debba essere aggiunto.
Ed invece la Rete non omaggia per niente il suo Creatore ...
Vi è pochissimo materiale, per di più assai disorganico, per chiunque voglia approfondire l'argomento. Ma forse non è solo colpa della Rete in verità.
Ho un ricordo personale di quando ebbi uno dei miei primo incontro con il mondo della programmazione e dei calcolatori.
Università, corso di Programmazione dei Calcolatori Elettronici. Von Neumann fu solo una citazione, al volo ed assai superficiale in verità, da parte del professore di turno.
Un sintetico accenno al diagramma (capolavoro di astrazione e semplicità) sull'architettura della MAG (Macchina Astratta Generalizzata), qualche cenno storico sull'ENIAC (il primo elaboratore così come noi oggi lo intendiamo) e via, subito avanti con il corso di programmazione... Fortran 77 ed UNIVAC 1100 (schede perforate!) come elaboratore del Laboratorio di Informatica.
Si dice che Von Neumann disegnò lo schema della MAG in pochi minuti, dopo aver compreso immediatamente che i progettisti di ciò che divenne poi l'ENIAC brancolavano nel buio ... nel buio fitto dell'Assenza dell'Intuizione.

Oggi, quasi sempre, quando si parla di Von Neumann e del suo Supremo Eclettismo (è stato anche uno dei più grandi matematici dell'era moderna), non sono pochi, purtroppo, i professionisti del settore IT che frugano alla rinfusa nella propria memoria.

E stiamo parlando, quando parliamo di Von Neumann, di colui che postulò e rese possibile l'applicazione del bit come unità di misura elementare dell'informazione.

Von Neumann è stato, comunque, senz'altro un genio e come spesso accade per le personalità eccezionali, di certo anche un genio del male.

A lui dobbiamo, infatti, anche la prima sistematica e non disinteressata collaborazione della scienza con l'industria degli armamenti. Ciò tramite un'organizzazione, la Rand Corporation, di cui egli fu uno dei massimi esponenti ed anche, forse, azionista occulto.

Insieme al suo amico, il fisico nucleare Edward Teller, scomparso peraltro di recente, rappresentò l'altra faccia della scienza, quella che negli Stati Uniti proponeva ad ogni riunione strategica presso il Gabinetto Presidenziale, l'esigenza di garantirsi il "primo colpo" durante la cosiddetta Guerra Fredda. In piena aderenza ai principi della Teoria dei Giochi.

I loro avversari, di Teller e Von Neumann, erano i Fermi, gli Oppheneimer, Einstein ed il paradosso era che tutti loro insieme, gli avversari di Von Neumann, che dopo la fine della seconda guerra mondiale assunsero il ruolo di colombe pacifiste, in realtà avevano loro stessi contribuito in maniera decisiva alla creazione del Nucleare Militare.

Molto più dello stesso Von Neumann che vediamo in una foto storica qui di seguito insieme ad Oppheneimer ed all'ENIAC.

Fermi aveva dimostrato la possibilità della reazione atomica di fissione, e sapeva bene, quando replicò l'esperimento negli Stati Uniti, a cosa sarebbe servito.
Einstein aveva addirittura scritto una lettera di preghiera al presidente Roosvelt affinchè si dotasse il progetto Mahnattan dei finanziamenti necessari. Ed Einstein argomentava la richiesta motivandola con la terribile necessità di sconfiggere ad ogni costo il mostro nazista.
Per Von Neumann il mostro da sconfiggere a qualsiasi prezzo sarebbe stato quello comunista.

Oppenheimer, last but not the least, fu lo scienziato dotato di capacità organizzative eccezionali che rese possibile arrivare alla Bomba in pochissimi anni. Il responsabile operativo dell'organizzazione del Progetto Mahnattan. Uno dei pìù grandi Organizzatori della storia, forse in quel periodo secondo solo ad Albert Speer, il Ministro degli Armamenti di Hitler, un altro Architetto. Architeto di Organizzazioni.
Tutti colombe comunque, Einstein e quelli della sua cerchia, dopo il lancio della Bomba...

L'unico demone ufficiale per così dire, però, è rimasto Von Neumann ... dimenticato o meglio omesso. Conosciuto solo dagli specialisti del settore, dai matematici e del tutto ignoto ai più.
Il creatore della Teoria dei Giochi, altro caposaldo fondamentale tra innumerevoli discipline scientifiche, insieme a Nash ... ma questa è ancora un'altra storia...

Software Architecture: to be fast...

Anni fa. Ennesima intervista a Bill Gates in cui la speaker chiede quale sia il comportamento, la metodologia, insomma la cosa da fare più importante nell'ambito dello sviluppo software.
Domanda tutto sommato banale, la risposta, a giudicare dal volto seccato di Gates e dal conseguente suo famoso sorrisetto ironico, potrebbe essere anche essa banale.
Gates si concentra un attimo e, dopo pochi secondi, da una risposta che, nella sua apparente banalità e semplicità, è e resta invece assolutamente geniale.
La risposta di Gates è semplicemente:

"to be fast..."

L'intervistatrice si mostra a sua volta un pochino seccata, per qualcosa che Gates sembra aver buttato lì tanto per rispondere, ed incalza Gates chiedendogli nuovamente, si... che è ovvio che sia necessario essere rapidi e veloci nel corso dello sviluppo di un qualsiasi software, ma che insomma... cos'altro, sempre secondo Gates, è realmente importante, dopo l'essere fast, nell'ambito dello sviluppo software?

Gates stavolta risponde... ancor più gelido se possibile:

"to be faster..."

Napoleone Bonaparte aveva già risposto, un po' di tempo prima, ad analoga domanda, ovviamente su quali erano i tre parametri più importanti di cui tener conto sul campo di battaglia, la risposta di Napoleone fu:

" ... vitesse, vitesse, vitesse!!!"

Vitesse, ovviamente, in francese significa velocità...

Velocità di motoscafo,1923 Benedetta Cappa Marinetti.

Architects: Paul Allen – Software Architect, Microsoft (1971-1983)

L'inizio
Questa è una storia che se non fosse realmente accaduta nessuno ci crederebbe.

Sembrerebbe una leggenda, ed in effetti è assolutamente indubitabile che molto di quello che racconteremo a breve ha i toni del leggendario e ciò malgrado il fatto che il personaggio, Paul Allen, essendo uno dei 10 uomini più ricchi del mondo, è ovviamente, e rappresenta, di certo, qualcosa di molto concreto.
E, nel caso in cui ce lo dimenticassimo, ci sono i suoi 30 miliardi di dollari di patrimonio stimato a tutt’oggi a ricordarcelo.

Altra cosa che dovremo avere sempre presente, nel raccontare la storia di Paul Allen, il vero ed unico numero due della Microsoft di tutti i tempi, ed il suo primo Software Architect, è il fatto che lui e Bill Gates sono amici da sempre, ed hanno condiviso la loro passione per l’informatica da quando erano due giovanissimi teen agers.
L’informatica è la loro passione comune ed è una passione che traspare tutta anche dalla foto seguente, una rarissima immagine del 1968 in cui Bill ha 13 anni (Gates è nato nel 1955) e Paul ne ha 15 (Allen è del 1953).


Aspetto da sottolineare e che traspare tutto ed è cosa ed atteggiamento ben noto a chi lavora nel settore dello sviluppo software (pair programming, programmazione in coppia, eccoli lì… anche Bill&Paul lavoravano con questo metodo!!!), c’è Paul alla tastiera che scrive il codice.

Ed in effetti il primo vero Software Architect, di quella che, al momento della fondazione, si chiamava Micro-Soft, è stato Paul Allen.

L’unica persona, oltre alla madre (che ha avuto un ruolo fondamentale nella creazione di quel colosso che è oggi la Microsoft) di cui si dice che Gates si sia mai fidato in vita sua.
Paul Allen, forse l’unico vero e solo amico di Bill Gates, ed il suo primo Architect!
Allen ha avuto un ruolo chiave nella scalata di Microsoft al successo e non ha mai creato problemi di leadership a Gates.
Problemi di leadership, per inciso, che sono molto sentiti nel mondo dell’informatica, per il particolare tipo di personalità "aggressiva" che hanno e devono avere sempre e necessariamente i buoni programmers.
Allen ha sempre accettato la leadership di Gates, ciò malgrado sia più grande di età, due anni, rispetto a Bill.
Ad Allen, in fondo, forse interessava solo l’aspetto tecnico-creativo ed in effetti tra Allen e Gates c’è stato, probabilmente, lo stesso tipo di simbiosi tecnica e capacità commerciali e di raiders nelle trattative che vi è stato per un'altra coppia storica dell’informatica, Steve Jobs e Steve Wozniak (Apple).

Gates, Allen e la Micro-Soft
Allen è colui che quando fondò, insieme a Gates, la Micro-Soft, ed erano entrambi poco più che ventenni, accettò senza fiatare il diktat di Gates. Bill infatti, su consiglio della madre, modificò, poco prima di trascrivere gli atti formali dinanzi ai notai, la ripartizione percentuale delle quote della società.
Le quote iniziali della Micro-Soft erano 50% Gates e 50% Allen.
Quando la madre di Gates (che si intendeva di affari ed era membro influente di molte potenti associazioni in ambito cittadino a Seattle, la loro residenza) vide la ripartizione fatta dal figlio gli impose di cambiarla…
Disse a Bill che non esistono società al 50% …disse, sempre al figlio, rimproverandolo duramente di non capire nulla, che sarebbe prima o poi arrivato un momento, nell’ambito della vita societaria, di decidere qualcosa di estremamente importante … ed in quel caso doveva essere chiaro chi aveva l’ultima parola e chi no.
Bill capì e torno da Paul dicendogli che lui, Bill Gates, aveva deciso che le quote dovevano essere cambiate, 51% riservate a lui stesso, Gates, e 49% per Paul.
Prendere o lasciare… si guardarono negli occhi mentre Paul prendeva la sua decisione… poche persone al mondo possono reggere lo sguardo di Bil Gates … e Paul accettò.


E fu l’inizio di qualcosa che adesso è, di fatto, leggenda.
Non la ripercorreremo tutta, solo alcuni aspetti cruciali, anche per capire meglio il ruolo di un Architect, quale era ed è Allen, e di quanto tale ruolo sia spesso decisivo.
Una buona scelta tecnica di un buon Architect può salvare una situazione grave ed apparentemente irrecuperabile.
Una cattiva scelta, oppure peggio ancora, l’assenza di un Software Architect e la situazione da critical diviene vero e proprio collasso tecnico.

Microsoft DOS
Allen è la persona che indirizzò Gates, dopo che lo stesso aveva concluso l’affare con IBM, alla scelta di acquistare la code – base di ciò che poi diverrà il DOS. Comprarono la code-base da un programmatore che aveva strutturato e prodotto, senza alcun successo commerciale, qualcosa di simile a ciò che occorreva loro, un clone del C/PM di Gary Kildall (Digital Research).
Lo comprarono per 40.000 dollari!!!
Fu Allen ad estenderlo, lavorando come un matto sui terminali dell’università, e fu lui soprattutto che compì un vero e proprio miracolo tecnico quando, la mattina in cui stava partendo per la sede IBM per consegnare il prodotto (e ci andò solo Allen perché stavano risparmiando anche sui soldi dei biglietti aerei) si accorsero, troppo tardi, Gates ed Allen, che si erano dimenticati di scrivere la sequenza di bootstrap.
Lavorando sui terminali universitari (avevano risparmiato anche su questo!) il bootstrap lo realizzava il mainframe centrale. Ma il DOS doveva essere autopartente!!!
Se lo erano semplicemente … dimenticato !!!
Allen allora realizzò un vero e proprio capolavoro tecnico. Gates stava già pensando a manovre e telefonate dilatorie ad IBM, ma erano già al terzo rinvio, avrebbero quasi certamente perso la commessa più importante della loro vita.
Allen prese allora la decisione, la decisione di una vita, disse a Gates di non preoccuparsi, che avrebbe scritto lui la sequenza di bootstrap… e lo avrebbe fatto… accidenti… da solo in aereo con carta e matita ed in 3 ore circa!!!
Gates lo guardò partire, incredulo, ma Allen era convinto di potercela fare … e Paul scrisse in aereo, su fogli rimediati all’ultimo momento, incredibilmente a memoria, il codice della sequenza di bootstrap!
Arrivato per il test nella sede IBM trascrisse con calma, mentre i tecnici presenti lo scrutavano scettici, il codice nel PC prototipo che IBM gli mise a disposizione e tutto funzionò … miracolosamente senza errori!!!


Non si diventa a caso uno dei dieci uomini più ricchi del mondo!!!


La malattia
E la storia va avanti sino al 1983 …la Microsoft è già una potenza del settore ICT negli Stati Uniti e nel mondo e sotto la guida di Gates si muove con una spregiudicatezza che è indicativa delle modalità aggressive con cui intendono sopraffare il mercato.
Sono, infatti, già di quel periodo, le denunce per approcci di marketing assai discutibili, utilizzati da Microsoft, (ma tipici ancor oggi di molti ambienti ICT!!!) secondo il metodo F.U.D. Fear, Uncertainty and Doubt - "paura, incertezza e dubbio" - e cioè sostanzialmente diffondere notizie, prevalentemente false, sull’incapacità tecnica o su gravi problemi tecnici dei software dei concorrenti per impedirgli di conquistare o difendere mercato.
Nel 1983 accade qualcosa di imprevisto, qualcosa che non ti aspetti…qualcosa che però ci ricorda che siamo uomini… tutti uomini.
Paul Allen si ammala… e gravemente…un cancro, il Morbo di Hodgkin.
Dura due anni la lotta di Allen contro la malattia. Intanto Gates è vicino all’amico e gli dice di non preoccuparsi… che ci penserà lui alla società…sono i due anni più duri per Gates e per Allen…anni in cui Allen la sfanga nella sua lotta per la vita …e Gates stravince contro tutti gli avversari commerciali.
Dopo due anni così Gates è ben felice di riaccogliere il suo Architect, che torna dopo aver vinto la sua lotta contro la malattia.
Ma Allen, che possedendo il 49% è già ricchissimo oltre l’immaginabile, da al suo amico una risposta inaspettata… gli dice che non ha più voglia di lavorare!!!
Che, avendo affrontato la morte, ha imparato il valore della vita ed adesso vuole godersela, vuole spendere tutti i soldi guadagnati, ha le sue passioni (musica, basket, football, donne, viaggi…) e non gli frega più nulla del lavoro!!!
…e quindi prega Bill di liquidarlo economicamente e di lasciarlo andare!!!
Per Gates è un brutto colpo, pensa inizialmente che il suo vecchio amico sia impazzito e prende tempo, anche perché liquidare il 49% di Microsoft non è una operazione economicamente tanto fattibile nel breve.
Ma poi passa il tempo e Gates capisce che il suo amico fa sul serio, che davvero ha staccato la spina, quindi si passa al piano B orchestrato da Gates… che è la parte finale della nostra storia come vedremo…
Nel frattempo, negli ultimi 20 anni, Allen ha realizzato e sta realizzando tutti i suoi capricci… compra squadre di basket (i Portland Trailblazers) ed una di football, i Seattle Seahawks.
Edifica e fonda un museo dal costo complessivo di 500 mil. di dollari dedicato ad uno dei suoi idoli, Jimi Hendrix, finanzia cospicuamente, tra l’altro, la ricerca di forme di vita extraterrestri (23 mil. di dollari al Seti Institute di Carl Sagan) ed una misteriosa società ICT, Transmeta, che è anch’essa una leggenda come il suo fondatore e vedremo poi perché…

L'incidente giudiziario
Peraltro Allen è personaggio molto discreto che non ama far parlare di sé e lo dimostra, circa 10 anni fa, quando, suo malgrado, incappa in un guaio giudiziario. Una sua segretaria lo denuncia per violenza sessuale, è il periodo in cui negli States sembra facile ottenere (vedi caso Mike Tyson) cospicui risarcimenti con denunce del genere.
Ma Allen è uomo pubblico e si ritiene che andrà, con il suo stuolo dei migliori avvocati, sino in fondo, senza patteggiare come è sempre possibile nel sistema americano di Common Law.
Ne sono convinti tutti i media americani e mondiali che cominciano a seguire morbosamente la vicenda.
Si arriva alla data dell’udienza preliminare dove, secondo la prassi americana, il magistrato chiede alle parti di, eventualmente, chiudere la partita con una cifra a risarcimento di tutto, è la prassi, ma Paul Allen è uomo pubblico, rifiuterà, credono tutti, senz’altro per proteggere il suo buon nome.
I difensori della segretaria sparano, senza convinzione, una cifra pro-forma….5 milioni di dollari … è appunto un pro forma.
Si attende l’ovvio NO dei difensori di Paul Allen, i migliori d’America.
Ed a questo punto accade qualcosa che si è visto e si vedrà raramente nelle sedi giudiziarie, gli avvocati di Paul Allen aprono una valigetta, tirano fuori un assegno, compilano la cifra e lo consegnano al magistrato che, incredulo, legge l’importo!!!
Quindici milioni di dollari!!!
Si pensa ad un errore ma gli avvocati di Allen chiariscono.
Essi hanno avuto esplicito mandato, da parte del loro cliente Paul Allen, di pagare 3 volte qualsiasi fosse la somma richiesta dalla controparte per chiudere, definitivamente, la questione in quella sede.
Perché il loro cliente non avrebbe avuto il tempo di dedicarsi alla vicenda!!! Aveva ed ha di meglio da fare…
E di sicuro guardando il suo mega yacht (il più grande del mondo) di cose da fare migliori di una vicenda giudiziaria ne ha!!!



Il sottoscritto estensore di questo post seguì la vicenda, 10 anni fa circa, sui notiziari web e sui giornali come Corriere e Repubblica che dedicarono… e lo ricordo bene davvero… più di un reportage dall’udienza in cui accade quanto descritto.
Uno, molto bello, da parte anche di uno dei migliori giornalisti italiani, Vittorio Zucconi, scritto davvero bene.
Di quella notizia oggi, e la cosa è abbastanza inquietante, non vi è più alcuna traccia sul web.
Provate a cercare…
Allen è un personaggio molto discreto ed anche i motori di ricerca lo sono…

Allen, Trasmeta e Linux
E veniamo a Transmeta… la società più importante di Paul Allen che continua, pur avendo ufficialmente lasciato Microsoft, a tenere un piede nel mondo ICT.
Per anni, prima di annunciare al pubblico di produrre microprocessori a basso consumo e quotarsi al NASDAQ, Transmeta rimane un segreto impenetrabile intorno al quale si accumulano rumours e misteri.
E' la società dove lavora, ma guarda un po’ i casi della vita, e sin dal 1997, Linus Torvalds.
Si, proprio quel Linus Torvalds, l’Architect (un altro ancora!!!) di Linux per intenderci, assunto dall'ex collega Architect Paul Allen con un contratto di milioni di dollari.
Transmeta si dice sia la società che assume programmatori e tecnici di altissimo livello togliendoli prevalentemente ai concorrenti di Microsoft.
E’ la società che si permette, per anni, una home page che è un capolavoro di anti-marketing.
E’ la società che, come il suo principale finanziatore Allen, non ama far parlare di sé sul web…
Tra le leggende che girano nei meandri della rete ve n’è una veramente incredibile… forse la più incredibile di tutte… e ciò la dice lunga sul fatto che le informazioni contenute sul web e nel web chissà cosa siano in realtà.
…comunque, si diceva, la leggenda più paradossale che circola sulla rete è che chiunque scriva di Paul Allen, del suo incidente giudiziario, di Transmeta, di Linus Torvalds che lavora per Transmeta … riceverà una telefonata da un qualche emissario misterioso… che pagherà 3 volte qualsiasi cifra per far sparire la notizia, oppure lo assumerà, se tecnico ICT, in Transmeta a peso d’oro!!!
E questo è veramente davvero incredibile…
Oops… scusate se interrompo adesso questo post …ma mi squilla il cellulare…

The Perils of JavaSchool

The Perils of JavaSchool

Un interessante articolo, come sempre scritto in modo estremamente piacevole, di Joel Spolsky (ex Program Manager Microsoft - Excel vi dice qualcosa?) uno dei "guru" del software attualmente più ascoltati. Una visita periodica al suo blog, http://www.joelonsoftware.com/ è sempre d'obbligo!
In quest'ultima nota egli si lamenta dei tempi moderni o del fatto che in realtà, come tutti noi, forse sta invecchiando: "A sure sign of my descent into senility is bitchin' and moanin' about 'kids these days,' and how they won't or can't do anything hard any more!"

Citazioni del mese

P. Picasso: "Quando i critici d'arte si incontrano parlano di Forma, Struttura ed Espressione. Quando gli artisti si incontrano parlano di dove si può acquistare a minor prezzo l'acquaragia".

Gibbon: "L'insegnamento è sempre inutile, eccetto nei casi in cui è superfluo".

Oscar Wilde: "Chi dice la verità, prima o poi, viene sempre scoperto".

Scott Ambler (http://www.ambysoft.com/): "A good developer knows that there is more to development than programming. A great developer knows that there is more to development than development".

Boullée, Speer...

Teorico, architetto rivoluzionario e uomo dell'Ancien Régime, Boullée, è architetto di cui resta praticamente quasi nulla di realizzato ma la cui influenza è stata poi, seppur misconosciuta, enorme... ed è arrivata a noi, tramite un sottile filo rosso, passando finanche per l'Architetto di Hitler, Albert Speer.

Speer, che è considerato uno dei fondatori delle teorie di project management ed organizzazione di sistemi complessi.
L'Architetto che, di fatto, ha consentito, con le sue "mostruose" capacità organizzative, riconosciute al tempo anche dagli avversari del Reich, e mediante aumenti di produzione dell'industria bellica tedesca, al Reich di Hitler di resistere alla pressione degli Alleati.
Ciò malgrado i distruttivi bombardamenti cui lo sottoponevano l'azione combinata degli inglesi e degli americani.

La "forza organizzativa" di una buona architettura!!!

Boullèe, comunque, è stato personaggio visionario ed amatissimo dal mondo del cinema.

Il film "Il Ventre dell'Architetto" girato a Roma da Peter Greenway, è basato sull'ammirazione sconfinata per Boullée da parte del protagonista.

La parte più importante della produzione di Boullèe era costituita da una serie di progetti fantastici destinati ad illustrare la sua visione di Architettura ... progetti di smisurati edifici pubblici in cui veniva proposta un'architettura nuova, basata sulla sperimentazione di forme geometriche elementari e carica di significati morali e simbolici.

Forme elementari, geometrie semplici ... tecnologia ed arte KISS ... keep it simple!!!