analisi-disegno.com

In questi giorni è in corso la più importante conferenza internazionale sulle architetture software, Saturn (SEI Architecture Technology User Network), organizzata dal Software Engineering Institute.

Tra gli interventi, una keynote di Michael Stal: Win-Win With Agile Architecture.

Linguaggi a oggetti e DBMS relationali: come farli convivere nel modo meno doloroso possibile?

Sul tema, antico ma sempre attuale, un articolo di Martin Fowler.

Come far fronte alla complessità dei sistemi complessi? Almeno, come comprenderla, come descriverla?

"Complexity Thinking", interessante presentazione di Jurgen Appelo.

"Software engineering is not, and should not become, engineering. It continues to seek an identity of its own. In the mean time, it’s probably better that it live alongside engineering—it might as well have neighbors who are a good influence. But art, psychology, and a host of others should also be in the neighborhood."

James Coplien, "It's Not Engineering, Jim"

La copertura dei test indica quali porzioni del codice software non sono controllate da test. Ma non è un indicatore assoluto di qualità del software.

Su questo, oltre a un classico (1997) di Brian Marick, un recente articolo di Martin Fowler.

La qualità del codice è importante, scrive Bjarne Stroustrup, l'ideatore del linguaggio di programmazione C++ , in un articolo pubblicato a gennaio 2012 su IEEE Computer.

Importante, in particolare, per il software presente in quei dispositivi su cui la nostra vita quotidiana si regge. Il software che controlla le automobili, i treni, gli aerei. Ma anche i dispositivi medici, gli apparati di controllo ambientale, i telefoni cellulari, o i PC tramite i quali accediamo ai conti bancari.

Stroustrup definisce tutto il software che può creare danni fisici, ambientali o economici come software infrastrutturale, e sostiene che deve essere progettato e implementato diversamente dagli altri tipi di software, quelli meno rischiosi per gli esseri umani:

"Infrastructure software needs more stringent correctness, reliability, efficiency, and maintainability requirements than non- essential applications. This implies greater emphasis on up-front design, static structure enforced by a type system, compact data structures, simplified code structure, and improved tool support. Education for infrastructure and application developers should differ to reflect that emphasis."

Interessante, tra l'altro, l'opinione di Stroustrup contraria al Model-Driven Development per il software infrastrutturale: "Many tasks aren't mathematically well-defined, resource constraints can be draconian, and we must deal with hardware errors. I see no alternative to programmers and designers directly dealing with code for most of these tasks."

Il Wall Street Journal riporta una classifica dei migliori mestieri per il 2012, basata su 5 fattori: impegno fisico, ambiente di lavoro, reddito, stress, prospettive di assunzione.
Le classifiche di questo tipo lasciano un po' il tempo che trovano, vanno prese con le molle, ma possono comunque fornire riscontri e indicazioni utili, come in questo caso.

Il mestiere migliore: Software Engineer.

Negli USA. Ma anche negli altri paesi in crescita. Non in Italia.

Il web è il più grande laboratorio mai esistito per studiare il comportamento umano, secondo Gerry McGovern:

"The Web facilitates continuous testing and improvement. Great web designs are responsive and flexible. They allow for rapid innovation based on feedback."

Dal "Built-to-last" (fatto per durare) al "Built-to-change" (fatto per cambiare).

Sulla stessa linea, per approfondire, l'ottimo libro di Eric Ries, The Lean Startup.

Dal sito di IEEE Europe, alcuni dati interessanti su chi sta cercando personale ICT in Europa, dove, e per quali skill.