Aumento del debito tecnico nelle piccole società di software indiane che sviluppano app e siti Web: chi ne è responsabile?

Sono stato nel settore dei servizi software indiani per 10 anni e durante tutto questo tempo ho visto buoni progetti completarsi e fare miracoli. Ho visto squadre scheletriche lavorare instancabilmente in condizioni angoscianti per costruire prodotti che sono stati amati dalle persone dall'altra parte del pianeta. E mentre ci sono stati grandi ricordi in questo decennio di lavoro su alcuni progetti meravigliosi, ho anche assistito a progetti che peggioravano e prodotti software che andavano male per vari motivi. È successo più volte di quanto avrei desiderato intorno a me e alle persone che ho conosciuto in questi 10 anni.

Si è parlato molto di progetti che vanno male. I meme brulicano su Internet di come l'intera gerarchia si rincorre come una catena alimentare nelle giungle. Alcune persone incolpano i programmatori per aver scritto codice difettoso, mentre altre persone maledicono il management per aver fatto promesse impraticabili che sono impossibili da mantenere. Alcune persone addirittura incolpano i clienti per non aver compreso i prerequisiti tecnici e le dipendenze di questo settore. Ma non ho sentito quasi nessuno parlare di debito tecnico, o debito di codice, e affrontare questo problema in modo civile senza puntarsi il dito l'un l'altro. Non una volta mi sono imbattuto in questo termine di Tech Debt dalle persone intorno a me, o dagli eventi a cui ho partecipato, o dai blog locali che ho letto.

Mi sono imbattuto in questo termine solo quando ho letto blog e giornali della Silicon Valley negli Stati Uniti. Ciò significa che la maggior parte dei programmatori e dirigenti di software che lavorano in società di sviluppo software di piccole e medie dimensioni in India non avrebbero nemmeno sentito parlare di questo termine prima d'ora. Quindi, vorrei iniziare spiegando il termine stesso. Il debito tecnico, o debito di codice, è un concetto nello sviluppo del software che riflette il costo implicito della rilavorazione aggiuntiva causata dalla scelta di una soluzione semplice (limitata) ora invece di utilizzare un approccio migliore che richiederebbe più tempo.

Lascia che lo scomponga per renderlo semplice. È un concetto per calcolare il costo della risoluzione dei problemi di programmazione e progettazione che potrebbero essere aumentati scegliendo un'opzione facile per costruire un particolare modulo, o un intero sistema, invece di scegliere il metodo migliore e più efficiente per costruirlo. Nel campo dello sviluppo software, questo fenomeno della tua pigrizia e del tuo ritardo che tornano a morderti nel culo accade molto più spesso che altrove. È quasi come se il Karma avesse una rappresentazione sociale di essere stronzo da parte dei programmatori.

Per favore, non fraintendetemi, non sto incolpando tutto il debito di codice sui programmatori. Ci sono sicuramente più entità che sono responsabili del debito di codice che sorge sicuramente in oltre il 90% dei progetti in società di sviluppo software di piccole dimensioni in India. Provo a coprirne alcuni brevemente:

1. CLIENTI IMPAZIATI E OVERSMART

Sì, inizierò mordendo proprio la mano che nutre e lo faccio senza pietà. Il mercato dei progetti di sviluppo software in outsourcing di piccole dimensioni è enorme e altamente frammentato. Ci sono aziende veramente buone che giustificano perfettamente questo mercato globalizzato, mentre altre sono solo aziende parassitarie che si nutrono di questo accordo perfettamente buono solo perché non è regolamentato e non controllato.

Questo porta i clienti a commettere un errore nella scelta dell'azienda giusta con cui collaborare in base alle loro esigenze. Anche se non avere adeguate capacità di controllo non è colpa loro, ma non c'è nessuno da incolpare se non hanno l'intelligenza di base nell'identificare un'azienda di rifiuti da una genuina. Ora, una volta che accettano di andare avanti con una squadra poco talentuosa, soffocano le loro aspettative e tempistiche irrealistiche su di loro. Non solo, alcuni di loro addirittura esagerano e mostrano quanto sono intelligenti portando i propri suggerimenti nel design e nella programmazione. (#notallclients)

Se sei mai un cliente di una società di sviluppo software, ti chiedo umilmente di lasciarli stare e permettere loro di fare il loro lavoro. Prova ad andare da un dottore o da un avvocato e digli cosa hai cercato su Google e cosa ha detto sul tuo problema e vedi la reazione sui loro volti. A nessun esperto nei loro campi piace essere avvisato sul proprio campo da un noob. Gli ingegneri del software non fanno eccezione.

Se trovi un buon team di sviluppo software e sembra promettente, dagli il suo spazio e non sentirà il bisogno di tagliare gli angoli che si tradurrebbero in un minor debito di codice nel tuo progetto. E indovina un po', la maggior parte delle volte, siete voi ragazzi, i clienti che pagano quel debito di codice. Mai sentito parlare delle parole: "Richiesta di modifica"? Scommetto che la maggior parte di voi ce l'ha! In uno scenario ideale, non dovresti mai sentire quelle parole nella tua vita. Ma ciò accade raramente. E la maggior parte delle volte che senti quelle parole, più sbagli a essere un cliente di un'azienda di software.

