Voice of the DBA

Author: way0utwest

  • We Are Not a Meritocracy

    I’ve heard a few times over the last month that the technology business ought to be a meritocracy, where people are hired, promoted, and fired based on their skills and talents. It’s usually accompanied by a mandate that everyone should  “hire the best person for the job.”

    Information Technology may be the closest we get to a meritocracy, but it certainly isn’t one. Your skills matter, your talent matters, but it’s still a who you know and who-you-get-along-with that overrides everything else. More often than not, skills alone will not carry you far. You need to have a bond with the people that hire you.

    If we were a meritocracy, we could just give everyone a test that applied for a job and hire the person with the highest score. Or just use a lottery to pick everyone that achieved a certain score. That doesn’t sound like the kind of place that I’d like to work since I place a lot of value on the interpersonal relationships with other people.

    It seems that most people really want their employees, or co-workers, to meet some minimum level of competency, continue to improve their skills, and do their share of the work. That’s reasonable and I can appreciate those qualities in people, but the thing that’s most important to me is that we get along.

    I can work with you to improve your technical skills, but I can’t usually do anything about your personality.

    Steve Jones

  • Busy Week

    It’s going to be a busy week for me. At last count, I had over 40 comments for my T-SQL Tuesday party. Most of them are of a decent length, and I need to get through them all to write a summary.

    I’m hoping to get it done for Friday, but no promises right now.

  • T-SQL Tuesday #13– The Business and Disaster Recovery

    I’m hosting this month’s T-SQL Tuesday blog party, but that doesn’t mean I can’t participate. I posted the invitation last week, and hopefully we’ll have a large number of people participating today.

    The Cost of HADR

    I’ve dealt with a lot of business people over the years, and for a variety of reasons. At one job, I worked for a small company, literally about 50 people, and we had a number of systems critical to our business. We had a large fax server, receiving hundreds of faxes a day from overseas. We had a large imaging server/platform in which we stored our faxes along with quite a bit of other business correspondence that we needed a record of, and we had an inventory management/sales system running on SQL Server that people used every day to run the business.

    These were all important systems, and if they were down, business would slow to a crawl. The owner of the company wanted to take advantage of all our technology and mandated “no downtime” and “zero data loss” to my boss, the VP of sales for the company. He was, of course, happy to push this down to me as a goal for the next year.

    This was in 1997, and as I investigated our possibilities for achieving this, I realized very quickly that it wasn’t a good move for the company. Clustering in SQL Server v6.5 was shaky and hard to install and maintain. Marathon Technologies had a machine that was basically a “cluster-in-box” that would do a lot of what we wanted, but it would have been around a $30k server. Since our two SQL Servers cost about $7k together, this didn’t seem like a great solution to me.

    Instead I investigated what downtime cost us. What would it cost in terms of work and salary if we had to re-enter data that might be lost. We had been down for various periods of time due to different events, and the business had survived, even one day when we were shut completely down for 2 days.

    It quickly came to light that we’d have to be down for over a week to really cost the business more than $30k, and that was debatable. We could still conduct lots of work on paper and over the phone, so it didn’t make sense to aim for zero data loss and zero downtime. I explained it to my boss, laid out a simple case for him with a few numbers highlighted, and the provided an alternative for investment in a little redundancy, designed to minimize losses, but not prevent them.

    In the end the big boss agreed. He hadn’t really meant zero loss, after all, anyone in business knows that there are always going to be some losses. What he wanted was his business to keep running, cost effectively. That’s what we gave him at a much more reasonable price.

  • The Low End

    Are products like Access and VB bad? A long time ago it seemed that if you could spell VB, you could get a job. That was good in some ways as it helped the explosion of growth in technology employment. It was bad because we had many people building applications without understanding software development and we ended up with many buggy, crash-prone applications.

    Someone posted recently  that these “low-end” products had helped them get a job and get started in this business. This person thought my comment was a complaint against these software products, but that’s not the case. I know quite a few people have built or supported applications on Access, VB, or Excel and then gone on to a career with SQL Server. In fact, the first business application I built was on Lotus 1-2-3, using a large combination of macros to help someone with estimating.

    Are “easy-to-use” products like Access or Excel good for business? Should they be used to build applications? Like most things in technology, the answer is “it depends.” Often these are not the basis for a robust system on which you run your business, but they can be. Often there is a need  or desire for something to be built quickly, and cheaply, in order to accommodate some aspect of business. These tools are a way for some type of automation to be assembled quickly and used by business people.

    However you can outgrow these applications and find that something stronger is needed. That’s the time when an IT project makes sense, and arguably, that’s the appropriate time to spend the money.

    I like prototyping useful tools, and Microsoft provides ways to easily accomplish this.  To me, software like Powerpivot seems likely to spur on more projects, not fewer.

    Steve Jones