Hands-Off Coding: Boosting Productivity

Development could learn a few lessons from farming when it comes to productivity. I recently finished a huge development project where borrowing lessons learned from farming saved me oodles of time.

Lessons Learned From Farming

It goes without saying that farmers today are absurdly more productive than they were a century ago. And a key contributor to that increase in productivity has been the adoption of mechanization, automation, and specialization within farming. In other words, while a Swathe may cost a lot of money, it enables a ridiculous boost in productivity by allowing famers to get away from tedious, hands-on, harvesting with something like a sickle or even a scythe.

Related: Boost Your Coding Productivity

By taking that same hands-off approach when it comes to developing applications, developers can see drastic increases in productivity as well. Or, as the saying goes within the development community: good developers write good code while great developers write code that creates good code.

Writing Code that Writes Code

My recent development project, I took advantage of two approaches that let me write literally thousands of fewer lines of code and save a ton of development time by taking a more hands-off; approach to coding. The first solution I used was an ORM (or Object-Relational-Mapping solution) that saved me days of coding when it came to data access. I also took advantage of templates which I was also able to use to generate the core functionality for a large number of web pages designed to interact with my data.

And while using templates and ORMs is hardly what I'd call revolutionary, I'm still a bit surprised by how many developers out in the development community still take the slower hands-on; approach. Accordingly, what follows is a high-level overview of each of these approaches, along with my opinions on some of the benefits and detractions involved with using them.

ORMs

I've now used ORMs in a number of development projects and found them to be completely indispensable from a development standpoint. Ironically, I'm still a bit mixed about their use when I approach them from the mindset I tend to take when I put on my DBA. And the fact that I'm a bit torn about them is fine, considering that their use engenders what amounts to holy wars all the time when developers and DBAs get together. In fact, the use of ORMs is occasionally so controversial that it's likened to being the Viet Nam of Computer Science.

That said, from a development standpoint, using them is definitely the difference between using a sickle or a combine, because the use of an ORM provides such a huge boost to developer productivity that it's hard to even quantify. Accordingly, as long as they're leveraged by someone with a good understanding of their limitations and proper database normalization, my opinion is that they're the correct tool to use in the majority of all applications. Of course, there are plenty of people who disagree with my take on the use of ORMs - especially hard-core OOP-focused developers who are tired of relational databases dictating so much of what their applications are allowed to do.

ORM Options

The key thing to take from my brief synopsis of a topic that has spanned countless hours of debate though is that if you haven't looked into the use of an ORM and made your own decisions as to their strengths and weaknesses, then you're completely missing out. And happily, when it comes to ORMs, there are a wide variety of options these days. One offering that enjoys tremendous support from developers is NHibernate - which offers a high degree of versatility and functionality (though it incurs a bit of a learning curve if you're new to ORMs). Likewise, Microsoft has two ORM offerings that it is slowly rolling out to more and more use within the development community at large. The first of these, LINQ to SQL can often be regarded as a bit of a "toy", but actually packs a lot of functionality into a very easy-to-use package. In fact, if you're new to ORM, I'd highly recommend looking into LINQ to SQL as it can very quickly and easily show you just how easy it can be to take advantage of ORMs and save oodles of development time. (The fact that it comes with a nice GUI is also a big plus when dealing with simple "throw away" applications too - though all of the real ORM pros tend to moderately look down on developers who use GUIs for their mapping.) Likewise, Microsoft's Entity Framework is beginning to show some serious potential and promise - even if it did rub some developers wrong for a while.

For developers who might not be convinced that ORMs are the way to go, CodeSmith Tools provides another great option that still allows developers to take a "hands-off" approach through the use of templates which can be used to easily generate an entire Data Access Layer in just a few minutes in many cases. Likewise, some other cool options to pay attention to are CodeSmith's recent approaches to blending templates and ORMs (such as PLINQ - which I may try out on one of my next projects).

Templates

And speaking of templates, using them in my recent dev project was another huge time-saver. In my case, I just threw together some very rough-and-tumble templates using .txt files, tokens and place-holders, and a simple WinForms application that was able to use mapping information from my ORM solution to quickly generate different CRUD pages for my web application. But had I been thinking a bit more clearly, I would have used Visual Studio's T4 Templates.

I actually first encountered these secret weapons in the war on becoming a great developer a few years ago (when they were actually known as T3 templates) while creating some tutorials for Visual Studio Extensibility. Since then, these templates have matured quite a bit, and there are now a number of really make it easy to get started with them. Clarius Consulting also offers a full-blown editor that you can plug into Visual Studio if you feel that your tractor needs air-conditioning and a CD-Player (metaphorically speaking of course

Of course, if you're an ASP.NET MVC fan, you'll likely have noticed that the MVC team provided some extremely nice scaffolding support using T4 templates for what will end up being the final, RTM, release of the MVC framework. And while this is a HUGE win for MVC developers (since T4 support is so heavily integrated right into Visual Studio for developing MVC applications), I'm looking for other teams a Microsoft to take this same approach. In other words, I'd love to see something very similar from the WPF teams as integrated templating support there would also go a long ways to help improve developer productivity.

Best of all though, templates allow you to gain the benefits of "hands-off" coding where needed, without sacrificing control. In other words, using templates is like using a combine instead of a sickle as it lets you cover tons more area in a short amount of time. Of course, when harvesting an entire field with a combine, you can't reach some areas - but with templates you still have the ability to 'jump off' of your tractor and use your sickle whenever you want as templates only generate code - which you can hand-tune as needed.

Coding for the Twenty-First Century

Without a doubt, plenty of development endeavors will still require hands-on coding in order to make things work just right, and hands-off coding isn't a good fit for many development needs. But the use of hands-off coding techniques can drastically boost development productivity to the point where ignoring these new paradigms will be the same as scoffing at tractors at the turn of the previous century.

Comments

Plain text