THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Adam Machanic

Adam Machanic, Boston-based SQL Server developer, shares his experiences with programming, monitoring, and performance tuning SQL Server. And the occasional battle with the query optimizer.

Things I Know Now...

I don't usually respond when I'm tagged with these blog memes, but this one is especially interesting so I decided to play along. I was tagged by the always-interesting Ward Pond, and the list of people this meme hit before it even got to him is already quite impressive, so I'll warn you in advance: most of what I'm going to say has probably already been said by the others. But why let that stop me? Here are a few of the tidbits I've picked up that I wish I knew when I was starting.

"Not Invented Here" syndrome really is a sickness. I once worked for an IT manager who felt threatened when one of the business units purchased a prefab intranet solution. "We could have done that, and done it better," he said. "Why didn't they come ask me for help before buying this solution? We're going to fight back--and create our own." And so my marching orders were handed down and I was told to start working on it. A year later I had built a pretty cool intranet app, but guess what? The prefab solution had more features, and in many cases did them better. Another time I was working for a company that had a really bad case of "we don't buy code we can build" and I spent weeks trying to emulate the behavior and match the performance of a commercial ActiveX grid control that I had tested. We could have purchased the control for $200, integrated it in a day or two, and moved on with solving actual business problems, but instead I wasted a large chunk of time and the company's funds--all because management felt that buying something already created would be cheating. Well, my idealistic days are well behind me, and now I do a Google search before I even think about firing up Visual Studio. In the vast majority of cases if I can buy it rather than build it that saves me--and my customers--time and money. And that's time and money that can be spent much better solving new problems rather than revisiting those already solved.


Great software cannot be created in a vacuum. My threatened manager--the one who had me build an intranet system to compete with the one the business had already purchased--subconsciously knew that he wouldn't get buy-in from the people who had bought the outside system. So we created our own set of specifications, without even telling the users that we were working on it. I was actually specifically forbidden from discussing the product with those who were supposed to eventually use the thing. I was young and somewhat naive, and although I knew that this felt wrong I didn't have the nerve to do anything about it. And so--of course--when we finally did unveil a test version the users weren't especially interested. The response we got was something along the lines of, "that looks okay, but it doesn't really match the work flow we need for our business processes..." And that failed project taught me a valuable lesson: When it comes down to it, software is created for one reason only, and that's to be used. Failing to talk to end users about their needs is an almost certain guarantee that they won't buy in, and failing to secure buy-in will almost certainly mean that the software won't be used. And unused software might as well have not been created to begin with. That project was a dismal failure.


Guessing is (ideally) not the right way to do performance tuning. I can't tell you how many hours I wasted, early on, trying to debug performance problems with absolutely no clue what I was doing. "Hmm," I would think. "Maybe if I try doing it this way it will make a difference." Eventually (usually) I would hit on a solution, and I would be happy, but I still had no conception of what I'd done or why. Today I take the most scientific approach I can: I collect evidence, I form a hypothesis, and I test that hypothesis. Sometimes I can't get enough information to create a complete picture and a bit of guesswork is necessary, but especially when working with SQL Server 2005 and the DMVs, guessing is mostly a thing of the past. If you find yourself randomly trying something different to see if it performs, take a few steps back and think about whether you can, instead, collect more information and think about why the current solution doesn't work and how the perfect solution would behave. Then think about how to get there. Chances are, you'll be a lot more productive, you'll learn something along the way, and as a bonus you'll be able to take a lot more pride in the results.

