Voice of the DBA

Category: Editorial

  • Teambuilding

    I worked in a large company at one point in a team of 20 people. My boss made it a point every month to take a long lunch with the team and engage in some teambuilding. Usually one of us would have to remain at the office, but we rotated the duty so that most of use could participate. We would go to movies, go bowling, have a team lunch, watch a baseball game, or something similar.

    At Redgate, the various groups schedule days out, and last month the company had a large “day out”, bringing many of the Americans over from the US to participate. It was a good time, and the chance to get to know some of people in the company I rarely interact with.

    Team building has been hit or miss, but I’m curious how many of you engage in the activity. I know I’ve worked in plenty of companies where there was no effort made to build a team. This week I wanted to ask you:

    Do you engage in team building at work and what events have you enjoyed?

    Maybe I should ask what worked well to help build a team, but sometimes the enjoyment and bonding go and in hand.

    I thought of this recently as my daughter wanted to ride zip lines for her birthday. We packed up the family to go, and while it wasn’t everyone’s first choice, we enjoyed it and had a few hours to laugh and joke with each other. It turned out to be a much better family bonding time than a few people expected. If you’ve never tried it, I might recommend it as a way to have fun with a small group of people.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Amateur Data Analysis

    What’s a good way to analyze data? How do you know if you’re actually looking at data in a way that provides a valid analysis? It’s entirely possible to statistically look at a set of data, run some aggregates, build graphs, and come to a conclusion (or recommendation) that would hurt your business rather than help it.

    In academia, many people have their analysis and conclusions reviewed by their peers. Over time, many of the people analyzing data learn from others and start to build skills in how to look at data sets and consider the interpretations that seem to be more valid. Of course plenty of mistakes are still made, but I think the quality of analysis is pretty good overall.

    In business we are often working in silos, in semi-secretive ways where our analysis might not be questioned or reviewed. How do we build some skills? One way might be to do what Dev Nambi did, publishing an analysis of college costs and including his thoughts on what the data shows. You could also look at this crime report from Samuel Vanga.

    I thought this was a great example of taking a set of data and trying to make sense of it in a variety of ways. While you might have your own thoughts on what conclusions and implications to draw (leave comments about that for Dev on his blog), I think this is an interesting way to approach analysis of a set of data. Many of us could experiment with different visualizations and the analysis of this (or other data), and get comments on our approach.

    For example, I find the stacked bar graphs more difficult to understand than a series of line graphs. I also would like a bit more context in what the author sees as an analysis of each graph, but those are my views. Perhaps if I wrote an analysis of some set of data, I’d find others would let me know the ways in which I present my findings are flawed or difficult to understand.

    I’d encourage you to practice building analysis, along with other skills you find useful in your job. While most of you can’t use business data on your own blog, perhaps you can find a data set that’s interesting to you and dig in to see what information you can extract and present.

    Steve Jones

  • Be Professional

    I’m not a very comfortable flyer. I do it regularly, and I’ve gotten used to it, but I’m a bit scared when the plane appears to be anything other than a slow elevator to me. I’m not quite sure how I’d react if I were on a small plane and experienced what this author did above Washington State.

    The piece is really about being professional, and the way the pilot reacted in that story certainly wasn’t the professional image most of us want from their pilots. A few might like that, just as a few might accept most behaviors, but the majority expect something else.

    In the article, there are seventeen habits that can make you look more professional in the piece I linked, and for the most part I really think these are the types of traits and images that a professional wants to project. Whether you’re a CEO or a developer, having confidence and candor are as important as realism and caring. We all expect professionals to follow through on commitments and be diligent in their work.

    The only item I might disagree with is fitness. Perhaps that’s more important in some areas than others, but I have found many people that are highly professional, competent, dependable, and worth every penny that I pay them, but not very healthy. Some might be unhealthy to the point I’d be concerned for their long term prospects, but that wouldn’t mean they aren’t good professionals in the short term.

    Steve Jones

    The Voice of the DBA Podcast

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

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