This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: So what if the contract's first?
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
I've been following the contract-first stuff going on for the last while in some disbelief. The assertion that "defining" the contract FIRST will somehow make the system better hasn't even gotten to the sparse anecdotal evidence stage. But, the idea of contract-first is not new - there have been proponents of this school for ages, many of them coming from old-school waterfall methodologies.
In the real world, when developing a new system, or any new piece of code that has an interface for the outside world to interact with it, you don't know enough to fully define the contract/interface, be it first, second, or third. In most cases, you start with a partial interface, start implementing it, change it, go on with some other parts, return to the first part, change it again, and on, and on, and on. It's a discovery process where you bounce between interface and implementation many times.
There something hiding behind that concept "contract-first", and it's "contract-once", which I believe is anti-thetical to how software is really built.
There's no reason web services with wsdl should be any different.
Previous Topic
