La cosa più importante

Durante il Forex ho avuto l'occasione di scambiare quattro chiacchiere con una persona di una azienda la cui offerta è in parziale sovrapposizione con quella della mia (insomma un concorrente). Parlavamo dei problemi che incontramo nel nostro lavoro quotidiano visto che ci occupiamo delle stesse cose. Molto gentilmente mi ha spiegato cosa loro stanno facendo per migliorare il loro processo produttivo, con alcuni spunti interessanti, tipo uso di indicatori e di indici per misurare il lavoro; ad un certo punto mi ha chiesto:

"Qual'e' la prima cosa che pensi vada affrontata dal tuo punto di vista?"

Non ci ho pensato, ho risposto immediatamente, di getto perché mi ero già fatto questa domanda, la mia risposta non era ancora chiara nella mia mente fino a quell'istante. La mia parte di cervello verbale (L-mode) ha subito approfittato del lavoro svolto in background dalla parte creativa (R-Mode) e la mia risposta è stata:

"La motivazione delle persone"

Il mio interlocutore, probabilmente, non si aspettava quella risposta e ha subito ricondotto il discorso verso la sua zona di comfort.

La mia risposta era in realtà ancora incompleta, ora risponderei:

"La motivazione delle persone nel migliorarsi"

Sono certo che questa sia la prima cosa che non vedo (abbastanza) intorno a me, ma è la più importante.
Le persone con cui lavoro sono in grado di affrontare e risolvere problemi complessi e in poco tempo molto meglio di me; alcuni riescono a produrre quantità di codice sufficientemente corretto in tempi incredibili: sono veramente da ammirare. Ma affrontano i problemi a testa bassa uno dopo l'altro.

E quindi per migliorare il processo produttivo, ma non solo, occorre alzare la testa, e non basta che uno solo la alzi, occorre creare e sviluppare la motivazione al miglioramento in tutte le figure professionali.
Migliorare non vuol dire imparare cose nuove o usare nuove tecnologie, aspetto comunque fondamentale del nostro lavoro, ma soprattutto osservarsi e chiedersi come sia possibile usare i propri strumenti al meglio e il cervello è il primo strumento del nostro lavoro, prima dei tool, dei linguaggi e delle tecnologie e di tutte le buzzword che ci bombardano.

Migliorarsi è faticoso, la motivazione al miglioramento non può essere imposta proprio perché è prima di tutto personale, ma se un gruppo può contare su persone che vogliono migliorare è impossibile che il gruppo non migliori.

La motivazione nel migliorarsi è per me la cosa più importante.

Clean Code

Ho cominciato a leggere Clean Code. Già solo l'introduzione e il primo capitolo valgono il prezzo del libro. Non vedo l'ora di continuare a leggerlo.

DRY vs Security

Quando si parla di siti web e security é facile rischiare di essere superficiali o farsi prendere dal panico. A me almeno é capitato. La superficialità ci porta ad esempio a pensare che i tool o i framework ci mettano al riparo dai problemi; il panico ci porta all' overengineering. Il risultato é comunque negativo.
Per rispondere coerentemente é necessario coltivare comunque la propria conoscenza; questo non rende il nostro software sicuro in assoluto, beato chi ci riesce, ma ci permette di guardare al problema obiettivamente identificando strategie e principi che minimizzino le attack surface.
L'anno scorso mi é stato consigliato un libro illuminante in tal senso (Ajax Security). Consiglio a chi ha qualche dubbio di dare una occhiata a questo testo, scoprirà come le paure sono fondate, ma anche che un approccio sistematico all'argomento é fondamentale per ottenere buoni risultati.

Programmare orientati alla sicurezza può portare però a violare altri principi di buona programmazione, un esempio che ho vissuto riguarda il DRY. Il principio DRY é in contrasto con un approccio tipo defence in depth (DID). Sequendo questo principio ad esempio la sicurezza di ogni layer non può e non deve essere mai delegata ad altri (someone else's problem). La ridondanza, e la duplicazione dei controlli sono quindi un effetto voluto usando un approccio DID. Nella mia esperienza ho adottato un principio importante "Validate Early Validate Often" (VEVO). Ogni layer all'interno del sistema é responsabile della validazione dei parametri che riceve, secondo le sue conoscenze e i suoi scopi. Ovviamente questa non é una risposta ai problemi di sicurezza ma un approccio alla defence in depth.

Usando un approccio VEVO e costringendo i membri del team a identificare percorsi diversi alla validazione dei dati, mi sono però scontrato con una certa resistenza dovuta alla duplicazione di logica di validazione, in pratica c'era che si opponeva all'approccio dando come giustificazione il mancato rispetto del principio DRY. Eppure anche quando si parla del principio DRY ( vale anche per Separation of Concers e Once And Only Once), occorre valutare attentamente se esistono dei requisiti in contrasto; a mio parere se la sicurezza é un requisito é possibile che si debbano sacrificare altri principi in suo onore.