software engineering

"Computer science focuses more on the realm of the ones and zeros, but software engineering attends to the delicious dance between the technical and the social, between the ones and zeros and the human stories.
[...] it's how we organize the humans who develop/deliver/deploy/evolve those bits that are at the heart of software engineering".

Grady Booch, "The Professional Architect", IEEE Software Jan/Feb 2012.

Forse la danza tra aspetti tecnici e aspetti umani non è sempre deliziosa, ma questa distinzione tra i due ambiti, computer science e software engineering, è precisa.

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.

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"

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.

Ottimo articolo di Tom DeMarco, uno tra i più lucidi esperti di sviluppo software (autore tra l'altro, con Tim Lister, dello straordinario Peopleware).

Tutte le cause legali, nei rapporti di outsourcing dello sviluppo software, vanno nello stesso modo:
"By the 1990s, a significant part of my practice was litigation support, which was a natural consequence of raising my rates to the level that only legal departments could afford. Of course, litigation is all about failure, so perhaps I was seeing more than my share of it. Surprisingly, the failures began to look pretty much alike. Company A contracts to build a software system for Company B and is late to finish, or it goes on beyond its contracted delivery date and the work is cancelled. B sues A or vice versa, one of them hires me, and we all obsess over failure for a while and then settle. In the end, A and B are poorer, the lawyers and I are slightly richer, and nothing has changed. "

E tutti i progetti in ritardo hanno qualcosa in comune... "All projects that finish late have this one thing in common: they started late."

Meno banale di quanto sembrerebbe a prima vista, come si scopre leggendo le motivazioni di DeMarco nell'articolo "All Late Projects Are the Same", comparso su IEEE Software Nov/Dec 2011, disponibile gratuitamente.

Se nello sviluppo software intervenissero solo due persone, chi vuole il
sistema e chi lo realizza, avremmo un solo canale di comunicazione.

La comunicazione potrebbe funzionare più o meno bene. Il committente
potrebbe avere le idee più o meno chiare ed esprimersi in modo più o
meno efficace, e chi realizza potrebbe capire ciò che il committente
vuole, oppure no. Sarebbe, comunque, una comunicazione diretta, con i
vantaggi e gli svantaggi del caso.

Se invece il numero degli interlocutori aumenta, ad esempio perché
intervengono ruoli specializzati, come analisti, architetti software,
progettisti, aumenta anche il numero di comunicazioni da gestire.

I ruoli intermedi, in quanto specializzati (l'esperto di analisi,
l'esperto di software design), possono e devono fornire un valore aggiunto.

Il numero delle comunicazioni, in ogni caso, cresce, e possono crescere
i tempi necessari a comunicare. Se le comunicazioni avvengono in
sequenza può aumentare anche il livello di rischio.

Quando ero bambino, alcuni decenni fa, giocavamo un gioco dal nome che
oggi fa sorridere: il telefono senza fili. Ci si metteva in fila, e il
primo bambino diceva sottovoce e velocemente una frase nell'orecchio del
secondo bambino, che a sua volta la ripeteva velocemente all'orecchio
del terzo, che la ripeteva all'orecchio del quarto, e così via. Alla
fine, la frase che arrivava all'ultimo bambino era certamente diversa
dalla frase iniziale.

Nello sviluppo software può andare anche peggio. Perché ogni sviluppo
software si basa su un insieme di requisiti che non sono fissati
all'inizio, ma si precisano gradualmente, nella progressiva acquisizione
di conoscenza che coinvolge tutti i partecipanti al progetto.

Più ruoli intermedi esistono tra chi ha l'esigenza e chi implementa, più
sono le comunicazioni da gestire. Più le comunicazioni avvengono in
sequenza (a catena), più crescono i tempi di realizzazione. E i rischi
di incomprensione.

Semat, Software Engineering Method and Theory, ha reso pubblica la propria proposta all'Object Management Group.

I benefici della certificazione CMMI non sono quelli di ricevere un "bollino", ma di migliorare in modo sostanziale la produttività e la qualità dello sviluppo software.
Con un ritorno di investimento molto elevato, particolarmente per i livelli più elevati (4 - Managed e 5 - Optimizing).

Sul tema, il numero monografico Jan/Feb 2012 di Crosstalk - The Journal of Defense Software Engineering

Ottimo articolo sulla codifica del software, ricco di indicazioni pratiche ed esempi concreti. "Coding Guidelines: Finding the Art in the Science" di Robert Green e Henry Ledgard, su Communications of the ACM December 2011.

Il messaggio di fondo: focalizzarsi su come si scrive il codice, non sui commenti al codice:

"Programmers must achieve a level of clarity, continuity, and beauty when writing code. This means focusing on the code and its clarity, balance, and symmetry, not on its length or comments. While this concept does not advocate the removal of comments or negate their use and importance in appropriate situations, it does suggest that programmers must use comments wisely and judiciously. The focus should be on developing code that, for the most part, clearly communicates intent and functionality. This practice will automatically reduce the need for many comments."