Resta semplice ora, o programma con il futuro in mente?

Se la scadenza è Scolpita nella pietra, basta finire ciò che devi incontrare. Assicurati di gonfiare le stime per v2 in modo da tenere conto delle modifiche al codice per il nuovo requisito. Assicurati anche di documentare brevemente ciò che pensi che sarà necessario modificare per le nuove funzionalità di v2 in modo che un collaboratore possa prenderlo se sei riassegnato a qualcos'altro.

Se c'è abbastanza flessibilità nella scadenza (1 giorno, dal suono, quindi mirare per 2,5 giorni di estensione) quindi sicuro, andare avanti e codice per il futuro noto!

Evita di cadere preda (in anticipo) al Secondo effetto di sistema . Ecco alcune buone tecniche da applicare:

1. Sicuramente evita la de-railing della versione 1 solo a causa di ciò che vedi apparire nella versione 2. pianificare in anticipo va bene, ma il creatore delle specifiche v2 dovrebbe essere responsabile del fallimento di v2, non di v1.
2. (Se possibile) vedi se puoi far sì che il creatore ri-lavori i requisiti per la versione 2 che non richieda le modifiche più grandi ora - e poi pianificali per dopo, forse per la v3.
3. Tieni presente YAGNI , ma prova a codificare per l'estensibilità in mente - evitare numeri magici, valori hard-coded, scrivere buoni test unitari o contratti di codice, ecc. L'applicazione tempestiva di buone tecniche renderà meno doloroso il refactoring e le modifiche al codice lungo il percorso.

La maggior parte dei progetti software che crescono come città hanno successo nel lungo periodo. La pianificazione evolutiva solo nel futuro limitato consente al tuo software di essere rilasciato in tempo e con le funzionalità richieste al momento del rilascio, e non di più. Vedi questo estratto da Carl Sagan:

The arrangement [of a city] might be more efficient if all civic systems were constructed in parallel and replaced periodically (which is why disastrous fires—the great conflagrations of London and Chicago, for example—are sometimes an aid in city planning). But the slow accretion of new functions permits the city to work more or less continuously through the centuries.

• Carl Sagan, Cosmos: http://www.eridanus.info/genesis.html

Non aggiungere codice oggi per il requisito del mese prossimo. Oggi dovresti scrivere il codice più pulito che puoi per i requisiti che hai. Sono scettico sul fatto che un giorno di lavoro ora salverà più giorni dopo. Ho sentito affermazioni del genere e non riesco a ricordare un singolo caso in cui fosse vero. Potresti essere in grado di convincermi mostrando un codice, ma la mia esperienza mi dice che è improbabile.

Lascia come è.

Gli sviluppatori in realtà APPREZZANO un progetto legacy che fa ciò che deve fare e non di più.

Quello che oggi può sembrare una buona idea per "mettere in scena" la base di codice per soddisfare un requisito "futuro", con tutta probabilità fungerà da ostacolo alla comprensione del codice in futuro. A nessuno piace occuparsi di funzionalità parzialmente implementate e tracce di requisiti fantasma dimenticati. Non sto dicendo che sarà il caso, ma le cose spesso si rivelano così nonostante le migliori intenzioni.

Buone risposte. Vorrei solo aggiungere - quello che faccio in un caso come questo è prendere una buona diff in modo da poter catturare quello che ho fatto e scoiattolo via in un luogo sicuro. Quindi se l'opportunità arriva a farlo di nuovo nella prossima versione, sarà facile.

In generale, un buon sviluppatore anticipa i requisiti futuri, ma quando una scadenza è imminente, è il momento di rispondere ai bug in quello che hai già ottenuto e non "scalare la barca".