My last post was also my most successful to date (where success is defined by page views and comments), but it came with a bit of criticism.

I made the argument that for the moment I’m more concerned with time to release than with building a perfect design. That’s not to say that I don’t care at all about actually sitting down and designing this thing, I am; it’s just that I have a few compelling arguments for getting this thing out sooner:

• This project was originally created to attempt to solve a problem at work, and I’d really love to see this deployed and enjoyed by the 20ish developers who could potentially benefit from it.
• By and large, this is meant to be a portfolio project to help find me a job in .Net. I’d like to escape my current job sooner rather than later, and get on with my new life working in areas I’m actually interested in. No offense to the language, but I just don’t spend much time outside of work working on personal COBOL projects, and I don’t read mainframe blogs. Conversely, this project shows I do work on C# outside of work, and I routinely read a number of blogs, and frequent sites, which highlight newer languages and methodologies du jour.
• If I leave room for improvement later, I’ll gain experience with refactoring (both designs and code). It’s a great learning tool to go back to your old code and see what works and what doesn’t. Seeing how far you’ve come since you wrote that stinking, rotting, maggot-infested piece of god awful code is a great way to remind yourself that you really are learning, and that you’re constantly improving.

With that said, I’d like to address one of the comments from my last post.

Reader JS writes:

Jesse,

I’d encourage you to write at least one or two database applications before you start using an ORM. While it can be a bit more tedious writing the queries by hand and debugging them, it is a worthwhile learning experience. Once the learning is done and you’re just repeating the same busywork you’ve already done a number of times before, then the ORM makes a lot more sense.

I think this is excellent advice. While I’m sure you’ll definitely learn a lot by implementing a ready-made ORM like NHibernate, it’ll pay more in the long run to have the understanding of how things work behind the scenes. Not all projects will use an ORM, especially when you’re working on an older code base, and being able to debug a problem in a method full of objects found in the System.Data.OleDB namespace is definitely a plus for your employer.

This argument is tangentially related to a topic which was popular on the internet last year – whether or not a programmer should know how to program in C. The argument there is largely the same argument I’m making here: knowing the guts of your tool of choice will make you a better programmer.

For example, I’m really amazingly bad at computer hardware. It’s embarrassing to say, but I’ve just never been comfortable pulling pieces out of my desktop and replacing them with new bits. It’s the reason why in 2003 when I bought the machine, I opted to have 1GB of RAM installed from the start. It was probably very much overkill for my needs, but I figured it would eventually be useful and I didn’t want to deal with it.

That desktop computer I bought failed the summer after I bought it. In desperation, I got brave and opened the machine up and started pulling bits in and out. I even took apart my parents working machine and tried to swap out the power supply to see if that was the issue. When I was done, I couldn’t even get the thing back together. I left some things unplugged for fear I’d blow the whole thing up when I plugged it in, if I’d put some connector in backwards somehow. When I took it into the local shop I’d bought it from, the guys there expertly snapped all the bits together and powered up my computer. They connected their various diagnostic tools and told me my motherboard was shot. They did in minutes what I failed to do in hours on the floor with screwdrivers and hope. All this because I didn’t understand the internals of a tool I relied on everyday.

With that in mind, I’ve decided to follow JS’ advice (which is really just following what I had decided already anyway) and forget the ORMs for now. I’m going to dig in and get dirty with my database classes. I’ll write SQL by hand, I’ll learn a bunch of new classes in a couple new namespaces, and when I crawl out the other side I’ll be a better developer for it.

There is a comment on one of the answers to a question on StackOverflow which sums up my point nicely. The question was “What is the best language for a beginner to write a blog engine in?” and the answerer had questioned why the asker wasn’t just going with an established brand like Wordpress.

StackOverflow user Nelson LaQuet stated:

The OP wants to build his own; and I believe it’s not so much for the practicality but for the learning experience. Re-inventing the wheel is a good way to learn how things work – even if you end up just using a prepacked solution in a production environment.

Excellent advice. I think I’ll take it.