Sometimes it's better to get the job done quickly than to do it perfectly. It's happened to all of us. You get so bogged down in some little tiny data quality issue that progress comes to a halt. The users are asking where the software is. Management is breathing down your neck. But damn it, you are going to fix those misspelled names in the database if it's the last thing you do! Perfection is a great goal, but in reality it's more of a journey. If users are getting impatient and a few errors won't hurt their overall impression or ability to use the product, ship now and fix later. I learned this lesson firsthand while working for a startup that managed to get a lot of press before it shipped its very interesting product. Users were lined up waiting to get in, but the CEO, a perfectionist, kept thinking of new ways to innovate, and six months after press time we had made so many changes that the once-stable product was a mess and we were not even close to a release date. The press noise had died down and users had moved on to other things. When we finally did ship, a year later, there was very little fanfare; the momentum was gone. And in retrospect, all of those cool things we did during that year could have been bolted on later; the product had been solid and in a shippable state at press time.


Sometimes it's better to do the job perfectly than to get it done quickly. First impressions are everything. A user, excited, turns on your new application... And waits a full and painful two minutes as the first screen loads and the buttons become responsive. Once things are ready, the user starts clicking around... And hits an exception. And the user shrugs, clicks the "X" in the title bar, and moves on to something else--never opening your application again. Users are fickle, and it's because they can be. Unless your application is truly revolutionary it has lots of competition. So don't ruin the first impression in your excitement to get something to market as quickly as possible.


Never stop asking questions... And always remember that there are no right answers. If you read both of the last two items you might be wondering where I'm headed. Are you supposed to ship now, or wait? The answer is, of course, in this example and most others, that it depends. The most important thing is, therefore, that you think about the right answer in every case. Always question everyone and everything, including yourself. Don't be afraid to change your own answers or admit that you're wrong; it looks much worse, in the long run, to stick with a wrong answer than to correct your path early--even if it might be painful for a little while. Regular readers of my blog know that I've corrected my own errors on many occasions, and I will continue to do so. Perfection, once again, is a journey, not a goal.


... and now it's my turn to pass the torch. But who should I tag..? How about:

Kalen Delaney

Gert Drapers

Remus Rusanu

Published Monday, March 16, 2009 1:38 PM by Adam Machanic

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Chris said:

for a small component not invented here is fine, but a lot of times like for a giant intranet system you need to pay support.  quite often the vendor does not give you source code access so if you don't keep paying for support the application will start to have bug after bug.  Also as other systems that you use with the application get later and later version without support it becomes a challenge to keep hiding changes from all the other applications to support this ancient legacy piece of software.

The other dark side is that you buy something external that needs to be "customized" to work with your system.  this customization costs more than it would cost for you to develop it yourself.  Now any change requires a huge amount of money from the vendor so you are hesitant to change anything.  You are left on an ancient version of the vendor product unable to upgrade because you would have to pay again for your customization.

What a nightmare.  And for a developer it is very frustrating to be in that situation where you don't know how the app works, you don't have source code or even adequate documentation, and you boss expects you to make it work even as everything else is changed/rewritten.  Honestly the stress in a job like that makes it not a long time career.

I'm not saying never buy.  But if you're going to buy then you're going to pay.  After all the extreme case (which still happens) is you bought the system for windows 3.1 and had it customized and then never upgraded.  Now you are stuck running windows 3.1, and supporting that, a long with whatever programming languages worked on windows 3.1 (I think VB 4 could do 16 bit and 32 bit apps).

March 23, 2009 8:31 AM

Leave a Comment


About Adam Machanic

Adam Machanic is a Boston-based SQL Server developer, writer, and speaker. He focuses on large-scale data warehouse performance and development, and is author of the award-winning SQL Server monitoring stored procedure, sp_WhoIsActive. Adam has written for numerous web sites and magazines, including SQLblog, Simple Talk, Search SQL Server, SQL Server Professional, CoDe, and VSJ. He has also contributed to several books on SQL Server, including "SQL Server 2008 Internals" (Microsoft Press, 2009) and "Expert SQL Server 2005 Development" (Apress, 2007). Adam regularly speaks at conferences and training events on a variety of SQL Server topics. He is a Microsoft Most Valuable Professional (MVP) for SQL Server, a Microsoft Certified IT Professional (MCITP), and an alumnus of the INETA North American Speakers Bureau.

This Blog


Privacy Statement