Adattabilità al Contesto

Spesso mi chiedo quanto un programmatore debba addentrarsi ed approfondire la materia nel contesto del dominio applicativo del suo progetto e quanto invece ne debba rimanere fuori abbastanza da non lasciarsi condizionare nei futuri progetti. Mi spiego meglio.

Chissà a quanti di noi sarà capitato di trovarsi in un meeting con persone esperte di dominio, che discutevano a lungo su un problema senza giungerne a una. E quante volte, in quelle occasioni, è sorta la necessità di chiarire alcuni termini (perché per es. percepivamo la brutta sensazione che alcuni termini venivano usati impropriamente da alcuni e male interpretati da altri, o sinonimi che apparivano semanticamente diversi e così via)? E forse avremmo voluto porre delle domande banali, anzi triviali, talmente semplici..., e poi abbiamo avuto la tentazione di desistere per non fare la figura di un perfetto "incompetente"?

E invece...l'avete fatto! Temerari, incuranti del pericolo e assetati di comprensione. Avete posto delle domande semplici. Avete favorito la chiarezza tra i presenti e permesso che essi si intendessero nei termini e nei significati, portandoli sempre più verso la soluzione al loro problema. Ma avete rischiato grosso!

Chi programma sa quanto profondamente bisogna indagare la materia per produrre un software di qualità e soprattutto sa quanto velocemente bisogna essere in grado di estrarre dagli esperti l'essenziale, quello che serve al programma da realizzare ed infine quanto velocemente bisogna saper porre le domande giuste, quelle che portano a eliminare le contraddizioni o le incertezze (che ogni dominio applicativo presenta). Chi programma sa anche che bisogna saper dimenticare in fretta, per evitare di portasi dietro preconcetti e interpretazioni errate che devierebbero dalla soluzione ideale del prossimo cliente e quindi di procurargli un danno.

La conoscenza che raggiungiamo durante questa fase di apprendimento io la chiamerei : conoscenza orizzontale. Ossia ci appropriamo dei concetti fondamentali, che ci consentono in maniera analitica di organizzare le informazioni e forniscono quel minimo di autonomia necessaria. Successivamente quest'autonomia porta all'individuazione di tutti quei dettagli infinitesimali, di cui il programma ha vitale bisogno. Questo approfondimento non è più autosufficiente, ma avviene attraverso un processo di indagine e interrogazione continuo rivolto nei confronti del nostro esperto-interlocutore di dominio (diciamo customer on site?).

Ho avuto la fortuna in età adulta di fare lavori di sviluppo (programmi e apparecchiature) in diversi settori o domini applicativi: building automation, apparecchiature mediche, ospedaliero, bancario, assicurativo, e-learning e farmaceutico. Quello che ho imparato è che quanto più velocemente apprendo, tanto più dimentico. Anzi il contrario: più dimentico veloce il vecchio, tanto più apprendo rapidamente il nuovo.

L'atteggiamento critico e vigile nei confronti della conoscenza di un business specifico è un aspetto fondamentale della nostra professione. Se dovessimo diventare esperti noi stessi, appropriandoci di quella che io chiamerei la conoscenza verticale, al punto tale di poter fare a meno dell'esperto (condizione anche troppo frequente per coloro che lavorano per lungo tempo come programmatori presso lo stesso determinato tipo di organizzazione), porterebbe osmosi del ruoli, ossia alla totale autonomia del programmatore. (sebbene in alcuni contesti ci può anche stare).

Le conseguenze di questa "metamorfosi" sono diverse.

• Innanzitutto l'esperto di business incomincia a delegare anche la definizione delle nuove funzionalità da svolgere.

E in seguito si avrà:

• un eccessivo carico di lavoro intellettuale sul personale tecnico.
• errori di interpretazione nel programma.
• la perdita di interesse da parte del programmatore degli aspetti di design, leggibilità del codice, e semplicità della soluzione;
  
• degrado del livello di sostenibilità del prodotto e che noi sappiamo essere, come il punto precedente, linfa vitale del software, nel genuino interesse economico del committente.
• un inesorabile ridimensionamento dell'importanza della formazione tecnica e della sperimentazione di nuove idee, nuove tecnologie e nuove indagini e tecniche di sviluppo del software;
  
• la compromissione dell'innovazione nell'azienda o della capacità evolutiva del prodotto in un contesto di mercato fortemente concorrenziale.
• l'implicita promessa di carriera, nei confronti del programmatore, che si basa maggiormente sulla conoscenza verticale del dominio e non, come dovrebbe, sulla sua capacità di comunicazione, risposta al cambiamento, programmazione, disciplina e innovazione.
  
• la perdita di assunzione delle responsabilità in maniera distinta tra coloro che definiscono cosa bisogna fare e con quale priorità, rispetto a coloro che devono definire come e in quanto tempo (si pensi al planning game).
• il potere persuasivo esercitato dal personale tecnico che dimostrano di possedere conoscenza verticale, ossia padronanza profonda del dominio applicativo, sulla reputazione del programmatore all'interno dell'organizzazione. Fattore controproducente sulle performance nello sviluppo del software, perché svilisce la nostra difficile professione e degrada nel tempo le prestazioni di sviluppo e la qualità del prodotto del cliente.
  
• infine dall'invito implicito al programmatore ad imparare un nuovo mestiere, nel caso in cui a egli interessasse guadagnare di più. (che spreco di know-how!)
  

Quante volte vediamo annunci di lavoro per tecnici specializzati in cui l'azienda cerca personale che abbia expertise nel dominio applicativo dell'azienda che lo pubblica?

Tutto questo spinge sempre più il programmatore a specializzarsi su un determinato business.

A mio avviso coloro che nel nostro lavoro si fanno sedurre dalla conoscenza orizzontale di dominio, rischiano di perdere flessibilità, di non essere in grado di cambiare colore come il camaleonte quando il contesto lo richiede, o la capacità di penetrare la materia rapidamente, facendo l'interesse del proprio cliente e dell'utente che si troverà confrontato 9 ore al giorno e per anni con il prodotto del suo lavoro di Programmatore.

Buon arcobaleno a tutti.