Friday, March 27, 2009

Big Headaches for MYSQL users

Here's something I didn't know, but which hopefully will help someone else out in the future:


Ok, if you know what that sentence means, and why I said it, you're done with this article, continue to the the next item in your RSS reader.

Now, for all the rest of you, let's start with what a nested subquery is. Let's say, for example, I have 2 tables in my database: students, and schools. Students each have a "school_id" as a foreign key. I want to retrieve from my DB all the students who go to a school that is in the zipcode 65203. I might write a query like this:

"select * from students where school_id in (select id from schools where zip = '65203')"

Or if I was working in rails (which I usually do):

Student.find(:all,:conditions=>"school_id in (select id from schools where zip = '65203')")

It looks really nice, it's easy to understand, and under certain circumstances it can DESTROY your database performance. There's a lot of reasons why this is the case, not the least of which is that query optimizers just don't have the time to figure out each one of your subqueries and fix them up. If you want a nice discussion about the why, I recommend This Blog Post wherein Scott Selikoff does a great job of explaining the problems.

For those of you who just want to fix it, do a join. Yeah, it's a little less pleasant to look at, but your hosting provider will thank you (or, in our case, will stop yelling at you for hurting their other client's database performance times). Here's an example of the previous query joined up:

"Select students.* from students, schools where students.school_id = and = '65203'"

And the rails version:

Student.find(:all,:conditions=>"students.school_id = and = '65203'",:joins=> ", schools")

May your DB feel better, and may you stop getting angry emails! Happy coding!

Wednesday, March 25, 2009

Opportunities where you least expect them

So for the last year I've been writing about software, trying to become better at what I do. In the process, I like to think I've become a better writer as well. Apparently, there are other people who think so too, because this last week I was asked to become a featured writer on (related to my new experiences as a recruit firefighter). Check the link!

Friday, March 20, 2009

What you say and how you say it

I was sitting in on a meeting with my wife and one of our business service providers a couple days ago, and an interesting thing happened.

We were meeting with two individuals from this company, both from the same department, both with approximately equal authority to get things done. We talked about some problems we were having with their software system, and they told us about the schedule they'd be able to address it on.

After we had left and were driving home, my wife turned to me and said "Which one of those two ladies did you like more?"

I hadn't thought about it, but I immediately said that it was the woman on the left.

"Me too!" my wife said.

We talked about it for a while and realized that both of them were telling us the same thing: "We understand your concerns, we're a little backed up, but we'll get them addressed within X timeframe". However, the woman on the right had mannerisms that were off-putting. She had her arms crossed the whole time, every time we tried to bring up an issue she was quick to come into direct conflict with it, she never smiled. The woman on the left, however, leaned in towards us when she talked, let us finish our sentences, smiled generously, and gave us phrased things with a "we" instead of a "you" in front of them. The first woman seemed to be accusing, the second was accommodating.

The first woman made me want to find another company to work with. The second made me want to return the favor sometime in the future.

It's not the message you're giving that typically affects peoples opinions of you, it's the way you deliver it.

Friday, March 13, 2009

3 Stereotypical Types of Software Labor

The last month has been really hectic here for both startups that I'm working on. With more and more that needs to be done, there's less and less time for me to get to it all, so the time finally had to come when I said "There's too much for just me to be working on". So we decided to hook up with some contract labor to bridge the gap until we could get a full time employee brought on, but the results have been a mixed bag. That's why I thought I'd put up a post that shows the experiences we've had with the 3 most common types of contract labor. (Please note ahead of time: This is just my honest experience. It does not automatically extrapolate to every person who falls into the categories I will define.)

1. The Cheap Off-Shore Worker

Cool! Software development for less than $10/hr! We couldn't find ANYBODY here to work for that price. When you're in a startup, cashflow is always at the front of your mind, so there's a big appeal to a little less value for a lot less money. When we found a gentleman in India who was willing to work for around half of what we would have to pay local labor, we couldn't pass up the chance to at least try it out.

PROS: Cheap is good. We got a lot of features started that had been waiting on the back-burner while I worked on more important stuff, and for the most part what came back to us was in working order.

CONS: It can be tough to explain what you're asking for when there's a language barrier. Also, frequently the finished work that we received had small problems with it that were not difficult enough for us to want to keep paying someone else to go back in and fix them, but were bothersome enough that they took some of my time to fix before we could deploy them to production.

VERDICT: Good for getting little things done, or maybe for giving you a place to start on larger features. Not to be relied upon for anything mission critical to your application. ALWAYS look over the code yourself before blindly including it in a deployment.

2. The Overpriced Consultant

I had one guy contact me who was very experienced and had a lot of great items on his resume. The problem? He wanted $100/hr to work (but was willing to start at $75/hr). Are you kidding me? Don't get me wrong, I'm sure this guy's very good at what he does, but I wasn't kidding when I mentioned cashflow earlier on. I don't care if this guy has six arms and 3 workstations that he can hack on simultaneously, there's no way he could produce anything that would be worth $100 every hour to a cash-poor startup operating out of the mid-west.

PROS: The gentleman was very nice to talk to, very experienced, and if we had worked with him I have no doubt that he would have produced excellent code and done fine work.

CONS: We have only so much cash, are barely profitable, and any expenditure at that level would quickly decrease our run-way of operation. We just can't afford that kind of recurring expense.

VERDICT: Better leave these blokes for the deep-pocketed mature companies.

3. The Local Student

The dude's never had a shot in the real world yet. Great! He's got lots of academic training, he's probably quite bright, but he won't charge as much as someone who's been in the industry for some time. What a deal, right? Well, maybe. You never know someone's ability level until you've tried them out. In my experience, the huge amount of intelligence you may have in a bright kid doesn't really translate to a great deal of productivity. Why? Well mainly because part of the experience you get from the industry is knowing what things have already been implemented and NOT REWRITING THEM YOURSELF. I don't care if you can implement a super fast bloom filter, what we need right now is the ability to upload pictures for the user's profile.

PROS: Pretty cheap, that's good. Also they're usually on-site, which is to me much easier than working with a remote developer.

CONS: Be prepared to watch every check-in that is made to the repo, because they probably haven't used attachment_fu yet and they may just decide to write their own image attachment library (which is probably very good, but we just don't have the time for that!).

VERDICT: Can consume as much time in supervision as they save you in implementation.

My conclusion: The best contractor we've had is the guy we're going to hire full-time anyway. There's no such thing as a bridge. My impression is that I want the same thing in a contractor that I want in an FTE, but I'm less likely to find it in someone who's not going to have a stake in the outcome. Thank God we're hiring.