Recensione “Ship it!”…

Mi ero ripromesso da un bel po’ di tempo di ultimare la lettura di questo libro, consigliatomi da un discreto numero di persone, perfino su Stackoverflow.

Finalmente, approfittando del periodo di ferie e sconfiggendo la pigrizia, sono riuscito nel mio intento, per cui eccovi la tanto attesa recensione di questa breve ma utilissima opera.

Scheda del libro

• Titolo: “Ship it!“
• Sottotitolo: “A Practical Guide to Successful Software Projects“
• Autori: Jared Richardson e Will Gwaltney Jr
• Editore: Pragmatic Bookshelf
• Anno: 2005 (prima edizione americana)
• Lingua: inglese (americano)
• Genere: libro tecnico
• Categoria: metodologie di sviluppo agili
• Argomenti trattati: tecniche di sviluppo pragmatiche, soluzioni a problemi ricorrenti, strumenti di sviluppo
• Pagine: 200
• Prezzo: 20.81€ su Amazon.it
• Pubblico-target: sviluppatori, leader e project manager tecnici

Introduzione

Quest’opera fa parte della serie “The Pragmatic Bookshelf” il cui capostipite, “The Pragmatic Programmer” (recentemente recensito dall’amico Stefano), rappresenta da un decennio e più una pietra miliare nel settore della programmazione.

“Ship It!“, sotto certi punti di vista, rappresenta una sorta di continuazione di quel libro, riprendendone alcuni concetti (es: “Tracer-Bullet Development”) o estendendo il discorso ben oltre l’ambito della programmazione in senso stretto. Tuttavia, per molti altri aspetti, rappresenta un’eccezionale fucina di suggerimenti tanto per migliorare sè stessi, quanto un intero team di sviluppo.

Il titolo, liberamente traducibile in “Consegnalo!” (letteralmente, “Spediscilo!”) rende bene lo scopo, ossia come arrivare a “vedere la luce alla fine del tunnel” dello sviluppo.

Il libro e la materia

Senza ombra di dubbio sono un fan di questa serie: piccoli, compatti, prezioni. Questo libro non è da meno: 200 pagine ricche di consigli, problemi ricorrenti e proposte di soluzione nonchè idee derivate dall’esperienza degli autori.

Niente buzzword, niente prese di posizioni nette per questa o quella metodologia o per questa o quella pratica. Anzi, gli autori esortano a fare l’opposto: nel libro, appendici escluse, non viene pressochè mai citata per nome alcuna metodologia. Eppure, leggendolo, non si fa fatica a capire da dove derivino certe idee. Gli autori non ne fanno mistero:

“Some of these ideas have been blatantly lifted from well-known software methodologies, and we’ve tried to give credit where it’s due. Other ideas were forged from blood, sweat, and tears. We’ve experimented with many tools, techniques, and best practices, and when something worked, we kept it.

When it flopped, we tossed it. Very little you will see here is blindingly original (this is a Good Thing). Instead, we ‘stood on the shoulders of giants,’ selecting ideas from the best minds in the industry, and transformed them into what you see here.”

Il risultato è un libro decisamente accessibile, utile, pratico. Non contiene “formule magiche”, non eccede in schemi e diagrammi, ha una trattazione scorrevolissima ed include un discreto numero di box-consigli (“tip”) sintetici ed efficaci.

Ho trovato molte delle indicazioni contenute logiche, poco invasive ed efficienti, quindi realmente impiegabili sul campo e spesso senza nemmeno troppa fatica. Ho molto apprezzato il tono “leggero”, amichevole, non autoritario ma piuttosto autorevole e convincente.

Contenuti

Introduzione a parte, il cuore del libro è rappresentato da pochi capitoli, quattro, ognuno dei quali racchiude e ragiona in un insieme di concetti ed appare sostanzialmente autoconclusivo.

Il primo, “Tools and Infrastructure“, tratta appunto della scelta degli strumenti adatti per il proprio lavoro e si apre con questa spettacolare frase-metafora, che lo riassume perfettamente:

“There were once two men (Mike and Joe) who wanted to build a house. One man (Mike) first spent a lot of time and a decent amount of money buying tools and learning how to use them. The other man (Joe) took the tools he already had (a hammer and four screwdrivers) and started working. Not surprisingly, Joe’s house got started faster.

