30 December, 2005
La sfida dei grandi numeri
L'esperienza dimostra che lanciando più volte una moneta, lo scarto tra "testa" e "croce" tende a ridursi, tanto che aumentando il numero di prove, l'equilibrio, la parità, la tendenza verso una armonia diventa sempre più evidente. Serie bizzarre tendono a normalizzarsi con il numero di lanci.
Anche quel particolare gioco che è la determinazione del sesso (in cui ogni incontro tra un ovulo e uno spermatozoo è indipendente da ogni altro. L'utero non ha memoria) segue la stessa legge: in ogni secolo, presso tutti i popoli, la popolazione è equamente divisa tra maschi e femmine. Nulla impedirebbe una distribuzione squilibrata con, ad esempio, un 20% contro un 80%.
Sembra che la roulette della vita segua le leggi della roulette delle case da gioco: compensazione, equilibrio, armonia. Un caso? Il caso si comporterebbe in modo contrario, con serie capricciose, dando risultati imprevedibili.
Che spiegazione date?
Anche quel particolare gioco che è la determinazione del sesso (in cui ogni incontro tra un ovulo e uno spermatozoo è indipendente da ogni altro. L'utero non ha memoria) segue la stessa legge: in ogni secolo, presso tutti i popoli, la popolazione è equamente divisa tra maschi e femmine. Nulla impedirebbe una distribuzione squilibrata con, ad esempio, un 20% contro un 80%.
Sembra che la roulette della vita segua le leggi della roulette delle case da gioco: compensazione, equilibrio, armonia. Un caso? Il caso si comporterebbe in modo contrario, con serie capricciose, dando risultati imprevedibili.
Che spiegazione date?
Labels: Science
Il cliente non ha sempre ragione
Uno dei cavalli di battaglia delle metodologie agili è la presenza o comunque il coinvolgimento costante del cliente. Pur trovandomi d'accordo in linea di principio, la realtà che quotidianamente sperimento (ma credo di non essere l'unico) è purtroppo un'altra.
Vi immaginate il cliente continuamente alle spalle? Quello che non si capisce è che il team di sviluppo deve ascoltare ciò che il cliente vuole ma realizzare ciò che il cliente ha veramente bisogno. Questa è una lezione costante che tende a valorizzare il team e a portare il cliente su posizioni più adeguate.
L'implicazione immediata è che l'attività di analisi smette di essere una pura trascrizione di requisiti diventando un momento di riflessione sul "significato" del sistema da realizzare.
Vi immaginate il cliente continuamente alle spalle? Quello che non si capisce è che il team di sviluppo deve ascoltare ciò che il cliente vuole ma realizzare ciò che il cliente ha veramente bisogno. Questa è una lezione costante che tende a valorizzare il team e a portare il cliente su posizioni più adeguate.
L'implicazione immediata è che l'attività di analisi smette di essere una pura trascrizione di requisiti diventando un momento di riflessione sul "significato" del sistema da realizzare.
Labels: IT
28 December, 2005
Index tomisticus
Grande quanto sconosciuto nel nostro ambiente questo pioniere del "literary and linguistic computing". Parlo di padre Roberto Busa S.J., ormai ultranovantenne.
Nel 1949 incontra a New York Thomas Watson Sr., amministratore delegato della IBM. Incontro proficuo che gli consentirà di realizzare sulle macchine della IBM il suo chiodo fisso: una colossale analisi sistematica della struttura del linguaggio di S. Tommaso registrata su 16Km di nastro, pubblicata tra il 1974 e il 1980 in 56 volumi e ora disponibile su Cd-Rom. Senza il timore di esagerare credo che quest'opera (appunto l'Index Tomisticus) segni la nascita dell'informatica linguistica.
In un afoso agosto riminese del 2000 ebbi il piacere di scambiare due chiacchiere con padre Busa, dopo la presentazione del suo libro "Dal computer agli angeli", ove l'autore ha trovato il tempo di confezionare in 1.261 "momenti di pensiero" giudizi puntuali sull'informatica, sull'AI, Internet e sul rapporto attivo tra uomo e macchina.
L'invito alla lettura è scontato da parte mia e per dare un assaggio inerente al nostro lavoro padre Busa sostiene che la programmazione è un atto di sapienza, quella sapienza che presiede all'organizzazione e che secondo l'Aquinate è «il modo con cui si produce qualcosa, cioè lo si pone in essere organizzandolo bene».
Il rapporto tra programmazione ad oggetti e la logica aristotelica/tomista è uno studio che prima o poi porterò a termine e spero di darne evidenza anche in questo spazio.
Nel 1949 incontra a New York Thomas Watson Sr., amministratore delegato della IBM. Incontro proficuo che gli consentirà di realizzare sulle macchine della IBM il suo chiodo fisso: una colossale analisi sistematica della struttura del linguaggio di S. Tommaso registrata su 16Km di nastro, pubblicata tra il 1974 e il 1980 in 56 volumi e ora disponibile su Cd-Rom. Senza il timore di esagerare credo che quest'opera (appunto l'Index Tomisticus) segni la nascita dell'informatica linguistica.
In un afoso agosto riminese del 2000 ebbi il piacere di scambiare due chiacchiere con padre Busa, dopo la presentazione del suo libro "Dal computer agli angeli", ove l'autore ha trovato il tempo di confezionare in 1.261 "momenti di pensiero" giudizi puntuali sull'informatica, sull'AI, Internet e sul rapporto attivo tra uomo e macchina.
L'invito alla lettura è scontato da parte mia e per dare un assaggio inerente al nostro lavoro padre Busa sostiene che la programmazione è un atto di sapienza, quella sapienza che presiede all'organizzazione e che secondo l'Aquinate è «il modo con cui si produce qualcosa, cioè lo si pone in essere organizzandolo bene».
Il rapporto tra programmazione ad oggetti e la logica aristotelica/tomista è uno studio che prima o poi porterò a termine e spero di darne evidenza anche in questo spazio.
Labels: IT
10 December, 2005
Analisi e sintesi
Il lavoro scientifico è orientato verso due direttrici: "una tendenza analitica a scomporre il complesso in oggetti semplici (ricerca della spiegazione, del come) e una tendenza opposta, sintetica, a collegare più oggetti integrandoli in unità più grandi, che non sono la pura collezione degli oggetti componenti, ma per effetti dei mutui cambiamenti acquistano un significato non prevedibile da una pura descrizione del componente: questa organizzazione in unità più complesse corrisponde a una ricerca di significato".
La scienza galileana è tutta permeata da una tendenza analitica e solo dai recenti studi sul paradigma della complessità è emerso una tendenza alla sintesi allargando la ricerca in molti campi non ultimo la scienza informatica. Un esempio chiaro è la realizzazione di architetture software che guidano poi lo sviluppo dei sistemi informatici. Mi sottraggo dal dare una formale definizione di architettura per ragioni innanzitutto di incompetenza, ma l'ossatura di un sistema software, dunque l'architettura portante, segue la direttrice della "sinteticità" intesa come interpretazione del significato che si vuole dare al sistema. A posteriori è assolutamente arduo spiegare il "cosa" di un sistema semplicemente consultando l'elenco dei componenti costituenti, bisogna piuttosto vederne la struttura, le relazioni e le dinamiche in essa contenuti (e qui che si misura la bontà della documentazione, spesso bistrattata e quando presente perfettamente ridondante rispetto all'architettura e quindi inutile, oltre che un peso per chi deve leggerla e/o studiarla).
Metodologicamente l'analisi guida l'esplorazione dei mattoni costituenti (le classi, i componenti) e la sintesi li agglomera dando forma e significato. Entrambe sono due momenti distinti dell'attività di design architetturale.
In continuità con il post precedente, non credo sia inutile mutuare dalla scienza (quella vera) metodi, pratiche e suggerimenti. Dirò di più: esiste un solo metodo di indagine della realtà (per la scienza, per la biologia, per gli ingegneri,...) e molte modalità applicative diversificate dalla fetta di realtà indagata e dagli strumenti adoperati.
La scienza galileana è tutta permeata da una tendenza analitica e solo dai recenti studi sul paradigma della complessità è emerso una tendenza alla sintesi allargando la ricerca in molti campi non ultimo la scienza informatica. Un esempio chiaro è la realizzazione di architetture software che guidano poi lo sviluppo dei sistemi informatici. Mi sottraggo dal dare una formale definizione di architettura per ragioni innanzitutto di incompetenza, ma l'ossatura di un sistema software, dunque l'architettura portante, segue la direttrice della "sinteticità" intesa come interpretazione del significato che si vuole dare al sistema. A posteriori è assolutamente arduo spiegare il "cosa" di un sistema semplicemente consultando l'elenco dei componenti costituenti, bisogna piuttosto vederne la struttura, le relazioni e le dinamiche in essa contenuti (e qui che si misura la bontà della documentazione, spesso bistrattata e quando presente perfettamente ridondante rispetto all'architettura e quindi inutile, oltre che un peso per chi deve leggerla e/o studiarla).
Metodologicamente l'analisi guida l'esplorazione dei mattoni costituenti (le classi, i componenti) e la sintesi li agglomera dando forma e significato. Entrambe sono due momenti distinti dell'attività di design architetturale.
In continuità con il post precedente, non credo sia inutile mutuare dalla scienza (quella vera) metodi, pratiche e suggerimenti. Dirò di più: esiste un solo metodo di indagine della realtà (per la scienza, per la biologia, per gli ingegneri,...) e molte modalità applicative diversificate dalla fetta di realtà indagata e dagli strumenti adoperati.
Labels: IT
