Should an interface be stable when semantics are not?

I know an architect who is developing an enterprise service for the passing of contracts from one system to another, (document metadata, not the image).  He knows the needs of the destination system very well, but he defined an interface that is not sufficient to meet the needs.

The interface describes the subset of data that the source system is prepared to send.  The source system is new, and will be released in iterations.  Eventually, it will send all of the data that the destination system needs.

In the mean time, it will send only a subset.

For some reason, he wants the interface to change with each iteration.  And thus, he will create the service repeatedly.

This thinking is typical: define what you need, refactor as you go.  The problem is that it ASSUMES that no one else ever needs to call your service or use your service.  It assumes that no one else will get to the destination system first.  In short, that you know everything.

The justification: we will change the destination system when the source system comes online.  Since we will not change it right now, there is no need to model the interface.

What do you think?  Should the interface describe all of the data that will eventually be needed, even if neither the source nor destination systems can leverage all of it yet?  Should there be a different interface each time the behavior of the destination system changes?

Comments

• Anonymous
  November 02, 2006

1. My first question would be.  Is he iterating it to production, or is he still in development.
2. My first thought is, "Wow, he must have a REALLY complete continous integrations solution in place.  One that will allow him to roll from Dev, to Test, to UAT, to Production all at the flick of a button. If the answer to 1 is "Development" and the answer to 2 is, "Yep, he sure does" the my response would be, 'Yes, change on each iteration. Mind you, a lot of this is contingient on your statement that he knows what he's building inside and out, and my assumption that he knows that there will be a few unexpecteds here and there. Otherwise, the approach seems to fly in the face of conventional wisdom.

• Anonymous
  November 02, 2006
  Hello Malcolm, The answers to your questions are "production" and "no, he has no automated deployment system."  In fact, it costs a LOT of money, time, and effort to make a single production change.

• Anonymous
  November 03, 2006
  Oh, well in that case, my uneducated developer opinion is, "Wow, sounds dumb as mud". Unless he is trying to drive towards an automated deployment system.  If he makes it painful for his team to get their job done, the WILL find a way to make it less painful. But it sounds like this guy isn't that devious.

• Anonymous
  November 03, 2006
  I think you should strive to have your contract stable - but don't make a religion out of it. So changing the contract every month is, in my opinion, not a good idea - even during development (if other development teams are dependent on that contract) By the way, you may want to read a short blog I did on when to change a contract version http://www.rgoarchitects.com/blog/PermaLink,guid,cabee589-69b7-497e-8ec9-d2fad050df2c.aspx