Il web per i cellulari

La prossima estinzione del WAP, secondo quanto pubblicato da Software Development Times. I cellulari sono ormai diventati dei normali client.

Italia ancora meno competitiva nell'IT

La conferma di un trend, secondo una ricerca pubblicata dalla Economist Intelligence Unit e ripresa dal sito di Computerworld Italia

Le scuole in Finlandia

Insegnare è un mestiere prestigioso, e selettivo. In Finlandia.

L'educazione è considerata "the centrepiece of national identity. So hard work and good behaviour are the norm; teaching tempts the best graduates (nearly nine out of ten would-be teachers are turned down)." Economist, 26 giugno 2008

Nove candidati all'insegnamento su dieci vengono scartati. I risultati si vedono: gli allievi delle scuole finlandesi compaiono ai vertici delle classifiche internazionali per capacità di comprensione ed espressione testuale, matematica, scienze.

Co-evoluzione di problemi e soluzioni

Mentre ragioniamo sulle possibili soluzioni ad un problema, la stessa definizione del problema può dover essere riformulata.

Uno studio interessante sul disegno creativo, di Kees Dorst e Nigel Cross: "Creativity in the design process: co-evolution of problem-solution"

Il modello di co-evoluzione tra spazio dei problemi e spazio delle soluzioni è stato formalizzato in:

Maher, M L, Poon, J and Boulanger, S Formalising design exploration as co-evolution: a
combined gene approach, in Gero, J S and Sudweeks, F (eds.) Advances in Formal Design Methods for CAD, Chapman and Hall, London, UK (1996)

You Tube e simili

Mi colpiscono soprattutto due cose:

1. che nessuno, mai, prima d'ora, neppure i centri informativi più ricchi che siano mai esistiti, ha mai avuto a disposizione questa varietà di registrazioni in tempi così rapidi. Possiamo vedere ciò che è stato trasmesso ieri dalle televisioni di tutto il mondo, ma possiamo anche vedere filmati realizzati da una miriade di produttori non professionali, con punti di vista eventualmente contradditori rispetto alle versioni degli eventi rese pubbliche dai governi e dalle fonti informative consolidate.

2. che nessuno, mai, prima d'ora, ha mai potuto vedere e ascoltare tante persone viventi o vissute. Posso vedere filmati di Nietzsche, del Mahatma Gandhi, di Jimi Hendrix, di qualunque personaggio pubblico di cui abbia mai sentito parlare che sia vissuto negli ultimi cento anni o più. Ascoltare le voci. Diventerà (è già diventato) normale, ma io, oggi, lo trovo impressionante.

Incremental Commitment Model

Barry Boehm e Jo Ann Lane: "Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering", in CrossTalk, October 2007

Many projects have difficulties in integrating their hardware, software, and human factor aspects.

In comparison to the software-intensive RUP, the ICM also addresses hardware and human factor integration. It extends the RUP phases to cover the full system life cycle: An Exploration phase precedes the RUP Inception phase, which is refocused on valuation and investment analysis. The RUP Elaboration phase is refocused on architecting (a term based on describing concurrent development of requirements, architecture, and plans),
which adds feasibility evidence; the RUP Construction and Transition phases are combined into the Development phase; and an additional Operation phase combines
operations, production, maintenance, and phase-out. Also, the names of the milestones
are changed to emphasize that their objectives are to ensure stakeholder commitment
to proceed to the next level of resource expenditure based on a thorough feasibility and risk analysis, and not just on the existence of a set of system objectives and a set of architecture diagrams. Thus, the RUP Life-Cycle Objectives (LCO) milestone is called the Architecture Commitment Review (ACR) in the ICM, and the RUP Life-Cycle Architecture (LCA) milestone is called the Development Commitment Review (DCR).

In comparison to the sequential waterfall and V-model, the ICM explicitly does the following:
• Emphasizes concurrent engineering of requirements and solutions.
• Establishes feasibility rationales as pass/ fail milestone criteria.
• Enables risk-driven avoidance of unnecessary documents, phases, and reviews.
• Provides support for a stabilized current-increment development concurrently with a separate change processing and rebaselining activity to prepare for appropriate and stabilized development of the next increment.

Agile è troppo rigido...

Kunal Mittal Executive Director, IT, Sony Pictures Entertainment: The software development life cycle for Web 2.0. Realize the benefits of agile development.

"You've probably read about extreme programming, Scrum, and other agile development processes. To me, those are also probably too rigid [...] User stories, iterative development and releases, and a simple planning game are the key elements of your new process. It's also a good idea to include a quality assurance and testing cycle, as well as user-acceptance testing."

Secondo me, esagera. Ma è indicativo del fatto che l'approccio agile è ritenuto ormai consolidato.

Google ci sta facendo diventare stupidi?

'Is Google Making Us Stupid?' è un articolo di Nicholas Carr, pubblicato su The Atlantic Online, July/August 2008.

