Browsing articles in "Snark"

Worst Bar Chart* of 2014–We May Already Have a Winner

Jan 29, 2014   //   by Karen Lopez   //   Blog, Data, Data Visualization, Fun, Snark, WTF  //  6 Comments

 

Update: It appears that this chart and other data visualizations have been removed from the website and report.  I’m hoping that means that the authors will be refactoring them with improved graphics.  Meanwhile, I’m going to leave my post below as is.  There are good lessons and tips to be shared. 

I know.  I hear you. It’s still January and we might just have a winner, one that will be impossible to beat during the next 12 months. Incredible. As you may recall, in late 2011 I awarded Stupidest Bar Chart to a doozy from Klout.  That bar chart was confusing, but not in the way this one is.  First, put down your beverage of choice.  Then take a look at this:

 

image

 

Yeah.  That…chart.  It’s kind of like a horizontal stacked bar chart.  I don’t understand anything about it, though.   This chart comes from an infographic at Deloitte.com  on Analysis Trends for 2014.

Maybe zooming in might help?

 

image

 

Nope, doesn’t make it any clearer. In fact, it’s just as crazy, but bigger.  Call it Big Crazy DataTM.

Here are the issues and questions I have about it:

  1. What do the colours mean? If this were a stacked bar chart, the grey and blue areas would indicate different data.  It appears that only some sections have data. But I’m not sure.
  2. What is the scale?  Normally a bar chart would have an axis that indicates some measure and all the bars would be graphed against that axis.  This has no axis.
  3. Why do some bars have signed numbers and one have a range?  Why are some numbers unsigned? Even some delta numbers are unsigned.
  4. What do the relative sizes of the sections mean?  In one bar we see a blue section labeled 285, but it’s larger than a section labeled 425-475
  5. Where numbers appear, do they describe the section they are on or the section next to the number? I’m not sure
  6. What does the relative position of the blue section mean? I’m not sure.
  7. Why are some of the labels in light grey and some in dark grey? I’m not sure
  8. What are the units of measurement for these numbers? Are some percentages? Units of 1000s? 100,000s? Are they of people? Positions? Something else? I’m not sure.
  9. Do the endnotes there explain the numbers? No, they are just citations for reference materials used to create the report.

Maybe the chart has an explanation inside the full document, Analytics Trends 2014: (And why some may not materialize)… No, same chart, no text that directly explains any of the numbers. To add some irony to this, the report itself is about Analytics and even covers trends in visualizations.

A Picture is Worth A Thousand Words, Unfortunately.

image

The report has something to say about data visualizations used in data analytics:

There’s no question that visualization has become a critical capability for organizations of virtually every shape and size. Easy-to-use software makes complex data accessible and understandable for almost any business user. From discovery and visual exploration to pattern and relationship identification, today’s visualization tools easily affirm the adage that a picture is worth a thousand words. Or, in this case, numbers.

This is especially true with big data, where visualization may even be a necessary capability for driving insights. That’s why visually oriented tools are rising in prominence for many big data applications. Users get to understand, explore, share, and apply data efficiently and collaboratively—often without the need for analytics professionals. And that’s where the risk comes in. In their eagerness to dive into data, users may choose polished graphics over thorough data preparation and normalization and rigorous analysis—glossing over important insights and analysis opportunities and potentially producing erroneous results. [emphasis mine]

Keep reading the report from that section.  The irony burns.

What’s Going on with this Bar Chart?

I’d bet that the Analytics professionals at Deloitte know much better than this.  The webpage and report for Analytics trends is beautiful to look at.  I’m guessing that a graphics designer has taken these numbers and created a beautiful, yet meaningless graphic with numbers. And just as the report predicts, people who don’t understand how to best use visualizations can gloss over important insights and analysis opportunities and potentially produce erroneous results.  This report has some great points. And it’s pretty.  Very, very pretty.  But the distraction of bad visualizations makes difficult for me to actually see the points the authors are trying to make.

My guess is also that this data, as a set, had no business being put together in one chart.  I’m not sure, but they don’t seem to have the same measures or even be the same type of data.  So putting them in one chart won’t help.  This was a page in a report needing a graphic, so someone made one.

*Updates:

Jamie Calder ( @jamiecalder) helped me “see” the story this chart is trying to tell: think of it as a math equation.  That might get you there.  But it’s still not an appropriate use of a bar chart.  And Josh Fennessy ( @joshuafennessy)  has pointed out that this isn’t supposed to be a bar chart at all. It’s supposed to be a waterfall chart.  But it’s dressed up as a bar chart, so I’m going to still leave as a contender for Worst Bar Chart of 2014.  Let’s just call it a self-nominated chart.  Martin Ribunal has found what is most likely the original chart from which this chart was most likely copied inspired by and has listed that in comments below.

