When I Was Your Age...

Back Draft

When I Was Your Age...

By Jonathan Goodyear

We ve all heard the phrase, usually spoken by our parentsor grandparents and usually when we re taking advantage of a modernconvenience that wasn t available when they were younger. They feel compelledto tell us how tough things were when they were our age, and how lazy we arenow that technology has made things easier for us. There are certainly olderprogrammers among us who tend to be curmudgeons when it comes to some of thenew programming techniques being used today. I have to resist this myself allthe time. But are such attitudes valid in some cases?

Whenever a new programming technology is released, itabstracts away the details of what is going on under the hood. The obviousadvantage is that programmers can get more work done in less time. The tradeoffis that there is an inherent loss of control over the underlyingimplementation. Consequently, many programmers never bother to learn thedetails of what the new technology is abstracting away from them, making itexponentially harder for them to diagnose problems that arise out of thattechnology s use. Joel Spolsky coined the term The Law of Leaky Abstractions to define this concept (http://joelonsoftware.com/articles/LeakyAbstractions.html).

One of the main points that Spolsky makes in his essay isthat programming abstractions are designed to make work more productive forprogrammers who already know how the underlying technologies work. The truth ofthe matter is that programming abstractions are usually used to commoditizeprogramming and bring it to the masses of people who have absolutely no ideawhat is happening under the covers. I will admit that were it not for the grandprogramming abstraction known as Visual Basic, I (an accounting major incollege) would never have gotten the opportunity to enter this incrediblecareer field.

I realized early on that I had a lot to learn and havedone my best to fill in the gaps of my knowledge, but it is hard for anyone tokeep up with the intricate details of every technology that comes our way. So,the larger questions become, which abstractions are good enough to use now,which will eventually be good enough (through our friend, the service pack),and which ones may never be good enough. Also, is a technology sometimes a goodalternative, and sometimes not?

The concept of Object Relational Mappers (ORM) springs tomind as an abstraction concept that is under intense debate lately. Several ORMtools, such as LLBLGen and SubSonic, have been out for awhile. They usuallyprovide a one-to-one mapping between database entities (tables, views, etc.)and programming objects in your favorite .NET language. More recently, Microsofthas released LINQ to SQL, and will be following up in a few months with LINQ toEntities. LINQ to SQL is very similar to the other ORM technologies that Imentioned, but adds several language enhancements that make its implementationeven more powerful. LINQ to Entities goes one step further by allowing thedeveloper to define the mappings between objects and multiple database entities(or vice-versa).

Both LINQ to SQL and LINQ to Entities, however, stillsuffer from the limitation that you have little to no control over the T-SQLthat these abstractions generate to actually interact with the database. If youhook up SQL Server Profiler and look at some of the queries that are beingexecuted against your database, you may be horrified at what you see. Manyindustry experts are skeptical about whether ORM technology can scale toenterprise systems, and recommend the tried-and-true approach of using vanillaADO.NET to call database stored procedures.

I used to be in that camp, but after using various ORMtechnologies over the past couple of years, I now take a middle-of-the-roadapproach. I agree that some of the most demanding enterprise applicationscannot afford any performance degradation, and require their databaseinteractions to be tweaked to exact specifications. However, I think that manyof the naysayers miss the point that ORM technology can be safely applied to morethan 90% of the software applications being built today. Most of them are Lineof Business (LOB) applications that won t feel the load of thousands ofconcurrent users, or have to deal with terabytes of data. They are being builtby average programmers who are looking for any possible advantage to help themmeet their deadlines.

Truth be told (and don t take this the wrong way), mostprogrammers in this industry would fare much worse performance-wise if theyattempted to do everything manually. That is why we buy third-party componentsfrom trusted vendors who are experts in their particular technology niche. Thisallows the average programmer to accomplish tasks that simply would not haveotherwise been possible. One thing I would definitely recommend, though, isthat each programming team have one or two senior programmers (or access tothem via consulting or other means) who are good at debugging, in order to getyour project over the hump when you run into one of the leaks in theabstractions that you choose to implement. You don t want to give back all thetime you initially saved by spinning your wheels. I also recommend usingabstractions that have been out for awhile, so there are fewer leaks to beplugged.

I d like to close out this month s BackDraft by giving ashout out to a software product that I use that is worth checking out.PureChat, by Axosoft, allows you to directly interact with the customers thatvisit your Web site. It s inexpensive, carries no ongoing fees, and Iimplemented it on my company s Web site in less than 30 minutes (http://purechat.com).

Jonathan Goodyearis president of ASPSOFT (http:// www.aspsoft.com), an Internetconsulting firm based in Orlando, FL. Jonathan is Microsoft Regional Directorfor Florida, an ASP.NET MVP, aMicrosoft Certified Solution Developer (MCSD), and co-author of ASP.NET 2.0 MVP Hacks (Wrox). Jonathan also isa contributing editor for asp.netPRO.E-mail him at mailto: [email protected] or through his angryCoder eZine at http:// www.angryCoder.com.