title: How do you balance the conflicting needs of backwards compatibility and innovation?
body: <p>I work on an application that has a both a GUI (graphical) and API (scripting) interface.  Our product has a very large installed base.  Many customers have invested a lot of time and effort into writing scripts that use our product.</p>
  
  <p>In all of our designs and implementation, we (understandably) have a very strict requirement to maintain 100% <strong>backwards compatibility</strong>.  A script which ran before must continue to run in exactly the same way, without any modification, when we introduce a new software version.</p>
  
  <p>Unfortunately, this requirement sometimes ties our hands behind our back, as it really restricts our ability to <strong>innovate</strong> and come up with new and better ways of doing things.</p>
  
  <p>For example, we might come up with a better (and more usable) way of achieving a task which is already possible.  It would be desirable to make this better way the default way, but we can't do this as it may have backwards compatibility implications.  So we are stuck with leaving the new (better) way as a mode, that the user must "turn on" before it becomes available to them.  Unless they read the documentation or online help (which many customers don't do), this new functionality will remain hidden forever.</p>
  
  <p>I know that Windows Vista annoyed a lot of people when it first came out, because of all the software and peripherals which didn't work on it, even when they worked on XP.  It received a pretty bad reception because of this.  But you can see that Microsoft have also succeeded in making some great innovations in Vista, at the expense of backwards compatibility for a lot of users.  They took a risk.  Did it pay off?  Did they make the right decision?  I guess only time will tell.</p>
  
  <p>Do you find yourself balancing the conflicting needs of innovation and backwards compatibility?  How do you handle the juggling act?</p>