What Have We Learned About Data Visualizations?

  1. The best data analysis can be invalidated with bad data visualizations.
  2. If you develop content, insist that you say in the final published work.  I know this is difficult in large corporate entities, but it’s important to ensuring that your goals are met.
  3. The more accessible we make self-serve BI and data visualization tools available, the more responsibility we have to educate, train, and mentor those using these tools.
  4. Show your visualizations to other people.  Ask them what they see. Ask them if they are confused, what conclusions they might have and what questions they still have.
  5. Choose the right chart type to fit your data.  Then use that chart correctly.
  6. If you needs a graphic image, don’t mimic a recognized chart type. 
  7. If you add a chart to a document, you should actual reference it in the text in the way that helps the reader understand it.
  8. If your chart has numbers, you have to say what those are number of, including some sort of unit of measure.  And your graphics should correctly portray their relative size.
  9. If a chart leaves viewers saying “I’m not sure” more than once, it’s not working.
  10. Loving your data means loving how it is presented, too.

What Would You Ask?

What other questions do you have about this…graphic.? How would you improve it?

I can’t bring myself to call it a bar chart any more.  But it’s still dressed as a bar chart, so it fits the nomination category.  If you find a bar chart or any other data visualization to nominate, let me know.  I wouldn’t want something worse than this one to go unrecognized.

Data Will Confess to Anything….

Jan 10, 2014   //   by Karen Lopez   //   Blog, Data, Data Governance, Fun, Snark  //  No Comments

Star Trek Data being interrogated

via Thomas LaRock ( blog | @sqlrockstar )

Remember this the next time you see some statistics.  Or a report.  Or anything that appears on Wikipedia.

To Santa with Love, Kitty

Dec 24, 2013   //   by Karen Lopez   //   Data, Data Modeling, Fun, NoSQL, Snark  //  2 Comments

Dear Santa,

My friend and debate foe victim Thomas LaRock ( blog | @sqlrockstar) sent you some last minute gift advice for organizations who need your help.  That got me thinking, so I made a list, too.  I checked it three times because I’m thorough like that. I’ve based this list on observations and data I’ve collected over the last year.  Much like you do.  Except I didn’t use that creepy shelf elf guy.  

Just in case you didn’t collect enough data, or it got lost in some hard drive failure:

For Twitter: A way to restore those 20k Tweets of mine they lost a few years ago.  Oh, wait…probably better that they aren’t part of the firehose any more.

image

For Data Modeling tool vendors: A copy of my multi-volume set of enhancement requests for supporting new database and datastore types. It’s nearly 2014; it’s time we data architects were able to do our job regardless of the target technology.

image

For the NoSQL Community: A love of data so strong that they can tolerate the mere mention of relational database solutions when appropriate.

image

For Microsoft: A brilliant new name for Windows Azure SQL Database. I can’t keep saying that in my presentations.  Even WASD is difficult. 

image

For Oracle, IBM, and Sybase users: A community as active and helpful on social media as those in the SQL community.

image

For United Airlines: A set of laminated copies for each employee of your Star Alliance agreement to remind you that 125k flyers do indeed get perks on your airline. First World Problems, I know.

image

For Star Alliance airlines, including Air Canada: A "Wifi in the Sky for Dummies" book. Tell them to get cracking.

image

For NASA: That other half a penny.

image

For Justin Bieber: US citizenship and a ranch in SoCal.  And a plane ticket.  No monkeys.

image

For Rob Ford:  NULL.  Not even coal.

image

For my readers and their customers: A year in which their data is much loved, in the right place, at the right time, with the right granularity and the right integrity.  Or World Peace.  Probably easier.

Love,

image

(Kitty is my Starbucks name.  I figure Santa knows that already.)

Your Christmas Cookies Can Teach You About Data: Sugar Cookies

iStock_000014842218XSmall-Xmascookies

I don’t do a lot of baking. My kitchen is mostly the place where I blend my breakfast and enable my caffeine addiction. But my family has a tradition of making dozens and dozens of cookies every holiday season. Sugar cookies, No Bake Cookies, Snickerdoodles…the list just goes on and on.

As I was looking in my pantry for ingredients this year, I started thinking about how the process of producing cookies was a lot like data architectures. I may have been drinking. I’m pretty sure of it, actually. A lot. I mean I’m a lot sure I might have been drinking. A lot.

This week I bring to you a short series about Christmas Cookies and data.

Sugar Cookies

Yum! Probably the most common version of Christmas cookie is the decorated, cut out sugar cookies. Recipe books, blogs and food network shows make them look so easy. They contain just a few simple ingredients (butter, sugar, flour, salt, vanilla, eggs) that form the basis of almost all other higher forms of cookies.

What makes these special is what you do with that dough. The most exciting versions have you to roll out the dough, cut it out with cute cookie cutters, bake, cool, then decorate them. It’s just cutters and icing, right?

