Relevant Quote Link
The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach? http://geekswithblogs.net/dmillard/archive/2004/11/09/14651.aspx
If contract-first means wrestling with the nine-headed monstrosity known as Hydra, er, I mean, XSD, then it's doomed to failure...But the "everyone just wants to write classes" meme is WRONG (yes, I'm shouting) and the teams at Microsoft that believe it are doing a great disservice to their customers by crippling the toolset...

I don’t know if they believe we (the great unwashed masses of programmers) are just too lazy, too stupid, or too ignorant to handle message-oriented programming, but they clearly don’t think we can handle it...

I’ll believe Microsoft is serious about SO when the “Whitehorse” tools include a GUI facility for building messages (not classes!) and that tool generates schema and compileable code that can be tweaked by developers... 		 http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
Let's face it, big SOA / integration projects like Government, Inusrance, Pharma (the list goes on) starts with massive pre-defined schemas and large numbers of non MS systems. WSDL is defined based on those schemas and then a contract is implemented as client or server using .Net or whatever.  http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
Contract-First Development doesn't go far enough. The CBDI Forum advocates an extended version of Design by Contract, including Pre/Post Conditions, QoS and Commercial Contract ...  http://pluralsight.com/blogs/aaron/archive/2004/08/27/2092.aspx
I design my contracts using the built in XML and XML Schema editor's, but ultimately end up stiching the WSDL file together by hand. http://blog.hackedbrain.com/archive/2004/08/31/163.aspx
Its this ability to have reusably defined types and easily assemble them into XML document definitions that we're looking for. Also, it would be great to have software that let you "harvest" the types present in XML document schemas and WSDLs to encourage type reuse, or for better searching amidst a sea of interface definitions. http://blum.typepad.com/coarsegrained/2003/11/xml_schemas.html
Now, as a software developer, one's sole interest in contract-first development should be in defining the inputs and outputs of one’s software, and in ensuring that, if necessary, those inputs and outputs can be represented in a platform-independent format...

The XML becomes a fetish, falsely imbued with the true virtues of contract-first development.		 http://blogs.msdn.com/craigmcmurtry/archive/2006/02/01/522353.aspx
This morning I had the simplest class, marked Serializable, and ran it through an XmlSerializer test just to "be sure". Little booger started throwing those weirdo XmlSerializer exceptions. They are so hard to understand, even if you look at the InnerException, its enough to make you go stark, raving mad.

Finally, I thought, "How about doing it backwards?" In other words, Let's write the XSD Schema and be happy with it. Then, we just fire up XSDObjectGen and let the tool generate the class, right?

Well, it serialized perfectly right out of the box. I had gotten a property assignment wrong (mistakenly assigned to the public field instead of the private one in the ctor).
http://petesbloggerama.blogspot.com/2005/07/interesting-story-about-contract-first.html
Interface constraints or restrictions cannot be expressed exactly enough using programming languages. For example: "enumerations of concrete values" or "date vs time" etc. Interface very often contains only subset of the internal domain data, maybe even transformed, often restricted. A separate layer of mapping is usually anyway requred. http://dev-blog.blogspot.com/2005/11/desing-web-services-contract-first.html
The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them. The problem here is WSDL itself: it’s an arcane, obtuse vocabulary that isn’t very human-readable. I don’t think it does a good job of describing web services in the same way that people actually think about them http://hyperthink.net/blog/PermaLink,guid,efd237dd-029b-4e51-91e4-711a8660c7c8.aspx
The insurance industry has two standards Origo and Accord. Both contain vast schemas detailing all the industry types and even message flows. Therefore the design of an SOA system will include message design and then the WSDL. The WSDL will define services based on these pre-defined types from these schema (such as a "policy" or a "customer" etc.). Once the WSDL has been built all the different parties involved can begin developing simultaneously against the contract in .Net or Java or KSH scripts and PERL if you like.
If you tried to do this the other way around you'd be in a world of pain...

minOccurs and maxOccurs just can't be represented using the code first approach. There's a huge impedance mismatch between .NET and Xml Schema.		 http://pluralsight.com/blogs/aaron/archive/2004/11/11/3440.aspx
I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA.  http://www.users.globalnet.co.uk/~rxv/so/2004/12/contract-first.htm
WSDL is even more tragic. XSD’s ugliness mostly hides in the plumbing where civilians don’t have to go near it, but WSDL is in the customer’s face; as Nelson Minar of Google once told me, “The WSDL should be the .h file for my Web-services application.” Indeed, but WSDL as it stands is not something that wins friends and influences people. Even if it’s too late for WS-* to untwine itself from XSD, maybe there’s still a hope for finding a better way to publish service interfaces? http://www.tbray.org/ongoing/When/200x/2004/10/21/Sells 
"Maybe one of the biggest misconceptions is to allow the ASMX runtime to automatically create the WSDL (Web Services Description Language) for a given Web service implementation.

This nice feature leads to a wrong approach to Web services. A lot of developers tend to just take their business logic classes and place a WebMethod attribute in front of those methods that should be accessible via SOAP. They neglect the fact that on the wire there are messages and that they must not think in .NET and its common type system for achieving interoperability and integration."

"There are basically two philosophies for contract-first design: code-based and schema-based. Code-based means that a developer still uses a CLS-compliant programming language to write down the interface of their Web service. ... I consider this a bit dangerous because it still centers on objects and the .NET BCL. Additionally, it does not hinder a developer to expose .NET idiosyncrasies like a dataset." 		http://www.code-magazine.com/Article.aspx?quickid=0507061