As I sat at home convalescing after a well twittered surgery, I have talked to several of my friends on the phone, and many on twitter.  One conversation has stuck in my mind. It was about what another person was going to do, and how they were going to stop doing such “commercial” stuff.  At first, it hit me as kind of weird thing to think about doing something different since I have been writing about database design now for nearly 10 years.  However, I realized that in the SQL writing world, there are lots of different sorts of projects and clearly I have not picked one that could be seen as commercial.

By commercial, I mean stuff that everyone wants to know about. There are a lot of people who are lucky in this respect.  For example, take my favorite SQL Server writer/MVP Kalen Delaney (easy target, for sure.)  Kalen has a lot of really great books on topics that people want to know about in that she talks about the internals of SQL Server and shows us how SQL Server works.  You can see her work on her Amazon author page here: http://www.amazon.com/Kalen-Delaney/e/B001JS5NZO.  This is clearly not like art where people “sell out” and start drawing pictures of babies playing jazz instruments instead of artsy stuff that no one will “get” until hundreds of years after the artist has died, just that some topics are more interesting right off the bat (internals, T-SQL, performance tuning, etc) while others (like database design) aren’t something that everyone cares a whole lot about.

The problem is, to write a technical book, there are a few factors that are important. I think the three important ones are:

• Interest – How much you care, how passionate you are about a subject, basically how willing you are to give up sleep/video games to share information about a subject with others.
• Experience – How much experience you have with the subject
• Audience – How many people there are that might shell out a few Andrew Jacksons to buy your book

Yes, there are other factors such as how good of a writer you are, if you have time, knowledge, etc. If you are thinking about writing a book on a subject, you probably have, or can get, the foundational knowledge, but experience is earned over time.  I did not have the proper experience when I wrote my first book, and it showed somewhat, though with books, editors are clearly the key to success, even with experienced writers as they can mask some poor writing and even some technical skills if they are good enough themselves.

Basically you have a diagram that looks like this:

Experience can be somewhat attained during the writing phase, since someone has to be the first person to do something.  And ALL people writing training and documentation are generally doing this as they go (which is  often why documentation and training often sucks, and a good teacher uses it as a guideline and a bad one reads from the book.)  Interest is sort of gained as you write, but I can’t see too many tech writers writing about something they don’t have passion for, particularly in this day and age.  13-15 years ago, before the Internet was so strong, you could make some good money, but (right around the time I got started,) afterwards not so much.  So we do it because we enjoy the topic (and it brings a modicum of notoriety).  Audience is very hard to gauge at time, but it isn’t hard to guess that something like design where 1 or 2 people in a company might do it is not going to sell as well as say a book where even people who don’t use databases everyday in their job might want a copy.

If you are lucky as an author the part in the middle of that diagram is very very large.  The more overlap of interest, experience and audience, the better.  All too often, though, the problem is interest.  There are lots of great DBA’s out there who have no interest in doing any more than just having and doing their job.  I call these people “sane”.  On the other end you have people who are what Microsoft’s MVP program is set up for.  People who want to share about what they do, somewhat for free at conferences and such (both major like PASS and TechEd, where you might get a small fee and ones like SQL Saturday where no one is making any money) and for really small amounts of money like 95% of all technical authors. For me, my problem is, the audience is quite small, so I end up with something more along the lines of:

A secondary problem is that getting experience is a bit problematic as most consultants (those who get the breadth of experience) deal with the after effects of a poor design.  Most companies think they can do it themselves and do a poor job, then call in a consultant.  This is where interest really plays a part because you have to really work your mind and design stuff in your head all of the time.  I have done mental data models about how I would model Disney World almost every trip down there. 

It is a subject I find near and dear to my heart because I see it done so poorly so often in conversations on the web, and even in the place where I work (when we did our huge project to end a legacy Foxpro App, they had me designing data warehouses…and all of the people who did database design on the other stuff…are gone…go figure.)  Database design is something everyone thinks they know how to do and they are “somewhat” correct. Take any novice’s design, and you will see some glimmer of correctness in it.  For example, you would almost never see a table with Customer, Invoice, and Invoice Line Item information all piled into the same table. Instinctively this information is put into three tables. Problem is…this information may only need to be in two tables. Customer information may need to be in the Invoice for historical purposes. Or perhaps not.  Or maybe it is in two places. Or maybe you need 20 tables. Without taking the time to analyze WHAT you are are actually trying to accomplish, you will inevitably get it wrong and pay the price.

The real audience out there is for information about what comes next.  I am part of that audience too, so I am grateful to the Kimberly Tripp’s, the Itzik Ben Gan’s, Adam Machanic,(again) Kalen Delaney, etc, etc (no offense to other writers, these are the books I have made an effort to read at one time on the subjects) who cover all of the programming stuff that I do cover too (triggers, etc) and stuff I don’t cover in any depth like T-SQL, Procedures, tuning, indexes, etc.  I could write for this audience (and did a chapter in Pro SQL Server 2005, much of which is included in Accelerated SQL Server 2008, though not credited as I did my chapter “work for hire”) and I do enjoy it, but the competition is great and I really don’t have much more to say than they already say, and probably wouldn’t do as good of a job at that. (Honesty is a very hard quality to master!)

The funny part is that the poor designs lead to SO much consulting work for many people, but I think even they wouldn’t mind it if they got to work on stuff that worked nicely every once in a while.  Even if you are the greatest designer fixing a poor design is never easy, mostly because tons of application code is deeply coupled with these structures.  The Audience for design information really ought to be anyone who needs to do a design, and this would be a huge pool of people. In fact almost every company out there who does anything more than purchase canned applications should need to think deeper about database design.

I too am working on a non-design book with Tim Ford for Red-Gate that will cover using the Dynamic Management views that has been slowed by my surgery, but should be on track to finish up this year (hopefully for SQL PASS!) that should have a great audience.  The topic there is how to find out how horribly your code is working your server…and eventually fix it.  Some of the problem with this book has been that I don’t have quite the passion I have for database design, and I have a hard time dragging myself out of the bed or off of the TV to work on the book when I am not feeling 100%..and every author with a day job knows, writing is like a second full time job without nearly the pay.

For much of the rest of the year, I will be focusing on Database Design for sure, as I have several speaking engagements on the topic with Paul Nielsen, who is the lead author on the SQL Server Bible Series):

• Devlink, August 13 (http://www.devlink.net/Sessions/InDepthSessions/tabid/200/Default.aspx) – In Depth Session on the Database Design Process
• 24 Hours of PASS, September 1, “Ten big ideas in Database Design”
• PASS, November 2-5 – Pre-Con on Relational Database Design. 

and tentatively a session at SQL Saturday in East Iowa (if accepted) and (already accepted) one session by myself at PASS dynamically entitled “Database Design”.  Plus I am going to finish up the pillar stuff so I can start working on my next Database Design book for the next version of SQL Server…but after that…Well, I will probably just keep going and whine about it occasionally to my blog readers.

Oh, and if you are anyone waiting on me to finish something, this blog has been written for weeks…just did a quick edit/mod tonight 🙂