How to Start Reading SQL Execution Plans

This morning I watched Grant Fritchey's SQL Pass 2012 session about reading execution plans. I'd highly recommend watching it, or seeing it in person when SQLPass comes around again next October. Grant had this slide to teach us where to begin when reading the cache plan.

 In summary, Grant says that execution plans can be overwhelming, but if you start with these six things, you'll probably find what you're looking for.

 Grant also wrote this blog post, detailing the same information: Home of the Scary DBA - Execution Plans, Where to Begin

Chart Porn Part 2: This is Hans' recent video with more numbers

Chart Porn - Hans Rosling's Awesome Visualizations

Dr. Rosling discusses why calling it the third world or a developing country is not positively contributing to a positive discussion on world affairs.  He uses some amazing visualizations to prove his point:





Also, this visualization is free to use.  Dr. Rosling has made it available here:

http://www.gapminder.org/

Responsive Web Design

Mario Hernandez was in San Diego, speaking to the San Diego .NET User Group on Responsive Web Design.  He had some great links to share on the topic, and I thought I'd share them here:

http://designsdrive.com/

https://github.com/mariohernandez/Introduction-to-Responsive-Web-Design

http://www.abookapart.com/products/responsive-web-design

http://www.splio.com/responsive/

http://foundation.zurb.com/

http://twitter.github.io/bootstrap/

http://960.gs/

Developers Need To Fail

Is failure the opposite of success?  If you fail does it mean you didn't succeed?  Does failing bring you closer to success?

Fear of failure is actually worse than failure.  Everyone has a fear of failing.  This often keeps us from doing something with all of our effort.  If we put in all the effort and we fail, does that mean that we are failures as human beings?  Our culture and our media would have us believe that was true.  Our ego would prevent us from coming to that conclusion, so it's just better to not try our best.  We're better off just doing a good job and holding something back.  That way when we fail we can always say "Well, I didn't really try all that hard, did I?"

Let's look at this with an example.  Let's say that your long term goal is to be in a relationship.  You want a girl who is beautiful, intelligent, witty, friendly, and a delight to be around.

You find a girl who meets these qualifications and are excited about her.  Do you ask her out?  What if she says no?  If she says no, does that mean you are less of a human being?  Does that mean you aren't worthy of a girl like that?  What would that do to your self-esteem?  Is failure at getting this girl you've chosen freezing you to inaction?

Here's the most important question.  If you never ask her out, will you ever go out with her?  If you ask her out and she says no, and you silence your ego, doesn't that make it easier to ask out the next girl?  If you ask out three girls and three say no, but the fourth one says yes, did you fail three times and succeed once?  Or are you just successful with women. 

When you've been married for twenty years, will it really matter that three girls rejected you before you found the one you ended up with?  Will anyone list your failures?  Will anyone really care?

But I can promise this, you'll never go out with her if you don't ask her.  It will just never happen, and you'll have failed before you even started.  It is much, much better to try, fail, and improve, then it is to never try at all.

This is a weird post for a software development blog.  My point is that developers need to feel like they are in a safe environment to fail.  If they think that failing is dangerous, then they will never do anything dangerous.  Dangerous things are scary, but when they succeed, they have the ability to change an entire organization, and leave the business stake holders gasping for breath at the magnificence of it all.  

Allow developers to fail and fail often.  Just make sure it is leading them to success and they are learning from it.  Eventually, they will have a bold success.  And that will make all the failures worth it, and you'll make back any lost money and then some. 

Developers who are afraid to fail just write boring code or they just watch YouTube videos all day.  They never do anything awesome.  And awesome is where the fun is.  Awesome is what we really want.

The problem with NULLs and T-SQL

I was reading Itzik Ben Gan's T-SQL Fundamentals book as part of the reading assignment for the SQL Pass Book Readers Group.

He made a great point about dealing with nulls and the IN clause and he had a great example.  Rather than use his database, I wrote my own script to demonstrate the problem, and thought I'd post the issue here, succinctly.

First run the setup script.  This creates two tables and populates it with data.

create table customers

(custID int

, custName varchar(100));

go

create table orders

(orderID int

, custID int

, OrderDate datetime);

go

insert into customers

(custID, CustName)

values

(1, 'Ike Ellis')

, (2, 'John Ackerman')

, (3, 'Scott Reed')

, (4, 'Brad Cunningham')

, (5, 'Llewellyn Falco');

go

insert into orders

(orderID, custID, OrderDate)

values

(1, 1, '20130101')

, (2, 1, '20130102')

, (3, 1, '20130103')

, (4, 3, '20130104')

, (5, 3, '20130105')

, (6, 4, '20130106')

, (7, 4, '20130107')

go

Next, we want to find out how many customers have not placed orders:

select * from customers

where custid not in (select custid from orders)

We get two results, John Ackerman and Llewellyn Falco.

Now let's add a NULL into the Orders table:

insert into orders

(orderid, custid, orderdate)

values

(8, null, '20130108')

And now, let's run the same query:

select * from customers

where custid not in (select custid from orders)

And we get no results.  This is because the column allows NULLs and NULL comparisons always return false.  Essentially the NULL customerID could be John Ackerman or Llewellyn Faloc.  We don't really know if it's them or not, so instead of returning them, we just won't return anything.  This is by design.  So how do we get the results we want.  We can do three things:

1)  We can make sure that columns that don't need null values are created with NOT NULL, thus disallowing them to be inserted. 

2)  We can strip out the NULLs in the subquery:

select * from customers

where custid not in (select custid from orders where custid is not null)

3)  We can use exists, which only uses two-value predicate logic, not three-value logic, thus giving us the desired result:

select * from customers c

where not exists (select * from orders o where o.custid = c.custid)

Hope that little script helps!

Why Developers Quit

Every time a software developer leaves a job, I always ask them why they left.  I do this because I like the software developers who work with me, and I really don't want them to leave.

Every time I have this conversation, I'm surprised at the wide variety of reasons why developers leave.  Most, however, leave for the following two reasons:

1)  They are bored with what they are doing.

2)  They don't like their new manager, or there was a change in leadership and they didn't like it.

I always expect them to say "I left for more money" or "I left because I hated the company."  I hear those reasons after layoffs or firings, but I hardly ever hear those reasons because someone quit.

As software development leaders, it is important that we address those two issues.

The first one is easily solved.  Keep your software project fresh, using new technology, and keep your company competitive by always pushing the envelope.  This will benefit the developers and keep the company profitable and current.

The second one is a lot tougher.  I wish I could answer how to be a good leader in one short blog post.  I am writing a book on the topic, where I will go into more depth and provide more information. 

I think one thing that covers a lot of what software developers like in a manager is as follows:

1)  Shield the developers from the chaos of the business.  Don't tell them stories about how there is so much change in the organization and no one knows what they want.  Don't confide your troubles in them.  Don't blame others when projects get cancelled.  Stay positive.

2)  Give clear direction on what they need to do in order to be successful.  They shouldn't have to guess on what their top three priorities are and what order they are in.

3)  Hold them accountable.  If you remember what you asked them to do, and you check in on them and how they are doing, you are not micromanaging them.  You are actually showing them that what they are working on is important and that you care about them.  You are showing them how to be successful and worth all that money you are paying them.

4)  Tell them what they have to do to earn more money.  Give them a way to earn money from you and not all their side projects.  If they don't have a way to increase their income with you, they will start taking work from other sources and they won't talk to you about it.

This is just the reality in an industry where 100% of the good developers have jobs and never have a problem finding more work.

This post doesn't give all the answers, but if you are struggling on how to keep your top talent, minimally addressing these things will go a long way in helping you with that goal.