Voice of the DBA

Category: Editorial

  • An Inconceivable Scale

    One of the talks I give on SQL Server deals with unstructured data. I start out this talk looking at the scales of data we deal with and was been amazed by the research I did about how much data we humans have created. What’s even more interesting is that the growth is outracing predictions made just a few years ago.

    When I started working with computers, we talked about kb of data, thousands of characters. That’s an amount of data we humans can easily comprehend. In fact, we used to talk about floppy disks and the number of average sized books that could be stored in kb, or single digits of MBs. As humans, we can comprehend that scale. Most of us have seen hundreds or thousands of books in a library.

    When we move to GB, things get harder, though at 4GB for a DVD, many of us can conceive what multiple GBs can mean. However terabytes? Can we conceive the scale of data? Sure. A TB is about 40 Blu-ray disks. While we might not appreciate how much data that is, we can picture it.

    A PB? That’s 41,000 Blu-ray disks. I can’t even conceive of what that looks like, much less imagine the billion MB sized pictures.  That’s a scale that has no reference. However as humans, we will create multiple exabytes of data this year. As individuals working with data, few of us will work with EB in our organizations, but some of us will. I read recently that Paypal processes 1.1PB of data regularly. Regularly processes, not just has in cold storage.

    We have zettabytes and yottabytes, but who could possibly conceive of what those mean? There’s not frame of reference I can imagine, though that may change. I expect that we will become used to PB at some point, just like a TB is no big deal right now. In fact, I really think I’ll see a TB on my phone sometime before the end of this decade.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Building Better Communication Skills

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

    I think that one of the most valuable skills that someone in technology can have is the ability to communicate with others. It doesn’t matter whether you write code, rack servers, or sit in meetings with business people, it is important that you find a way to express clearly what you want, need, or would expect from someone else. If you can’t, you will find that you often struggle to get anything accomplished in an efficient manner.

    It’s possible that you can get by with verbal communications in many instances, but it seems that so much gets done by written communications of some sort. Especially these days where it seems that so much of the interaction between people takes place through email, IM, or even Twitter. We are constantly using some form of written text to convey information between each other.

    However it seems that many people don’t place a premium on building better writing skills. When I talk to many people at SQL Saturdays, most of them are hesitant to try something like blogging. The most common complaint: I hate writing.

    But we have to do it constantly at work and working on your writing skills will not only help you to communicate better, but it will also help you learn to better organize your own thoughts. You will have a better understanding of the logical thought process, which might even help you build better code.

    Steve Jones

     

  • The Office

    This editorial was originally published on Dec 29, 2010. It is being re-run as Steve is on vacation.

    An article caught my eye. The majority of workers think they can be productive outside of an office in a survey conducted of 2,600 IT professionals. Most of the these people also said that they tended to work extra hours each day outside of the office. The majority also said they would take a lower paying job if they could access the information they needed outside the office.

    That’s actually a smaller percentage that I expected would want to work away from an office,  though more than I expected would actually take less pay to do so. As least in America, it seems that people are very concerned with their salary, and reluctant to ever take a pay cut. I’m glad it seems that some people are starting to understand that value of their time to themselves and their families.

    It’s hard to work at the office, as Jason Fried said recently in a TED Talk. I haven’t worked in an office in some time, but I do remember a constant stream of interruptions. An hour of time without someone talking to you was rare, and I assume that the situation is similar with many knowledge workers today. We have people that we pay to think, and solve problems, but we don’t give them the time to actually work on those problems.

    Steve Jones

  • What is DevOps?

    There is a lot of confusion in the world about DevOps. Some of that might be because the concept hasn’t been well defined, or implemented, in many organizations. It might also be because other companies have been running as DevOps organizations for years without having a name for what they did and no good way to talk about their practices as a whole. Plenty of those efficient organizations resent having DevOps presented as a “new” idea when it’s been their modus operandi for years.

    I an across a primer on DevOps that I thought was a good explanation for management. It’s not perfect, and the piece minimizes the problems of changing culture and attitude. There is an emphasis on breaking down barriers and silos, but no discussion as to how managers should do this. I think most people expect managers to know how to get teams to work together, but in practice, I have found few managers that could do this.

    There is no magic to DevOps. There isn’t a tool you can buy, or a consultant that you can hire to implement it. All you can do is get help and guidance in helping your staff to learn to work more closely together. Developers have to learn to consider the operational impacts of their work, while formalizing some of their processes. They need to automate their testing, but also the packaging and installation of their software, while working in standardized environments. Operations is the flip side of this, in that Operations staff must be responsive and quick to build the standard environments developers need. They must work with developers to feedback issues and requirements from Operations to the developers, including bugs that can be caught with changes to the automated testing processes.

    DevOps is about working together. With respect and professionalism, but also the attitude that we can help each other do our jobs better. This impacts our compensation and reward systems, as well as organizational structures. I wouldn’t underestimate the impact this has on the way an IT department works, but I also wouldn’t be afraid of the changes. However I would move slowly, evaluating the impacts as processes change, and working to assuage the fears and concerns of your staff.

    Ultimately DevOps, in my mind, isn’t about saving money or getting software build faster. It’s about working together to become more responsive to our clients as our software becomes ever more important to them.

    Steve Jones

    The Voice of the DBA Podcast

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