Stored procedures, business logic and certifications
I was getting into it on another site with this guy who insists that you should apply business rules to data in stored procedures, going as far as to quote something either on MSDN or in a certification training book. I disagreed with him but he was sure he was right.
I brought up an example relevant to my current project where we're migrating to .NET from an old COBOL system. The datastore will be last to change from the mainframe to SQL Server. If we applied our rules on the mainframe we'd have to rewrite that code when we went to SQL Server, and that's not something we want to do. This didn't click with him.
I'll be the first to admit that the academic teaching of n-tier architecture is somewhat out of control and frequently ignores the practical aspect of a project or application. However, with service oriented architectures being all the rage in gigantic systems that combine all kinds of different technologies, I generally feel that the less you tie together the better. That's why I get all excited about ObjectSpaces. At the end of the day, I still don't want my datastore applying business rules.
The guy I was arguing with has only college experience, and is no pursuing a PhD. That's a fine and noble thing to do (my wife has two masters degrees). When he started pulling out stuff from certification texts, that's when I thought back to a recent post from someone about the relative quality and use of a certification.
In the OS/networking space, certifications are a dime a dozen, and as many hiring managers will tell you, they mean a lot less than being able to demonstrate the ability to solve problems. I don't know if this is true for programming folks, but would you hire someone with an MSCD issued last month or someone who has been using .NET since it was beta? I think the choice is obvious.