Il titolo è ad effetto, ma il nostro istupidimento non è causato in modo specifico da Google. Il problema è "What the Internet is doing to our brain", le modifiche che Internet porta al nostro modo di apprendere e pensare.

Carr segnala, partendo dalla propria personale esperienza e da quella di altri utenti, che chi frequenta in modo sistematico la rete si abitua ad una modalità di apprendimento e di elaborazione del pensiero diverse rispetto a quelle a cui era abituato. Più frammentarie, meno riflessive. Per alcuni versi, il discorso rimanda a quello trattato trent'anni fa da Neil Postman (in Amusing Ourselves to Death - anche in italiano) sugli effetti del modello culturale visuale - pubblicitario - televisivo.

Il wiki e la civiltà

The Software Practitioner è una newsletter (a pagamento) curata da Robert Glass. Sul numero gratuito di maggio 2006, scaricabile come esempio, in fondo, c'è una storiella intrigante sul wiki e la civiltà, di Peter e Dorothy Denning.

Tecnologie di collaborazione

Peter Denning, Peter Yaholkovsky: 'Getting to "We". Solidarity, not software, generates collaboration.' in Communications of the ACM, April 2008.

'Collaboration occurs when a community creates a solution to a messy problem that takes care of all their concerns at the same time. Collaboration is an ideal achieved far less often than it is invoked. It is often confused with information sharing, cooperation, or coordination. Most of our “collaboration technologies” are actually tools for information sharing.

[...] Collaboration does not mean that you give up or compromise your dearest concerns. It means designing a solution that recognizes your concerns. The process often leads to a reconfiguration of everyone’s concerns. The hallmark of successful collaboration is the

experience of solidarity and new energy: a “we”.'

L'offshoring cresce

Charalambos L. Iacovou and Robbie Nakatsu: 'A Risk Profile of Offshore-Outsourced Development Projects' in Communications of the ACM, June 2008.

'According to Forrester Research, 65% of American and European enterprises (with 1,000 or more employees) currently use offshore providers for application development; another 13% plan to begin doing so in the next year. Two years ago, only 45% of such organizations utilized offshore vendors to develop applications.'

Lo sviluppo in team distribuiti a livello internazionale

Michael Cusumano: 'Managing Software Development in Globally Distributed Teams' in Communications of the ACM, February 2008.

Cusumano raccomanda uno sviluppo agile, basato su un contratto "iterativo" tra cliente e fornitore, con definizione progressiva dei requisiti e distribuzione guidata dalle scelte architetturali.

Nulla di nuovo e di rilevante, se non un segnale di quanto gli approcci agili siano ormai considerati come la base necessaria anche per lo sviluppo software distribuito.

L'insegnamento e le stringhe

Alistair Cockburn: Teaching is pushing a string; learning is pulling the string

People keep asking, "What is the difference between teaching and learning? What is the instructor's role? After years of noodling, here's what I end up with:

Teaching is putting various strings in front of the students to pull on. The role of the instructor is to select and lay out the strings, indicate something about the meaning of pulling on them, etc.

Learning is their pulling on any of those strings. The role of the student is to select some strings, pull on them, abstract/note something about what happens. The instructor can't really know which strings the student is pulling on, or what the student will learn/abstract/note.

Note that this applies to parenting as much as to teachers.

Cosa leggere - Grandi libri

Stando così le cose in Italia, due problemi mi stanno particolarmente a cuore.

Prima di tutto, la sistematica sottovalutazione del merito e della competenza, che da trent'anni ci fa perdere competitività nel mondo.

Poi, la trasmissione del sapere. Che è un effetto della sottovalutazione del merito, come si vede dai meccanismi di selezione a livello di docenze universitarie, a livello di quadri politici, e di management in una parte consistente del settore pubblico. Ma che è anche una concausa del declino della competitività italiana. I paesi in cui si studia poco e male vanno sempre peggio, in una economia mondiale basata sulla conoscenza e sull'innovazione.

Cosa leggere. Nel sessantotto avevo dieci anni, ma il clima culturale degli anni seguenti vedeva con sospetto la tradizione, si amava piuttosto la rottura degli schemi. In quel contesto, la proposta di percorso culturale formulata da Mortimer Adler (negli Usa, prima metà del novecento) non mi era arrivata. E se fosse arrivata, l'avrei guardata con molto sospetto. Sbagliavo.

Adler proponeva un percorso di apprendimento basato sulla lettura dei Grandi Libri, in una certa sequenza. La scelta dei libri e della sequenza è certamente incompleta, e riflette uno specifico punto di vista (quello di Adler) e una specifica cultura (quella statunitense della prima metà del secolo scorso). Ma la lista di Adler ha tre vantaggi:

1. fornisce una guida sintetica, che la scuola a miei tempi non dava in modo altrettanto efficace
2. include testi sia "umanistici" che "scientifici", contribuendo a superare la distanza tra le due culture
3. non contiene testi mediocri o scadenti.

