Things I Know Now...

Adam Machanic — Mon, 16 Mar 2009 16:38:00 GMT

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

Adam Machanic : experience, things you know now

Things I Know Now...