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.

Unacceptable

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.

Mentoring

Paul Randal has announced that he will mentor six people over a two-month stretch.  The night before he announced this, I had incidentally been watching Jason Alba’s Management 101 and Paul’s Communications:  How to Talk, Write, Present, and Get Ahead! courses on Pluralsight.  Both of these courses covered the idea of mentoring and the importance of finding a good mentor at various points in your career.

I am at one of those points in my career now.  I have spent the past several years establishing my technical chops, and it’s time for me to take the next step.  I can see two different visions of what “the next step” entails.  My first vision is a move into a technical leadership role, running a team.  For most of my career, I’ve been a lone wolf, the only database person around.  At my current position, I am a peer but not really a lead (because we have no database leads, due to the way the organization is structured).  As a result, taking my next step might involve moving to a new company…although I do like where I work, so this might be a tough call.

My second vision is to develop further my voice in the community.  Last year, I presented at three SQL Saturdays, gave a number of local user group talks, and even helped put on the first SQL Saturday in Raleigh since 2010.  This year, my goal is to present at a dozen SQL Saturdays (current stats:  1 down, 2 officially slated, and 9 to go), as well as hosting another SQL Saturday and presenting at various Triangle area events.  I even want to go outside of my comfort zone and looking at user groups tied to other technologies and concepts, like Azure, Hadoop, and analytics.  I may never present at PASS Summit (though do trust that I’ll try…at some point…), but teaching people techniques to help them solve their technical problems is enjoyable and I’d like to develop a reputation as a great teacher.  This means pouring time and energy into building a personal brand and establishing enough trustworthiness within the community that enough people would be willing to spend some of their precious time listening to me.

These visions are not mutually exclusive and I think a mentorship with Paul Randal would help me with both.  I have thought of a few areas in which Paul could provide outstanding guidance, and I’ll list some of them here in bulleted format:

  • I want to work on my presentation skills.  As I watch other presenters, I take mental notes on good (and bad) things they do and try to integrate some of the good things into my own presentations.  I have spent some time reading blog posts about improving presentation skills as well, but being able to ask questions to an outstanding presenter (who happens to be married to an even-better presenter) would not hurt at all.
  • I mentioned above my desire to take the next step with regard to the SQL Server community.  My game plan for this year is to present at more SQL Saturday events, but once I’m presenting across the eastern third of the US and Canada, what’s the next step?  There are definitely steps between SQL Saturdays and TechEd/PASS Summit, but I don’t really have a presenter roadmap.  I’m thinking that getting more active with the virtual user group chapters would be a stepping stone, but I admit that I don’t have a good game plan yet.
  • In addition to presenting in person, I’m thinking about trying to create some shorter-length videos on various topics.  My questions here would occasionally be technical in nature (e.g., recommendations on microphones and editing software), but mostly they would be about the human element.  For example, listening to Paul present at a user group (as he did—remotely—to our Raleigh user group last month), I can pick up some differences in style versus watching his SQLskills or Pluralsight videos.  I’d like to be able to discuss these stylistic differences, improving my understanding of videos as a separate medium from in-person or remote presentations to a live audience.
  • Another avenue I have not really pursued up to this point is writing.  I was fortunate enough to be able to contribute to Tribal SQL back in 2013 and I enjoyed the experience enough that I’d like to continue writing.  I have a few ideas, but I’d love to be able to pick the brain of somebody who earns (some) money writing and ask questions about choosing topics and his writing workflow.
  • Following from my first vision, I would definitely love to discuss how to develop leadership skills.  Leadership is about a lot more than simply understanding the technical details; a lot of it is about managing products under constraints (budget, time, political capital, etc.) and keeping your team members excited and productive.  I have some questions about how to do that, and being able to ask somebody who has run development teams at Microsoft and who currently manages a team of consultants would be fantastic.
  • The last topic I’ll hit here is work/life balance.  I will need to do most of the above on my own time, outside of my day job.  I look at some of the more frenetic members of the SQL Server community and wonder how, exactly, they do it.  In Paul’s case, I see scuba, travel, reading lots and lots of books, blogging, Twitter, work, managing a team of top-shelf consultants, conferences, Pluralsight videos, and giving a lot of presentations.  By contrast, I feel like I’m treading water too many days and I don’t want my home life (i.e., the lovely and talented missus) to suffer as a result of professional improvement.  If there are any techniques or practices I can glean to become more efficient or improve that work/life balance, I absolutely want to know.

These are thoughts I scribbled down while on the tarmac in Cleveland; I think that with a mentorship in place, I could expound upon these themes as well as several more.  To me, a mentor is not someone who tells you where to go, nor even really how to get there, but rather someone who helps you develop the mental tools to figure those things out for yourself.  I know where I want to go and I have some ideas on how to get there, and I believe that getting the guidance of an experienced person at the top of my field could help me considerably in making it to “the next step.”