Nella situazione attuale della scuola e della cultura in Italia, l'elenco dei Grandi Libri di Adler può essere un buon punto di partenza. Purtroppo, l'elenco aggiornato è in Wikipedia edizione inglese. Un elenco in italiano, anche se riferito ad una versione precedente, è curato da Valentino Sossella.

Letteratura divertente

Sembra quasi un ossimoro (in questo caso, due parole che dicono una il contrario dell'altra).

Eppure esiste, in Italia, una letteratura divertente. Non solo quella lontana del tempo e considerata minore, dall'Ariosto in poi, che può essere difficile da leggere oggi perché la lingua è cambiata (almeno un po'). Esiste anche una letteratura italiana recente (del novecento) divertente. Achille Campanile, per fare un nome (ad esempio Gli asparagi e l'immortalità dell'anima, Vite di uomini illustri, Il povero Piero). O Ermanno Cavazzoni (es. Vite brevi di idioti).

La letteratura divertente esiste, ma non viene insegnata a scuola (ai miei tempi, negli anni settanta, non veniva neppure citata), né data da bere in televisione. L'unica è il passaparola.

Lo saprò quando lo vedrò

Barry Boehm - Making a Difference in the Software Century

Un eccellente articolo su IEEE Computer, marzo 2008 (in realtà, si tratta di un estratto della introduzione scritta da Boehm per l'antologia dei propri scritti, pubblicata nel 2007 da IEEE CS Press-John Wiley & Sons ).

Riporto un paio di passi.

Il primo, sulla difficoltà per gli utenti di chiarire i requisiti in anticipo :

"Spesso, quando si chiede agli utenti di specificare come vorrebbero interagire con una nuova applicazione, essi rispondono “Lo saprò quando la vedrò” (IKIWISI - I’ll Know It When I See It). In questi casi, usare un modello a cascata sequenziale, specificare-prima-i-requisiti, diventa di solito la ricetta per un sistema inefficace e per un mucchio di costosi rifacimenti".

Il secondo, sul conflitto tra punti di vista ed interessi tra gli stakeholder di progetto:

"Il fatto che ci siano molti conflitti potenziali tra i principali stakeholder significa che il progetto può entrare in situazioni in cui uno vince e un altro perde. E una situazione del genere di solito diventa una situazione in cui perdono tutti.

In situazioni simili è importante gestire le aspettative degli stakeholder, lavorare di più per assicurare che la soluzione proposta sia fattibile e adeguata agli interessi di tutti, e negoziare un insieme globalmente soddisfacente e vantaggioso di specifiche, piani e risorse, prima di procedere con lo sviluppo. Quando si negoziano i requisiti, nei momenti iniziali è meglio sostituire termini che possono essere interpretati come non negoziabili, ad esempio il termine 'requisiti' (cose richieste con autorità e diritto) con parole come 'obiettivi' e 'scopi'."

About us

aboutus.org è un'organizzazione che ha tra i suoi obiettivi il miglioramento dei servizi offerti dalle aziende su web, attraverso critiche costruttive e pubbliche da parte degli utenti.

L'ho scoperta perché attualmente vi lavora Ward Cunningham (tra le altre cose, ideatore dei Wiki e ispiratore di Extreme Programming), le cui iniziative sono normalmente da seguire con attenzione.

Potrebbe servire a diffondere anche in Italia la pratica della critica pubblica e costruttiva dei servizi web?

Being Your Own Boss

Watts Humprey è il padre del Software Engineering Institute e del Capability Maturity Model.

In una serie di cinque articoli, tratteggia l'atteggiamento mentale di sviluppatori e manager nei confronti dello sviluppo software.

1: The Ideal Job
2: The Autocratic manager
3: Knowledge Work
4: Being a Victim
5: Building Trust

Legge di Conway

"Ogni organizzazione che progetti un sistema (sistemi informativi, e non solo) produrrà inevitabilmente un design la cui struttura è una copia della struttura comunicativa dell'organizzazione."

Melvin E. Conway “How Do Committees Invent?” Datamation 14(4), April 1968

In altri termini, esiste uno stretto rapporto tra l'organizzazione dello sviluppo e l'architettura dei sistemi che un'organizzazione produce.

Conoscevo la legge di Conway grazie agli Organizational Patterns of Agile Software Development di James Coplien e Neil Harrison, ma non avevo letto il testo originale di Melvin Conway, apparso nel 1968. Vale la pena farlo.

Patterns of Agile Adoption

Un articolo di Mike Cohn su Agile Journal delinea alcuni possibili percorsi per modificare il processo di sviluppo di un'organizzazione verso una maggiore agilità.

Cohn descrive tre coppie di alternative:

• partire con progetti pilota o intervenire contemporaneamente su tutti i progetti ("Start Small or go All In?")
• iniziare dalle pratiche agili più "tecniche" o partire dall'approccio iterativo ("Technical Practices First or Iterative First?")
• partire di nascosto o pubblicizzare in anticipo il cambiamento ("Stealth Mode or a Public Display of Agility?")

Per ognuna delle alternative, vengono elencati vantaggi e svantaggi.