Voice of the DBA

Category: Editorial

  • Down Tools Week 2016

    Last week I went to the Redgate Software office in Cambridge, UK. I travel there a few times a year to meet with product groups and touch base with the other people in marketing. However, this trip was planned around Down Tools week, which is an event that Redgate has once or twice a year. This is similar to what other companies have done, like Atlassian ShipIt day, and I had the chance to participate a bit in one of the projects. It was quite fun, and a memorable experience.

    The idea is that a project is pitched as an idea for a single week. These are usually ideas that aren’t worth funding as a large project, or would help the world somehow. A team comes together for a long week and has to showcase their work by Friday afternoon. There have been projects just to try something fun at Redgate and investigate something. We had a number of projects, including a charitable image recognition project for Waterscope. That one was really interesting, as some of the software and documentation improvements that were made will be pitched to their investors and taken our for field trials.

    I got involved with the Rescue DLM Dashboard project. I like DLM Dashboard as a tool, but it needs some work and should provide more value. A team got together with the idea of seeing where we could add more value and make this a commercially viable product. We also tried to fix a few bugs and get some UX love for the tool. By the end of the week, we had integrated DLM Dashboard with a couple other projects, and had other items to work on. We did win a couple of the contests (best t-shirt, best presentation), but we still have a commercial brief to write and get approved before any more work will be done.

    The project structure itself was interesting, with a daily standup at 11am, and teams of programmers working in pairs to add features. I didn’t do any coding, mostly because my C# skills are far below others, and I had other commitments during the week. I was in and out of the dedicated conference room, talking with the project managers and watching developers work through the coding. We had a few interns that worked with experienced developers, and it seemed that people worked well together, sharing ideas and solutions for issues.

    I was impressed that the setup of everyone’s workstations, all moved to a conference room, connected, and with cloned git repos was done fairly quickly, with working builds for most people by Monday at lunch. It’s not as simple as one might expect to grab a new project and get a working build, especially on a complex piece of software, and it was fascinating to watch people debugging issues across web pages and local services. I was also pleased to see how open other teams were to lending us a person for a day or two in order to facilitate integrations or extend APIs.

    Down Tools week is expensive, but it certainly could be done in different ways. An organization wouldn’t need to cater food every night. Pizza or other alternatives might be fun for some groups. However, I think this can be a great way to create some excitement for your developers, as well as investigate some research that might not otherwise be feasible to undertake. I don’t know that you need to make as big a production as Redgate does, but I’d encourage you to think about taking a week off from normal projects once a year and letting developers work on things that might excite them at your organization.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Encryption Keys Matter

    Perhaps the importance of protecting encryption keys is even greater than we realize. It appears that the NSA and the US Government have been able to read encrypted traffic for some time on the Internet, perhaps for most of the last decade. There was an exploit in Cisco PIX routers, which I’ve used in many companies, that allowed the NSA to gain the encryption keys used by VPN traffic. In fact, it is likely the NSA could actually penetrate the networks on either end of the VPN with those keys.

    Some of you may be against back doors for governments in encryption products, and some of you may be for allowing governments access with legal protections. However, the most disturbing part of this for me is that no organization knew their communications, supposedly secure, were being intercepted and read. The nature of the digital world is that exploits can copy information without the holders of that information being aware of the effort. This is much harder with physical items, where the movement of an object from one person to the next is easily noticed.

    One of the very difficult things with protecting the data in our databases is trying to understand when someone has actually retreived information they shouldn’t. This is much more difficult than just tracking changes to data, which is more straightforward. We have auditing mechanisms that easily track changes to data, though most of us don’t have this set up or configured to catch all changes. In practice, that might be good enough to prevent data quality issues, but it doesn’t necessarily protect data from read disclosure.

    Monitoring what information is accessed is far harder than tracking changes. Do you know if someone in Sales is accessing a single row with customer details or the sensitive information for all customers? Can you tell when a request is legitimate for an application or if there’s an unusual query that might be seeking massive amount of data for download? Those are hard questions, and ones that I think can only be handled by a large amount of activity monitoring along with machine learning assistance to look for patterns in user activity. Other features like Row Level Security can help limit the inadvertent mistakes made by developers or users, but not necessarily prevent a single user, especially a malicious user, from querying information.

    Apart from the activity issues, we should ensure that where it is possible, we should be using encryption to prevent accidental disclosures outside of our applications. I think Always Encrypted has possibilities for the database, but the key management for this, as well as key management for VPNs, disk encryption, and other protection mechanisms, needs both more maturity and the open disclosure to prevent back doors from being included in products. We also need more maturity in our software development that takes the implementation and protection of encryption mechanisms seriously.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Ignoring Database Version Control

    I find myself surprised that so many people resist keeping their code in version control. I think this is less people all the time, but I don’t have good percentages because at this point I think a fair number of people embarassed enough to not answer the questions. However, in quick conversations, I still find people that don’t think a VCS is necessary. I can’t conceive of this for application code, but more and more I think this also makes sense for database code.

    I ran across a blog that asks you to find a way to keep your database code in a VCS. While I’m glad that the author provides some ideas on how you might script this yourself in a pinch, I think that’s silly. There are tools to help, whether paid for ones, like SQL Source Control or free utilities. In either case, it makes sense to work with something that has been tested a bit rather than inventing your own. It seems that running scripts is simple and easy. In practice, these tools add value because of their maturity. Some of the mistakes you’ll make with your own software have already been made, and solved, with many of these frameworks and paid for tools. Don’t spend your time maintaining software scripts when you need to be developing other software.

    I also think the author makes the process sound a bit simpler and easier than it is. In practice, moving between schema versions in a database is typically a one way process, and rollback scripts are of dubious benefit. A discussion of this post on Hacker News shows some of the shortcomings in trying to version database schemas and easily move between versions. In practice many database schema changes can be rolled forward and back, and the corner cases that are very difficult for tools to solve, aren’t items that occur too often. Really, it’s table changes that are hard, and having a good process helps here, but these are usually one way changes.

    However, the reason I think version control is important is that database development is often disconnected between the database and application. Changes might occur in the database long before they are used in code, or they may need to be undone in development, perhaps in a destructive way that isn’t possible in production. The history of changes, and understanding of what needs to be changed, is much easier with a record in a VCS.

    These days there are a variety of ways to capture your schema changes and record them. I would encourage you to investigate some method and give it a try. Even building the habit of manually recording changes by all developers will help you to move faster and faster in your development process without worrying about losing track of what’s happening.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Impressive Accomplishments

    This editorial was originally published on February 15, 2013. It is being republished as Steve is out of the office.

    Most of us have had an interview or two in our lives. We’ve had to assemble a resume or CV, create cover letters, and practice answering questions in preparation for an interview. In all of these things, we are looking for ways to market our past work and present it in the best light as evidence that we will make a good employee in our next position.

    We each have our own experiences, successes, and failures, but we aren’t bound by what’s happened in our career so far. We have the ability to shape our brand for the future by making changes in the way we approach our career from this day forward. I have a talk and blog on this subject, but I certainly don’t have all the answers. I’m always looking for more ideas and suggestions to help people and wanted to ask for your ideas this week.

    What would impress you most about a job candidate?

    Is there something that you’ve seen or heard about in the past that impressed you? If a candidate had written a book, or created some software, would that make you look upon them favorably? I know that a candidate needs to present themselves well in an interview and be able to write SQL, or manage an instance, but when you are examining dozens of resumes, is there something that stands out?

    Take a moment and tell us what has impressed you in the past, and whether it was an indicator of a good employee or not.

    Steve Jones