Strategie

Via Whatsapp, Lunedì mattino¶

9:21, io:

Le convenzioni e le modalità con le quali due persone sono felici assieme non hanno bisogno dell’approvazione sociale. Non è la mia vita privata o la supposta qualità di vita privata che devi giudicare, ma solo gli aspetti professionali. Forse hai l’impressione che io abbia problemi comunicativi per una insoddisfazione a livello relazionale, ma ci sono aspetti tecnici comunicativi a cui dai poco peso ed importanza, e questi generano conflitti continui.
In qualche maniera ti rifiuti di riconoscerli, e lo hai sempre fatto, quando consiglio un libro come Domain Driven Design, che è piuttosto palloso e difficile da leggere, è perché evidenza quanto sia palloso e difficile interagire tra chi approccia la soluzione dal punto di vista della logica di business, e chi approccia la soluzione dal punto di vista implementativo.
Pensare che logica di business e architettura del sistema siano perfettamente sovrapponibili è la cosa più semplice da farsi, la cosa che sembra più semplice da mantenere, la cosa che sembra più semplice ed efficace da implementare.

Eric Evans ha scritto circa 500 pagine di testo per spiegare un caso studio per una applicazione bancaria, ambito nel quale gli errori nel software non sono ammessi, e la consistenza dei dati è critica.

Ha scritto 500 pagine, ma nonostante tutto non si capisce esattamente di cosa parla. Fino a che non ci si scontra con un problema simile. In realtà, con molti problemi simili.

Ogni volta che hai una necessità, una funzionalità, un’idea, quell’idea è ragionata secondo le logiche di business, e non secondo le logiche implementative, che emergono solo durante l’implementazione della soluzione.

Inoltre c’è una necessità contingente, che è quella di poter andare a modificare alcune parti del sistema, in isolamento. Questo concetto sembra che sfugga completamente a tutti in azienda. Scrivere microservizi, scrivere classi separate con responsabilità definite, e tutta questa roba, serve a poter garantire l’implementazione veloce di nuove funzionalità, per poter garantire l’analisi veloce dei problemi, per poter allungare la vita ad ogni singolo modulo (microservizio o classe). In sostanza serve per rispondere più prontamente al mercato, e mantenere al tempo stesso stabilità.

Visto che la logica di business non coincide esattamente con l’architettura che la implementa, quando si riportano problemi, è sempre richiesto che si riportino gli eventi, e non la spiegazione. Questo per 2 ragioni: la spiegazione potrebbe non essere esatta, e si perde la sequenza degli eventi. C’è una terza ragione: la revisione e il refactoring dell’architettura. Sì, perché alcuni approcci sensati dal punto di vista della business logic, non lo sono implementativamente, e questo può emergere anche dagli eventi anomali. In sostanza l’evento anomalo (bug) evidenza delle carenze architetturali, ma solo se l’evento è descritto per quello che è, non per la spiegazione che gli si da. Altrimenti bisogna fare tutto un lavoro di indagine aggiuntiva.

Quando mi siedo per programmare, spesso è dopo un duro allenamento, quindi l’ultima cosa che voglio è disturbare gli altri, voglio che questa attività sia rilassante come la percepisco io: mi siedo, progetto, e scrivo codice. Evito e automatizzo tutto ciò che è ripetitivo, tolgo la parte noiosa, e mi concentro sulla soluzione.

Solo che, come ho cercato di spiegare, logica di business e soluzione architetturale non sempre coincidono. E questo è un valore per la capacità del sistema di rispondere alle richieste di mercato, ma è una cosa grossolanamente ignorata e svalutata.

Anche il vocabolario della logica di business ed il vocabolario della logica architetturale, non sempre coincidono.

Persino l’organizzazione del database, non è necessariamente coincidente con la logica di business.

Non scambiamo valori per disvalori semplicemente perché non sono facilmente apprezzati senza un’adeguata analisi e confronto con altre realtà. Considera che è la stessa cosa in ambito bancario, quindi non è che vado altrove e trovo meglio, probabilmente vado altrove e trovo colleghi che già vivono questo conflitto, oppure una cultura aziendale condivisa che riconosce questa discrepanza di vocabolari e la percepisce come valore.

Ogni valore ha un costo, ovviamente, ma cancellare un vocabolario, come suggerisci tu, Chris, e anche un po’ Gunter, senza neanche averlo aperto, mi sembra una idea piuttosto approssimativa ed affrettata. E il vocabolario non è docker help, il vocabolario sono le varie architetture, i moduli, le classi definite, i pattern utilizzati nei singoli micro servizi, l’uso che viene fatto del message broker, e via dicendo.

9:29, io:

quick&dirty non è solo sporco e veloce, ma rompe e annulla questo valore, le modifiche fatto per soddisfare velocemente qualcuno, non tengono conto di altre logiche adottate, e di conseguenza l’obiettivo di avere un sistema facilmente modificabile, controllabile, consistente, e che risponda velocemente alle richieste di cambiamento è sabotato.
Quick&dirty è solamente dirty&destructive.
Per di più, non è affatto detto che rispondere velocemente alla richiesta del cliente sia un valore: se mostri che quello che chiede può essere soddisfatto immediatamente, il valore che percepisce il cliente è che quella cosa è semplice e di poco valore, ci vuole poco sforzo, vale poco.

10:21, io:

500 euro, ma in realtà sono molte di più quelle che butteresti