Selezione del design dell'applicazione (giusto?) [chiuso]

Dipende da quanto sarà facile convincere i poteri a buttare via il prototipo vivo.

Si vede non appena il prototipo / proof of concept, diventa attivo, diventa un vero sistema live. E i "poteri che sono" vorranno che tu apporti modifiche e cambiamenti, e mentre questo accadrà otterrà un uso reale del mondo, e quindi non è così facile da sostituire.

E apporti queste modifiche e correzioni, la base utenti crescerà e la qualità esterna del sistema migliorerà e la qualità interna si ridurrà. E gli aggiornamenti diventeranno sempre più difficili, più lenti e lenti, e il debito tecnico crescerà e crescerà.

E dirai, dobbiamo sostituire il sistema, è sempre stato supposto essere una prova di concetto, e diranno, ma funziona, e abbiamo speso così tanto tempo e denaro per farlo, sicuramente può continuare, e se si piegano alle richieste, si continuerà, e la qualità interna affonderà e affonderà, e 1 anno dall'inizio, non riconosceranno nemmeno che si trattava di un prototipo da buttare via, e sarete ammassati dagli incubi di manutenzione e domande sulla qualità della tua implementazione.

Ho imparato a mie spese, fallo bene la prima volta. Alcuni turds sono difficili da affondare.

For a startup, what are the pros and cons of building a software product predicated on "Throw away code" vs "an extendible codebase"?

In realtà, se esprimi la domanda come "uno o l'altro", potrebbe ridurre significativamente le tue opzioni. Mi sento come se avessi già risposto ai pro e ai contro nella domanda, quindi proverò ad esercitare la vera domanda:

Non conosco una singola storia di successo di startup in cui le persone si prendano il loro tempo per costruire un buon sistema. Il time to market è il re e, come hai detto tu, andare controcorrente può aumentare significativamente il rischio di andare fuori mercato.

"Fare bene" ha seri problemi nei primi momenti di una startup. Uno, richiede ingegneri esperti (che richiede denaro); due, richiede un tempo illimitato (dipende dalla complessità del prodotto e dall'esperienza degli ingegneri con questo tipo di sistema). Infine, sappiamo tutti che non hai bisogno di un buon design per essere in attività, hai bisogno di qualcosa che funzioni e dei cui problemi sono nascosti i tuoi clienti.

Praticamente qualsiasi esperienza di avvio che conosco (e probabilmente ogni singolo famoso) ha tratto grande vantaggio da questo fatto: se parte del tuo prodotto è di scarsa qualità, ma quella parte è invisibile al cliente (o il suo potenziale desiderio non è significativamente influenzato da esso), non perdere tempo a migliorarlo, basta spedirlo.

Ma questo è "tempo 0" nella scala temporale. Nel tempo t > 0 inizi a imparare ciò che la maggior parte delle startup apprende nel modo più duro: la scarsa qualità di quelle parti invisibili sta limitando le tue attuali opportunità. Cioè, il team ha bisogno di molto più tempo per implementare nuove funzionalità, questi vengono spediti a metà cottura, i bug sono bugging dei clienti e li fanno arrabbiare, ecc.

tangente : a questo punto, si spera che il manager conosca il peccato capitale dell'ingegneria del software e che non cada nel mito del mese uomo .

La differenza che fa la differenza qui è sapere in quale momento t dovresti fare una pausa, tenere i cavalli e fare un po 'di fatica nella pulizia della casa prima di affondare (e quanto tempo dedicato a e quanta pulizia dovrebbe da fare).

In altre parole, questo non viene risolto selezionando una volta "Throw away code" o "extendbase codebase" una volta all'inizio, chiudendo gli occhi e correndo nella direzione scelta. Puoi risolverlo mettendo il "tempo" nell'equazione e riconoscendo che c'è una domanda che dovresti fare di volta in volta, e di tanto in tanto potrebbe richiedere risposte opposte.

In sintesi, invece di avere un pick-two-triangle statico "time vs. cost vs. quality", mettili in una scala temporale:

link

Ora, prendi in considerazione che, a qualsiasi t , cost e time per lo sviluppo di una funzione dipende dal% co_de risultante del prodotto a quality . In altre parole, quanta qualità di design hai deciso di investire in questo momento è la dimostrazione di quanto siano economici o onerosi gli sviluppi futuri (quindi, t-1 è la variabile che ti dice il costo del tuo futuro).

Se sei un manager, questo punto di vista può darti più indizi su come gestire la tensione tra qualità del design e time to market. E questo è qualcosa da gestire costantemente.

Infine, gli ingegneri esperti sono ottimizzati per il design. E se ne avete di validi, potete farvi condizionare i vincoli di tempo e faranno uno sforzo significativo nella selezione delle parti critiche del sistema da dedicare alla progettazione e al collaudo, e lascerà che le parti meno critiche siano di minore qualità - sanno che questi hanno pasticci che sono più facilmente gestibili e il compromesso per la consegna rapida paga. Puoi anche contare su di loro per fare delle pause alle richieste in arrivo e dirti che questo è il momento di quality che dovrebbero fermarsi e lavorare sulla base del codice per fare spazio a nuove manovre. In altre parole, quello che stai facendo è "ammortizzare" il costo totale di una buona progettazione (e rischi) diffondendolo attraverso parti prioritarie del sistema e nel tempo.

Siete sicuri che consegnerete "soluzioni estendibili" - che non si trasformeranno nel "prototipo" a causa di vincoli di tempo e requisiti imprevisti?

Credo che quello che succede più spesso sia che il "prototipo" diventa il prodotto - con tutte le sue imperfezioni e imperfezioni funziona ancora. Le startup che vanno per la soluzione definitiva spesso finiscono per essere finanziate e non vengono mai consegnate.