Sul “Design by committee” (antipattern)…

Qualche giorno fa ho avuto un piacevole scambio di opinioni con un conoscente sul tema di prendere le decisioni giuste pur tenendo conto delle varie opinioni “del popolo”.

Pur lavorando lui in un ambito differente dal mio, sentendolo parlare non ho potuto che concordare con il suo ragionamento che in sostanza si riassume in:

“E’ giusto sentire tutte le parti coinvolte in un dato contesto. E’ giusto tener conto delle loro richieste, suggerimenti e critiche. Tuttavia alla fine bisogna decidere e qualcuno deve imporre la sua soluzione, sapendo benissimo che con tutta probabilità causerà panico, sgomento e fastidio in qualcuno.”

Dopotutto, così come non si può piacere a tutti, la stessa cosa vale per le decisioni prese da qualcuno.

Il primo problema delle decisioni è che vanno prese e non se ne può diversamente fare a meno: temporeggiare, procrastinare, rinviare a tempo indefinito o fare finta che qualcosa non esista raramente è una buona scelta perchè i problemi tendono comunque a ripresentarsi ciclicamente.

Il secondo è che chi le prende se ne deve assumere la responsabilità sapendo spesso di giocare d’azzardo, a meno che non sia un aruspice, un indovino o simile.

Il terzo è come limitare l’impatto di tutte le persone coinvolte nella decisione che, se interpellate, porteranno magari un valido contributo alla discussione ma anche certamente un terribile rumore di fondo che impedisce di arrivare a qualcosa di concreto e accettabile.

In ambito sviluppo questo tipo di infausta situazione in cui più persone, spesso con idee molto contrastanti, “partoriscono” infine una decisione tecnica raffazzonata o arrivano ad un prodotto qualitativamente scarso viene indicata come “design by committee“: si tratta di un antipattern e, come tale, è qualcosa da evitare assolutamente.

A camel is a horse designed by committee

Questo è uno scherzoso esempio di quello che può arrivare a creare un “comitato” (immagine tratta dal bel post “Design By Committee: A Designers Worst Nightmare!“): molto divertente, almeno quanto preoccupante.

Wikipedia mette in chiaro benissimo cosa sia e da cosa muova il “design by committee“:

“Design by committee is a term referring to a style of design and its resultant output when a group of entities comes together to produce something (often the design of technological systems or standards), particularly in the presence of poor leadership.

The defining characteristics of “design by committee” are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision.

The term is especially common in technical parlance, and it legitimizes the need and general acceptance of a unique systems architect. Often, when software is designed by a committee, the original motivation, specifications and technical criteria take a backseat and poor choices may be made merely to appease the egos of several individual committee members. Such products and standards end up doing too many things or having parts that fit together poorly (because the entities who produced those parts were unaware of each other’s requirements for a good fit).”

Ecco il punto: mancanza di una visione unificante spesso dovuta all’ego smisurato dei partecipanti, ognuno dei quali, per una questione di prestigio e di principio, vuole concorrere alle decisioni-chiave così come i suoi “pari” o inferiori: “il progetto è mio quanto loro (se non di più)“.

In altri casi è semplicemente la volontà di mettere tutti d’accordo e non scontentare nessuno a portare a risultati imbarazzanti e raccapriccianti. Un esempio abituale si verifica quando si dà troppa voce in capitolo, in ambito squisitamente tecnico, a dei clienti che tecnici non sono. Nel provare ad accontentarli comunque (“il cliente ha sempre ragione!”) può capitare di dover rivedere e sconvolgere tutti i piani per poter inserire in qualche modo anche quella cosa che il cliente desidera. Spesso un “no” detto al momento giusto e nel modo corretto significa salvare i progetti dagli stessi committenti.

Infine, ma non meno importante, il caso dei veri committee che si trovano a dover standardizzare qualcosa, ad esempio un linguaggio di programmazione, partendo dalla volontà di trovare il minimo comune denominatore di molte, troppe implementazioni già esistenti. Nell’impossibilità di porre dei limiti si finisce a creare standard, come quello C, in cui buona parte delle pagine di fatto non ordina nulla, ma lascia spesso alla specifica implementazione il compito di decidere il da farsi. Qualcuno potrebbe dire che hanno standardizzato il “farsi gli affari propri, così come si vuole“.

Come evitarlo?

Wikipedia di fatto ha già fornito una soluzione al problema di come evitare i “design by committee“: serve una leadership chiara e concreta che prenda le decisioni, nel caso imponendole. Questo è il concetto di unificante: in mancanza di concordia di intenti, qualcuno deve ergersi e decidere, assumendosi tutte le responsabilità del caso.

Tuttavia non sempre c’è questa possibilità per cui l’ideale è minimizzare al massimo il numero degli attori coinvolti (“stakeholders”), in modo da minimizzare anche la necessità di compromesso. Insomma evitare il “committee” e, se proprio, puntare allo “smallest interest group” per un dato progetto.

Se anche questo non è possibile o non dà i frutti sperati, vale la pena provare a stabilire in modo ancora più rigoroso le priorità, in modo che le cose irrilevanti (e spesso potenzialmente distruttive rispetto all’armonia dell’insieme) scivolino in fondo e, si spera, finiscano nel dimenticatoio.

Infine c’è sempre una specie di refactoring del progetto, ma si tratta di una scelta dura perchè significa, anche solo potenzialmente, dover rimettere in discussione scelte e compromessi già dati per acquisiti. In determinati casi, per esempio nell’impossibilità di rifare tutto da capo o di fronte ad un disastro preannunciato, non c’è davvero altra soluzione.

Che ne pensate?