Voice of the DBA

Tag: software development

  • Rogue Algorithms

    Rogue Brewery
    If our systems go rogue, it’s not good for anyone. Keep those people around that understand them well.

    I have always thought that computers do some amazing things, but they tend to do what we tell them to do, even if what we tell them to do is not what we want them to do. In those cases we usually find computers are helping us make mistakes faster than ever before. As we automate and link more and more systems, this can become a bigger and bigger problem in the world.

    I ran across this short link on a rogue algorithm that caused a fluctuation in a number of stocks. It looks like this was a case of poor analysis and poor QA at one firm, bunt imagine if we had some type of “update” released to a large number of companies? This type of problem could cause a dramatic short term fluctuation in the stock market, which shouldn’t affect most of us in the long run, but you never know. If this caused a company to go out of business, and they were the company holding your retirement savings, you might feel differently.

    This isn’t necessarily a problem that affects just financial institutions and their custom software. This is potentially a problem in any business that writes its own algorithms. That includes many of our companies, and many of us. We write queries, reports, and develop algorithms that help “the business” analyze data and make decisions that can affect our companies.

    This is worrisome to me, especially when we have companies that press for more and more analysis, with algorithms written more and more quickly to respond to business events. Success in this area often depends on an understanding of the nature of the business and the meaning of data, and strong working relationships with the business analysts. That comes over time, and is easily lost when employee turnover is too high.

    I hope that companies are learning that there is value to retaining employees, especially those that work with data and have invested effort in learning more about their business. Unfortunately I think that it take a disaster like this for some managers to understand the value of retaining employees and their knowledge. Even more unfortunate is the fact some managers never learn that.

    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.

  • Password Resets

    I read this piece from Troy Hunt, which is a long look at the password reset process for a web application. It’s one of the first that I’ve seen which talks about the different implementations, along with the pitfalls and advantages of each.

    It’s a great look at passwords, and there are definitely a few things in there I think should be built into authentication frameworks. I know we need to change a few things at SQLServerCentral and I’ve added them to the list.

    Pass this one along to your developers. They should be aware of this stuff.