May Speaking Events

I will be speaking at two SQL Saturdays in the month of May.

On May 9th, I will be in Jacksonville, Florida for SQL Saturday #391.  My topic will be Hadoop.  This will be the only Big Data session at #391.  Right now, I’m scheduled to speak at noon.

On May 16th, I will be in Rochester, New York for SQL Saturday #383.  My topic, again, is Hadoop, and I am scheduled to present at 1:30 PM.  James Serra will be there, so if you’re looking for Big Data, you can schedule the entire afternoon.

Speaking At SQL Saturday Rochester

I just received word that I was selected to be a speaker at SQL Saturday #383 in Rochester, New York.  I will give my presentation, Much Ado About Hadoop.  I might even touch it up a little bit, now that I have a little more work experience with Hadoop.

I will be in Rochester for a few days, as it’s the first time I’ve ever been to upstate New York.  My plan is to stock up on Buffalo Bills paraphernalia while I have the chance…

Pluralsight Review: Unit Testing T-SQL Code With tSQLt

I recently completed Dave Green’s Pluralsight course entitled Unit Testing T-SQL Code with tSQLt.  I think the material was solid and Green does a good job presenting it, as well as Red Gate’s add-on tool called SQL Test.

I did learn a lot about tSQLt from this course.  I had played with tSQLt a little bit a few years back, and it looks like the product has matured since then.  One of the big reasons I was interested in checking out this course is to see how tSQLt handles isolating dependencies, and Green has an entire section on the topic.

My main problem with the course has nothing to do with Green or the way he presented the topic; rather, I think it’s a flaw in the product itself.  It seems like a lot of the tests that Green walked through did more testing of tSQLt than actual business or procedure logic.  For example, to test a check constraint, the tests weren’t really checking the constraint, but rather a mocked constraint.  This seems like an artificial attempt to force unit testing in a place where integration testing is appropriate.  Again, I don’t blame Green for this; rather, I think it’s a disagreement I have with the product itself.

Earning The Right To Say “No”

I’m a little late to the party here, but Grant Fritchey had an interesting post about DBAs being auto-naysayers.  Let me preface this by saying that I agree with Fritchey and I believe he would agree with me.  Our difference here is more in tone than content.

I believe that protecting the data is a data professional’s most important job.  These are people who have specialized in methods of data storage and access which most developers want to ignore, and I like developers who freely admit that they don’t want to deal with this stuff; it lets them specialize in other techniques and technologies and work with me to figure out the best way to collect and retrieve what they need when they need it.

There are three important words in the paragraph above:  “work with me.”  In other words, data professionals need to work with UI professionals and web service professionals and guts-programming professionals and all other kinds of professionals to build products for which customers are willing to pay.  Protecting the data is vital within the constraint that the company needs to be able to deliver features and functionality that customers want.

Putting this in monetary terms, good ideas debit your psychic account, and saying “No” to people credits your account.  If you run out of cash in your psychic account, people stop listening to you and start trying to go around you.  What this means is not that you need to be a doormat.  Instead, I draw three conclusions from this:

  1. Build up your psychic account.  You do this by making processes faster, getting difficult reports out, and generally getting off your lazy butt and doing work.  Show that you’re improving your code base, delivering products, and not just acting like an anchor.  Show that you can work with developers, with operations, with management.
  2. Say “No” when you really mean it.  People who are not data professionals (should) look to you for advice and understanding.  They will often have naive or incorrect understandings of how things work.  Sometimes, these ideas are terrible.  Shoot them down.
  3. Try to have an alternative when you say “No” to someone.  That psychic credit isn’t nearly as steep when you say “No, we can’t do X because of reasons A, B, and C.  Instead, we can do Y, which will get you the same result, but will reduce database load by 40% and prevent this from blocking ETL process Z.”  You don’t always need an alternative, but it certainly helps.

It’s easy to fall back on “No” as the automatic answer, and that’s generally the wrong answer.

Code Is A Liability

I love deleting code.  I like getting rid of unused code, reducing the amount of code in my code base, and making sure that the remaining code is adequate to the task.  I think that this is so important that I even wrote a series which focuses in part on minimizing code.  I think that a good developer could walk into any non-trivial environment and find, with a nominal level of effort, 10-20% of the code base which could be eliminated entirely and nobody would notice.

The title of this post, as well as my introductory paragraph, is deliberately provocative.  Nevertheless, I believe that it is entirely true.

When most people think about code, they think about the end result:  the applications.  They tend to equate “the code” with “the application.”  In reality, those are different:  a particular code base is one way to achieve a specific application result.  The application itself is an asset; people are interested in that application inasmuch as it provides use value to them.  The specific details of underlying code has no bearing on their use value of the application itself.  In other words, if you could take a million-line code base and refactor it into 100,000 lines, it would provide no direct benefit to the end user in a steady state.

So why do I push so hard for refactoring code?  The reason is that it provides value to users and to those producing and maintaining the code over time.  Every line of code which exists in an application is a line of code which somebody needed to write, somebody needed to test (hopefully!), and somebody needs to maintain.  Those are all direct code costs.  In addition to those costs, there is a cost of new features.  With an ossified code base full of junk code, writing a new feature is significantly harder; there are many more dependencies, more places for code to break, and more undocumented expectations than in a clean code base.  By refactoring code vigorously and improving the code base, we reduce the time-to-market for new features, providing additional value to the end user.

To use an analogy, let’s say that I make a wooden chair.  My amount of effort is a liability:  it is a direct cost that I, the seller, incur and which provides zero value to the buyer.  The buyer wants my chair because of its quality, not because of the number of hours I put into it.  If my process is very inefficient, I might not produce enough chairs or chairs of a high enough quality.  I grant that this analogy is imperfect, but hopefully it clarifies more than it clouds.


SQL injection vulnerabilities were up in 2014.  Sounds like a bunch of product managers need to buy copies of Tribal SQL and read the SQL injection chapter.  Seriously, SQL injection should have died a decade ago and my presentation on the topic should simply have historical value.

On the Anthem breach, Chris Bell is fed up as well.  Check out the comments there for additional insight.  There’s no word yet on the exact nature of the breach, but given the frequency with which data gets out into the wild, someone else will get popped next week.