Voice of the DBA

Category: Editorial

  • Being Responsible for Code

    I read this great account of how Facebook releases new code, and found it to be very interesting. Apparently the entire FB site compiles to a single 1.5GB binary at this time. That in and of itself is interesting, but their deployment strategy caught my eye as well. They use bittorrent to deploy the large file to all their servers. Very creative and interesting look at things from one of the largest web sites in the world.

    The process is interesting, but one of the comments caught my eye. It includes a quote from the article:

    developers must be held responsible
    I’m sure many DBAs wish developers were held responsible for issues.

    I know there’s no shortage of developers that make mistakes and don’t want to have responsibility for the code they release. I like the idea of tracking these metrics, and letting people’s actual performance being a part of their evaluation each year. Not trusting the manager’s memory, or the recent complaints from co-workers, but actually looking at the relative mistakes being made. This leaves out scale, but I’m not sure the scale of the mistake is as important as the frequency.

    However this is a double edged sword. Some people will perform worse if you place them under this pressure and may find it too stressful an environment. If you don’t have the same pressures as a company like Facebook, you might end up driving away good employees that could fit in elsewhere.

    My recommendation would be that you hold people accountable for their work and use metrics like this to actually track that back to specific incidents, but that you use this as only a portion of someone’s evaluation. Track other measures available that help you determine if a particular worker is contributing value to your company outside of the bugs they might have in their code.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • A Lifetime of Software

    old programmer
    I hope I’m still working with technology at this age.

    I’ve been working with computers and software for most of my life, but it’s been a career for a couple of decades now. I don’t do as much technical work as I used to, mostly testing and experimenting, but my job is related to SQL Server and software, and I anticipate that’s what I’ll be doing for the next two decades.

    However that’s not necessarily the plan for everyone that works in the technology business. I know plenty of people that would like to move into management, or even move into some other career field if they can afford to do so. In the responses to many editorials in the past, I read that quite a few people think the technology business isn’t a great choice and wouldn’t encourage their children to enter this field.

    I disagree, and think that this business has been very good to me, overall I’ve enjoyed it, and I think it would make a good career  for any of my kids. However this Friday I wanted to ask the rest of you what you think.

    Do you expect to work in the technology field until you retire?

    I know many of you will change your focus in technology, perhaps moving to develop from DBA, vice versa, or moving into another field. I know most of you will change companies before you retire, but I’m curious about whether you think you will remain a technology worker for the rest of the time you work.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Security Outside the Database

    SQL Injection on nametag
    SQL Injection shouldn’t be this easy

    It’s 2012.

    We’ve known about SQL Injection for years, we’ve known about the issues with high privilege admin accounts for decades, and poor configuration has been an issue ever since we first started networking two computing devices together. Yet these supposedly well known issues are still problems for databases in many companies.

    We have a lot of work to do in the database with regards to security. Auditing, tracking, configuring security, these are all challenges, and while SQL Server is getting better with the enhancements they have in SQL Server 2012, there is still work to do on the platform. I do think that Microsoft needs some help and guidance from us here as well, as we implement new features, find problems with using, scaling, or just understanding them, and I hope you will try out the new features and then submit feedback on Connect and write about your experiences.

    However the security implemented in the database is often circumvented by poor practices outside the database. There’s little  excuse for developers not to understand SQL Injection and code around it. There’s no excuse for frameworks and sample code to show code that allows SQL Injection. As far as privileged accounts go, that’s a bit of laziness on the part of admins. The modern OSs go a good job of allowing you to elevate from a non-privileged account. So even if you want to be lazy and give more access to developers or non-admins, give them an audited, second account that can be used to track activity. I’d prefer that we educate admins more and work closer with each other to ensure work gets done quickly, but maintaining a separation of duties, if for no other reason than to have a second pair of eyes examine changes for issues.

    As far as networking issues go, we have to demand more education from networking people. The days of connecting machines to a hub and worrying about IP addressing and the correct gateways are gone. Networking is much more complicated, and firewall administrators need to better understand their systems.

    Education is the key to making the systems work better, as it is in so many parts of life. Demand (if you can) or ask (if you can’t demand) that your fellow workers learn to work with their platforms better and improve the security throughout your entire system.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Technology for Sharing

    Zipcar
    Zipcar has done a great job of using technology to more efficiently manage assets in the real world.

    Computer technology has done an amazing job of making many parts of business more efficient. It has streamlined processes, freed up many people from relatively menial tasks and increased the speed at which we can accomplish many things. This has been both good and bad, as fewer people are needed in many positions because of the capabilities of technology, but this has also freed many more people up to spend more time thinking about more complex problems.

    We have also seen investments in computer technology result in much more efficient operations in many industries. One example is our delivery companies plot our optimum routes for package delivery, saving time and fuel. Another example caught my eye the other day: car sharing for government fleets of vehicles. It’s a concept, using technology from ZipCar, that could potentially save tens of millions of dollars.

    The concept of sharing is nothing new in computing, where our applications have been sharing computer resources for decades. However a number of companies have started to expand that concept to the real world, because of the power of new technologies that allow tracking, management, and administration of physical assets. Quite a few companies have come up with a way to share resources and run a business. This same concept is something that we are doing with virualization, allowing multiple users to share the same hardware as there are significant amounts of time when any particular server is not being used to its potential.

    In the real world, we have to have enough cars to satisfy the peak demand, when the most number of people need a car, which is challenging. My guess is that some people will not be able to get a car when they need it, especially as the software tries to reduce the number of cars to the minimum level it can. We see people doing this with VMs (Virtual Machines) as well, which can lead to worse performance than expected from a particular VM. I think in many cases this is acceptable to companies in order to save money, but there are cases where it isn’t. For those cases, you might be better off with your instance on a physical host rather than a VM.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.