Code Camps and Revisiting a Common Theme

Adam Machanic — Sat, 29 Sep 2007 19:33:00 GMT

Today I gave two talks at New England Code Camp 8. A fun experience as always, and for those of you who were in my talks and are looking for decks/code, please see this post and this post from when I did slightly different versions of the same talks earlier this year as MSDN Webcsts. I am not quite ready to publish the decks I used today.

But the topic of this post is not so much the code camp as an observation about what I saw there. Recent posts by both of our resident Andys (Kelly and Leonard) share the theme of organizations treating their database staff as next-to-worthless. And developers, in general, seem much more interested in other facets of development than all of that "database stuff."

Today's code camp proved this once again; my two talks were both quite lightly attended, even though I was talking about important issues around data security and exception handling--things that any developer working with data should get. Perhaps it's just me, but the evidence says otherwise: after my talks I peeked into a few others and found a standing room only session on Silverlight and a session on LINQ to SQL that had a comparable number of attendees to what I'd had.

Why is it that data, while the foundation of any business application, is not a draw to the developer masses? How can we ignore the data and instead focus on creating spiffy new UIs (to display flawed data, no doubt)? Perhaps data seems easy--if you know how to write a query and set up an ADO.NET connection, that's all you need, right? Or perhaps data is just someone else's job--just let the DBA or database developer handle it and display anything that comes back, flawed or not. It's not your problem, you're a UI developer. But everyone can't be a UI developer, can they? Someone has to take control of the data.

Bad data can and does lead to project failure. If you're a UI developer you're going to get canned just as quickly as the DBA if you're project is no longer being funded--so if your UI displays bad data, you are just as guilty as whomever designed the database that returned it! If you're a business tier developer, you are just as responsible for data validation as the database developer!

Alas, if you're reading this post you're already one of the converted. This is SQLblog.com, so you obviously care enough about your data to read up on it a bit more. But as developers who know the value and importance of data, it is our job to spread the data gospel. Data issues around security, validation, and performance are every developer's responsibility.

Adam Machanic : developers, code samples

Code Camps and Revisiting a Common Theme