Software per uno

Poco dopo le superiori ho fatto un corso di Visual Basic¹. Allora, come adesso, passavo le giornate davanti a un computer, e sembrava una buona idea saperne di più.

Durante il corso ho cominciato a fare una serie di piccoli programmi, tutti solo per me. Uno mi ricordava quando cambiare le lenti a contatto² e partiva all’avvio del computer. Uno per altri promemoria, una specie di app per le note. Non so se all’epoca già si chiamavano widget, ma erano qualcosa di simile.

Poi gli studi e il lavoro mi hanno portato dall’altro lato, quello del design. Scrivere codice non faceva per me³. Mi interessava di più definire cosa dovesse fare un programma e come organizzarlo, e col tempo anche chi l’avrebbe usato. Mi piaceva fare software, ma quella parte, il codice, la lasciavo a qualcun altro.

Adesso quella parte costa sempre meno. Decidere per chi, e per quanto tempo, mi pare costi come prima.

Negli ultimi anni ho fatto software per lavoro: piattaforme web pensate per molti utenti e da tenere in piedi per anni. Negli ultimi mesi ho ripreso a farlo per me e per poche altre persone. Ogni sera sul mio computer si genera una pagina web delle cose fatte, di mattina un’altra con email ed eventi in calendario. Ho messo su un’app calendario che usiamo in due. Un’app per verificare le consegne dei miei studenti. Una piccola guida di Catania per la mia famiglia, l’ultima volta che è venuta a trovarmi, valida per quei pochi giorni.

Una cosa che avevo fatto per me, l’ho poi messa online l’anno scorso: sad.abacatania.it. Una piccola applicazione utile ai docenti di Accademie e Conservatori alle prese, come me, con le conversioni dei codici SAD. In questo periodo sto anche facendo un’app per salvare link, immagini e note, con l’idea di condividerla con un cerchio comunque ristretto.

In Software for One⁴, AJ Waxman racconta sei mesi passati a costruire strumenti personali con gli agenti AI: un’app per monitorare il sonno del figlio, una specie di Duolingo per gli accordi jazz, uno strumento per i dati medici.

Parte da un post di Robin Sloan del 2020, che aveva costruito un’app di messaggistica per la sua famiglia. La usavano tutti e quattro. Un successo.

An app can be a home-cooked meal. You don’t need scale. You don’t need users. You cook for the people you love.

Sloan all’epoca ci aveva messo una settimana, metà persa dietro la firma del codice, e si augurava «some kind of modern, flexible HyperCard for iOS»⁵.

L’immagine di Sloan, l’app come un pasto fatto in casa, mi sembra molto azzeccata. Aggiungerei la parte dell’improvvisazione: arriva qualcuno, apri il frigo e usi quello che c’è.

Tra le cose che Waxman dice di aver imparato: «ephemeral is fine».

L’app per il sonno l’hanno usata per circa quattro mesi. Adesso il bambino dorme tutta la notte e l’hanno messa da parte. Se ci avesse messo mesi a costruirla, scrive, forse gli dispiacerebbe. Ci ha messo una settimana, ed è contento che abbia funzionato quando serviva.

La guida di Catania ha avuto più o meno la stessa vita, qualche giorno. Anche il programma delle lentine, a pensarci, è durato quanto il sistema operativo su cui girava.

Ma chi vuole farlo?

Jason Fried, che fa software da più di vent’anni con 37signals, non crede alla rivoluzione del software su misura. Come succede spesso quando arriva una nuova tecnologia, i più entusiasti sono quelli che con la tecnologia hanno già confidenza, e magari ci si divertono pure. Non vale per tutti e in tutte le situazioni. Uno studio contabile di tre persone, sommerso dalle pratiche dei clienti, forse non ha come priorità gestire e mantenere un software fatto in casa. Un’azienda di trasporti con quaranta camion è più interessata a ottimizzare i percorsi che a sentire un dipendente che si dilunga sul nuovo sistema con cui sta smanettando. Per loro sarebbe un lavoro in più, sopra quello che fanno già.

