Voice of the DBA

Category: Editorial

  • Data or Experience

    Data Driven

    Listen to the data.

    There are any number of phrases that implore us to use bits and bytes, pieces of information that lead us to better decisions. However, can the data ensure we make the best decisions? Do the models we use get better and better over time? It’s hard to tell.

    This has certainly been debated in the wake of Moneyball, the book that ocuses on the use of data over experience to drive decisions for baseball teams. The Oakland As were the first team to do this, without winning a championship, but the Boston Red Sox also followed the formula and won three championships in the last eleven years.

    However they’ve also had some abysmal years, including the current one. Does that mean that the principles of data driven decisions work, don’t work, or something in between? Personally, I think that the ideas of predictive analytics does work, but it’s not magic. It’s also not a guarantee of reaching some level of performance.

    In sports there’s a strong human element involved. While many players do perform at a similar level from one year to the next (slightly higher or lower), there are also times when a player dramatically diverges from the past. There’s also the notion that a sports team is a very small sample size for statistical analysis. Trends tend to be easier to predict when there are thousands of people’s behavior involved.

    There’s also some variance from transaction to transaction. Even in retail, where I might be able to predict today’s sales fairly accurately, I couldn’t necessarily determine the volume of sales for a particular product or the total on any transaction. Statistics are generated over time, and they’ll be accurate over time as well. Just understand that in the more a human is involved and the more detailed your granularity, the more actual results might deviate from your predictions.

    Even the card counters in Bringing Down the House, for all the millions they earned, still expected to lose some hands, and occasionally some big ones. Keep that in mind when making data driven decisions.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • Trust People

    This editorial was originally published on Jan 6, 2011. It is being re-run as Steve is away on vacation.

    I saw an article recently with a great title: Put your trust in systems, not in genius. It is a great read, and starts out by talking about the Gauls and their sacking of Rome in 4BC with a superior army. However by 200 years later, the Roman army was the strongest in the ancient world. How did this happen? Many people believe it was the creation of a set of processes, management, and training that used standards and synergies to achieve greatness.

    Many companies today try to implement standards, and strong management of their staffs, but they don’t achieve greatness. Why not?

    I think it is because we have failed to grasp the important fact that building a system, a set of processes and procedures and unleashing managers to enforce the rules is not the important part. The really, really important thing is using the thoughts and ideas, the brain power of the individuals to evolve and adapt the procedures to work better. We too often don’t “trust” our individual knowledge workers to make good decisions.

    We have to hold people accountable for results, for building better systems, and then let them bend rules, change procedures where it counts. Most people want to do a good job. If we give them the responsibility to do so, I think most people will rise to the challenge.

    Steve Jones

  • Data Loss or Downtime

    This editorial was originally published on Jan 7, 2011. It is being re-run as Steve is on vacation.

    I was watching Kimberly Tripp of SQL Skills talk recently about VLDB disasters and how to recover from them. One of the first things she said in the session was getting a damaged database back online, even without all of the data, was important. Often her clients need to keep working, and it is important that they get the system back online, even without all the data. This allows business applications and business people to get back to work.

    That is interesting. I had always thought of my production OLTP databases as needing to be online, but also needing all the critical data. After Mrs. Tripp’s talk, I had to rethink that a bit and consider that a little data loss might be acceptable.

    To me this is a topic that is worth understanding. At the very least, it will help you make decisions in the event of some disaster for how you will proceed. So for this Friday’s poll:

    What is more important to you: downtime or data loss?

    My feeling is that most of the people would really rather have the database online, even without all the data so they can continue to work. I realized that most of the time, getting the site back up, having lookup and other types of ancillary data (like products, prices, etc), was the most important thing. Recovering other data such as older orders, was secondary.

    Once the database is up, you can then work on getting other data back and merging it into the production system.

    Let us know what you think this Friday and what’s more important to your business (and why).

    Steve Jones

  • Why Can’t We Code?

    Today’s editorial was originally published on June 8, 2011. It is being re-run because Steve is on vacation.

    I think that most of the developers or data professionals out there have been through a variety of types of interviews in their careers. You might have had technical interviews that asked you to write code, or maybe you’ve been quizzed on SQL Server trivia or asked to explain methods and properties. Maybe you’ve had interviews with managers that had you define a few database terms. Perhaps you’ve just had someone ask you the ten common interview questions without requiring you to demonstrate any technical knowledge.

    No matter what you’ve experienced, I think that many people would agree that the hiring process needs work. It does a poor job of actually predicting if the new employee can produce quality code or manage servers. Why is that?

    Many companies have really tried to solve this. From the famous “How would you move Mt. Fuji?” questions at Microsoft to the common CS type questions at Google. Joel Spolsky has his own guerilla guide, which I assume has worked well for him, though on a much smaller scale. I think, however, that for the most part no one has come up with a good way to solve this issue.

    A friend sent me this piece recently: Why the New Guy Can’t Code. It’s a little heavy handed, but there was one quote in there that I thought made sense: “don’t interview anyone who hasn’t accomplished anything. Ever.” It’s so easy to set up your own website, design a database on your personal machine, even put an app out for sale, that there’s no excuse not to make some effort to accomplish something. Craig Farrall talked about building something in Looking for Work in SQL Server, as did Brandie Tarvin in Changing Career Gears. It’s also one of the things I talk about at the Modern Resume: show people what you’ve done.

    I don’t know that we’ll ever find a fool proof way to hire great employees, but hiring people that have proven themselves in the past, and can point to something they’ve done, is good start.

    Steve Jones