While Mike was learning how to use the air compressor and nail gun, Joe was hammering nails. However, once Mike got over his learning curve and started building, he passed Joe in no time. Mike was able to build a better house in a shorter amount of time by investing time and learning how to use his tools. And does anyone wonder who finished their next house faster?”

In poco più di 40 pagine vengono trattati, spiegati e sopratutto motivati temi come: operare in modo indipendente dalle altre persone (sandbox), l’importanza del codice come asset aziendale e come proteggerlo (SCM, gestione delle revisioni del codice, …), l’opportunità e necessità di rendere le procedure di compilazioni deterministiche ed automatizzate, l’importanza di tracciare i bug ed anche le feature, la necessità di impiego di procedure di test precise ed automatiche (“test harness”), magari simulando i client-tipo (“mocking clients”) per un dato progetto.

Dovendo riassumerlo in poche parole, lo definirei come un invito a scegliere ed impiegare tutti gli strumenti adatti ad evitarsi guai.

Ci sono anche affermazioni apparentemente strane, controcorrente ma sempre motivate, come la seguente:

“Now remember we’re not talking about compiling/building within your IDE. For the most part, you do not want to use your personal developer IDE to compile the project, even if you’re the only one using it.“

In questo caso gli autori vogliono far capire l’importanza di una macchina di “build” isolata da quelle su cui viene scritto il codice. Periodicamente o in base a qualche “trigger” automatico, questa macchina recupera da sola i sorgenti prendendoli da un repository, li ricompila, applicando poi una serie di test automatizzati ed informando tutte le persone coinvolte dei risultati, positivi o negativi che siano.

Il secondo capitolo, “Pragmatic Project Techniques“, sembra un riassunto semplificato quanto terribilmente efficace di una metodologia agile. Il riferimento al tracciare lo stato dello sviluppo tramite un documento condiviso (“The List”), sembra un richiamo netto a Scrum senza citarlo:

“The List is how you set your daily and weekly agendas. You order your work with The List, as does the entire team (it’s fractal!). When you get swamped, overwhelmed, or scattered, you come back to The List and use it to regain your focus.

If you get stuck on a tough problem and you need to step away for a while, The List gives you a readily available set of items to use as filler. This ensures that you’re working on the most important item, rather than the proverbial ‘squeaky wheel.’”

Nel capitolo si spiega inoltre il ruolo-chiave di una guida tecnica (“tech lead”), il valore della comunicazione fra le persone, l’utilità delle revisione del codice fra colleghi in chiave di miglioramento professionale e di come notificare le modifiche al codice ai colleghi senza causare problemi.

Un trafiletto mi ha colpito ed ispirato:

“If you aspire to be a tech lead, you need to prove you’re ready to handle the additional responsibility. Look over the job requirements, and strive to live up to them. Voluntarily perform as many of the tech lead duties as you can. Don’t wait for the job to fall into your lap; demonstrate that you are trying to earn the position and can handle it well.“

Ho apprezzato anche il piccolo box-suggerimento sul cosiddetto “burn rate”:

“Burn rate is a term that describes how much money it costs to operate the company, including salaries, rent, electricity, benefits, and so on. It’s the amount of money you “burn” whether you are getting work done or not.

When you have meetings of any size, always step back and do a rough calculation of how much the meeting is costing you per hour. Knowing this number tends to keep meetings shorter.”

Nel terzo viene recuperata la “metodologia” del libro “The Pragmatic Programmer“, ossia il “Tracer Bullet Development“. Devo ammettere che la (ri)spiegazione mi è piaciuta molto anche perchè, in coerenza con quanto detto, gli autori affermano che non è “una verità di fede” e non è sempre possibile utilizzarla con successo.

“Here’s how to put Tracer Bullet Development to work:

Identify the major parts of your project, and divide your product into blocks of related functionality. For example, you might have blocks called client, web server, and database layer.

Define the information that the blocks need to exchange and document the information with method signatures. These areas of layer interactions are called interfaces. Don’t worry about getting this perfect the interfaces first few times.

Give each block to a different developer, team of developers, or corner of your mind (if you’re working solo).

