Monthly Archives: November 2016

Strumenti di produttività

Leave a reply

E così capita che la nostra macchinetta Nespresso smette di forare le cialde nel bel mezzo della giornata lavorativa. Prova, riprova ma niente da fare. Non ne vuole più sapere.
Interviene il CEO che era in coda anche lui per prendere il caffé e dopo l’ultimo tentativo dichiara: “Ok! È rotta!”. Con risolutezza si avvia verso il suo ufficio, apre l’anta di un mobiletto, ci entra dentro con testa e spalle, sposta un paio di scatole e tira fuori una Nespresso nuova di pacca che nessuno sapeva ci fosse: “Ecco qua! Avanti coi caffè!”

Mai lasciare i programmatori senza lo strumento di produttività numero uno!

Archivio ma non troppo

Leave a reply

Avevo la necessità di scrivere un test per il metodo Acquisisci() di una classe per la l’importazione di alcuni file di testo. Questo metodo al suo interno esegue, in pseudocodice:

…

Importa(file); //Legge il file e salva il suo contenuto nel db.

Archivia(file); //Sposta il file in una cartella di archivio.

…

Il mio scopo nello scrivere il test era quello di evitare l’istruzione Archivia(file) per poter lanciare ripetutamente i test senza dover rimettere i file nella posizione originale ogni volta.

Così ho ereditato dalla classe di Acquisizione come segue

http://pastebin.com/embed_iframe/bJNMrhEf

e poi il test è diventato qualcosa del tipo:

http://pastebin.com/embed_js/bJNMrhEf

In questo modo sono riuscito a scrivere un test ripetibile senza dover modificare la classe sotto test.

Categorie

Leave a reply

In vari blog, testi o letture sparse per il web spesso trovo il termine “line of business software”, “enterprise-grade software”, “business application” e così via. Non ho mai trovato però una spiegazione che mi convincesse riguardo queste categorie di software.

Nel libro “Release It!” Michael T. Nygard dice qualcosa come:

Un software è una business application se quando il software ha problemi le persone che lo usano non possono più lavorare e ricevi telefonate anche di notte.

Finalmente una definizione convincente! Adoro queste definizioni che hanno un riscontro tangibile e pratico. Talmente tangibile che allora anch’io sono tra quelli che sviluppano business applications.

La pratica rende permanente

Leave a reply

Io ho sempre sentito dire che la pratica rende perfetti ma Sergio Borra la pensa diversamente e nel suo video “Il ciclo di miglioramento delle performance” lo spiega chiaramente.

È un concetto generale applicabile a ogni livello nella quotidianità. Vogliamo adottare una nuova procedura in ufficio? Un nuovo metodo di lavoro? Una best practice? Un nuovo modo di relazionarci con i nostri cari? Allora sarà necessario applicarsi decine e decine di volte prima che diventi routine e pratica consolidata. Chi fa arti marziali ripete migliaia di volte gli stessi gesti per farli diventare memoria muscolare. Chi studia musica ripete migliaia di volte scale / arpeggi per imprimerli nel cervello come gesti naturali. Tutto ciò però nasconde un tranello. La ripetizione rende permanente anche le pratiche sbagliate. Ed è proprio così che nascono le cattive abitudini, difficilissime da sradicare.

C’è chi dice: “Una volta è nessuna volta.” Mio padre dice: “Per cambiare abitudine basta prendere una nuova abitudine”. E cambiare le mie abitudini ho scoperto essere un arduo compito. L’abitudine, la ruotine, la tranquillità della ripetizione di ciò che già faccio è una barriera da sconfiggere.

Il mio strumento principale per aiutarmi a cambiare abitudine è il post-it. Post-it strategici. Appiccico qualche piccolo post-it in posti che visito spesso. Il mio preferito è un piccolo post-it appena sotto lo schermo del portatile che uso per lavoro. Un gentile promemoria che mi ricorda cosa devo o non devo fare.

Voi come cercate di cambiare le vostre abitudini? Che strumenti usate?

Tempo di attesa

Leave a reply

Perché è necessario visualizzare il lavoro e controllare il WIP? Per questo semplice motivo.

Se lavoro 50% del mio tempo si ha che sono libero il 50% del mio tempo. Dato che la definizione di tempo di attesa è data da % tempo occupato / % tempo libero ottengo che => 50% / 50% = 1 unità di tempo è il mio wait time come risorsa se sono occupato al 50%.

Se lavoro il 90% del mio tempo si ha che: 90 / 10 = 9 unità.

Attenzione al punto dell’80%! Da lì in poi si vola all’infinito e oltre!

clip_image004

Se definiamo la nostra unità di tempo come 1h abbiamo che quando chiediamo qualcosa a qualcuno che è impegnato (o libero) al 50% ci impiegherà 1h per prendere in mano la questione. Se la chiediamo a qualcuno che è occupato al 90% ci impiegherà 9h per dedicarsi al nostro problema. Un incremento del 40% del lavoro porta a moltiplicare per 9 il nostro tempo di attesa. Se supponiamo che la nostra richiesta a tale persona/risorsa sia per 1h di lavoro abbiamo che la percentuale di tempo a valore aggiunto (o touch time) è del 10%!

1 ora di lavoro  / (9 ore di attesa + 1 ora di lavoro) = 1h / 10h => 10 %

Per me questo grafico è disarmante per la sua semplicità e per quanto apra gli occhi sull’avere tutte le persone coinvolte in un processo sempre cariche di lavoro.
Pensiamo a un processo che coinvolge due sole persone per un’ora ciascuna e che entrambe siano occupate al 90%. Ottengo che per un lavoro di 2 ore uomo ci vogliono 20 ore di attesa.

Avete mai ragionato su tematiche simili? Qual è la vostra esperienza sui tempi di attesa e quali sono le tecniche che usate per ridurli?

Le tre vie

Leave a reply

Archivio qui degli appunti che avevo preso per sintetizzare un po’ di concetti appresi dopo la lettura di The Phoenix Project.

Vengono elencati e brevemente spiegati tre principi cardine che sono alla base del DevOps. Per me DevOps è un termine un po’ troppo inflazionato: qualcosa che fa figo dire adesso perché va di moda. Restano comunque validi i principi enunciati e le pratiche esposte.

La prima via – il flusso

Riguarda il flusso di lavoro da sinistra a destra dal dipartimento Development alle IT Operations al cliente finale.
Per massimizzare il flusso bisogna ridurre le dimensioni dei batch e gli intervalli di lavoro, evitando di passare difetti ai centri di lavoro successivi.
Bisogna ottimizzare per obiettivi globali, non locali per reparto.

Le pratiche necessarie richiedono: continuous build, integration and deployment; creazione di ambienti a richiesta; limitare il WIP; costruire sistemi che sono sicuri e facili da cambiare.

La seconda via – i feedback

Riguarda il costante flusso di feedback da destra a sinistra, in tutti gli stadi del flusso del valore.
Amplificare i feedback per assicurarci di imparare dagli errori (e non ripeterli!). Migliorare i processi di raccolta feedback. Facendo questo si migliora la qualità alla fonte (o dove serve).

Le pratiche necessarie includono “fermare la linea di produzione” quando le build o i test falliscono. Impegnarsi costantemente per migliorare il lavoro oltre che lavorare. Creare test suite automatiche e rapide; creare telemetrie per ambienti di produzione.

La terza via – cultura

Creare una cultura che favorisca: sperimentazione continua che richiede prendere rischi e imparare dai successi e dai fallimenti; capire che ripetere e fare pratica è il prerequisito per la maestria. Rischiare permette di migliorare il nostro modo di lavorare, richiede spesso di fare cose diversamente da come la stiamo facendo da decenni. Il non cambiare non porta a una situazione piatta, ma di declino, perché interviene l’entropia.

Le pratiche necessarie includono creare una cultura orientata all’innovazione e al rischio (in maniera opposta alla paura o al “accettare ordini” senza pensarci); allocare almeno il 20% del tempo ai requisiti non funzionali; costantemente ricordare che i miglioramenti sono incoraggiati e celebrati.

Inferno

Leave a reply

L’inferno esiste.

Per noi programmatori ce ne sono di due tipi, anzi. Il dll-hell e il merge-hell.

Il primo l’ho raramente sperimentato mentre di recente sono rimasto scottato dal secondo. Un paio di branch avevano preso la tangente da qualche mese rispetto al master ed era giunto il momento di prendere il coraggio a piene mani e farlo tornare a casa con un bel merge. Si salvi chi può.

Cosa mai potrebbe andare storto, fa tutto git! Sì sì, certo… Preparatevi a:

  • Risolvere conflitti di pezzi di codice che non avete scritto voi;
  • Mantenere inalterate le funzionalità;
  • Gestire problemi sui file .resx in particolare per le stringhe e la localizzazione;
  • Inveire contro i comandi di git;
  • Una combinazione di tutte le precedenti.

Sono quelle cose che leggi e poi dici: “ah ma tanto a me non capita! Il mio è un progetto piccolo e poi cosa vuoi avrò toccato un paio di classi in quel branch.”. E invece!

P.S.: mi permetto di dare un piccolo consiglio. Fatelo in coppia. In questi casi il pair programming vince a mani basse per quanto mi riguarda!

Software rot

Leave a reply

Il software rot è un lento e inesorabile deterioramento delle performance di un sistema software con l’avanzare del tempo (parafrasando un po’ Wikipedia).

1369

La macchina virtuale che uso per sviluppo da una settimana a questa parte ogni tanto ha dei rallentamenti spaventosi che durano un paio di minuti, CPU a bomba senza apparente motivo.

Nell’iPhone ogni tanto non riesco a rispondere a una chiamata perché lo swipe per la risposta non viene percepito.

Quando spengo Windows 10 ogni tanto esce un errore di Virtual Box durante lo shutdown.

Ma qual è la causa del bit rot? Secondo il papero è questa:

Il bit rot è figlio del peccato originale del software: tutto il software viene rilasciato in maniera consapevolmente bacata. La madre del bit rot è l’impossibilità di testare gli aggiornamenti successivi come si può fare con i cosidetti golden bits, fotografia di un istante lungo quanto la durata di una build.

Nel momento in cui si aggiunge qualcosa a quei dannati bits si perde la speranza di avere un’idea per se già estremamente vaga della stabilità del sistema.

Qual è la vostra esperienza di calo di prestazioni di un software? Dove lo notate di più? Dove di meno?

Piccoli momenti di gioia

Leave a reply

Ci sono quei momenti in cui ritrovi del codice che hai scritto che ti rende contento.

Di solito sono convinto che tutto quello scrivo sia a un livello compreso tra il pavimento e la polvere. A volte, rare, riscopro dei pezzi di qualcosa che ho scritto, una classe, una gestione degli errori, dei commenti che mi fanno dire: “Ah ah! Allora a volte qualcosa di buono faccio!”. È come darsi una pacca sulle spalle da soli, me ne rendo conto.

Mi è capitato ieri di essere contento per un componente che avevo scritto che con poche righe faceva ciò che volevo senza troppe complicazioni. Era là sepolto da anni e mi ha fatto riscoprire alcune cose.

A voi capita mai di riscoprire vecchie classi dimenticate? Pezzi di codice utili che voi stessi avete fatto e dimenticato?

Il vero orrore di Halloween l’hai scritto tu

1 Reply

Per quanto mi riguarda mi basta andare indietro anche di 5 mesi. 5 giorni, lo ammetto, sarebbe un po’ troppo grave.

Untitled

Penso che rendersi conto dei nostri orrori del passato sia già un primo passo per sconfiggere il peggior nemico di sempre e fare un po’ meno schifo ogni giorno. Sarà che questo è uno di quei momenti ciclici in cui credo che tutto quello che scrivo faccia pietà e che non sappia progettare 2 classi in croce.

A voi capitano mai questi periodi? Come reagite? Come ne uscite?