Voice of the DBA

Category: Editorial

  • 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.

  • Rethinking Hiring

    We’ve had endless discussions here, and elsewhere on the Internet, about hiring qualified candidates. We’ve had conversations about interviewing unqualified candidates. There are also no shortage of talented people, evidenced by the the knowledge and code they share on the Internet, who struggle to find good jobs that fit their skills.

    It seems that overall, we have a problem in matching people with jobs. Many companies bemoan the difficulties of finding talented development staff, and I understand the challenges. Certainly there is no shortage of individuals that don’t bother to expand their skills and learn good, fundamentals about their craft. Often this lack of skill shows up in interviews and leaves many of the interviewers thinking they’ve wasted thier time, or the candidate has misrepresented their experience.

    However, I think part of the issue is the lack of training and investment in individuals the companies make. Maybe one of the more problematic issues I see is that we don’t have good paths for teaching and progressing knowledge, whether inside of a company or as a person seeking to learn. It seems that while there is a huge amount of information available, it is poorly organized, and very cumbersome for an individual to manage. Even with companies, we don’t seem to have well structured training that adapts and helps our staff grow.

    I thought this was an interesting piece on how many companies don’t do a good, basic job of deciding who to interview. Too often companies have fallen back on the general guidelines of a degree or years of experience in a job. That’s not a great solution, and since most of us don’t have great track records in hiring, this limits the chances we’ll see good candidates. There are definitely failings on both sides of this equation. I hear constant horror stories from people interviewing DBAs and developers that don’t know basic concepts. However I also hear from candidates that aren’t even called to interview for positions because they don’t have a degree or some other generic qualification.

    I do think that many people can learn new skills and new jobs. I think as developers and DBAs, we should be trying to learn new skills, or improve our existing ones regularly. I also think that companies should look to invest in their staff and improve the skills of individuals. I realize that this is a tough task, and there aren’t necessarily easy ways to do this, especially as it seems talented staff might just leave for another position right away.

    I hope that in the future we find companies that look to grow their staff’s skills at all levels, with the understanding that they might leave, but they might stay, especially if they are treated well. And if they do leave, a good training program will help minimize the impact, since other people should have some idea of what work is being performed, and new people can be taught the skills they lack.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Auditor Attack Vector

    The phone on the desk buzzed. The CEO picked it up, expecting his assistant to let him know his next appointment had arrived. Instead he was told a person had called and wanted to discuss why his managers were paid less than some of their direct reports.

    The CEO was puzzled, and worried, so he accepted the call.

    “Did you know that you have programmers making more than some of their managers? ” the caller asked, quoting the specific people and their salaries.

    The CEO did know, acknowledged this, but declined to discuss the matter. Instead he asked who was on the phone, and how did they know the salaries of his employees.

    The caller declined to give their name, but told him that they had found a USB thumb drive outside on the street and had plugged it into a computer. A number of spreadsheets were on the drive, with one containing the salaries and organizational structure of the company. The called left the story there, promising to mail the drive back to the CEO.

    The CEO was upset, and worried, but waited a few days to get a package in the mail. He had been planning to terminate someone for carelessness. However when he opened the package, he realized none of his employees was to blame. Instead, this was a device given to an auditor who was verifying the accounting practices of the company.

    I don’t know the rest of the story, but it was given to me by someone that runs a decent sized company. It’s a scary story and shows a concern one that has nothing to do with most of us that work in technology departments. However this does show that there are always holes in our processes and practices. We need to consider the fact that many of the businesspeople we work with value convenience much more than security. We need to be sure we take precautions where possible, such as encrypting all data at rest, and in transit, wherever possible.

    It might not be our fault, and it might not be something we’re blamed for, but I certainly would feel some guilt if I had copied the data onto the USB drive without providing additional security, such as encryption or at least a password.

     

     

    Steve Jones

    The Voice of the DBA Podcast

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