Archivi tag: software

Sopravvivenza

Uno degli ultimi acquisti in ambito di manuali: Software Project Survival Guide di Steve McConnell.

photo_2017-03-26_15-18-31

Conosciamo tutti Steve McConnell per il suo super famoso Code Complete 2.

In questo testo McConnell ci spiega come gestire un progetto software che richiede dai 3 mesi a un paio di anni. L’autore ci fa capire quanto alcune attività che dai manager mediocri vengono considerati sprechi sono in realtà necessarie e sane. Inoltre ci fornisce delle check-list di controllo e propone dei metodi di controllo.

Calza a pennello, a mio avviso, il paragone che fa subito all’inizio tra la piramide dei bisogni di un essere umano di Maslow e quelli di un progetto.

photo_2017-03-26_15-28-29

 

photo_2017-03-26_15-28-34

Se un progetto non riesce a soddisfare i suoi bisogni di sopravvivenza e sicurezza non sarà possibile raggiungere i più alti livelli di stato dell’arte del software.

È ricco di molti altri spunti di riflessione e mi senti di consigliare a chiunque sia coinvolto in progetti software (anche se non strettamente un programmatore) a studiare questo testo.

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.

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

Categorie

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.

Le tre vie

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.

Software rot

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?

Che ne dite di una build ogni ora?

La maggior parte di noi non lavora su progetti giganteschi ma chi ci ha lavorato assicura che compilare un sorgente il più frequentemente possibile porta molti vantaggi.

  • Minimizza i rischi di integrazione: uno dei più grandi problemi di un progetto in team è il merge dei sorgenti quando le persone hanno lavorato troppo a lungo in maniera separata. Sforzarsi ogni giorno di creare una build ed eseguire degli smoke test aiuta a contenere gli errori di integrazione;
  • Riduce il rischio di scarsa qualità: eseguendo dei semplici test sparsi per il programma si previene l’insorgere di grossi problemi legati alla qualità;
  • Rende facile l’analisi dei difetti: se la build del giorno n-esimo si rompe, è facile risalire al problema confrontando le differenze da quella del giorno precedente;
  • Migliora il morale: vedere un prodotto che funziona, anche se fa poco, aiuta a mantenere alto il morale del team.

Secondo Martin Fowler integrare frequentemente i sorgenti porta cambiamenti anche nel modo di approcciarsi al proprio lavoro da parte dello sviluppatore:

Frequent commits encourage developers to break down their work into small chunks of a few hours each. This helps track progress and provides a sense of progress. Often people initially feel they can’t do something meaningful in just a few hours, but we’ve found that mentoring and practice helps them learn.

In questo modo si tende ad approcciare il proprio lavoro in maniera incrementale, in piccoli step che ogni giorno aggiungono qualcosa (anche se poco) e ci si assicura che quei progressi si integrano correttamente con quegli degli altri.