Adam Machanic : things you know now, experience, wisdomhttp://sqlblog.com/blogs/adam_machanic/archive/tags/things+you+know+now/experience/wisdom/default.aspxTags: things you know now, experience, wisdomenCommunityServer 2.1 SP2 (Build: 61129.1)Things I Know Now...http://sqlblog.com/blogs/adam_machanic/archive/2009/03/16/things-i-know-now.aspxMon, 16 Mar 2009 16:38:00 GMT21093a07-8b3d-42db-8cbf-3350fcbf5496:12653Adam Machanic1http://sqlblog.com/blogs/adam_machanic/comments/12653.aspxhttp://sqlblog.com/blogs/adam_machanic/commentrss.aspx?PostID=12653<p>I don't usually respond when I'm tagged with these blog memes, but <a href="http://www.straightpathsql.com/blog/2009/2/9/things-you-know-now.html">this one</a> is especially interesting so I decided to play along. I was <a href="http://blogs.technet.com/wardpond/archive/2009/03/15/what-i-know-now-ward-s-epistle-to-the-n00bs.aspx">tagged by the always-interesting Ward Pond</a>,
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.</p><p><b>"Not Invented Here" syndrome really is a sickness. </b>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 <i>actual business problems</i>, 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 <i>think </i>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.</p><p>&nbsp;</p><p><b>Great software cannot be created in a vacuum. </b>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.<br></p><p>&nbsp;</p><p><b>Guessing is (ideally) not the right way to do performance tuning. </b>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 <i>this way</i> 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. <br></p><p><b><br></b></p><p><b>Sometimes it's better to get the job done quickly than to do it perfectly.</b>
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.<br></p><p>&nbsp;</p><p><b>Sometimes it's better to do the job perfectly than to get it done quickly. </b>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.<br></p><p>&nbsp;</p><p><b>Never stop asking questions... And always remember that there are no right answers.</b>
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.</p><p>&nbsp;</p><p>... and now it's my turn to pass the torch. But who should I tag..? How about:</p><p><a href="http://sqlblog.com/blogs/kalen_delaney/default.aspx">Kalen Delaney</a> </p><p><a href="http://blogs.msdn.com/gertd/">Gert Drapers</a></p><p><a href="http://rusanu.com/">Remus Rusanu</a><br>
</p><img src="http://sqlblog.com/aggbug.aspx?PostID=12653" width="1" height="1">wisdomthings you know nowexperience