Chart Porn: Most popular name for girls state by state

Original Source

Amazed by the Azure! Try out the new SQL Server 2014 CTP2

Yesterday, Microsoft announced SQL Server 2014 CTP2. The same day they announced it, they made a VM image available on Windows Azure. You could be playing with the Enterprise version of SQL Server 2014 in five minutes. Gone are the days of spending an hour or two installing and configuring it in order to play with it. Amazing!

Continuous Integration & Continuous Deployment delivered to Silicon Valley Code Camp

SQL Tips - Delivered to Silicon Valley Code Camp & SQL in the City

Winston Churchill was a Data Analyst

"However beautiful the strategy, you should occasionally look at the results." -Winston Churchill

Script I used to populate DimDate from AdventureWorks with current data

WITH mycte AS
    (
    SELECT CAST('2012-01-01' AS DATETIME) DateValue
        UNION ALL
    SELECT DateValue + 1
        FROM mycte
        WHERE DateValue + 1 < '2013-12-31'
    )INSERT INTO dimdate
    SELECT CONVERT(VARCHAR, DateValue, 112) AS DateKey
            , CAST(DateValue AS date) AS FullDateAlternateKey
            , DATEPART(dw, datevalue) AS DayNumberOfWeek
            , [dbo].[FormatDateTime] (DateValue, '[dweek]') AS DayNameOfWeek
            , dbo.FormatDateTime(DateValue, '[d]') AS DayNumberOfMonth
            , DATEPART(dy, datevalue) AS DayNumberOfYear
            , DATEPART(ww, datevalue) AS WeekNumberOfYear
            , dbo.FormatDateTime(DateValue, '[MONTH]') AS MonthName
            , dbo.FormatDateTime(DateValue, '[M]') AS MonthNumberOfYear
            , DATEPART(q, datevalue) AS CalendarQuarter
            , DATEPART(yyyy, datevalue) AS CalendarYear
    FROM mycte
            OPTION (MAXRECURSION 0)

I'll include a new script that will populate the other tables with good dates some time later.

Quote on Business Failure

"I can't give you a surefire formula for success, but there is one for failure: Try to please everybody all the time." Herbert Bayard Swope

Thomas Edison Believes in Iterations, Too!

"I have not failed. I've just found 10,000 ways that won't work." -Thomas Edison

Hugh Prather speaking to Agilists

"It's simple: if I never try anything, I never learn anything."-Hugh Prather

Quote for Agilists

Salman Rushdie speaking to agilists: "A bit of this and a bit of that is how newness enters the world."

Quote

"If one FELT successful, there'd be so little incentive to BE successful." Alain de Botton

Louis L'amour Speaking to Future Agilists

"Are you where you want to be if it doesn't work?" - Louis L'amour speaking to future agilists.

Einstein Quotes on Education

"It is,in fact, nothing short of a miracle that modern methods of instruction have not entirely strangled the curiosity of inquiry" Einstein

Quote from Edmund Burke

"Hypocrisy can afford to be magnificent in its promises; for never intending to go beyond promises, it costs nothing."-Edmund Burke

Love this Quote from Bertrand Russell

"In all affairs, it's a healthy thing now and then to hang a question mark on the things you have long taken for granted"-Bertrand Russell

Quote

"Whoever best describes the problem is the one most likely to solve it." -Dan Roam (Back of the Napkin)

Another Quote on Education

"Self-education is, I firmly believe, the only kind of education there is." Isaac Asimov

New Tip on Executing SSIS Packages

Quote on Eduction

"Eduction is not the answer to the question. Education is the means to the answer to all questions." -Bill Allin

Business Intelligence Quote

"Praemonitus praemunitus (forewarned is forearmed)" -Even the Roman's depended on business intelligence.

New Tip on Searching Schema

Quote

"One must learn by doing the thing, for though you think you know it, you have no certainty until you try." -Aristotle

New Tip - Formatting a Report

Here's my latest tip about formatting SQL Server Reporting Services Reports:

Rob Sullivan on SQL Server's Last Breath

This is my friend, Rob Sullivan, talking about the pressure SQL Server is getting from competition.

Rob Sullivan: SQL Server's Last Breath from NDCOslo on Vimeo.

New SQL Tip on How To Find Bad Queries

In this video, I show SQL Server 2012 Profiler, Performance Monitor, and how to link the two together:

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.

Find the Right Metric: The NYPD and Prostitution

Looking at the wrong thing to achieve goals is more dangerous than having no goals.  When picking KPIs for executive dashboards, it's critical that we choose wisely, and that we're prepared to change.

So often, once dashboards are created, they seem to be set in stone.  When an executive says a metric is important, it is sometimes difficult to speak up against them and say that perhaps we're looking at the wrong thing.   If we're somewhat flexible on what we see, and we're willing to change in the future, it provides a safe place where mistakes can be made.  

The New York Police Department will often search suspected hookers to see if they are carrying an abnormal amount of condoms.  If they are, they use that as proof against the suspect that they are a sex worker.  Although this seems to satisfy the metric that prostitutes be arrested and off the street, it ignores the bigger goals of public health and safety.  It incentives women to not carry protection, thus spreading disease and sickness through the population.

The NYPD is looking at the wrong metric.  I suppose this is the risk when you use law enforcement to work on what is probably a primarily public health problem.

If call centers look at average call time, and they want the number as low as possible, because that means they are saving money, they might be looking at the wrong metric.  It might be incentivizing rude customer service, abruptness, and poor call etiquette.  Measuring customer satisfaction or absolute resolution time might be a better number to look at.  Perhaps low calls into the center will emphasis the quality of the product you're selling and how easy it is to use.