Mi sono sentito chiamato in causa. E mi pare di vederlo anche tra amici e colleghi. Chi si sta rifacendo il sito, o si costruisce piccoli strumenti per il proprio lavoro, in genere lo faceva in qualche modo già da prima. Chiaramente la vista da qui, dalla mia scrivania, non è una prova di niente.

Nel post di Fried si intravede un altro aspetto, quello che viene subito dopo: chi tiene in piedi quel software, e per chi. Una guida di Catania per qualche giorno non ha questo problema. Non è il sistema con cui un’azienda organizza il lavoro. Se smette di funzionare quando la vacanza è finita, non succede niente. Il «per chi» è un numero ristretto di utenti, la mia famiglia, e il «per quanto» sono quei giorni.

Quando qualcuno comincia a contarci

Geoff Teehan, in We Built Companies Around the Cost of Building, descrive come le aziende abbiano organizzato processi e approvazioni intorno al costo di costruire software. Se oggi il primo tentativo costa poco, si può costruire prima e decidere dopo. Una frase tiene separate le due cose:

Making something and committing to it are not the same decision.

Nel #079 facevo una distinzione tra funzionante e deciso. In alcune situazioni bisognerebbe aggiungere impegno, legato alla durata e a chi lo tiene su. Uno strumento piccolo, che funziona e serve davvero, può diventare qualcosa da mantenere molto più a lungo del previsto.

Per capire cosa abbiamo deciso davvero, e cosa abbiamo solo costruito, può tornare utile uno strumento che usiamo da più di vent’anni: i cinque piani di Jesse James Garrett, in The Elements of User Experience. È ancora il riferimento che uso a lezione, anche se non lo seguo alla lettera. Il processo va dall’astratto al concreto, strategia, scope, struttura, scheletro, superficie, e ogni piano poggia su quello sotto. In un intervento dell’anno scorso, The Elements of UX in the Age of AI, Garrett ha ripreso il suo modello e ha diviso in due lo schema dei piani. Sopra ci sono i piani che si vedono, wireframe e UI, le cose che un’AI oggi genera in pochi minuti. Sotto, le cose che bisogna aver deciso prima. La strategia resta il piano più basso, quello da cui parte tutto: perché lo stiamo facendo e per chi.

Nel software per uno la strategia costa poco. C’è un solo utente, che molto spesso sono io. Si può partire dalla superficie senza troppi problemi, anche se un minimo di piano sarebbe comunque utile, solo per non perdersi dietro a mille modifiche, ma il perché e il per chi sono già risolti prima di cominciare.

In progetti più complessi l’assenza di strategia la si nota subito. In questo periodo sto lavorando a un sito con migliaia di link, grande e stratificato. Con gli agenti sono riuscito a ricostruire la struttura, mappare le sezioni e fare inventari dei contenuti che da solo non avrei nemmeno provato a fare. Le cose si sono complicate quando ho dovuto spiegarlo a qualcun altro. A quel punto ho dovuto scegliere cosa contava e cosa lasciare fuori, e quel lavoro è rimasto a me. Anzi, con tutto quel materiale a disposizione mi è sembrato più faticoso di prima.

Il sito sulle conversioni SAD sta in mezzo. L’ho fatto per capirci qualcosa io, poi l’ho messo online e a un certo punto non era più una cena improvvisata, ma una cena con giorno e ora fissati con richieste su preferenze e intolleranze. Il «per chi» era cambiato. Era comunque un «per chi» simile a me e non è stato troppo problematico. In più, la funzione base era una sola e semplice da gestire, accogliendo i vari feedback e richieste.

Con l’app per i bookmark, quando comincerò a condividerla, potrebbe essere più problematico. Ogni volta che la chiudo mi vengono in mente altre dieci funzioni, e si aggiungono in poco tempo. Poi è da capire se ha senso tenerle, come spiegarle a chi le userà, se tra qualche mese avrò voglia di farle ancora funzionare. Nel software per uno il costo del «per chi» e «per quanto» sparisce. Nel software per tanti utenti, resta lì.

Con la guida di Catania sapevo quando sarebbe finita. Con il sito SAD no, e me ne sono accorto quando qualcuno ci contava già. Quanto tempo dedicare a una cosa fatta per me lo decido io. Quando smettere, se è entrata nelle abitudini di qualcun altro, non lo decido più da solo.