2. GESTORI PIZZERI E DIVERSI

Quando dico manager qui, è chiunque ricopra la posizione di project management dalla parte dell'azienda di sviluppo software. Che si tratti di un project manager, di un team leader, di un responsabile delle consegne o di un proprietario di un'azienda, se hai mai provato a lavarti rapidamente le mani di un progetto solo per concludere e riscuotere il pagamento, sei una festa da incolpare anche in questo importo di Tech Debt nei tuoi progetti.

Anche se la parte più triste qui è che voi ragazzi non dovete mai pagare l'importo del debito tecnologico. O è il cliente che lo paga utilizzando un prodotto scadente o pagando effettivamente più soldi per farlo pulire. E se non è il cliente, sono i poveri programmatori che lo pagano, dovendo lavorare infinite ore ben oltre quello che sono tenuti a fare. Ma non sono quasi mai questi ragazzi di mezzo, quindi secondo me dovrebbero essere le entità più responsabili in questo argomento del debito tecnologico.

Se mai ne assumerai uno, la più grande qualità che dovrebbero avere è la moralità. Se la loro bussola morale sta puntando nella giusta direzione, si assumeranno la responsabilità e prenderanno la decisione giusta a favore del progetto, che alla fine porterebbe a una minore accumulazione del debito tecnologico. Questo mi ricorda quella famosa citazione di Jack Ma in cui parlava della scelta di lavorare per il leader giusto. Molto adatto in questo scenario qui.

3. PROGRAMMATORI

Oh sì, non finirei questo argomento incolpando anche voi ragazzi! Ma ehi, #notallprogrammers giusto? Bene, sì, ma quasi il 94% dei programmatori. Almeno questo è ciò che pensa CP Gurani, CEO di Tech Mahindra, quando un paio di anni fa ha fatto la scioccante rivelazione che il 94% dei laureati in informatica non è idoneo al lavoro. Non so esattamente come sia arrivato a quel numero, ma essendo un prodotto dei college di ingegneria indiani e avendo assistito all'intero ecosistema di ingegneria IT negli ultimi 10 anni, posso dire che tendo ad essere d'accordo su quanto affermato dal signor Gurani.

Non sto cercando di discutere se sia 94%, 90% o 80%. Ma per farvi un'analogia, è come se quasi tutti sapessimo che per fare l'impasto abbiamo bisogno di farina, acqua e un pizzico di sale, e per fare i chapati con il mattarello. Ma pochissimi di noi possono effettivamente fare dei chapati commestibili. È un processo estremamente semplice, ma richiede comunque un certo talento e tonnellate di pratica per eccellere in questo. Lo stesso vale per la programmazione. Tutti noi conosciamo la ricetta, ma pochissimi si sono effettivamente rimboccati le maniche e si sono sporcati le mani e l'hanno praticata per tutto il tempo necessario per padroneggiare quel mestiere.

Quindi, anche quando un programmatore medio viene incaricato di un progetto, scriverebbe inconsapevolmente del codice con un debito tecnologico incorporato in esso che non realizzerebbe fino a dopo. E se ti stai chiedendo come funziona il settore nel complesso in modo positivo con la maggior parte dei programmatori inadatti al lavoro, è a causa dei loro manager efficienti e dei loro anziani esperti che hanno imparato le cose nel modo più duro. Aiutano quelle mani e menti fresche a navigare nei percorsi insidiosi della scrittura di codice ottimale e rendono fattibile la spedizione del progetto e lo mantengono libero da un debito gravoso. E alla fine con un'adeguata cura e formazione di quei principianti per diventare bravi nel loro lavoro, o finiscono per dire addio al settore IT.

Quindi, in conclusione, sento che tutte e 3 le parti principali di questa collaborazione devono condividere la colpa per aver compilato il debito di codice. Ancora una volta, non prendere questo pezzo come un pezzo da smontare per tutto ciò che non va nel settore. È proprio come qualsiasi altra industria al mondo con la sua giusta dose di orrori oltre che di eroi. Anche dopo 10 anni in cui ho fatto questo, non farei nient'altro nella mia vita. Amo questo lavoro, amo essere una piccola azienda che lavora su progetti entusiasmanti da clienti in tutto il mondo.

Lo scopo era quello di rendere tutte e 3 le parti interessate più responsabili e informarle di questa perdita morbida sottostante che veniva colpita da una cattiva collaborazione. Se un team di sviluppo software desidera calcolare e misurare con precisione il proprio debito tecnologico, può seguire un modello di processo rigoroso basato sulla metodologia Agile o persino sulla metodologia Waterfall. Quando segui questo approccio disciplinato, sarai in grado di contrassegnare separatamente quegli sprint di revisione e riparazione e, alla fine di una fase, sarai in grado di calcolare con precisione quanti di essi ti servivano e arrivare facilmente al ragione per questo.

Concludo questo con questa citazione conclusiva di Samuel Beckett: