Questa puntata del podcast è dedicata al codice “brutto” che si vede spesso nelle startup e nelle aziende che costruiscono la prima versione di un nuovo prodotto digitale.
E il tuo è un MVP o… un prototipo?
Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.
Trascrizione
Ciao da Alex Pagnoni e benvenuto nel podcast di CTO Mastermind, il podcast dedicato ai CTO e ai responsabili dei team di sviluppo, oltre che a imprenditori e founder di startup e aziende che vogliono capire meglio gli aspetti tecnologici alla base dei loro prodotti e servizi digitali.
Questa puntata è dedicata al codice brutto che si vede spesso nelle startup e nelle aziende che costruiscono la prima versione di un nuovo prodotto digitale.
Devo innanzitutto ammettere che nei miei primi anni di programmazione professionale ho scritto la mia bella quota di codice orribile di cui a distanza di anni non vado certo fiero, questo prima di scoprire concetti come quelli dei design pattern, i principi SOLID, Don’t Repeat Yourself e best practice di questo genere.
O meglio, man mano che scrivevo quantità di codice sempre più grandi mi accorgevo che iniziavano ad emergere dei pattern di sviluppo che poi ho scoperto essere appunto i design pattern, ma di certo non con la completezza della cosiddetta “Ganf of Four”, che sono gli autori dell’omonimo libro.
In ogni caso c’è sempre spazio per migliorare e se si continua con lo studio e la pratica di concetti come quelli che ho appena accennato, allora sicuramente aumentano le probabilità di finire prima o poi a ritrovarsi a parlare con delle persone esperte a discutere sulle varie metodologie di sviluppo.
L’importante è rendersi conto del livello qualitativo con il quale si sta lavorando.
Questo però si scontra con quella che è l’esperienza di chi si trova ad esaminare o prendere in carico il codice scritto per un MVP, termine con il quale banalmente si intende la prima versione minima per uscire sul mercato con un nuovo prodotto o servizio digitale che sia fruibile dagli utenti.
Quando ci si imbatte in una codebase di quel genere, tipicamente gli sviluppatori e i founder della startup non ti dicono che il codice l’hanno scritto male perché sono nuovi del mestiere o inesperti, ma ti dicono che hanno costruito un MVP.
Quello che dico io è che invece hanno costruito una schifezza di spaghetti coding destinata a perseguitare con dei brutti incubi gli sviluppatori che poi si occuperanno della manutenzione e dei futuri sviluppi, perché un MVP è un modo per creare un prodotto funzionante nella sua forma più semplice.
Invece quello che hanno costruito è un prototipo, con codice di qualità adeguata a qualcosa di usa e getta come è appunto un prototipo, che si costruisce con criteri ben diversi da quelli necessari per costruire un prodotto reale e portarlo in produzione, anche se nella sua forma più elementare.
Anche in passato ho scritto articoli in cui citavo il fatto che i primi sviluppi di una startup sono quasi sicuramente da gettare, ma nell’ottica di creare un prototipo da validare, non un prodotto reale da vendere sul mercato.
Un prototipo infatti non è altro che una versione preliminare di un prodotto software, per dare la forma iniziale al prodotto che si costruirà successivamente.
Quando parliamo invece di MVP, parliamo della quantità minima di software capace di funzionare correttamente costruita per arrivare sul mercato.
Il problema è proprio quello di usare questi due termini in modo interscambiabile.
In alcuni casi questa confusione è voluta in un certo senso, come quando dei founder presentano a degli investitori un prototipo etichettandolo come MVP, chiaramente perché hanno bisogno dei fondi per costruire il prodotto vero e proprio, mentre gli investitori pensano che quel denaro è ciò che serve per portare quel codice scritto male sul mercato.
Molte volte sono stato contattato da aziende e startup che mi hanno presentato il loro MVP dicendomi che avevano alcuni problemi e che avevano bisogno di aiuto.
Questo invariabilmente capita quando cercando di far scalare il loro prodotto e si accorgono di avere sotto il sedere qualcosa che assomiglia ad un prodotto, ma che non lo è realmente perché devono ancora progettarlo realmente.
Mi vengono in mente ad esempio quei casi di piattaforme digitali che altro non erano che dei siti WordPress con degli accrocchi micidiali in forma di plugin che dovevano erogare funzionalità per le quali era necessario tutt’altro approccio.
In quei casi la mia risposta è sempre che non hanno a che fare con un prodotto ma con un prototipo da buttare via, più che da sottoporre a bug fixing o refactoring.
D’altra parte non voglio certo dire che un MVP deve essere scritto in modo perfetto, deve anzi essere scritto in modo buono quanto basta, chiaramente agli occhi di un esperto e non di un junior.
D’altra parte capisco anche la situazione che ho descritto prima e se hai tirato fuori un accrocchio di fretta per avere un prototipo da presente e ottenere denaro è comprensibile, le motivazioni sono chiare.
Però se poi quel denaro lo riesci ad ottenere, assicurati di chiederne abbastanza per sviluppare il prodotto vero e proprio in modo corretto, con un team eccellente e con i criteri di cui ho accennato.
Se non sei sicuro a quale livello di qualità devi attenerti o se ti manca qualche sviluppatore per creare un team di elevata qualità, chiedimi pure come posso aiutarti, in ogni caso devi assicurarti di costruire un prodotto che non ha bisogno di essere riscritto da capo per funzionare bene e scalare quando necessario.
Bene, siamo arrivati alla fine del podcast e ti voglio ringraziare per aver ascoltato questa puntata.
Se vuoi saperne di più sull’argomento di oggi oppure vuoi dire la tua, puoi scrivere nella CTO Mastermind Community.
Nei prossimi episodi parleremo di alcuni argomenti come ad esempio capire quando è meglio riscrivere il codice da capo oppure fare refactoring, e come evitare di sovraingegnerizzare gli sviluppi.
Grazie ancora e ti aspetto alla prossima puntata, ciao da Alex.
