Tu non fai la differenza

Come nasce un software? Facile. Lo scrive un programmatore, appunto, programmando. È quindi il programmatore che fa la differenza se il software è buono o meno. Giusto? Io rispondevo sì finché non ho letto quest’articolo su un gruppo software della NASA.

Non siamo noi programmatori che facciamo la differenza.

È il processo.

È il processo che crea un software, che decide come il software deve fare qualcosa, che ne scova i bug e che è pensato per migliorare continuamente. Le persone sono degli esecutori di un processo. Il software sarà buono tanto quanto lo è il processo. Il software e la numerosità dei suoi difetti sono rispettivamente l’output e la misura della qualità del processo.

Le persone non devono essere creative quando scrivono software, devono essere creative nel pensare un processo.

Può essere un punto di vista che annienta il nostro ego, il nostro sentirci creativi e potenti quando programmiamo: almeno in parte io mi sono sentito così. Ma noi programmatori dobbiamo smetterla di pensare che è tutto merito nostro. Non facciamo la differenza e il codice che scriviamo è pieno di bug. Perciò dobbiamo pensare e contribuire a un processo che ci salvi dai nostri stessi errori, che li prevenga e che tuteli l’intero team di sviluppo. È questa la differenza tra chi fa software “tanto per” e chi lo fa seriamente.

Un appunto. Il gruppo di sviluppo del software per il sistema di bordo dello Shuttle non fa le nottate a programmare. Iniziano alle 9 della mattina e finiscono alle 17, gli straordinari sono rari. Sono persone normalissime con famiglia e figli. Magari con 8 lauree e 2 Phd ma a parte questo sono l’antitesi dell’hacker o del programmatore che i media ci propinano. E loro scrivono software perfetto.

Advertisements

Strive for tests

Testing “hard” things is tough because you have to build them to test them,
which discourages speculative building just to see what will happen. But the
building process in software is ridiculously cheap. We’ve developed an entire
ecosystem of tools that make it easy to do just that: unit testing, mock objects,
test harnesses, and lots of other stuff. Other engineers would love to be able
to build something and test it under realistic conditions. As software developers,
we should embrace testing as the primary (but not the only) verification
mechanism for software. Rather than waiting for some sort of calculus for
software, we already have the tools at our disposal to ensure good engineering
practices. Viewed in this light, we now have ammunition against managers
who tell us “we don’t have time to test.” A bridge builder would never hear
from his boss, “Don’t bother doing structural analysis on that building—we
have a tight deadline.” The recognition that testing is indeed the path to reproducibility
and quality in software allows us as developers to push back on
arguments against it as professionally irresponsible.
Testing takes time, just like structural analysis takes time. Both activities ensure
the quality of the end product. It’s time for software developers to take up the
mantle of responsibility for what they produce. Testing alone isn’t sufficient,
but it is necessary. Testing is the engineering rigor of software development.

-Neal Ford

da “97 things every programmer should know” – O’Reilly

Game over

Ci sono cose che si progetti che partono e che prendono vita e ce ne sono altri che falliscono.

xqr7A

Se tutti i progetti si concludessero con successo credo che non ci sarebbe gloria nel riuscire a portarli a termine perché non si avrebbe il confronto con gli stati d’animo, le sensazioni e le conseguenze che un progetto fallito porta con sé.

Un po’ come dire che non c’è buio senza la luce. O era il viceversa? Insomma, avete capito l’antifona.

La differenza la fa chi riesce a fare tesoro di quello che un progetto fallito ci insegna sotto tutti i punti di vista possibili: di business, economico e tecnico.

Sperando di non vederne comunque troppi di progetti così.

Candidàti

Ultimamente mi ritrovo a fare più colloqui di quello che avrei mai creduto, soprattutto dalla parte dell’intervistatore. Così mi sono documentato su come poter svolgere una selezione tecnica dei candidati e ho fatto una fusione con ciò che il mio istinto mi dice. Non sono assolutamente un professionista in questo ambito, quello che segue è il mio metodo ed è sicuramente da migliorare. Fino poco tempo fa non facevo fare alcuna prova tecnica, che mancanza!

Quello che cerco è la passione. Perché se nel tempo libero il candidato si mette a studiare Swift o a svolgere code kata invece di [inserire attività più social qui], allora la programmazione piace davvero e il lavoro per cui si è presentato non è un ripiego; allora stare al passo coi tempi e studiare framework, librerie e quant’altro non sarà mai un problema e non sarà una persona che si fossilizza tecnologicamente.

Quello che cerco è velocità. Perché se qualcuno sa maneggiare i problemi di base che gli sottopongo con rapidità e scioltezza allora ho speranze che possa cavarsela con quelli complessi. Perché il mondo del software sul lavoro è ben diverso dalla preparazione che ci viene data durante il percorso di studi qui in Italia (almeno per la mia esperienza). Il software con cui dobbiamo lavorare tutti i giorni è complesso, scritto così così e con poca documentazione. Con i concetti base il candidato dovrebbe scrivere su carta e penna quasi alla velocità con qui vi sta spiegando il ragionamento che gli frulla in testa.

Quello che cerco è capacità di concludere le cose. Perché a un certo punto il mondo del codice elegante, raffinato e bla bla è bello ma il troppo stroppia (come si dice dalle mie parti). A un certo punto bisogna saper scegliere il giusto compromesso e consegnare quella dannata feature. Bisogna venirne fuori da documentazione imprecisa e requisiti ambigui. Bisogna concludere, stringere le viti e consegnare. E allora non bisogna avere paura di usare il martello e battere tanti tasti e scrivere quel dannato codice anche se non come vorremmo. Per questo chiedo di esperienze passate magari problematiche e chiedo come se ne è usciti.

