Perché la maggior parte del software viene costruita al contrario

La maggior parte del software viene costruita al contrario.

Questo accade perché le persone premiano le cose sbagliate.

Le funzionalità attirano l'attenzione. L'architettura no. Gli annunci attirano l'attenzione. La documentazione no. Le nuove capacità attirano l'attenzione. La manutenzione no.

I team iniziano dalle parti visibili. Trascurano le fondamenta.

Le domande comuni sul software si concentrano sulla fase sbagliata:

  • Quali funzionalità dovremmo costruire?
  • Come dovrebbe apparire la dashboard?
  • Quali integrazioni dovremmo supportare?
  • Cosa possiamo annunciare dopo?

Queste domande arrivano troppo presto. Devi comprendere il sistema prima di costruire le funzionalità.

Pensa alla costruzione di una casa. Non inizi con i colori delle pareti. Inizi con:

  • Le fondamenta
  • La struttura
  • L'impianto idraulico
  • L'impianto elettrico

I dettagli visibili dipendono da sistemi invisibili. Il software funziona allo stesso modo.

L'interfaccia utente è visibile. L'architettura no. Le funzionalità sono visibili. I sistemi che le supportano no.

I sistemi determinano se un software ha successo.

Le funzionalità risolvono problemi individuali. I sistemi risolvono intere categorie di problemi. Le funzionalità creano capacità. I sistemi creano coerenza.

Concentrati sulle funzionalità e la complessità cresce. Concentrati sui sistemi e la complessità si organizza.

La documentazione rivela la verità. Un sistema ben progettato ha una documentazione chiara. Un sistema progettato male richiede spiegazioni lunghe e complesse. Se un flusso di lavoro richiede pagine di istruzioni, è probabile che il problema sia proprio il flusso di lavoro.

Gli utenti non sperimentano singole funzionalità. Sperimentano i sistemi.

Gli utenti non vedono:

  • L'autenticazione
  • Le API
  • Le query al database
  • Le pipeline di deployment

Gli utenti sperimentano:

  • Affidabilità
  • Velocità
  • Semplicità
  • Fiducia

Queste sensazioni derivano dall'intero sistema.

Costruire al contrario è facile da capire. Le funzionalità stanno in uno screenshot. Puoi annunciare una funzionalità. Non puoi annunciare facilmente un sistema.

Il lavoro invisibile crea il maggior valore.

Ho cambiato il mio approccio. Ho smesso di chiedere di quali funzionalità abbia bisogno un progetto. Ho iniziato a chiedermi quale sistema sto costruendo.

Un sistema crea vincoli. Un sistema crea priorità. Un sistema crea una direzione.

Le funzionalità diventano più semplici quando le fondamenta esistono.

I prodotti di successo non hanno solo molte funzionalità. Hanno sistemi ben pensati. I flussi di lavoro sembrano naturali. L'esperienza sembra intenzionale.

Smetti di partire dalle parti visibili. Costruisci prima il sistema. Lascia che le funzionalità ne emergano.

Fonte: https://dev.to/stinklewinks/why-most-software-is-built-backwards-46i