Decision-making: come scegliere il tuo prossimo stack tecnologico

Qual è il giusto stack?

Java o JavaScript? O forse C#? E ancora: dovremmo implementare un’architettura a monolite o a microservizi? React o Angular? Queste sono alcune delle decisioni che ogni team di sviluppo software front-end deve prendere quando si trova a lavorare su un prodotto (o progetto?).
Eppure, il decision-making è una skill normalmente poco considerata da chi sviluppa software.

Ricordando il talk di Dan North “Decisions, decisions” la risposta è…DIPENDE. Non esiste una risposta corretta, in base alle situazioni ci sono una miriade di fattori da prendere in considerazione. L’argomento è più complesso di quello che si pensa.

Non-Functional Requirements

Qual è l’obiettivo di un’architettura software? Solitamente cerchiamo di implementare software che rispondano ai seguenti requisiti:

• Manutenibilità
• Performance
• Scalabilità
• Velocità

Questi sono tutti requisiti non funzionali, o NFR, I requisiti non funzionali rappresentano i vincoli e le proprietà/caratteristiche relative ad sistema, come vincoli di natura temporale, vincoli sul processo di sviluppo e sugli standard da adottare. Tipicamente, i requisiti non funzionali non si applicano a singole funzioni o servizi, bensì all’intero sistema. Sono strettamente vincolati alle esigenze degli utenti, alle politiche organizzative adottate, agli standard adoperati, alla necessaria modalità di interazione del relativo sistema con altri componenti. Pertanto, essi possono essere classificati in requisiti:

• di prodotto, che descrivono le caratteristiche del prodotto, in termini di usabilità, efficienza, affidabilità e portabilità;
• organizzativi (o di processo), che derivano dalle politiche e procedure organizzative relative al cliente ed allo sviluppatore;
• esterni, che si riferiscono a fattori estranei al sistema ed al relativo processo di sviluppo, come requisiti legislativi, requisiti di interoperabilità.

Riassumendo, i requisiti non funzionali rispondono alla domanda What a software should do?. Non descrivono come un software deve essere. Per questo ci pensano i requisiti funzionali (What a software should be?).

Consultando la pagina Wikipedia, possiamo notare che esistono tanti requisiti non funzionali. Sarebbe meglio, nel nostro processo di decision-making di un’architettura software, scegliere un sottoinsieme di questi requisiti e in base a questi scegliere le tecnologie per il nostro sistema. E una volta deciso il sottoinsieme, capire come si relazionano tra loro questi requisiti.

Francesco prosegue il suo intervento introducendo alcune tecniche di decision-making (trovate i link di approfondimento nel paragrafo Riferimenti).

Criteri di decision-making

Elevator pitch

Elevator pitch è la traduzione inglese della parola ascensore. Si tratta infatti del discorso che un imprenditore farebbe ad un investitore se si trovasse per caso con lui in ascensore. L’imprenditore (ad esempio di una startup), quindi, si troverebbe costretto a descrivere sé e la propria attività sinteticamente, chiaramente ed efficacemente per convincere l’investitore ad investire su di lui, ma nei limiti di tempo imposti dalla corsa dell’ascensore.

Il requisito non funzionale potrebbe essere espresso nella seguente forma

For [TARGET CUSTOMER TYPE] who want to [NEED / DESIRE], [PRODUCT / FEATURE] is a [MARKET CATEGORY] that [KEY BENEFIT].

Il KEY BENEFIT è il requisito non funzionale principale.

SWOT analysis

L’analisi SWOT (conosciuta anche come matrice SWOT) è uno strumento di pianificazione strategica usato per valutare i punti di forza (Strengths), le debolezze (Weaknesses), le opportunità (Opportunities) e le minacce (Threats) di un progetto o in un’impresa o in ogni altra situazione in cui un’organizzazione o un individuo debba svolgere una decisione per il raggiungimento di un obiettivo. L’analisi può riguardare l’ambiente interno (analizzando punti di forza e di debolezza) o esterno di un’organizzazione (analizzando minacce ed opportunità).

