Usable Software

Usable software with solid code

La cultura dell’agilità

La cultura dell’agilità si rispecchia nella velocità con cui si prendono le decisioni, nella misura in cui si monitora un processo per prendere decisioni informate, nella misura in cui si adatta un processo per migliorare la qualità di un prodotto nel rispetto della sostenibilità. Nel contesto dell’ingegneria del software, che

La rottamazione dell’agile

Basta scrivere rottamazione oggi (2017) e in Italia si diventa subito impopolari. Esattamente l’opposto di ciò che accadeva qualche anno fa, in epoca “renziana”, quando rottamare era lo spot del “nuovo” che incalzava il “vecchio”. Questo è il potere delle buzz-word. Per riscoprire il vero significato di un termine bisogna

Consulenti di business, analisti-programmatori e proxy-expert: i volti di un ruolo che cambia

In un era, quella agile, in cui spopolano le figure dei “pragmatic-” programmers e degli architetti “evolutivi” (evolution architects), anche la figura dell’analista è soggetta al cambiamento. Negli anni ’70-’90 essere analisti significava ricoprire un ruolo ben definito all’interno di un altrettanto chiaro ciclo di vita del software (il modello

La postura di un leader

La gestione di un progetto è un aspetto determinante per il suo successo. Questo vale nel mondo del software come in qualsiasi altro settore. I migliori manager sono innanzitutto dei leader in grado di motivare le persone che lavorano per loro. La leadership, per essere realmente efficace, non avviene per

Spaghetti, lasagne, ravioli e software

Recentemente sulla rete sta girando un post che, attraverso una simpatica vignetta, ripercorre trent’anni di evoluzione industriale delle architetture software. La metafora utilizzata per descrivere i tre modelli di riferimento citati è quella culinaria. Si parte dalle architetture “Spaghetti-oriented” degli anni ’90, per arrivare alle architetture stratificate, applicazione monolitica del

Dangerous software coupling: when it is time to divorce

Every seasoned software architect knows that some degree of coupling is unavoidable in any real software project. The larger is a project, the higher is the likelihood that it contains several interconnected modules. Not all these interconnections, however, are equally dangerous: some forms are worst than others. In this series