The Big Lie

I’m here to tell you that it’s all a lie. First, unless you have a lot of practice, the dough never rolls out cleanly because a whole lot of things have to go right first. Then you cut them out and they fall apart or tear. You’ll end up burning the first few batches until you know how your oven heats and how your baking pans work.  Maybe you need at Silpat liner. Or parchment paper.  Or an actual baker.

But no amount of equipment prepares you for the disaster of decorating them. They NEVER come out like the pictures. Those cookies on blogs and in recipe books are probably made by specialist magical cookie elves who spent their 10,000 hours learning to make cookies from Betty Crocker herself.  With Photoshop. I’m pretty sure every decorated cookie recipe is shopped worse than a Ralph Lauren model.

There are all kinds of warnings in the recipes: let the cookies cool on a rack. But who has time for that? Be agile and decorate them while the cookies are still in the cooling sprint. Oh. Crap. What the heck happened? If you haven’t spent a lot of time doing some test and training baking, your first set of cookies are going to be an embarrassment.

Burnt Cookie by Flare http://www.flickr.com/photos/75898532@N00/Cookie - http://joshuafennessy.com/

Silver Balls, Silver Balls…

And did you know that those little silver and gold balls that are the key part of the most beautiful cookies ARE NOT SUPPOSED TO BE EATEN? It says so right there on the label, “To be used as a decoration, not as a confection”. I bet you didn’t even RTFML. You’ve been unintentionally poisoning your kids and grandpa for decades. Or maybe intentionally. I won’t ask.

Silver Balls with warning (c) Karen Lopez

Lessons Learned

What does this teach us about data?

  1. Recipes make everything look easy. A lot of people see the recipe books and assume that making these cookies is very easy. And yet it’s difficult to get them right. The dough needs to be the right temperature and have the right ratio of ingredients to make the dough the right consistency. This requires not just a recipe, but a lot of practice.  It also requires good technique, the right tools and the right environmental factors.

    The same thing applies to data architecture. Sure, one can watch a 45 minute presentation on what all those boxes and lines are, but until they have applied the principles then lived with the results of their practice designs, they won’t really understand why one cannot just use melted butter or leave out the baking soda because it’s easier. It takes a lot of experience to be a good architect. Just like it takes a lot of experience to make beautiful decorated cookies.

  2. Demos of data modeling and design tools make everything look a lot easier than they are in real life. Part of this is because demos take time to give and they have to deal with the easy case. Sure you can migrate a database from Oracle to SQL Server by running a wizard. But you might not like the database or the data that comes out the other end. In fact, I can guarantee it you won’t. Migrating from one infrastructure to another always requires analysis, design, and implementation expertise. Decisions, even. Tools are never a substitute for design.
  3. If you are an amateur, you’re going to make a lot of mistakes. Heck, even professionals will make mistakes. But amateurs are going to make more.  It’s how it works.  You make mistakes, learn from them, get better. You’re going to burn a lot of data, and therefore users and ultimately customers.  You can read all the recipes in the world and watch all the episodes of Iron Chef, but living with the results of your design decisions is what helps you learn. It’s okay to make a lot of mistakes if you are learning in a class. Or are working on a development project iteration.

    Production, though, is like learning to cook your first meal for Christmas dinner for a close family of 20-30 people. It doesn’t scale well and you’ll just end up disappointing everyone in a big way. Heck, you might even kill some people with your bad design.  You might have some letters after your name, but until you get to the professional level, don’t call yourself a chef.  Well, you can, but your customers aren’t going to trust you after the second batch.

  4. You need to read and learn. Warning labels are a good start. The great think about most data principles is that they haven’t changed a lot. The technologies have, but not the foundations.  If you don’t read and learn, you won’t be in a position to deal with change that is coming whether you want it or not.
  5. Some ingredients for data actually don’t really help the data. Comma delimited data in a column is fast. It allows people to go around the whole data governance process. Stuffing internal-only customer data in to AddressLineFour is fine, right? Until someone prints that on the envelope and mails it to the customer. Sure, these cute workarounds are shiny and happy. You need to be able to see when people are proposing the equivalent of shiny silver balls. They are pretty, but not for use in real life. You can quote me on that.

There are probably a lot more lessons to be learned from Sugar Cookies, but I just wanted to cover the basics. Just like the ingredients for Sugar Cookies.

The Minimalist DBA: DBA Fundamentals

Nov 27, 2013   //   by Karen Lopez   //   Blog, Data, Database, Database Design, Events, Snark, Speaking, SQL Server  //  No Comments

What do you think are the minimum skills a person should have before they are allowed to manage a database?  Does it matter whether or not it’s a production database?  Does it matter how much data is there? What kind of data? Is recovery a goal or a symptom?  Does it matter how old you are? Or how old the database is?  What is the meaning of all this anyway?

