---
disqus: pierodibello
---

###### tags: `design` `italian`

# Costo del cambiamento e design

:::info
Lo scopo del design è quello di rendere basso il costo del cambiamento: il software deve essere facile da cambiare e facile da capire.
:::

Come ci comportiamo quando non è così?
Come cambia il nostro comportamento se cambiare il codice diventa costoso?

### Upfront Design
Di fatto questa è la premessa dell'upfront design: faccio tanto design e analisi prima di iniziare a scrivere il codice perché so che poi modificarlo in corsa sarà difficile. Anticipo tante scelte perché non ho paura che farle dopo mi potrà costare troppo.
Il sogno dell'upfront design è che il momento migliore per prendere decisioni di design è all'inizio del progetto.

Questo assunto si è rivelato falso: l'inizio del progetto è il momento peggiore per assumere tutte le decisioni di design, perché è il momento in cui abbiamo meno informazioni riguardo al sistema da costruire (può sembrare paradossale, ma è così se ci pensate).

### E se il costo del cambiamento fosse basso?
Questo è anche uno dei cardini dei metodi agili e dell'approccio iterativo-incrementale (release early, release often): vogliamo poter cambiare il design del sw nel corso dello sviluppo, per poter accettare e includere le nuove necessità quando emergono e non prima, così da poter costruire veramente un prodotto in base al feedback che riceviamo dal costruirlo e da chi lo usa.
Per fare questo, per poter cambiare il design in corsa, il costo del cambiamento deve essere basso, altrimenti stiamo solo facendo un grosso azzardo.

### Qualche esempio tratto dalla vita quotidiana
Prendiamo degli esempi tratti dalla vita di tutti i giorni: quanto è facile per voi cambiare il vostro operatore telefonico x telefono e internet? E' dannatamente costosto! Mandare raccomandate entro un certo tempo, restituire il router, aspettare che disattivino la linea, poi ti danno un numero temporaneo, poi arriva il nuovo router, che deve essere agganciato (sperando che non dovete anche fare lavori in centralina o in casa vostra).
Come rispondete voi a questo alto costo del cambiamento? Facendo tantissime ricerche e analisi prima di scegliere l'operatore, e cambiandolo solo in casi disperati. Questo è un esempio dove i vincoli ci impongono di anticipare molte valuazioni, di fare "upfront design".
Cosa fareste se fosse possibile cambiare fornitore internet da un giorno all'altro? Provereste diversi fornitori, fareste le vostre valutazioni sul campo e poi decidereste, e cambiereste al volo se mai le condizioni cambiassero.

Pensiamo invece al cambio di operatore di energia elettrica e gas: quanto è difficile cambiare? Meno di quanto non sia con il telefono! In casa mia non cambia niente, ieri l'energia mi veniva fornita da Enel, domani da un altro fornitore. Il costo del cambiamento è più basso, e sono portato a cambiare quindi più facilmente.

Prendiamo un altro esempio: le luci di casa vostra. Cosa dovete fare se non vi piace un punto luce in casa? Comprate una nuova lampada, staccate quella vecchia e attaccate quella nuova... fatto.
Il costo del cambiamento è molto basso, e potete decidere facilmente di cambiare.
Questo perché la lampada (e tutti i nostri elettrodomestici) sono "disaccoppiati" dal modo in cui ricevono energia...

### Costo del cambiamento e flessibilità
Nello sviluppo di prodotti digitali moderni è quindi essenziale tenere basso il costo del cambiamento del sw, per essere in grado di cambiare facilmente senza essere costretti ad anticipare scelte di design che poi potrebbero diventare zavorre che ci frenano invece che renderci agili.
E per abilitare quell'approccio iterativo e incrementale basato sulla raccolta del feedback e sulla scoperta di quello che dobbiamo veramente costruire vs quello che pensavamo avremmo dovuto costruire.

Certamente un prodotto digitale non può rendere tutte le scelte flessibili, non può consentire la variabilità di tutti i suoi aspetti... c'è una scelta di quali aspetti rendere variabili e quali no.
Ad esempio, la nostra lampada ha due evidenti punti di flessibilità: dove attaccarla (grazie alla presa elettrica, posso attaccarla ovunque ci sia una presa) e quale luce fare (grazie all'attacco del bulbo, posso cambiare lampadina facilmente). Ma se volessi ad esempio cambiare il colore del braccio della lampada, non potrei farlo facilmente: probabilmente dovrei buttare via quella che ho e prederne un'altra.

Nessun prodotto può essere variato in tutti i suoi aspetti, e questo vale anche per il design del sw: vanno resi "variabili" quegli aspetti che cambiano più spesso. Questo perché ogni punto di flessibilità ha anche un costo di complessità che renderebbe ingestibile un prodotto con un eccessivo numero di punti di flessibilità (eccessivo rispetto ai suoi reali bisogni, a quello che cambia più frequentemente).

### Come tenere basso il costo del cambiamento?
Quindi, riassumendo: lo scopo del design è tenere basso il costo del cambiamento, altrimenti costruire prodotti software diventa molto difficile e rischiamo di ricadere nell'anticipare tante scelte di design (e peggio ancora, di farle fare ad entità esterne al team di sviluppo).
Per farlo uno dei cardini è quello di individuare i punti di variabilità e rendere lì possibile introdurre nuovi comportamenti idealmente aggiungendo solo nuovo codice senza toccare quello esistente (e qui leggete una forte relazione con OCP).

Ci sono tanti principi utili a tenere basso il costo del cambiamento:
* mettere le cose che cambiano per lo stesso motivo e con la stessa frequenza nello stesso "posto", e tenere separate cose che cambiano per motivi diversi e con frequenze diverse (SRP)
* orientare il verso delle dipendenze in modo che i componenti di basso livello (dettagli) dipendano dai componenti di più alto livello (DIP)
* orientare le dipendenze tra le componenti in modo che componenti più instabili puntino a componenti più stabili
* etc