Write just enough code to make everything look as if it works. Think of it as an entire application of Mock Objects. Each layer appears to Mock Objects be authenticating users or fetching data (or whatever your application needs to do), but in reality, each layer is stubbed out and is simply returning canned data.

With this thin, skeletal framework in place, you can begin to fill in the real logic inside each block.

Finally, and most importantly remember that interfaces will change and evolve throughout the project. Your first shot will always miss the target, so be flexible and adjust your aim at any point. When another team approaches you for new interfaces, or to make changes to existing ones, go ahead and make the change. This is software, after all.”

Concettualmente è molto facile e perfino logico: ci si mette d’accordo su chi-fa-cosa e ci si organizza per lavorare in parallelo, rispettando i vincoli di interfaccia stabiliti o variandoli con il consenso di tutte le parti coinvolte. Fine.

Fantastico anche l’utilizzo – citato poco sopra – di dati fasulli/pronti all’uso per provare rapidamente porzioni di codice prima di avere a disposizione le vere e proprie sorgenti di dati reali:

“You might often find yourself in a situation where you need reproducible input or output data, especially for testing and Tracer Bullet Development. We call predefined data canned data.

Canned data is often used for tests because it provides a reproducible input for the tests. Using it with Tracer Bullet Development allows your components to return “valid” data, appearing to work long before the components are fully functional.“

Nuovamente nulla di eccezionale o innovativo (qualunque programmatore lo ha fatto e lo fa quotidianamente) ma è davvero piacevole ed insolito trovare tutto questo in un libro, per giunta indicato come pratica utile ed addirittura incoraggiata. Wow!

Il quarto capitolo, “Common Problems and How to Fix Them“, contiene un bell’elenco di situazioni standard e di come provare ad affrontarle: si va dal dover mettere mano a codice “legacy“, a come spingere ed ottimizzare l’uso dei test a come gestire clienti non particolarmente soddisfatti o colleghi “problematici” (“rougue developer”) o ancora aiutare gli sviluppatori alle prime armi a crescere professionalmente. Si tratta di piccole ma interessanti “ricette”-proposte per provare a risolvere vari problemi che sorgono normalmente sul posto di lavoro.

Lo si può interpretare anche come una sorta di “reference“, da sfoderare in presenza di uno di questi problemi-pattern ricorrenti. Ad esempio mi è piaciuto molto la parte sulle nuove “practice“. Dopo aver chiaramente avvertito che “Only fix what needs fixing“, gli autori parlano anche di come introdurle in pianta stabile nel team di sviluppo:

“Innovate from the bottom up.

So how do get your team excited about this new idea? Remember we talked earlier about demonstrating? Show them the process or tool; don’t just tell them about it. In particular, show them how well it works, especially in comparison with the old way of doing things.

If you know a ‘raving fan’ who has actually used this practice to good effect, bring them in and have them show the group how well it has worked for them. Even better, use it yourself. Build up evidence about how much more productive and efficient you are, and then tell your team about it.

You probably won’t have to do much talking because the team has probably already noticed how much better you’re doing! The key is to prove that this new-fangled idea is everything you say it is.”

Infine, i libro comprende anche alcune appendici contenente una serie di elenchi di programmi e metodologie opportunamente ripartite in “categorie”: qui verrà rapidamente chiamato per nome tutto ciò che può tornare utile, Scrum incluso.

Conclusioni

Ho decisamente apprezzato quest’opera: da buon libro “pragmatico” contiene una sana dose di saggezza “terrena”, frutto dell’esperienza degli autori, non di una qualche visione teorica unificante e risolutiva (come promesso da certi libri e da certi autori).

Visti i contenuti, concettualmente mi verrebbe da interporlo fra “The Pragmatic Programmer“, rivolto principalmente all’aspetto della programmazione e Peopleware (citato nel libro e che ho già recensito), più impostato sulle persone e sul come far funzionare un team.

Se proprio devo trovargli un difetto è che non propone idee innovative, ma riprende e rielabora concetti abbastanza noti al pubblico (a dire il vero, ho il dubbio che lo siano davvero). Per il resto è una lettura piacevole, non impegnativa, interessante: non sono soldi buttati, anzi…

Morale della fiaba: consigliato.
Voto complessivo: 7.