Voice of the DBA

Category: Editorial

  • The Good Job

    I have the best job in the world.

    These days it also seems that many people are disenchanted with their jobs. They work for the paycheck with little loyalty or concern for their company’s business, and I think that’s fair. When I hear about companies that are not very loyal or concerned with their employees, asking for more work every year without more compensation, with less people and the threat of layoffs hanging over the employee’s head, I think employees have to start treating themselves as self-employed. They should consider their employment as a “contract” with their employer, one that is temporary.

    However I don’t know that this is how the majority of people feel. It seems that I regularly meet people that like their jobs, and feel their employers treat them fairly. I feel that way, and think my employer does an excellent job of partnering with employees, rather than exploiting them. People are treated fairly, trusted, and in return, they do a professional job, to the best of their abilities.

    In the last few months, I’ve attended quite a few events and spoken with hundred of people. While the people that often attend events are a self-selective group, but most of the people I’ve had conversations with like their jobs. For the most part they think their jobs are fairly secure. That’s comforting, especially at a time when much of the news in the world relating to the economy and job outlooks is bleak.

    If you don’t have a good job, it’s up to you to look to make a change. It can be a slow, drawn out process, but it doesn’t get done through delay. Make a plan, build up your skills, improve your brand, and set a goal to make a change to find a better job across the next year or two. Life’s too short to live with a crappy job for a long time, no matter how much they pay you.

    Steve Jones

    The Voice of the DBA Podcasts

  • The HR Scorecard

    Dundas controls make building interesting dashboards easy

    Are you looking for a BI project in your company to get some experience with? I’ve got an idea that you might try tackling as a side project, or even an informal project within the business.

    One of the problems that many corporations face today is a regular turnover of employees. That causes a loss of productivity, moral suffers, and projects may run late. This might be because of poor working conditions, poor management, or some other factor. While you might not be able to change that, perhaps you can help bring some visibility to potential problems.

    Human Resource departments are similar to IT departments in that both of them are a cost to the organization without generating revenue. These are overhead departments, and often receive limited budgets and assistance to accomplish anything beyond the bare minimum. These departments can add value, and the good ones help companies in many ways, reducing the costs that might otherwise occur.

    I have rarely seen HR departments with deep analysis tools available to them that might help them function more efficiently. If you want to tackle a BI project, think about building a detailed scorecard or set of KPIs for the HR department that might help them better understand what is happening in the company. Watching for the impact of vacations, turnover, etc. and aggregating exit interview data might help HR improve the conditions at the company, perhaps even for you.

    I’d consider working on an HR BI project, even during some off hours if you have an interest in this area. I’m sure the HR people will appreciate it, and they might be the ones that are in the best position to help you with your career down the road.

    Steve Jones

    The Voice of the DBA Podcasts

  • The Cost of Architecture

    Falling Water is an amazing architectural wonder.

    I saw a note recently about the cost of decisions in programming made over time (thanks to BrentOzar, PLF). It’s an interesting look back at what decisions might have ended up costing computing a tremendous amount of pain and problems over time. It’s a nice read, especially if you remember something about the history of computing and how technology has evolved over the last forty or so years.

    Making decisions and choices early on in the development of a system is hard work. There’s a reason why architects are paid well, and sometimes seem slow to decide how to proceed. The high pay, however, is a reason why so many people crave the architect title, and even find reasons why they should get it, even when under qualified. Unfortunately we have no good guidelines on how to decide what titles someone should have, or they have earned.

    A great developer, a great architect, is often worth much more productive than an average one. Not only while building a system, but also in the future as the system is used, evolves, and is improved by others. Making good choices early on can result in much better software over time, as the ways in which software is improved are often based on the way it was originally built. Future developers try to continue to add to the project, or are constrained, by the early decisions made about the architecture.

    Hindsight always gives you a better view of a decision than you have when you are making it. Even in the article the author points out that the biggest mistake he found in computing was still the best decision at the time. We will hopefully make many good decisions, but all of us will make some bad ones. Whether in specifying hardware, writing T-SQL, or some other choice, we will find over time that some of our choices were poor ones.

    The best thing we can do is learn to look back at our architecture decisions over time and evaluate whether they were good or bad. Learn from our mistakes, and learn from the mistakes others have made, trying to strive to do better in the future with the knowledge that comes from examining the past.

    Steve Jones

    The Voice of the DBA Podcasts

  • Which Versions of SQL Server Do You Have?

    SQL Server v6.5 retail box
    This was my 5th SQL Server version upgrade.

    I have worked with every version of SQL Server since it was first available from Microsoft on OS/2. Each version has improved the features, the stability, and the scalability, and I’ve looked forward to each change. In many of the companies I worked at, we had a fairly homogenous environment, with one or two versions to support. I think some of that was the timing of my employment dates with the version release dates. If I’d stayed longer at a few jobs, I think I might have ended up supporting three versions of SQL Server in a few places.

    That seems to have changed, however with the long delay of SQL Server 2005, and then the very short delays for SQL Server 2008 and 2008 R2. Now it seems many companies have two or three versions at a minimum and might have 4 versions, with SQL Server 2000 servers still available. The last year on Twitter I’ve seen a number of DBAs noting that they are retiring SQL Server 2000 instances at a good clip, with a few people eliminating the version from their environments, but there are plenty of instances still out there.

    This week I wanted to see what percentage of people are still supporting older versions. There seems to be less of a push to upgrade old servers, but we still install the latest version for newer servers. Supporting more versions may mean a higher cost of support for your infrastructure, so I decided to ask this question:

    What’s the oldest version of SQL Server you still support?

    It would be good to know how many versions you are supporting, and if you have older versions (v6.5, v7, v2000), are they used in limited systems, such as keycard systems only. My intention is to try and get an understanding of the shape of the SQL Server community, and the types of work they do each day.

    As SQL Server evolves from a core database engine and includes a wide variety of subsystems and features, I think there is less of a need to upgrade existing instances en masse. Instead targeting those applications that receive large benefits from the changes seems to make more sense. With a very stable engine and very few security problems, I think that companies will use each version longer and require their DBAs to support more versions at any one time. I am sure by the middle of 2010, we will have some DBAs supporting five versions of SQL Server in their companies, going back to SQL Server 2000.

    The Voice of the DBA Podcasts