His mentality reminds me of a co-worker from a couple of years ago. He was a contractor on the job in charge of creating the client app for mobile devices which would communicate via web services to the server app. Here are a couple of examples.
1- He didn't think that the posted XML to the web service should be rejected if it was badly formatted - it should never be rejected regardless of format or data quality issues. Part of his reasoning was that there was no way to test his data serialization code sufficiently to be sure it would always be correct. In fact he went so far to say "can my client app reject the server's response if it doesn't like what it sends back?" We said "sure - just have your app re-post as many times as it wants until it gets an answer it will accept" ;-]
2- Part of his client app was a feature to download credentials to support local authentication (only someone with credentials registered in the central db should be able to get into the client app itself). During the discussion of the response XML format, a pretty standard structure like <cred><user>xxx</user><pass>xxx</pass></cred> was defined. Since the protocol was HTTPS and the passwords were encrypted, we were comfortable with this feature. Well, he planned on having his app hold that data in a particular format - encode the user:pass pair in to a single value. So he asked that the data be returned to him like that. When we decided not to for various reasons, primary of which was to not return data specially structured for one of the several web-service clients, he went a step further and declared that that's the way it should be held in the db to begin with....a single column with user/encrypted-pass pairs encoded. His reasoning was that it's faster to do the final db scan on a single column than against two, never mind other functionality that an application may need (say, getting a list of users). Now, this wasn't just a suggestion of his, he was adamant that that's the way it should be and there was no reasoning with him.
suzilou