Why Change?

Pretty sure this happens to everyone. One day, some higher authority comes along and tells you that what you have been doing is not quite "right" anymore and there is a new way of doing things. Not only that, along the way, while you are in transition, even the new way is changed. What do you do? Do you change your ways of doing things?

This is how I perceive Microsoft's data access technology. Don't get me wrong - it is great to have choice and the future of data access is getting better (okay I am hopeful and I am not even blaming Al Gore on this one). I joined the data access technology evolution in middle 90's. Back then we have ODBC, OLE DB, and ADO. Programming with recordsets in ADO in VB 6 has always been cumbersome, but had my fun of coding. While Not rst.EOF .. Wend anyone?

Then early 2000's, started with .NET 1.0, quickly became 1.1 in 2002. We were introduced to ADO.NET. Between ADO and ADO.NET, there were a lot of changes (besides the addition of .NET). Old way of doing things was not recommended. Now we had datasets and datareader, and data adapters. The relational database is still there (and it will be there for awhile!), but how we shuffle the data between the application tiers was altered. Besides the data access, finally OOP became first class citizen in VB.NET. And that's when I switched to C#. I was getting too confused between VB-6 and VB.NET, but still I did application development in VB.NET. Besides it is really not too hard to program between the languages. It all comes down to Common Language Runtime (CLR. Not a big fan of language wars... just use the right tool for the right job. Maybe Ruby on Rails...

Meantime I delivered and worked with ADO.NET 2.0 projects along with ASP.NET. Things were working out okay, then around 2003, started hearing about eXtreme Programming (XP), writing tests first like Test Driven Development, then came Ajax. Was not quite getting it for awhile. But the best thing to learn a new technology is doing a project with it. Using NUnit framework, did a few applications I realized how easy and fun to write code and test it right there, without launching the debugger, using Asserts and such. And I changed once again and I don't ever want to go back to the old way, especially for enterprise applications. Like Michael Feathers tells you in his book "Working Effectively with Legacy Code", legacy code is code which does not have tests.

In 2005, I attended my first Professional Developers Conference in Los Angeles. The highlight of this conference was the announcement of Linq (stands for Language Integrated Query). Using this colorful, a little terse (at first) syntax, one can get intellisense code from the database. Thought it was very powerful and can't wait to use it. Just as ramping up with this Linq-to-SQL technology (by the way, it only worked with SQL Server), and I was supporting a few Oracle databases (I was using Oracle's .NET library and there is no Linq in that). Thus I did not get ramp up too far ahead.

Meantime around 2007, we heard another technology called ADO.NET Entity Framework. With EF, other databases besides SQL Server can also be accessed using entityclients and object contexts. It's not even done yet. After version 1.0, Microsoft is delivering EF v.4 (what? is that a typo? no, that's MS. they can do that, ver.2 & 3. are skipped) Here we go again...

My point is the change is going to happen, whether you like it or not. If you don't change, you take the risk of being obsolete. Be flexible and learn the new technologies. Master them as much as you can, but when it is time to jump and move on, do not resist and adapt as soon as you can. Software project delivery time-lines are usually set aggressively. How do you factor this in your project delivery timeline. Hmmm.. That may be another blog post.

Again the mantra is sometimes, the old technology is fine and it works, hopefully testable. Now do we want to change it? It works, right?. Is it worth changing it? Maybe. But I know I will be changing, hopefully for the better when it comes to data access.

References:
Working Effectively with Legacy Code