Francesco ha portato un esempio da un workshop tenuto in un’azienda.
Siamo una startup in un mercato vergine, quindi siamo nel cosiddetto green field (prato verde) dove non abbiamo concorrenti diretti. In questo caso il requisito non funzionale può essere la velocity (Opportunities), essere i primi a rilasciare il nostro prodotto. Dieci anni dopo, sempre con lo stesso prodotto/progetto, come ci muoveremmo? Vedremmo delle minacce, dei Threats, e quindi forse il requisito non funzionale sarebbe quello della minaccia della concorrenza.

Trade-off Sliders

Con questo criterio di decision-making si scrivono quelli che sono i requisiti non funzionali importanti per il sistema, dopodiché si valuta assieme con il resto del team a quali dare più peso. Ovviamente “la coperta è corta, se tiri da una parte inevitabilmente ne rimarrà scoperta un’altra.”
Francesco ha portato l’esempio di quattro requisiti non funzionali quali budget, quality, scope, deadline.

Architecture compass chart

Un altro strumento utile per visualizzare la relazione tra gli NFR del prodotto. La prima cosa da fare è disporre i requisiti su un grafico radar, come quello proposto da Francesco nella seguente immagine.

Questo grafico è molto importante per capire quali tipi di compromessi sono accettabili quando si prende una decisione. Nello scenario descritto nella tabella sopra per raggiungere Interoperability e Deployability, il team può sacrificare Performances e Throughput ma dovrebbe mantenere Evolvability abbastanza in equilibrio con il resto.

Questi sono solo alcuni esempi di criteri di decision-making. Ogni stack scelto avrà i suoi pro e contro, quantomeno saranno però basati su scelte fatte da un’analisi precedente.

La scelta di uno stack tecnologico è solo uno degli argomenti di decision-making che riguardano un team di sviluppo software. Che non è salvo da anti pattern nel quale si può ricadere.

Anti Pattern

Hype-driven development

Scegliere la/le tecnologia/e più in voga, o perché sono le ultime novità, non sempre è la scelta giusta. Bisogna fare attenzione, ad esempio scegliere sì l’ultimo framework per lo sviluppo del frontend del proprio applicativo, ma farlo in maniera consapevole. Francesco ci ricorda di consultare il Gartner Hype Cicle (realizzato ogni anno) che spiega bene l’andamento di una tecnologia nel tempo (immagine seguente).

Facciamo quello che abbiamo sempre fatto

E’ il classico atteggiamento che porta a scegliere uno stack tecnologico basato sull’esperienza e la conoscenza acquisiti nel tempo.
Una frase tipica di questo anti pattern potrebbe essere “Abbiamo sempre sviluppato in C#, continuiamo a farlo”. Magari scelte imposte da figure che ricoprono un ruolo più manageriale e quindi hanno perso il contatto con la realtà.

Chiamare l’esperto

Per il prodotto che bisogna realizzare, si decide di usare un framework diverso dal solito, quindi scegliamo uno stack tecnologico con l’aiuto di un esperto (un consulente ad esempio). Non va bene, perché anche in questo caso sarebbero scelte imposte da figure esterne.

Decisioni guidate dalla rabbia

L’anti-pattern in cui si sceglie lo stack stando attenti a non commettere gli errori del passato. “Il nostro ultimo progetto è fallito e avevamo scelto di usare AngularJS, evitiamo di usarlo per il futuro”.

Conclusioni

Riprendendo quanto scritto all’inizio, non esiste uno stack tecnologico giusto, come non esiste un pattern valido da seguire per scegliere lo stack corretto. Si possono e si devono fare analisi in base alla propria situazione, selezionare un sottoinsieme di requisiti non funzionali e in base a questi fare, tra le altre, una scelta dello stack tecnologico.

Riferimenti

• Video dell’intervento
• Slide del talk “Come scegliere il tuo prossimo stack tecnologico”
• Elevator pitch
• SWOT analysis
• Trade-off sliders