Voice of the DBA

Category: Editorial

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

  • Big Data Jobs

    big data
    Big Data opportunities are growing.

    If I asked you to give me five industries where Big Data jobs are likely to be growing, what would you say? Everyone’s data is growing, but a few places may grow faster than others. One survey lists banking, retail, pharmaceuticals, government, and insurance as the top growth areas, which makes sense. Despite the slowdowns in the worldwide economies, retailers and banks have improved their systems to gather more and more data. There’s no shortage of government growth with regards to the data being collected, and the drug companies see more data analysis as the way to reduce the costs of introducing new drugs.

    What if I asked you to pick the places in North America where there will be lots of new Big Data jobs? According to the same report these cities lead the way with job openings: San Francisco, CA, Maclean, VA, Boston, MA, St Louis, MO, and Toronto in Canada. These are all areas with large concentrations of organizations from the industries with the most Big Data jobs.

    I’m not surprised at the list, though there are plenty of other places that are likely just below these five in terms of jobs. I wouldn’t look to move to any of these places just for the Big Data job, but if you are looking to work in this field, you might think about checking out various recruiters and contracting companies’ sites to see where there are lots of jobs.

    As slow as the worldwide economies seem to be moving these days, our fields of technology and data seem to be growing, with plenty of companies looking to improve their systems and tackle new initiatives that might improve their ability to take advantage of the all the data they store. There are lots of jobs out there, and with some work you might find one is a great fit for you.

    Steve Jones

    The Voice of the DBA Podcasts

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