Spediscilo o muori (con o senza qualità, però?)

Una delle idee che mi intriga è la mentalità "ship it or muori". Riguardo a come si chiama, ci sono variazioni, ma l’idea alla base della frase è semplice:

Se hai un’idea, portala dall’ideazione al prodotto il più rapidamente possibile.

Certo, l’idea di arrivare al concept di un prodotto può anche essere chiamata "concept to cash", ma non c’è mai la garanzia che genererai denaro, giusto? C’è una garanzia che puoi trasformarlo in un prodotto tangibile, però.

E nei circoli di sviluppo software, c’è sempre molto per cui una persona può discutere a favore o contro l’idea. In cima alla mia testa, i due pro e contro che mi vengono subito in mente sono:

1. Pro. Ottenere qualcosa fatto rapidamente che funziona e che [potenzialmente] genera entrate.
2. Con. Architettura debole, manutenzione, scalabilità, testabilità e così via.

In breve, potrebbe esserci un compromesso tra la velocità con cui puoi spedire qualcosa per un mercato e l’architettura dietro il progetto. A volte c’è, a volte non c’è. In generale, però, penso che sia lecito presumere il primo.

Inoltre, alcuni potrebbero vedere la prima come una facile via d’uscita, alcuni potrebbero vedere la seconda come un esercizio in YAGNI o, ancora più semplicemente, che il problema può essere affrontato ogni volta che si presenta.

Ma cosa c’entra questo con qualcosa in questo momento?

Spedirlo o morire?

L’intera ragione per cui sto dedicando tempo a scrivere di questo è che è qualcosa a cui io, e sospetto che altri nel nostro campo, riflettiamo almeno un po’. Tutto questo va bene quando se ne parla in senso astratto, ma vorrei provare a legarlo a qualcosa di un po’ più realistico.

C’era una volta…

Alcuni anni fa, lo sviluppo del front-end consisteva nel racchiudere il contenuto in elementi inline oa livello di blocco e modellarli con CSS di base?

Avevamo strumenti avanzati per lavorare con il nostro codice back-end, ma il front-end era relativamente semplice a parte forse gli standard di codifica imposti dall’azienda o dal team con cui lavoravamo.

Ma allora…

I nostri dispositivi avanzati (che, per la cronaca, considero una cosa buona e persino naturale nella tecnologia). Insieme a tale avanzamento, ora disponiamo di strumenti di creazione specifici per lo sviluppo front-end che sono altrettanto avanzati per alcuni aspetti rispetto a quelli che utilizziamo per il software di back-end.

Certo, abbiamo alcuni che sono "sviluppatori full stack", ma sono felice di ammettere che sono molto più a mio agio a lavorare sul lato server che sul front-end. Se lavoro sul front-end, tendo ad attenermi agli strumenti che conosco e cerco di rimanere all’interno dei guardrail definiti dalla corsia in cui opero.

Aiuta a mantenere lo sviluppo concentrato, veloce e coerente tra i progetti.

Ok, allora qual è il punto?

Di per sé, questa sezione potrebbe essere un post lungo, ma non mi interessa andare così lontano. Invece, prenderò una singola fetta di come funziona lo sviluppo front-end in questo momento e vedrò se non riesco a usarlo per chiarire il mio punto.

Diventando impertinente

Prendi ad esempio ciò che è diventato CSS. Abbiamo le lingue sopra le lingue (come Sass che si trova sopra o aggiunge ai CSS di base).

E abbiamo processori che compilano, minimizzano, sfilacciano e ci impediscono di vedere il nostro lavoro prima che determinati errori e avvisi vengano corretti per motivi di qualità. (Non lo considero una cosa negativa, ma mostra il livello crescente di complessità – o forse maturità – dei nostri strumenti di front-end).

Lo sviluppo del front-end è fin troppo facile, rendiamolo più complesso in modo da poterci sentire più intelligenti tra quei nostri colleghi che apparentemente hanno a che fare con aspetti più "critici" del business. Ricorda che questa è una competizione.

Questo articolo ha una visione umoristica dell’intera faccenda.

Un ragionevole grado di qualità

Per essere chiari, non sto dicendo che questa sia una cosa negativa, ma sto dicendo che le cose che una volta erano relegate al lato server o ai linguaggi compilati ora si stanno estendendo all’intero stack di sviluppo di un’applicazione web.

Per essere il più chiaro possibile: sono tutto per la qualità. Spedire cose senza alcun grado può essere visto come un esercizio di irresponsabilità.

Ma credo anche che ci sia un equilibrio da trovare tra la scrittura del codice più ottimale, funzionale e performante possibile con i vincoli di tempo e budget.

Non credo, non importa quanto ci sforziamo di imporre a noi stessi, che viviamo in un’utopia degli sviluppatori in cui possiamo ottimizzare, progettare e implementare sistemi incontaminati in ogni singolo progetto.

Sembra, però, che abbiamo fatto del nostro meglio per crearlo, vero?

Ma a un certo punto, non vale la pena chiedersi se tutti gli strumenti che stiamo creando e tutte le cose che stiamo aggiungendo ai nostri progetti rimuovono proprio ciò che ci ha fatto entrare nel settore in primo luogo? Certo, per alcuni di noi, questo è probabilmente diverso. È giusto chiedere che avere un’idea, scrivere codice per darle vita e vederla risolvere un problema è ciò che ci ha portato all’ovile?

A questo punto, tuttavia, abbiamo introdotto così tanti strumenti che mettere in funzione un ambiente di sviluppo per un’applicazione Web in esecuzione dal database fino al browser è un’attività intimidatoria.

Devono succedere così tante cose prima di essere effettivamente pronti per iniziare a scrivere codice che può diventare noioso e persino un po’ estenuante solo fare i primi passi per farlo.

Un parere personale e definitivo

Gravito verso l’applicazione di solide pratiche e strumenti orientati agli oggetti in molti dei progetti su cui lavoro con il mio team e che spedisco per altri perché so, per esperienza, il tempo, i soldi e i dati che possono essere persi di qualcosa non è ‘ t indirizzato da tutte le parti.

Questo non vuol dire che la spedizione di qualcosa neghi rapidamente nulla di tutto ciò. Ma il processo e l’organizzazione del codice alla base di un progetto è qualcosa che è molto difficile ignorare così tanto che sembra quasi paralizzante spedire qualcosa che non è stato testato e verificato al massimo grado possibile (e anche in questo caso, ci sono i problemi).

D’altra parte, però, c’è una parte di me che vuole sperimentare un’idea o due dietro la mentalità "ship it or die", solo per vedere quanto velocemente qualcosa può essere costruito, spedito e generare qualsiasi tipo di reddito indipendentemente da quanto incontaminato la base di codice è.

E forse ci proverò con alcuni progetti imminenti.