Thomas LaRock ( blog | @sqlrockstar ) and I will be talking about what a Minimalist DBA is, what skills we think they need, and how to ensure that they have them on 3 December at Noon EST for the DBA Fundamentals Virtual Chapter of PASS.

image
               "The best DBA is a lazy DBA…or at least a Minimalist DBA"

Every profession has a core set of responsibilities that are expected of every practitioner.  For anyone that has the letters “DBA” in their job description their job function is a black box to anyone on the outside. "What do you do here?" is a common question for most DBAs.

Some DBAs are a part-time data modelers, SAN admins, VM admins. Sometimes they know all about security, or Active Directory, or .NET. It differs from one shop to another. Whether it is day one or one hundred in your career as a DBA you need to make certain you stay focused on your core duties. If you slip up then you will find out why DBA often stands for Default Blame Acceptor.

Attend this webinar to make sure that no matter what your level of efficiency and laziness you are able to focus on the bare essentials (the minimum) necessary to be a Rockstar DBA."

Karen Lopez is a senior project manager and architect for InfoAdvisors. A frequent speaker at conferences and local user groups, she has 20+ years of experience in project and data management on large, multi-project programs. Karen is a chronic volunteer, a SQL Server MVP, and an active advocate for science, technology, engineering, and mathematics (STEM) education and data quality. She isn’t a DBA, but loves to talk and debate about the effectiveness of lazy DBAs.  She isn’t sure if the minimalist thing is a strength or an excuse. 

Thomas LaRock is a Microsoft Certified Master, a SQL Server MVP, a VMWare vExpert, and a Microsoft Certified Trainer with over 15 years’ experience in the IT industry in various roles such as programmer, developer, analyst, and database administrator. He is also the author of “DBA Survivor: Become a Rock Star DBA” (http://dbasurvivor.com) and has participated in the technical review of several other books.

Currently, Thomas is a Technical Evangelist for Confio Software. This role allows for him to work with a variety of customers to help solve questions regarding database performance tuning and virtualization. Thomas also serves on the Board of Directors for PASS as Vice President of Marketing. You can find out more information about him at his blog: http://thomaslarock.com/resume/.

You can probably expect our usual level of snark, debate, levity and great info for this presentation.  Bring your ideas and snark, too.  I always ensure that the audience is part of the presentation, so expect more the a slew of bullet points and demos.  And even though this is hosted by a SQL Server organization, all we will be talking about will be applicable to multiple platforms.  That’s how real enterprise database systems are anyway, right?

You’ll need to register, but it’s free.  By the way, if you also register on that site, you’ll become a member of that chapter.  And that’s free, too.

#SQLLinkBait Contest Winner (CLICK HERE NOW!)…

Sep 16, 2013   //   by Karen Lopez   //   Awesome, Blog, Data, Fun, Snark, SQL Server  //  2 Comments

Recently on Twitter I ran a fun contest to come up with the best SQL blog post title link bait.  Link baiting is a controversial approach to blogging.  The term itself is controversial actually.  In some contexts it just means using a great title.  But this contest was looking for the the best example of a different use of the term, one that’s a little bit more on the dark side of blogging:

Linkbait Definition #2 – “Attracting Link Attention with Controversy”
A lot of folks seem to suggest that certain things people write on the web or create on their sites are “just for the linkbait” – these can include negative or derogatory pieces, inflammatory material, and anything else that designed to incite or provoke a reaction from one or many online communities or blogs.

From <http://moz.com/blog/the-two-kinds-of-linkbait>

That’s the definition I was going for in this contest.  An snark we did receive.   I think this means that the SQL & Twitter communities have seen a lot of linkbaiting.  This was a short contest, with just under 300 posts and about 100 people participating in the conversation, but it reached more than 1 million potential impressions.  That’s the power of social media.

(click to enlarge this chart)

image

The full report on this hashtag can be found at http://keyhole.co/realtime/zA3oKj/

 

Some honourable (dishonourable?) mentions:

Our crack team of judges – Allen Kinsel ( blog | @AllenKinsel ), Thomas LaRock ( blog | @SQLRockstar ) and I picked  Tracy McKibben’s ( blog | @RealSQLGuy ) entry.  I’ll be DMing you, Tracy, with info for collecting your prize pack.  I sure hope you are following me (hint, hint).

I’d love to see some of you take this challenge to heart and write those blog posts.  Hmmm.  Maybe a new contest idea?

Update: It seems that Twitter or WP is having a bit of an issue rendering some of the tweets. Perhaps they will fix this data quality problem soon. Anyway, congrats Tracy.

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to blog.infoadvisors.com by Email


Facebook Flickr foursquare Google+ LinkedIn Skype StumbleUpon Twitter YouTube

Categories

Archive

UA-356944-2