Qualche giorno fa l’amico JustB ha sollevato un interessante quesito su Meemi:
“Avete consigli su come approcciare lo studio di un’applicazione legacy su cui dovrete lavorare ed effettuare modifiche, considerando che si tratta di un’infinita schiera di file salvati in n+1 cartelle, che si includono a vicenda, senza uno straccio di documentazione né commenti esplicativi?”
Domanda molto interessante, a cui vorrei rispondere ora, seppur brevemente…
Di tanto in tanto mi viene chiesto qualche consiglio su come iniziare a programmare, “partendo con il piede giusto“. Non che io sia un guru ma questo non mi impedisce certo di provare a rispondere.
Alcuni dei consigli sono emersi qua e là, nei miei post passati, ma ho notato di aver trascurato del tutto un “fattore di crescita professionale” molto importante, che mi si è rivelato utilissimo: i “modelli di riferimento“.
Gironzolando sulla rete mi sono imbattuto in queste sei “leggi” dello storico della tecnologia Melvin Kranzberg:
Kranzberg’s laws of technology
- Technology is neither good nor bad; nor is it neutral.
- Invention is the mother of necessity.
- Technology comes in packages, big and small.
- Although technology might be a prime element in many public issues, nontechnical factors take precedence in technology-policy decisions.
- All history is relevant, but the history of technology is the most relevant.
- Technology is a very human activity – and so is the history of technology.
Sulle prime ho riso, poi ho riflettuto, quindi ho convenuto con il loro autore.
Cosa distingue un utente da quello che viene spregiativamente definito un “utonto“?
Forse una particolare forma di intelligenza? Forse la coordinazione nell’uso degli strumenti di input? Forse la tenacia nell’imparare e nel contempo piegarsi poco a poco al modo di funzionare di una macchina?
Dipende da caso a caso ma, dovendo generalizzare, credo che nessuna di queste caratteristiche sia più importante della mancanza di possibilità e di volontà di osare.
Un celebre aforisma, spesso veritiero negli effetti, così recita:
Zawinski’s Law of Software Envelopment
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
Una mia personale revisitazione generica di quella legge:
JP’s Law on Software Expansion
“Every software attempts to expand until it can even make coffee. Just before reaching that goal, someone else complains about that huge mess and will start a new tiny replacement project.”
È da quando sono bambino che in casa mia sento ripetere questo genere di discorso:
“Esiste una differenza sostanziale fra il modo con cui ci hanno copiato il ‘made in Italy’. Prendi i cinesi: loro ci copiano e basta, puntano all’imitazione e la qualità non è così importante. I giapponesi invece copiano per migliorare.”
Ora, questa frase ha almeno ventanni, nel senso che risale al periodo in cui mio papà lavorava per una celebre (allora) ditta italiana che produceva bambole, poi scomparsa più per smania di outsourcing che non per un qualche problema aziendale (così sostiene lui, conti e prodotti alla mano).
 |
Sia chiaro: l’intento di questo post non è polemico nè tantomeno razzista (orrore!).
Ho citato i nomi di due popolazioni, quella cinese e quella giapponese, ma in un contesto composto di stereotipi, ossia di presunti celebri “copiatori”. Un po’ come quando fanno con noi italiani, appioppandoci pizza e mandolino. Non è giusto, sono d’accordo, ma nascondere i nomi avrebbe reso il discorso un po’ troppo generico per i miei gusti. |
Tempo addietro lessi da qualche parte sulla Rete – sfortunatamente non trovo più l’URL – un articolo in cui si parlava dell’ennesimo studio scientifico “particolare”, in cui veniva “dimostrato” il legame indissolubile fra gli acquisti di una persona ed i sui gusti personali.
Ovviamente, penso non serva uno studio per capirne la portata, mettere in dubbio un acquisto può equivalere a mettere in discussione il raziocinio dell’acquirente.
Come se sbagliare un acquisto fosse una prova della stupidità di una persona…
Esiste un’enorme quantità di modelli/metodologie di sviluppo. Ce ne sono così tanti che è davvero difficile non trovarne uno adatta a sè stessi. Mi accorgo però che, ripensando anche alla mia formazione accademica, parlare di queste tematiche sembra un voler “vendere fumo“, una vera e propria perdita di tempo.
In questo post vorrei chiarire qualche punto che mi sta decisamente a cuore.
Documentare le cose richiede generalmente una buona quantità di tempo e di fatica: è incredibile quante parole si riescano e si debbano spendere anche per lavori di taglia modesta. Di più: non è raro che lo sforzo di gestire le scartoffie ecceda quello di produrre le cose a cui si riferiscono.
Sono sempre stato contrario ai progetti lasciati deliberatamente “troppo aperti“, che nascono cioè per uno scopo preciso – quello che il cliente si aspetta e per cui paga – ma contengono già riferimenti espliciti ad (improbabili) aggiustamenti futuri.
