First off, let’s just say that Devlink (www.devlink.net) is a fantastic conference. It returned to the Lipscomb campus this year, and that was a great blessing.  MTSU last year was not as nice of a venue, and some of the way it had to be organized was not as nice as both years I have been at Lipscomb. Part of it is that it is a private college, but another part is that it is a smaller college.  The food that I ate was good, the seating was nice, and the layout was awesome.  The first day we had comedian Rik Roberts during lunch, and two years ago he was the party.  The party this year was a baseball game, with a small amount you had to pay extra.  I actually missed the party to go to a different gathering, but still it was a good idea for the party. Probably the only thing negative I could say about the conference was that it was harder to find a drink, and the refrigerators weren’t as cold as the barrels of ice from previous years. And if that is the worst thing I can think of, it was a great conference. 

Second, the sessions I attended ranged from great to excellent. Paul Nielsen and I kicked off the conference for the database track (after lots of last minute prep…worst misstep were a few slides that had black text on blue).  In the afternoon I attended Tommy Norman’s Scrum/XP in Team System Deep Dive session and learned more and more about Scrum and some things you can do with Team System (I learned more about Scrum and the Team System was kind of out of my league…Why can’t we use management studio yet for Team System connectivity?). After the first day of expanded sessions, I attended the Opening Keynote by Josh Holmes, a developer evangelist with Microsoft whose topic was whether or not software development has gotten too complex.  That was the first thing that stuck in my mind.

Over the next two days, I attended lots of sessions by Brad McGehee, Kevin Kline, Joe Webb, Jessica Moss, Craig Berntson and Wally McClure. All of the sessions were great, but one of them was the second thing that really stuck in my mind. In addition, saw Tim Ford,  Jeremiah Peschka, Robert Cain, Stephen Russell and many others.

Finally, we had a taping of DotNetRocks Live. Carl Franklin  and Richard Campbell led their show (http://www.dotnetrocks.com/) “live” in front of a studio audience. Again, complexity was the topic…

And that is when I decided that I had to do a bigger write up than what I had gotten to so far. Complexity? Complexity? Complexity?!? As a data architect/programmer, this started to bug me…  In the data driven design session, Craig Berntson had really started to get me cranked up by starting to imply that data wasn’t that important. Design “process” first.  His words sounded like every developer who I have know that wanted to build the database themselves. I think we eventually go to the point where he liked having strong data assistance, but one thing I think that was presented was this:

In my database design sessions, one of the most important things I try to get through to people is that you cannot have a screen that maps to a class that maps to a table perfectly.  If you do, your database will stink, or your UI will stink.  Your classes are also going to be a mess…But wait you say…this is exactly what we do.  It is what most people do because it takes less work.  He was coming from the class side of the equation, as most people design the data first, then everything else. I would note that this is not a good idea, even if you are by trade the data architect. First comes the processes and needs of the client, then the data and everything shakes out from there.

Of course, as a data guy, I want to put up a few layers to deal with this.  One a set of stored procedures that encapsulates all interaction, and then a solid layer of software that works with the stored procedures.  Many business rules (those without any override for sure) would reside minimally in the data structures, and again in the UI to make the user happy (we all need users to be happy), and any rules that aren’t naturally handled in the structure of the data or in simple constraints, moved out to the functional classes.

Many non-data programmers would prefer that all the database did was hold the data. Even things like UNIQUE constraints that fail whenever duplicated data is inserted are too much.

What I really find interesting is that while stored procedures have been reasonably steady for 15 years, I couldn’t keep up with the number of different languages that were bantered around in the 4 or 5 hours of non-data topics I heard over the week. Ruby, PHP, VB 6, VB.NET, C#, Ajax, Python, F#, ASP, AUGH! I mean, seriously. And these are just a few. We have T-SQL. Maybe a little VB or C# for a CLR object now and again, but basically T-SQL has been around forever and is just getting better over time.  Databases that we create in 4.21 would pretty much work now.  And the stored procedures we created could have been upgraded in minutes.

The problem is partially because it seems like it is really hard to change the database, but that is more about the fact that databases have state, unlike code.  Why do you think there is COBOL code still in use?  Because the code is so hard to replace?  No, because the code is strongly coupled with data, which is hard to change because it is so valuable.  But even if the data store could not be changed, if a proper encapsulation layer had been created, well, we might have a COBOL data access layer, but would we have a text terminals still in use? I doubt it.

So if we could just work together and fortify the database and an encapsulation layer, replacing the code wouldn’t be so big of a deal.  Look, I am all about getting things done fast.  But it should say a lot that as data architects we want to do MORE work. I mean, in the short run, just getting the data normalized is win enough.  And putting on CHECK constraints, UNIQUE constraints, and Triggers in some cases would be win enough (and very little work.)  But if we do the more work up front, then later we can save our data administrating brothers (and sisters!) from having to demand code changes to optimize a query.  Which we can’t  because, based on Josh Turner’s keynote, the average tenure of a programmer is about 18 months and no one seems to understand how the code works anymore.

So, if the definition of a great conference is to get people thinking… well, I guarantee you it was a great conference for me.