Too Hard == Broken?

I’ve spent a few hours over the last couple of days trying to get NHibernate to work. I failed. As soon as I call Configuration.Configure() I get an exception. I’ve tried various combinations of app.config and hibernate.cfg.xml files etc to no avail. I give up.

And this isn’t the first time I’ve had this. I’ve started to think, that if I can’t get something to work, its effectively a fault. A bug, no less. I’ve blogged about the risk of learning a new framework, and this proves my point perfectly.

I’ve taken to giving up on things like this.  I have better things to do with my time than work through problem after problem after problem trying to get something working.  I even recently uninstalled Resharper, because while it was very good, it stopped my solutions opening quickly. Sometimes entirely.  Again, broken.

So I’m going to look for an alternative to NHibernate that I can get running, and therefore “works”. It’s official - NHibernate is broken.

Unless you can help me out…

One Job to Do

My PC will confound me several times a day, every day. It’s not just me, either.

Today I had trouble installing .NET 3.0. Recently I’ve also had problems with Explorer freezing, the Outlook notify icon stays visible even when I have no unread email, and occasionally double-clicking a file only opens the application and not the file. Grrr.

These are all things that should just work (though I hear not even Apple are doing so well in this area recently…). These are tools, appliances, they have one job to do and I expect them to do it. SVN was recently a problem for me. The settings for Tortoise SVN to integrate with Araxis Merge didn’t seem to be giving the correct results, and only after many hours of poring over various files and reading various TSVN webpages did I find that it was just confusing filenames causing my problems, and that everything was working perfectly.

I’ve installed and almost as quickly uninstalled Resharper, too. I’m really disappointed about this, but the 20-minute performance hit opening one of my solutions (before I got bored and killed the process) was too much to bear for the additional refactoring tools. I was looking forward to catching up to where I was 4 years ago on Eclipse, too. Turns out I’m not the only one.

These often aren’t actually problems with the tools as much as the environment they’re in. Other people say it works on their machine.

So this has turned into a rant, and I’m not the only one who’s been through it I’m sure. I’m at a point where I’d like to re-install Windows, but seriously - that’s a lot of work. I get upset too easily.  The really worrying thing is that there are probably lots of people out there thinking the same thing about software I’ve written…

The Evil of Implicitness

I really dislike things that are implicit. Okay, it doesn’t help that I’m the most forgetful person I know, but still.

I’m a believer that if you want something done, you should do it. Use a framework if you like as a tool, but explicitly ask that tool to perform the task. Things shouldn’t be hidden away, doing as they please.

Examples:

Post build steps
I’ve mentioned it before, but I really do like my build process to explicitly do everything I need, in one place.

SQL
My boss gave me a tip yesterday. He says that for things like this:

insert into a_table (id, the_value) values (1, 11)

He sometimes cheats and does this:

insert into a_table select 1, 11

I think that’s dead clever (because I thought you had to specify the columns you want to insert into), although I’d personally never run it on a production database, and it would only be for quick and dirty test code on a database I control. The problem is (and to be fair he admitted this), if someone changes the schema of that table, things can get messy very quickly. I’m more anal so my first thought was that I just like to know what columns I’m editing without having to investigate that table schema before I run it.

Of course we all know the evils of:

select * from a_table_that_might_have_columns_added

Which speaks for itself, so let’s not dwell on that.

Attack of the Scheduled Job
I personally dislike any kind of scheduled task. It makes me nervous to think that there’s an unknown cloud of processes that I don’t know about that might be editing my data without me knowing.  Also, you lose a bit of the “realtimeness” of information with scheduled jobs. Of course sometimes this is necessary, as in the case of maintenance tasks.

So I like to do things by hand a lot of the time. I don’t like to write classes that do work in constructors, I prefer instead to use factory methods or create static methods called “Load” which create the object and populate it for me. Right or wrong is tough to decide, and is probably a religious issue as much as anything else. But “better safe than sorry” and “keep it simple, stupid” are principles that make applications easier to maintain, because you avoid more issues from happening, and make it easier to find and fix those that do appear.

Hidden in plain sight

What’s your opinion on pre and post build steps? Personally I prefer all my build operations to be performed by the build script itself, so that if there are any problems to be fixed or changes to be made, I only have one place to look and one thing to update. Post-build options are what you look at hours into a problem when you finally remember that you have them, so can make debugging your build process much more difficult.

Let me know what you think.