A community of more than 1,600,000 database professionals and growing

This editorial was originally published on Dec 17, 2013. It is being re-run today as Steve is traveling. 

Along with risk comes the inevitability of failure.  With few exceptions, every organization and every person will, in time, experience some form of failure.  We all hope to prevent and avoid the kind of colossal failure that presents a do-or-die moment for a business (or career), but when those moments do come, it's important to fail properly.  Even when the unthinkable - a hack, a dropped production database, a loss of data - happens, it's critical to respond properly to minimize the damage and clearly communicate with those affected by the disaster. 

When I first read the news about the massive Buffer hack recently, I was nervous.  I have been a Buffer user (albeit a relatively inactive one) for a few months, and since I have several social media networks connected through Buffer, I was concerned that those accounts may have also been compromised.  I quickly learned that my account was not impacted, but immediately I was impressed with the way Buffer handled the whole mess.  It was bad - some 30,000 users were affected (out of a total user base of over 1 million) by the hack that allowed spammers to post message to the Facebook accounts of the affected users. 

Regardless of how the issue was handled, it was going to be ugly at the end of the day.  However, Buffer did a fantastic job of minimizing the damage in the way they responded to the breach.  Within a couple of hours of discovery of the hack, Joel Gascoigne, CEO of Buffer, owned the failure by notifying Buffer users via email as well as through his blog and other social media.  In a message entitled "Buffer has been hacked - here is what's going on," Gascoigne admitted that there had been a breach, described the symptoms of affected accounts, and listed for users what they should do in the meantime to prevent any further spam postings.  Even though they didn't (at that time) know exactly what had led to the hack, he repeatedly apologized on behalf of Buffer without trying to make excuses or shift blame.

In the hours and days to come, Gascoigne repeatedly updated Buffer users, via email and through his blog, on what they had learned about the breach, how it happened, and what users needed to do to resume normal operations with their Buffer accounts.  The information he shared was both detailed and transparent - he didn't try to hide behind vague explanations or invoke confidentiality.

Did he handle this failure properly?  A quick perusal through the comments on his blog post show an overwhelming collective message of support and thanks.  There is no doubt that this breach cost Buffer some users, very likely some of which were paying users.  However, the public response in support of Buffer shows that rapid response, clarity and honesty in communication, and taking responsibility for failures goes a long way when the worst happens.

Failures will come.  How we address those failures is often as much of the story as the failure itself.  Fail the right way.

Join the debate, and respond to today's editorial on the forums

The correct answer is to use the SSMS Compare Showplan menu choice.

SSMS 2016 has introduced a new utility that allows you to compare two execution plans to find their similarities and their differences. One of the plans must be saved as a *.SQLPLAN file. That can then be opened to compare to another plan within SSMS. Initially the plans above look like this:

The similarities have been highlighted. Differences are not highlighted. This means that differences are in the SELECT operator in the properties. You can drill down on them to see the actuall differences between these plans:

The primary difference in these two plans is the time and resources it takes to compile them.

» Discuss this question and answer on the forums