Consigli per programmatori in consulenza

Ciò che scrivo in questo post deriva dalla mia esperienza da programmatore in aziende di consulenza.
Ho lavorato, e lavoro attualmente su progetti software, piuttosto grandi ed importanti per grosse aziende Italiane, che non credo sia il caso di citare.

Molto spesso il business ha esigenze che poco si conciliano con i tempi di sviluppo. Ciò porta i reparti IT ad approciarsi alle varie problematiche senza affrontarle dalla giusta prospettiva, ma semplicemente traducendo quelli che sono i bisogni del business in codice, nel minor tempo possibile.
Ciò purtroppo, oltre a produrre software di scarsa qualità, fa si che gli sviluppi vengono fatti non tenendo conto di buona parte di quello che c'è attorno, causando spesso delle regressioni sulle funzionalità già esistenti.
Tali regressioni si trasformano in ulteriori richieste da parte del cliente, che necessita ovviamente di una risoluzione, anche questa volta in tempi brevi. E a chi tocca risolvere il problema? Allo sviluppatore ovviamente!
Si entra così in un circolo vizioso da cui diventa sempre più difficile uscire.

Il mio consiglio è quello di avere il coraggio di NON fare solo quello che il tuo capo ti dice, o meglio, non limitarsi alle richieste e non farsi prendere dalla frenesia del poco tempo a disposizione. E' sempre meglio ragionare prima di cominciare a scrivere il codice. E' molto meglio uno sviluppo rilasciato magari con due settimane di ritardo piuttosto che uno rilasciato in tempo ma piuttosto problematico, che causa problemi a volte di difficile soluzione.
Di recente un cliente, per cui lavoro, è stato costretto a pagare una penale di diverse decine di migliaia di euro per non aver rispettato dei vincoli legali nel suo business. Inutile dire che questo business è gestito tramite processi software che in questo caso presentavano dei bug piuttosto gravi. E indovinate un po'? Quando si trattava di rilasciare queste funzionalità non abbiamo avuto neanche un giorno in più per affrontare con più calma e razionalità le varie problematiche, tempo che magari ci avrebbe permesso di non rilasciare quei bug che hanno poi causato le penali!
Non sarebbe stato meglio aspettare una settimana invece che andare di fretta e subire quindi una multa, buttando via quindi dei soldi.

C'è da considerare un altro aspetto, un software fatto bene è più facilmente estendibile e mantenibile. Più un software viene pensato e realizzato per poter essere poi modificato, più le successive modifiche saranno facili da fare!
Se durante una nuova implementazione ci si rende conto che è necessario modificare una parte di codice, magari consolidata, ma che è difficile da adattare alle nuove esigenze, allora molto probabilmente è meglio fermarsi un attimo e cercare un modo per ripensare la struttura esistente in modo che possa accogliere facilmente questa modifica e successive modifiche dello stesso genere. Apparentemente questo è un lavoro in più, ma i suoi vantaggi si vedranno nel tempo.

Infine, dalla mia esperienza, è utilissimo non limitarsi ad implementare quelle che sono le richieste, ma produrre dei tool di supporto, nelle modalità che sono più congeniali al contesto del progetto, in grado di automatizzare procedure che diversamente dovrebbero essere svolte manualmente. E' vero che anche in questo caso all'inizio ci sarà del lavoro in più, ma nel medio termine, questo tipo di approccio consentirà di eseguire uno sviluppo migliore, avere degli strumenti per testare velocemente la non regressione, meno problemi ed in definitiva più tempo libero!

Lavorare bene, scrivere codice di qualità fa accrescere quelle che sono le proprie abilità, e la stima che si ha di se stessi, inoltre ciò permette anche di avere il riconoscimento delle proprie capacità da parte dei propri colleghi e ancor di più dei capi, che concederanno più facilmente un aumento di stipendio!

Buon coding!