Voice of the DBA

Category: Editorial

  • Working in Smaller Teams

    I don’t know what the average size of a team is, but I know I’ve worked in all sizes in my career. I’ve had teams of 1-3, which is common in database work, but I’ve also been on a 20 person Ops team. I’ve been in 2 person development teams, 25 person teams, and everything in between. At Redgate, it seems most of our development teams are less than 10 people, but I’m sure we’ve exceeded that at times.

    I do think smaller teams are better, and they are certainly easier to keep track of what everyone else is doing. Once a team becomes large, even with regular status reports or meetings, there is too much information to easily hold in one’s memory about tasks other than our own. Knowing what others are working on can be invaluable in coordinating and avoiding conflicts. This also ensures that the team can more easily ensure code is written in a similar fashion and knowledge is easily shared.

    There is research that seems to indicate that smaller teams are better. This article talks about some of the reasons small teams seem to perform better. These all seem to intuitively make sense to me, and I’ve certainly experienced people behaving in these manners. In the second piece, there is advice on how to get teams to be more effective. The biggest advice seems to be a lot of what we do at Redgate. We empower teams, give them tools, and don’t manage them in traditional ways. We hold them accountable to get work done and meet goals, and we challenge them, but we want them to move forward, not work in a particular way.

    Building a team is hard, and getting a team to perform at a high level is very hard. I do think that the internal talent and motivations of individuals can make a big difference, but I also think that management can bring out the best in people, or it can ensure you never get anywhere near the potential of team and encourage under-performance.

    It constantly surprises me how often I find managers and their organizational culture built to control and not inspire employees to do their best. I think it’s a holdover of years of working a certain way, rather than supporting and encouraging each person supervising others to get the best from others. I hope this changes, but it’s certainly something I try to detect in interviews before I ever commit to a new position. I hate working for micromanagers and never want to do it again.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Good Reason to use a VCS

    Imagine that you have some important year end procedures in your SQL Server database. Or maybe you have some important, but rarely run code. No matter what the circumstance, if this is a large amount of code, it might be difficult to remember how it’s structured or even how it works on different sets of data.

    Now, imagine that you have a malicious individual that thinks like Andy Mallon talks about in this post. They run an ALTER PROCEDURE and replace the entire procedure body with “RETURN 0”. Now imagine that you don’t find out about this until months later when the important code is run. That would be a bad day, and certainly one that might have you struggling to recover the code from backups. Do you have months of old backups? I used to, in a place where we kept an end of month backup from every month for a year. I always had the previous 12 months, but I wouldn’t want to restore them all to find out where code got changed.

    In most places, we don’t have that many backups, and we often assume we’d only go back a few full backups at most in the event of a disaster. I’ve also been a consultant for more than a few companies that found out that they had 2-10 full backups, all of which were corrupt and from the last few weeks. Sometimes there were older backups on dev/test machines, but in some cases, lots of data was lost.

    It’s important to run DBCC to catch corruption, but it’s also important to keep track of your code. There might not be maliciousness, but simple errors in code that’s changed without comprehensive testing. This can be especially problematic for rarely run code that we don’t test as thoroughly and won’t detect issues for a significant amount of time.

    Save your code in a VCS. Git is free. File|Save is in every editor on the planet. There’s no excuse not to use a VCS and save code. Redgate has tools to make this easy, but I worked in a file|save environment for years, and it worked. Learn about a VCS and build the habit to backup your code in a repository. It’s simple and easy, and you won’t know you need it until you do. At that point, it’s too late.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Beware, More Ransomware is Coming

    Criminals seem to take advantage of anything that will allow them to gain more money, power, or notoriety. It seems in the last year that ransomware has become more prevalent and widespread in all sorts of organizations, though a number of governments have had high profile attacks. They’ve often paid the ransom, with the help of insurers.

    While that might seem like the most expedient way to get back to working, it can be a problem, as this article points out. It can often be more expensive, in time and currency, to combat an attack than to pay a deductable and have the insurer cover the rest. When insurers start to pay for the attacks, then it provides an incentive for more attacks, especially similar attacks at governments or other corporate divisions where the security (or lack thereof) might be similar.

    This also can influence more organizations to purchase insurance, which might be part of the reason insurance companies are happy to pay out the policy. I expect that insurers can’t pay all policies, so I would hope they would start to require more proactive security measures and policies to prevent attacks against some companies. In fact, I hold out hope that insurance, not government, will drive more companies and organizations to implement better security practices.

    The downside is that sometimes paying the ransom doesn’t get the keys to decrypt files. In fact, I suspect that it’s as likely that the criminals don’t have the key as they just make a mistake in their “customer service” effort to provide the key. All sorts of organizations have trouble providing the right keys at times to customers, so I’d expect this happens to criminals as well. I also wouldn’t be surprised if some criminals aim to exact a second ransom, perhaps devised to be just below the insurance policy limit, before providing a key.

    The takeaway for most data professionals here is that we want to be very careful with our data, especially our backups. While others might lose their data to encryption, it behooves us to severely limit access to backup files to prevent a rogue account accessing them, and certainly we would want to to air gap backups wherever possible. If we find out that systems are encrypted, at least we can recover our data on new hardware. If our application code is likewise held in another system, like GitHub or BitBucket, then we might even get back to work quicker, at least for our data-driven applications.

    Security continues to be an increasing part of the data professionals job. As a way to ensure your career continues to advance and grow, pay attention to how well you secure your organization’s data.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What You Should Know About Coding

    What are the important things you should know about writing T-SQL code for an organization or on a team? I’m sure that many of you have ideas, and please, feel free to share them with us with a comment. As you think about your answers, think about this as well: what do you wish you’d have known when you started writing code?

    I went through university quite some time ago, over 30 years ago, and some things have changed in this industry. Not so much in the way we structure the code we write, though we have gotten much better in some ways. Rather the way that organizations work has dramatically changed. It’s not just this new DevOps thing, but more that many organizations are starting to expect developers to do more than sit in a cube and react to a set of tickets or a specification written months ago.

    More companies are expecting developers to think and interact with others, knowing more about other parts of their environment and application. More developers work in teams, and perhaps very interesting to me, the once dreaded and heavyweight code review that seemed to die during the middle of my career has become a commonplace, quick task that developers do every day now.

    There’s an interesting piece, written by Ryland Goldstein, about the things he thinks developers should be learning in college or early on. I thought it was interesting to see him open with lines of code (LoC) as a metric, and show the growth in code for some large applications. To me, LoC hasn’t been important at any point in my career, but I know it was talked about while I was in school.

    He does talk about some things that good code should have, and I agree that most of the time the language doesn’t matter. I do think his points on reading code, and learning to work with other people’s code is good. To me, this really means we want to adapt and learn to write code in the style that our team uses. That can have a huge impact on group productivity, when we can write in a similar style, and then also read (and review) code quicker because it’s all the same style.

    Perhaps the best line is this: ” Every single member of our team (including me) would have a full blown panic-attack if someone ever suggested committing un-reviewed code.” I think too often the database side of things ends up committing (and deploying) un-reviewed code too often. We could to better, even if we need to teach someone how to review our code. Having a second set of inexperienced eyes might not prevent mistakes, but it certainly might help others learn to write better database code.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.