Voice of the DBA

Category: Editorial

  • Shadow IT

    shadow
    Do you have shadow IT in your organization?

    When I started working as a system administrator over 20 years ago, I worked for a central IT department at a remote facility for our company. Four of us managed a network of 1,000 nodes, with multiple servers under a boss that decreed we needed to respond quickly and effectively to requests made by clients. They came to us often, expecting results, and we delivered. I assumed all IT groups worked like this. Almost a year later I worked at another facility and was quite surprised to find a different situation.

    In the other location there were also four people and 1,000 nodes, but the IT group only managed around three quarters of those nodes. Different groups had their own servers and applications they managed. There were machines under desks in one department, where the desk’s owner was tasked with working half his time on department work, and half his time on technology issues. I only found out about this when one of them asked me how to solve a few problems; I then realized he was managing his own IT services for his group.

    Shadow IT is still around, and in some cases it’s growing. That can be a problem, not only for IT staffs who have less demand for services, and thus staff, but also for the security and data integrity of an organization. Someone managing IT operations part time may not understand the security or data issues they create, face, or just may not have time to deal with. They also won’t necessarily have the experience to work efficiently and effectively on administrative needs, though I know a central IT staff will necessarily do a better job.

    As a data professional I get concerned about Shadow IT groups, which might hoard their data, or even keep around data that’s gotten stale. I worry they’ll lose systems and then come to me for a solution to recover the data, often without having managed backups. Most importantly, I worry they’ll make a mistake, cause a business problem, and not only will I need to clean up the mess, I’ll share in the blame for not helping them build something they needed in the first place.

    Shadow IT is usually the result of a non-responsive central group. I’ve always made it a point to try and help people get the tools they need to work. Sometimes blanket policies prevent this from happening, but by making friends I can usually get Shadow IT people to consult with me and listen to suggestions and ideas. It isn’t perfect, but if I can get them to make regular backups, it’s a win.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Ten Million Lines of Code

    QuickBooks 2012
    Ten million lines of code in the codebase for this product.

    How many lines of code are in the applications you code on? I think that the largest applications I’ve been heavily involved in contained tens of thousands of lines of code. This was code that I actually had to search through to find a particular module to improve or refactor. I know lines of code aren’t a great measurement of the value or complexity of an application, but they do represent an amount of overhead that you need to deal with. The more lines of code, the harder it can be to change, test, and deploy the application.

    Quickbooks, from Intuit, is a very popular program that exists on multiple platforms, localized in different regions, with a variety of editions and features, including a subscription version that gets new features as they are released. On the Windows platform, that system consists of 10mm lines of code in a single codebase, with different features turned on and off through a license key.

    Ten million lines of code.

    Wow, that’s quite a branch of code. They manage that with a variety of techniques, one of which is fast becoming a requirement in technology. They use a continuous integration process that builds a new copy of the application every 15 minutes if any changes have been checked into their version control system. If there are any warnings or errors, all developers who checked in code are notified and they must track down the changes. The closer to development time a bug is found, the easier and cheaper it is to fix, so this is a great way to speed development.

    They have a few other cool ideas, like building in parallel, and using separate builds for specific tools that handle different types of code analysis. However you look at it, this is quite a system for smoothing the software development lifecycle and managing a large, complex codebase. If you do corporate development, you might not have quite the same challenges, but I’m sure applying continuous integration, automated builds, and good source control habits can help you produce cleaner code, much faster than ever before.

    Steve Jones

    Advertisement: If you are looking to speed up your development process and reduce mistakes with Contiuous Integration, you might be interested in these white papers on automated deployment and CI for databases from Red Gate Software. It talks about how you can set up a process using various tools.

    The Voice of the DBA Podcasts

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

  • Fix v. Create

    fix typewriter
    Do you perform more fixing or creating?

    Whether you write code, or administer server instances, chances are that you have a decent amount of maintenance to do. This might be fixing a bug in code, whether yours or someone else’s. It might be reindexing tables or even running periodic maintenance routines that can’t easily be automated. There are any number of tasks that might require an administrator’s attention, but are essentially the equivalent of the tedious activities that are involved with existing items as opposed to new creations.

    I ran across this piece on Ars Technica, and I’ll admit it sounded silly at first, but the more I thought about it, the more I thought that 90% of time spent on maintenance of some sort, and 10% spent on new items might be accurate. After all, it seems there’s not shortage of work being done to tackle bugs, tune code, or enhance a feature that wasn’t quite right the first time. The more I think about my career, the more I think that I’ve spent more time fixing things than actually working on new code.

    If you think about your workload, do you fix things or create new ones most of the time?

    Give us a rough idea of how your coding time is spent. Are you more of a craftsman that develops new widgets for your clients to use, or are you the handyman, repairing and improving things that weren’t built well enough the first time.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Make a Backup First

    Mat Honan
    Are you protecting your digital life?

    I was reading in detail about the Apple / Amazon hack that targeted a Gizmodo writer.  A hacker used a few techniques to get from his Amazon account to his Apple account, his GMail, Twitter, and more. His iPhone, iPad, and Macbook were remotely wiped, and he ended up losing quite a bit of data that wasn’t backed up. That’s a horrible situation, and I know every time I’ve lost a picture or document at home, I regret not making another backup.

    The situation caused some discussion and comments on Twitter about the various things you should do to prevent this type of issue. Updating your security, choosing better passwords, and other ideas are great, but the number one thing you need to do is make a backup of your data. No matter what happens to your security or even hardware, if you have a second copy of your data somewhere else, you can recover from the situation.

    While listening to a Brent Ozar, PLF webinar recently, I heard this interview question: what is the first thing you do on a new server you’ve never worked with? The answer is ensure it’s being backed up. Not run a backup, since you can cause problems, but make sure there is a backup plan in place, or get one started as soon as possible. Why? Because if you have a backup, you can recover.

    I think this is the number one priority for any data professional, and perhaps for anyone using a computer. I know I have backups of my home machines run to a Windows Home Server. I take a backup of my Macbook regularly, and leave a copy at home when I’m traveling. I also carry backups of my VMs on separate disks, in a separate suitcase when I travel. I know that if I have one of those copies of my data, I can recover from almost anything.

    What’s the saddest part of this story? There wasn’t any intent (allegedly) to target the writer’s work or his data. The hacked just wanted to use his cool Twitter account, @mat.

    Steve Jones

    The Voice of the DBA Podcasts

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