But mistakes will always be made when selecting metrics and KPIs.  The trick is to make sure that the technology and the business are both able to quickly and effectively change it when the mistake is realized.

Just Venting A Little

Feel free to ignore this post.  I'm writing for me and to get something off my chest.  I'm absolutely not writing to you.  Nor am I disappointed with anyone in particular.

I am often asked by software developers and other consultants about how to be successful.  Now, I don't consider myself to be successful.  I enjoy my career and like where it's at.  I'm excited about where it's going.  I enjoy the process of learning new technology and making new friends and meeting new people and advising customers on how to be successful and profitable.

With that said, I'm often asked about how to be successful.  When I have these conversations, I find that everyone already knows everything I have to say.  They know how to make more money, how to gain recognition, how to achieve...and they knew it before they even asked me the question.

They don't need answers from me.

Their answers all come from within.  Yet time and time again, they fail to execute.

I am consistently disappointed at the small percentage of people willing to execute the simple daily self-disciplines needed to reach higher levels of success.  They know exactly what they must do to bring about their dreams and yet they fail to execute.  It's not a failure of vision or knowledge...it's a FAILURE OF ACTION AND COMPLETION.

They chart their work by the progress they've made, not with any specific goal.

I know that the person who achieves in this business is the person with passion....the person who wants it the most.  They are the people who wake up at 5am to read Hacker News.  They are the people who are writing blog posts at 11pm.  They are the people who spend their weekends speaking and learning at Code Camps and SQL Saturdays.  They are the people who volunteer and attend user groups.  They accept no excuses.  While others are watching TV show after TV show, they are learning, reading, digesting, blogging, tweeting, and writing.

It seems that there are very few people who are willing to put forth the effort to get from where they are to where they want to be.  Most make excuses and blame others for their own poor choices.  They kill the messenger.

Some of you will discredit me.  Some of you will say things like "Who is Ike to say these things to me?"  or "Ike isn't perfect either.  I know he makes mistakes."  Some of you will find other ways to ignore what I'm saying, belittling me or my success.  That's totally fine. 

But others of you will take this opportunity to look inside yourselves and ask if you are doing everything you can to learn, grow, market, achieve, raise bill rates, provide value, write, and succeed.  Others will humbly ask "If I know what it takes to succeed, what excuses are getting in my way of taking ACTION and actually achieving?"

I know you know what to do.  You have all that you need to be self-sufficient, to earn more money, to achieve respect and recognition, to contribute value to your community.  GO FORTH AND DO IT!

Just as Important as Control

I've been reading "Making Sense of Behavior", by William T. Powers.  The book is about controlling human behavior, but one section really made me think about the importance of proper business intelligence and SQL reporting for an organization who wants to achieve ambitious goals:

==================
"On a twisty mountain road with cars coming around every blind corner you don't look away for even a second!  Because the general rule is that if you want to control something, you have to perceive it.

When you're filling your bath, you don't just perceive that the water looks hot, you specifically use your temperature sensors in your hand to report on the current temperature of the water because that's what you're controlling: temperature.

Perception tells us the current status of whatever it is we're trying to control.  Without that information, received continuously or at frequent intervals, we can't control anything.  Perception is just as important as action, for controlling."
==================

Reporting is not our only means at perception, but it is a powerful one.  And when organizations ignore effective reporting and business intelligence strategies, they do so at their own peril.   I have always felt that business intelligence was nothing more than delivering the right data to the right person at the right time.

I Love Lucy: A Lesson For Business Analysts

In this episode of I Love Lucy, a conversation is taking place between two people who don't understand each other's languages.  They struggle to find someone who can translate between french and english, which they fail to do.  Instead, they find linking languages between them.  So the translation goes from French to German, to German to Spanish, and finally Spanish to English.

The episode is hilarious, and it highlighted to me how difficult it is for software developers and business stake holders to communicate.  Executives, Directors, and other leaders are often fluent in their line of business.  They are also fluent in general areas of business.  Words like cash flow, just-in-time manufacturing, and copywriting are thrown around frequently, and often are lost on engineers and software developers.

Conversely, software developers speak in terms that business leaders find foreign and awkward.  Words like source control, unit testing, and SCRUM are thrown around frequently, and business leaders find themselves equally lost.

Companies often struggle with these two different languages  and rather than putting in the time, effort, and energy into investing in being somewhat bi-lingual into these two worlds, they hire a translator.  Called a business analyst, these translators specialize in speaking both languages fluently.  This is an acceptable solution to the translation problem, but it is less than ideal.

Business Analysts create the following problems:

1)  In the kindergarten game telephone, a message is whispered around the circle and the original message is compared to the final message, and they are often very, very different.

2)  Business analysts are expensive.

3)  If your job is to bridge the communication gap, then you really don't have a vested interest in bridging the gap, in fact, there is profit to be made in making sure the gap is as wide as possible.  This creates a culture of information hoarding and miscommunication.

4)  When mistakes are made, blame is spread around.  Since the analysts are in the middle, you often hear several different stories on who is at fault and what the problems actually are.

5)  Translation takes time, and therefore delays projects, decreases velocity, and hurts shipping times.

So what is a better solution?  I think business people can spend 20% of their time and get 80% of the value by spending some time learning some basic terms of software development, so they understand the challenges that developers face.  I think developers can spend the same amount of time learning to serve the business they are in.   This investment is just for the initial communication issues.  Within months, these communication problems will go away, and that investment will pay off year after year. 

This small investment has no downside, will increase velocity, and will definitely improve your software ship times, while decreasing bugs and increasing software quality. 

We prefer to have constant access to our customer so we can be in constant communication.  This helps us learn from each other and grow together.  Trust will build, and software will ship.  Everyone is happy and the communication problem is solved.