Voice of the DBA

Category: Editorial

  • The Security Payoff

    I wrote a few months ago about United offering rewards for people that discovered security issues in the United Airlines software. Not the plane software, thankfully, but in their customer facing IT systems. Apparently a few people discovered flaws and were recently awarded frequent flyer miles, a couple of which received 1 million miles. That’s a nice bonus for some people, though I hope the end result of this is that United builds better security into their software and learns to code better. Certainly other manufacturers have programs that have helped in the tech world. Microsoft, Google, and others have programs that pay bounties for flaws that are discovered and reported.

    However I wonder if this isn’t something that should become an accepted practice. I don’t necessarily want regulation here, though I would prefer our regulation not prevent the research and exploration of security issues. Imagine, however, if we had an accepted, known process for finding flaws in all software. Maybe this would be like a standard process, like reporting spam to the webmaster@ address for websites. If someone finds an issue, they let the company know. The company has a bounty of some sort, perhaps a token reward, and a limited time to fix the issue. One the time passes, the individual is free to disclose the issue to the public, the problem can be publicly discussed and analyzed. More importantly, the company now has liability for any data loss or productivity issues.

    In theory this should already exist. However it doesn’t seem to regularly work, and we have lots of software with flaws, along with no incentive to fix the issues, even when data is exposed. There are some laws for personally identifiable information (PII), but what about random data that might be annoying to users? What about the various software packages that we use that monitor our systems or provide anti-virus protection or manage other aspects of business. I’d like to see perhaps more class action arbitration (not lawsuits, we need less lawyers involved in the world) that perhaps doesn’t award damages, but refunds purchase costs. If that CMS doesn’t work, your money is refunded. I’d think that would incentivize some secure coding practices. If vendors had to make insurance claims, I bet we’d start to see more requirements of code reviews and PEN testing of software in general.

    This is certainly a hard issue to discuss. For every solution out there, plenty of edge cases or exceptions will be an issue. The openness and ease with which people can create software is a double edged sword. This encourages innovation and experimentation, resulting in some amazing new concepts, but that same freedom often also brings about lots of poorly written software, full of vulnerabilities and bugs. I hope that we find a way to mature this industry and start to build better, standard, well engineered practices and habits that encourage secure, robust, well written code.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • Hiring for Culture

    I’ve written in the past that I think that it’s important the hire people that get along with your group first, and with technical skills second. It’s not that technical skills aren’t important, but I think that fitting in with a team is more important. We can teach someone to be a better developer. We can’t easily teach them to be a person that others like to work alongside. Certainly, however, the person needs to have the technical skills needed for the job.

    When I was interviewed in college, the hiring manager told me there were two important tests to pass: Would he drive cross country with me and would he go out for a drink with me after work? That doesn’t imply that those are the most important (soft) skills for a candidate. It’s that all the other, more quantifiable skills were similar in all the candidates. The ability to get along socially was a differentiating factor.

    I was reminded of this reading a blog post that hiring for culture can hurt your culture. It’s a look at a developer’s opinion about the ways in which some startups operate. However I think the author confuses social situations or behaviors with culture. The culture includes much more than our schedule of activities outside of work. It includes our attitude towards work, towards building software, towards each other. Certainly this is mentioned in the piece, but there seems to be an emphasis on the social interactions with new hires.

    Certainly a person coming to work at a company that refuses to engage with others in any way outside of work can be a problem. We need to get along with each other as social creatures, and be able to hold a conversation with each other that might not involve work. However I’m not sure that anyone expects every other employee to have, discuss, and participate in the same interests as the manager or even a group of people.

    Finding a cultural fit is a difficult task. I do think plenty of people hire the best programmer they find (whatever that means), regardless of their ability to get along with others. I also think plenty of managers hire someone that gets along great, but isn’t a good employee. As with many things in hiring, finding a balance of talent, attitude, work ethic, and social compatibility is important and worth striving for, but difficult to actually achieve in practice.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Visualizing in Space

    One of the really interesting things that we are able to do as developers and DBAs is help find ways to analyze data for our clients and customers. Many of us might not have expertise in the actual areas that are represented by our data, the industry specific knowlege, but those of us that will be the most successful in the future at our jobs will be able to work with the people that have that specific knowledge and need help to implement the analysis.

    That will take some practice. I’d encourage many of you to start playing with some sort of data that you are interested in and try to perform some analysis. Whether it’s useful or just for fun, you will be gaining some skills in both analysis and presentation that will serve you at some point.

    There are so many sets of data available for practice that you can probably find something in an area that’s interesting to you. I don’t know if you could get the cool spatial data set seen in this talk, but there are certainly sports sets available, open data sets from government, movies, entertainment, and more.

    Working with a set of data that intrigues you is a way to enhance the very skills that you’ll want to have to help your employer. Building reports, visualizations, and more is a technique to show value to your current employer. It’s also a great way to showcase your talents on a blog that might just get you an inquiry or interview for an amazing next job.

    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

  • What We Want and What We’ll Pay For

    I’m sure many of you see surveys that note IT job growth is up 30%. Or that executives want to hire 20% more people. Or that the market dictates that salaries will be going up 12%.

    Those are exciting numbers, and I see them too. However I saw a great post that summed up the fact that those are just quotes, perhaps even desires, but not necessarily realities. This answer notes that what we want and what we’ll pay for are often two different things.

    Many IT executives would like to hire more staff. They know that there’s a backlog in IT that can be reduced with additional staff. They might also believe that hiring more staff increases the chances of talented staff that can produce higher quality work, playing a game of numbers. They also know that newer hardware or software technologies can often produce better results for the organization.

    However whatever their beliefs, they will often be constrained by budgets. There are always going to be other priorities in an organization that compete for additional resources. Sometimes IT will get what they want; sometimes they won’t. Often the end result will be less than they want, but more than other groups would have spent on technology.

    The surveys and quotes we see published, good or bad, aren’t worthless. They’re often a reflection of a best case hope, like so many of the estimates that developers give about their work. The numbers can indicate a trend, but take them with a grain of salt. Apply a little skepticism and treat them like averages. Remember, an average of 50 can come from 49 and 51 or from 1 and 99, both pairs of numbers reflecting different realities. Above all remember that an average or ideal also doesn’t necessarily reflect what you, personally, will experience in your career.

    Steve Jones

    The Voice of the DBA Podcast

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