Quali sono le vostre esperienze con i colloqui sia da una che dall’altra parte della scrivania? Come capite se chi avete davanti può essere d’aiuto o si rivelerà un peso per la squadra?

WPF modificare i menù in base al componente attivo

Durante l’aggiunta di funzioni a un’applicazione che sviluppiamo in azienda mi ero accorto che era giunto il momento di un pesante refactoring sulla gestione delle voci di menù. È così nata l’esigenza di poter modificare le funzioni esposte all’utente contestualizzandole sugli elementi attivi scrivendo le minori cablature possibile nel codice. L’obiettivo era quello di realizzare in maniera semplice il concetto che vediamo in Microsoft Word quando selezioniamo per esempio una tabella: subito in alto compare la zona del menù “Strumenti Tabella”.

image

Per spiegare i concetti su come ho implementato la mia versione ho realizzato un esempio di un’app WPF (scaricabile qui) che, tramite l’uso di UserControl e un po’ di System.Reflection, è in grado di modificare una zona della UI per offrire all’utente le funzionalità dello specifico UserControl. È un’implementazione all’acqua di rose del concetto di plug-in per cui farò altri esempi più avanti.

compo

La MainWindows è una semplice shell che contiene un menù con 3 voci.

image

Component 1 richiama il primo componente e lo aggancia sotto al menù.

Component 2 richiama il componente numero 2 e lo aggancia.

La voce “selected component options” si costruisce dinamicamente in base al componente attivo mostrando le sue specifiche opzioni.

image

image

Il meccanismo si basa su due cose:

  1. I componenti che ho realizzato (le classi Component1 e Component2) ereditano da UserControl;
  2. Un Attribute custom chiamato ComponentFunctionAttribute da utilizzare sui metodi che i componenti vogliono rendere disponibili alla shell che li ospita: in questo caso MainWindow.

Ecco che il code behind di Component1 e Component2 diviene:

image

image

In questo modo gli UserControl con questo Attribute etichettano i metodi che vogliono esperre alla shell.

Il codice di ComponentFunctionAttribute è:

image

(per le Guidelines sugli Attribute rimando a MSDN)

A questo punto alla shell non resta che cercare che cosa espone un determinato componente e disegnare il menù di conseguenza, agganciando le funzioni ai controlli utente che più fanno comodo. In questo esempio a dei MenuItem del menù “Selected component options”.

image

image

Per una stringa di dollari

Ieri stavo scrivendo il milionesimo string.Format della mia vita per comporre del testo da assegnare a una label. Dico ad alta voce  mentre digito “string punto format” e un collega che è con noi da un mese mi guarda, mi fissa e mi fa: “Ma tu conosci le stringhe col dollaro?”. Lo guardo un po’ strano e dico di no. Allora viene alla mia scrivania e mi mostra qualcosa del tipo:

image

Fantastico! Inoltre Visual Studio riconosce gli oggetti dentro le graffe in tutto e per tutto quindi anche nelle procedure di refactoring con F2. Il risultato è ovviamente questo:

image

Quando qualcuno mi insegna qualcosa, anche di così piccolo, mi fa riflettere quanto un team eterogeneo che funziona si trasmetta le conoscenze, quanto la diversa formazione ed esperienza lavorativa ci porti al confronto continuo. Il risultato è grandioso.

Striking the Kanban bargain

Kanban richiede al team di sviluppo software di negoziare diversamente con i suoi business partner. Perché? Perché di solito la gestione di un progetto fa promesse basate su: obiettivi, tempistiche e budget. Dopo un processo di stima e di pianificazione, vengono assegnati un budget, delle risorse, un insieme di requisiti e la pianificazione è decisa a priori.

Kanban negozia in maniera diversa. Kanban non pretende di fare una promessa basata su qualcosa deciso a priori che è molto probabile che nel tempo cambierà. La tipica implementazione Kanban include degli accordi che ci sarà un regolare rilascio di software funzionante, probabilmente ogni due settimane. Agli esterni interessati viene offerta completa trasparenza sul funzionamento del processo e, se vogliono, visibilità giornaliera dei progressi. Allo stesso modo viene offerta l’opportunità di selezionare le attività più importanti da sviluppare. La frequenza di questo processo di selezione è probabilmente più frequente di quella del rilascio – tipicamente una volta a settimana.

Il team offre di fare un ottimo lavoro e rilasciare la più grande quantità di software funzionante possibile. Offre di fare miglioramenti continui per migliorare la quantità e la rapidità di rilascio.

Kanban non offre un impegno basato su una certa quantità di lavoro rilasciata un certo giorno; offre una promessa rispetto i service-level-agreement per ogni classe di servizio. Il tutto è sostenuto da un impegno a rilasci regolari, trasparenza, flessibilità e lead time ridotti. Un sistema kanban che funziona correttamente mantiene un impegno alle attività che creano vero valore per il cliente. In cambio, il team chiede una relazione a lungo termine in cui il team di sviluppo si sforza costantemente di migliorare il livello di servizio.

Il tradizionale approccio della consegna con obiettivi prefissati, scadenze e budget è indicativo di un rapporto “una volta e via”. Implica che non c’è relazione con i business partner, implica un livello di fiducia basso.

L’approccio Kanban è basato sulla nozione che il team starà insieme e avrà una relazione a lungo termine con i propri business-partner.

Traduzione della sezione “Striking the Kanban bargain” di “Kanban” di David J. Andreson.

image