Come si bilanciano le esigenze contrastanti di compatibilità e innovazione all'indietro?

Question

Lavoro su un'applicazione che ha un'interfaccia sia grafica (grafica) che API (scripting). Il nostro prodotto ha una base installata molto ampia. Molti clienti hanno investito molto tempo e sforzi nella scrittura di script che utilizzano il nostro prodotto.

In tutti i nostri progetti e implementazioni, abbiamo (comprensibilmente) un requisito molto rigoroso per mantenere il 100% di retrocompatibilità . Uno script eseguito in precedenza deve continuare a funzionare esattamente allo stesso modo, senza alcuna modifica, quando introduciamo una nuova versione del software.

Sfortunatamente, questo requisito a volte ci lega le mani dietro la schiena, in quanto limita davvero la nostra capacità di innovare e trovare nuovi e migliori modi di fare le cose.

Ad esempio, potremmo trovare un modo migliore (e più utilizzabile) per raggiungere un compito che è già possibile. Sarebbe auspicabile rendere questo modo migliore il modo predefinito, ma non possiamo farlo poiché potrebbe avere implicazioni di retrocompatibilità. Quindi siamo bloccati a lasciare il nuovo (migliore) modo come modalità, che l'utente deve " attivare " prima che diventi disponibile per loro. A meno che non leggano la documentazione o la guida in linea (cosa che molti clienti non fanno), questa nuova funzionalità rimarrà nascosta per sempre.

So che Windows Vista ha infastidito molte persone quando è uscito per la prima volta, a causa di tutto il software e le periferiche che non funzionavano su di esso, anche quando lavoravano su XP. Ha ricevuto una ricezione piuttosto negativa a causa di questo. Ma puoi vedere che Microsoft è anche riuscita a fare alcune grandi innovazioni in Vista, a scapito della retrocompatibilità per molti utenti. Hanno preso un rischio. Ha pagato? Hanno preso la decisione giusta? Immagino che solo il tempo lo dirà.

Ti trovi a bilanciare le esigenze contrastanti di innovazione e retrocompatibilità? Come gestite l'atto di giocoleria?

Answer 1

Per quanto riguarda la mia esperienza di programmazione, se ho intenzione di cambiare in modo sostanziale qualcosa che impedirà il corretto utilizzo dei dati in arrivo passati, devo creare un livello di astrazione per i vecchi dati in cui possono essere convertiti per l'uso nel nuovo formato.

Fondamentalmente ho impostato il "migliorato" come impostazione predefinita e assicurarsi che tramite un convertitore possa leggere i dati del vecchio formato, ma salvare o archiviare i dati come nuovo formato.

Penso che la cosa importante qui sia test, test, test. La compatibilità con le versioni precedenti non dovrebbe ostacolare i progressi in avanti.

Questo è solo il mio 2c

Answer 2

Dividi lo sviluppo in due rami, uno che mantiene la compatibilità con le versioni precedenti e uno per una nuova versione principale, in cui chiarisci che la compatibilità con le versioni precedenti viene interrotta.

Answer 3

La domanda fondamentale che devi porre è se i clienti vogliono / hanno bisogno di questo "miglioramento" anche se lo percepisci come quello che potrebbero non essere i tuoi clienti. Una volta stabilito un certo modo di fare le cose, cambiare il flusso di lavoro è molto "costoso" operazione. A seconda della serietà del computer degli utenti, potrebbe essere necessario molto tempo per adattarsi alla modifica dell'interfaccia utente.

Se hai a che fare con l'innovazione dei clienti per il bene dell'innovazione non è sempre una cosa divertente come potrebbe essere per te sviluppare questi miglioramenti.

Answer 4

Potresti sempre cercare modi innovativi per mantenere la retrocompatibilità.