Category Archives: Opinion

What are the Necessary Ingredients for Writing a Successful Book for New SQL Server Developers?

Posted on by

A number of book publishers regularly send me books, hoping that I will write a good review for them. Most of the time, I don’t have the time to read them, so they end up on my bookshelf collecting dust, or maybe I will give them away to friends.

Recently, though, I decided to read one of the books that was sent to me with the goal of writing a review. The book was designed to get non-SQL Server developers up to speed on how to develop SQL Server 2008 applications using Transact-SQL. This is a very worthy goal, because based on my experience, it is bad application design and code that is the root of most SQL Server scalability and performance problems. So I had great expectations when I began reading the book.

Before I go any further, I want to give you an example that I think summarizes this book, then I will go into more specifics. For example, let’s say that a company has hired a new developer right out of college. The developer is bright and knows Visual BASIC, C#, .NET, and so on. In other words, he knows application coding inside and out. For his first project, he is assigned to create a new application that will use SQL Server as the backend database. Unfortunately, other than taking a couple of database theory classes in college, he has never written any Transact-SQL code. No problem, this is a bright developer. He picks up a copy of the book (I was reviewing), reads it, and because he is bright, masters the fundamentals of Transact-SQL development quickly, and he is ready to begin coding his first SQL Server-based application. If I was the DBA for this organization, I would be scared, very scared. The problem is that you can’t learn how to develop SQL Server-based applications from a single book, especially if that book focuses strictly on how to write Transact-SQL, and little else.

Reading this book got me thinking. What would the ideal book that teaches developers how to create SQL Server-based applications include? After some thought, I came up with the following suggestions (not in any special order):

  1. Introduction to DBMS: Assuming the reader has no knowledge of DBMS, the book should begin with strong overview of how DBMS systems work.
  2. Database Design: While entire books have been written on this topic, it is important that developers learn the basics earlier than later.
  3. Teach Transact-SQL: Transact-SQL must be taught in an appropriate order, starting with the basics, building a strong foundation, and then moving onto more complex coding.
  4. Teach How to Resolve Real World Problems: While learning the basics of Transact-SQL is fine and dandy, what is more important is that developers understand how to use it to resolve specific business problems that they will face day-in and day-out. This is one of the biggest mistakes I think most books make. They leave out the messy, real world stuff, instead, focusing on simple examples that are rarely realistic.
  5. Content Must be Current: While this seems obvious, many books include old information that is no longer true. For example, don’t include recommendations based on SQL Server 6.5 if the book focuses on SQL Server 2008.
  6. Must be Accurate: Another obvious point, but some books include obvious mistakes and provide misinformation.
  7. Cover Available Tools: SQL Server has many tools built-in that can make development faster and easier. New developers need to learn how to best take advantage of them.
  8. Best Practices: Transact-SQL allows you to write bad and great code. As a beginner, this is not always obvious. A great book should include recommended best practices so new developers won’t make obvious mistakes.
  9. Holistic: SQL Server-based applications aren’t written in isolation. Because of this, the book should include information on SQL Server internals, indexing, scalability, high availability, how SQL Server best interacts with client-side application languages, the operating system, networking, and much more.

After writing the above list, I realize that it is virtually impossible to include everything I have included to fit into a single book. Instead, perhaps a series of book, each building upon the other, might be a good approach. This way, a person new to SQL Server development would properly get up to speed, putting them in the position so that they could write competent database applications, even though they may not have a lot of experience. Of course, experience is the key to writing great applications, but everybody has to start somewhere, and hopefully is not from reading a single, poorly-written book on SQL Server development.

So what do you think? What are the biggest problems you have found with books you have read that “supposedly” teach SQL Server development? Do you agree with my list, and do you have any items you would like to add to it?

Also, if you have read some books that come close to the above ideals, what are they?

Decoding Micro-speak

Posted on by

I spend a lot of time at conferences where Microsoft employees, such as product managers and developers, make presentations. In addition, I also spend a lot of time talking with them, one-on-one. Over the years, I have noticed that Microsoft has its own set of internal buzz words. Many of these terms are used generically in the IT industry, but I don’t know if they started with Microsoft and then transitioned to the IT industry, or if Microsoft picked up this terms from the IT industry and made them their own.

However it happened, here are some of the buzz words that I hear over and over again from Microsoft employees, along with what they mean.

Ubiquitous:  Commonly and widely used or available. While the use of “ubiquitous” at Microsoft is not as ubiquitous as it once was, it was one of the first terms I noticed that Microsoft used over, and over, and over.

Story: An explanation of the benefits of a particular feature, product, or service. This now appears to be the most common buzz word at Microsoft. Everything has to have a story, from a new feature in SQL Server, to the latest marketing campaign. Another variation of “story” is the buzz phrase “value proposition,” although it is less in fashion than it used to be.

Space: A market niche. “Space” has become popular throughout the IT industry, and is still used a lot at Microsoft, but its use seems to be dying out over time.

Adoption Blocker: Something that prevents a customer from buying a Microsoft product or service. Microsoft often assumes that everything they design and market should sell well. If it doesn’t sell well, then some “adoption blocker” has prevented the sales from taking place. Sometimes, I think Microsoft forgets that not everything they design and sell is necessarily what their customers really want.

Ecosystem: All of the parts that make up a larger system. For example, SQL Server has its own ecosystem, and when Microsoft evaluates a new feature to be added to SQL Server, it has to fit appropriately within the “ecosystem.”

Baked In: A feature or functionality that is included with a product. This term is becoming more popular, and I have often heard Microsoft people say that a particular feature has been baked in the product, which often implies that the customer is getting it for free (as part of a larger purchase).

Dog Fooding: We use our own products for internal use at Microsoft. In most cases, “dog fooding” refers to Microsoft using a beta or CTP version of a product internally before it is released to the public. Think of it as internal beta testing.

Conversation: A discussion. I think a “conversation” often implies that someone is asking for input and feedback, but that it doesn’t necessarily mean that they are really listening, or will take action based on the “conversation.”

Long Pole: Critical path. For example, “If we hire another two engineers, we can do tasks A and B in parallel, but C and D have to be done sequentially, so that’s our long pole.” Thanks to a former Microsoft employee for providing this definition for me.

There a lot more of these buzz words, and I don’t have the space to cover them all. What I want to hear from you is what buzz words do you commonly run across in your work, especially those buzz words that sound amusing or are way overused.