Gabriele Lana

Dopo aver letto un bel po’ di cose sull’argomento, questa è una perfetta sintesi

• The customer is the most important thing in your business
• The best business plan is to sell people the things they want
• Your business is successfull if your earnings are higher than your spendings

Troppo spesso le startup vengono fondate su una vision di progetto che esiste solo nelle menti degli stessi fondatori, Eric Ries dice sempre nelle sue presentazioni “vision not delusion”, che potrebbe anche essere “vision not illusion”. Il compito principale di una startup è quello di validare/raffinare nel più breve tempo possibile la propria vision di progetto confrontandosi con l’unica fonte di verità: gli utenti

VC: “Interessante la vostra idea, potete mostrarci il vostro business plan?”
Startup: “Inizialmente avevamo questo set di funzionalità, poi abbiamo eliminato queste funzionalità ed abbiamo aggiunto queste altre e siamo passati da X utenti a 3X utenti, a partire da questa informazione abbiamo modificato il nostro posizionamento nel mercato, abbiamo validato queste informazioni passando da 3X utenti a 10X utenti aggiungendo queste altre funzionalità in accordo con quanto avevamo scoperto. Ora ci aspettiamo di raggiungere i 100X utenti, quindi una revenue di Y, togliendo queste funzionalità e aggiungedo queste altre nei prossimi 2 mesi”

Questo è un business plan nel quale metterei dei soldi…

Qualche giorno fa Robert Martin come esercizio per imparare Clojure ha risolto il kata del bowling (da lui stesso ideato). Qualche programmatore più avvezzo al mondo funzionale ha cassato la soluzione ritenendola troppo “imperativa”, accusando non tanto Martin stesso quanto la presenza dei test :-D

L’argomentazione utilizzata per minimizzare l’utilità dei test è la semplicità dell’esercizio, al che ho pensato a come l’avrei risolto in Erlang, mi sono detto che “effettivamente la soluzione è semplice”, ho iniziato a scriverla provandola nella shell del linguaggio e subito ho provato un senso di fastidio

Continuavo a scrivere e riscrivere (va bhe, la shell ti da la possibilità di richiamare i comandi passati, ma il discorso non cambia) le stesse invocazioni verificando ad occhio il risultato, al che ho capito il senso di fastidio: che differenza c’è fra quello che stavo facendo e scrivere dei test unitari? Nessuna, tranne che i primi sono effimeri e non ti possono venire in aiuto quando sarai chiamato a fare refactoring. Quindi, amici dei linguaggi funzionali, perchè non vedete i test unitari come delle sessioni di interazione con la shell permanenti e automatiche?

Vi dirò di più, la soluzione che avevo inizialmente pensato era sbagliata :-) Dopo aver passato tutti i test che Martin aveva fatto nella presentazione di cui sopra, mi sono chiesto se potevo rompere il codice in qualche modo, ho visto che non erano coperti dei corner case, per esempio c’è la partita peggiore (tutti 0), ma non c’è la partita migliore (tutti strike), scrivo un test… e non passa :-)

Come vedete qui sotto, utilizzo una variabile per tenere il conto dei frame elaborati, inizialmente non lo facevo e nel caso di uno strike nell’ultimo frame, i due tiri di bonus successivi metchavano con la terza clausola e venivano considerati dei frame normali, quindi il “perfect game” che dovrebbe avere uno score di 300 aveva score 320

Alla fine ho guardato il codice e quella variabile arbitraria per contare il numero dei frame proprio non mi andava giù e senza cambiare i test sono arrivato a questa seconda soluzione

Che non mi piace perchè anche se rende più esplicito (forse anche più imperativo?) il conto dei frame, secondo me si capisce di meno, sopratutto non mi piace score_frame perchè si occupa sia di calcolare lo score di un frame (e fin qui), sia di selezionare i tiri rimanenti eliminando quelli del frame corrente

Cosa ne dite? Quale vi piace di più?

Semplicemente perfetto:

I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. [...] Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. [...] Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.

Estratto da l’ultimo articolo di Tom DeMarco. Consideriamo anche che DeMarco non è proprio uno di quei “giovani rivoluzionari delle metodologie Agili che non hanno ancora capito niente e che vogliono reinventare la ruota”, è uno dei padri fondatori che si è sparato un po’ tutte le ere geologiche dell’informatica. Il problema è che di solito passa qualche lustro prima che il pensiero degli illuminati diventi di comune dominio… speriamo di esserci quando avverrà :-)

Qualche giorno fa Federico mi ha regalato questo libro, visto che l’ha comprato anche lui, visto che ha già iniziato a leggerlo e visto che a causa di questa lettura ha un’epifania ogni 10 minuti (di cui m’informa in tempo reale), non ho potuto far altro che iniziare a leggerlo anch’io, scelta felice, la prima epifania riguarda la tecnica del pomodoro

Il succo del discorso è che fare scelte è molto impegnativo, la situazione peggiora se:

• gli obiettivi non sono chiari
• non è chiaro come una scelta potrebbe influenzare il raggiungimento dell’obiettivo
• le scelte sono molte

Provate a pensare al nostro lavoro, o in generale al lavoro creativo dove le possibili scelte sono infinite, dove l’obiettivo è soddisfare un’utente che nella maggior parte dei casi non conosciamo, ecc… capite che non siamo messi molto bene :-)

La tecnica del pomodoro per lo meno ti consente di separare i momenti in cui devi effettuare una scelta (cosa fare e quando farla) e i momenti in cui devi eseguire. La possibilità offerta è quella di eliminare lo stress continuo della scelta, ovvero di eliminare quella vocina che continuamente si chiede “sto facendo la cosa giusta? Potrei fare anche quall’altra cosa! Ah e poi devo fare anche quell’altra! Non sarebbe meglio se quell’altra cosa la facessi subito? Caxxo quante cose ho da fare! Riuscirò a farle tutte in tempo? Ecc…”, ovvero un context switch mentale continuo, uno stress altissimo che non porta sicuramente a nessun risultato

Nei 25 minuti del pomodoro non sei autorizzato a pensare ad altro oltre a quello che stai facendo, quando hai finito hai la possibilità di utilizzare il risultato del tuo lavoro per poter operare delle scelte informate, limitando le speculazioni mentali e diminuendo notevolmente l’ansia

Sostanzialmente è quello che fanno le metodologie iterative ed incrementali a livello di progetto, la tecnica del pomodoro ti consente di applicare lo stesso principio e di ottenere gli stessi vantaggi ad una granularità più fine e direi più umana