Rendere le cose funzionanti e poi migliorarle, o tentare di renderle "perfette" dall'inizio?

Hai sentito solo una parte dell'idea. Diversi metodi iterativi, come Test-Driven Development (TDD), consigliano di far funzionare il codice (per TDD: superare i test) il prima possibile. Il punto è che puoi ottenere un feedback prima nel processo di programmazione e adattare il tuo progetto alle reali esigenze.

Negli attuali ambienti di lavoro, questo modello di realizzazione di un implacabile ma imperfetto impianto, ottenendo informazioni con esso, e quindi migliorando e acquisendo nuove informazioni, viene utilizzato pesantemente quando si esegue una programmazione Agile. Il punto cruciale è che non lo fai per rielaborare, ma perché i requisiti non sono chiari all'inizio del progetto e non c'è semplicemente alcun modo per ottenere un risultato accettabile dall'inizio perché "accettabile" non è definito ancora.

Il concetto ha ben poco a che fare con una pianificazione e un pensiero meno accurati. Riconosce solo che la pianificazione e il pensiero sono spesso inutili quando tu e l'utente non riesci a vedere il prodotto finito a metà e ottenere un feedback in anticipo.

Il mio consiglio rapido sarebbe che, se puoi, cerca di essere il più vicino possibile dalla seconda scelta.

Tuttavia, se sei nuovo a qualcosa, se riesci a farlo funzionare prima, è già fantastico, credo.

Perché scoraggio il "finché funziona!" modo di pensare? Beh ... il più delle volte, tu sei colui che dovrà mantenere il tuo codice, per capirlo anche in sei mesi senza averlo toccato per mesi, ecc. Quindi, se devi passare ore, trova qualche mal di testa, solo per capisci di nuovo il tuo codice (e solo così sarai in grado di lavorarci di nuovo), è un po 'stupido. Quanto è più piacevole quando hai impiegato un po 'più di tempo a fare qualcosa di meglio e poi non perderai più tempo quando dovrai lavorarci sopra, ecc.

E anche se, in futuro, non saresti tu a dover lavorarci sopra, pensa agli altri, poiché è ancora più difficile capire il codice di qualcun altro.

E sì, anche la codifica corretta è spesso contraria a "farla funzionare e basta". Se il tuo codice non è facile da capire (forse grazie ad alcuni commenti in aggiunta), è più probabile che non sia codificato affatto.

La perfezione costa molto più denaro di "funziona" e tutto quel denaro deve essere speso prima che il prodotto venga spedito a un cliente. Molti prodotti perfetti non sono mai stati finiti - non sono mai stati usati dagli utenti reali per risolvere un problema reale, perché lo sviluppatore ha perso interesse per i soldi rimasti prima che arrivasse. L'altro estremo - "fallo funzionare" significa che rischi di passare tutto il tempo a correggere i difetti su una palla di fango mal strutturata. Molti clienti hanno scoperto che lo sviluppatore ha perso interesse e / o ha finito i soldi riparando la palla di fango.

Quindi la realtà è che è necessario un equilibrio. Deve essere abbastanza buono da essere abbastanza affidabile da essere utilizzabile, e abbastanza buono da essere manutenibile, senza essere perfetto. Nella mia esperienza di oltre 30 anni, la "perfezione" è una ragione più grande per il fallimento del prodotto di "palle o fango".

Agile, TDD sono considerati metodologie moderne che affrontano il problema di trovare quell'equilibrio, affrontando il problema a livello micro (e, g, sprint) e fermandosi quando una metrica di qualità determina il suo "buon enuf" e "adattamento" per scopo "spesso si presume che la macro sia anche indirizzata (es. Spedizione di un nuovo sistema di fatturazione aerea). Tuttavia, a livello macro, le considerazioni non tecniche (legali, commerciali e di altro tipo) spesso impediscono che un simile approccio funzioni come promettono alcuni evangelisti.