Michael Koby

This Thursday the 3rd monthly Houston Alt.NET Geek Dinner will be held at Star Pizza beginning at 6pm.  If you are interested in continuous improvement in your development or for your development team, come to the dinner.  You’ll meet others like minded and possibly learn a thing or two (I usually do).

Here are the deets again:

What: Houston Alt.NET Geek Dinner
Where: Star Pizza (2111 Norfolk, Houston, TX 77098)
Time: 6pm-ish till 8ish

For more information on the Houston Alt.NET Group, please check out the Houston Alt.NET Google Group.

Since I’ve come to Sogeti, I’ve met a lot of developers with more experience than myself.  This is a good thing, as it allows me to learn from these people and become better at what I do.  They have introduced me to processes, ideas, concepts, and methods I had never heard of.  One thing that seems to be popular though is the idea of object relational mapping (ORM for short).  The idea behind ORM is that there is a layer between your database and your application that maps objects in code to objects in the database.  Making data more “object-oriented” and thus easier to program against.

Along with the concept of ORMs comes the idea that data should be more object oriented when it is in the database.  The idea of organizing your database structures around the application rather than developing your application around your data.  I find issue with this.  What I am about to say is probably going to cause of my Alt.Net buddies to flame me, but this is how I feel and my current out look on these ideas.

For a point of reference, I want to point out that I spent years (5 to be exact) developing and supporting applications that revolved around real estate data.  The basic idea was to take MLS data and integrate it into a database schema and then use that data in several applications (both web based and windows forms based).  So I spent a lot of time working with the data, inside the database.  This probably gives me a different perspective than someone who just works with a database rather than in one.

The Argument

Let me get right to the point of my argument.  I believe that applications should be developed around the data they view and modify rather than the other way around.  The more I read about new development strategies, processes, and methods the more I see people saying this is a bad idea.  People seem to have this idea that data should be stored in a more OO way, which would make development easier.  Here’s why I think they are wrong.

Data is Relational, Not Object Oriented

Data by its very definition is relational.  An address and phone number are tied to a person.  A postion, title, and salary are tied to an employee.  All data is related to some other piece of data.  So the idea that data should be stored in a object model rather than a relational model, completely ignores the very idea of data itself.  A piece of data connects to another piece of data and the trend continues on.

Sure, viewing and developing around correctly designed relational databases is never fun, but a good database design looks at how data connects to other pieces of data, not how that data is used progmatically.

Data Drives Applications

Without data, there’d be almost no neeed for applications (unless of course we’re talking about game development).  Data drives applications, applications do not drive data.  Yes, applications view & modify data but if there was no data, there would be nothing to view or modify would there?  This is something a lot of developers forget in their search for the perfect object-oriented database structure.  Combine this point with the fact that data is realational, and you have something to really think about when talking about data in relation to application development and design.

I realize that data doesn’t always drive applications, but how many times have you gotten to a job/client and heard this: “We have some data and we’d like to be able to…”  This is something I’ve heard a lot.  Rarely do you hear “Well we need an application that does XYZ, you’ll be able to store your data here in this database.”  Such things happen but the former is more likely in most cases.  What I’m arguing here is the idea that an application should drive and help determine how data is stored in a database.

Data is Used in More Than Applications

Data is used for things (often) far beyond the application a developer is designing.  Years later, a higher level executive might want to run reports on that data.  Companies might use that data to determine their future direction and/or product launches.  When you realize this, the object-oriented data design for data doesn’t hold as much water.  Sure, your data is in a format that makes the developers job easier, but when you try to relate, things can get complicated.

Conclusion

Hopefully, at the very least, I have given you something to think about.  I understand (as a developer) the need to make developing against data easier and more object based.  Hence my understanding of the need for ORM tools like NHibernate or the (hated) Entity Framework.  I’m not saying that developers shouldn’t find new ways to make data work in their objects, but rather stop the consistant idea that applications should drive data.  Data is realtional, it drives the applications that view/modify it, and it is always used for more than you originally intended (always).

This past weekend I attended Austin CodeCamp 2008.  My first true “geek meeting” and I have to say, a ton of fun.  I got to see a co-worker present, talk to other developers, and really be engrossed in something I thoroughly enjoy.

I learned a lot of stuff and took a lot of notes (which I have photoed and uploaded to EverNote).  Once I figure out how to share things via EverNote, I’ll post a link to my notes.  For those interested, I attended the following sessions:

• Development Patterns Cage Match by Scott Lilly (notes taken)
• Principles of Object Oriented Design by John Teague & Mahendra Mavani (notes taken)
• From Minefield to Greenfield: Taming the Legacy Beast by Jimmy Bogard (notes taken)
• Reshaper-Fu by Ben Scheirman (more demonstration and discussion, no notes)
• Sarbanes Oaxley Proofing Your SDLC by Josh Handel (notes taken but not uploaded)
• Practical Uses for LINQ by Josh Handel (more demonstration, no notes)

Hopefully I didn’t get anyone’s blog link wrong (if I did let me know and I’ll correct it ASAP).  All in all the experience was great and I’d totally do it again.  One thing I need to do though is be more social.  I truely suck a being social around a bunch of people I don’t know.  I don’t ask about them, their interests, and what they work on.  Need to get better at that.

If you’re looking for some pictures, the rest are on my Flickr page in the Austin CodeCamp 2008 set.

You should specialize in application development.  A couple of weeks ago, we looked at the pros and cons of specializing as a consultant and how can hurt you long term (see Consulting Consultants: Why Specialization Can Hurt).  But after I wrote that I began thinking about my own skill sets and how I can greatly improve my abilities and make myself a better consultant.  My conclusion is what we will be looking at today.

In the article I linked above I touch on something.  That something was the idea of specializing in a programming language.  Because learning one can help you easily learn many and it can keep you billable and relevant as a consultant.  There is more to specializing in a programming language than learning more than one.  There is the logic that comes with learning how to develop and program applications that can be transferred to other areas and other platforms, services, and architectures.

You see there is a theory (or theories) and practice behind application development that will pretty much never change on a grand scale.  The idea of “Object Oriented Programming” and the theories and “best practices” behind it have not really changed over 20-25 years.  The concept of requirements building, architect-ing an application, and coding have pretty much stayed the same over the last few decades.  Sure there are new theories and ideas but the general rules stay the same.  There are different methodologies, concepts, and paths one can take in doing development.  Many of these are transferable across languages and remain extremely similar regardless if it is C++, C#, Java, or even Python.

This is why specializing in a language and and application development can give you that specialization “credit” but keep you transferable between technologies.  Programming is an incredibly logical process and that process can be applied to anything that requires problem solving abilities.  Then on top of that if you understand, lets pick Java, if you need to learn C#, the overall concepts behind application development do not change, just the syntax for developing the logic and algorithms.

I am definitely still of the opinion that you should not specialize too much on one technology and platform because that causes you to (in many cases) want to use that technology/platform to solve all the problems you encounter.  I think that a good consultant understands several tools (even if they are not experts on those tools) and can determine the best solution for the problem at hand.

However, I do think there is some value in specializing in a particular programming language (with the intent to learn others) and understanding development concepts, theories, and methodologies.  You start with one a single language and then move through the others as you need to.  The .Net platform is not always the best solution (neither is Java, Python, or C) but a solid understand of a single language can help you move across others with ease.