Voice of the DBA

Tag: software development

  • Test Coverage

    I’ve never had to work full time in a QA group, but I have had to perform software testing of an application and it wasn’t fun. Even as I worked through the various features, looking for edge cases, common mistakes, etc., I realized that running tests was something that really required more discipline and process than I was giving it at the time. Too often I ‘d realize that my regressions weren’t 100% duplicates of previous executions because I’d allowed too much “human effort” into my process.
    These days most testing of software is automated. I know QA groups still exist, and they need to handle some of the manual checks that are very hard to automate. However more and more testing is being pushed back onto developers to handle, with frameworks like NUnit and JUnit. In the database world, we haven’t done a great job of including testing into the code we write, but there’s a great testing framework we can use.
    TSQLT is a framework written by Sebastian Meine and Dennis Lloyd and it’s free. It’s been developed to help you write tests that can exercise your T-SQL code to determine if it’s doing what you expect. I’ve used it a little, and while I see the potential, I also realize that this will take some practice to learn how to more easily write tests that can cover the various potential places where bugs can be introduced.
    However, if you use version control, and you should, then you can easily spread the load of writing tests to all of your developers. Since the tests are stored procedures, they can be included in your VCS project and shared by all your developers. With a little effort from each member of your team, you might be surprised at the code coverage you can achieve with this framework.
    Testing is important, as we see over and over again as software is released and doesn’t work as expected. I think much of that is our fault, as software developers, for not improving our testing skills and discipline.
    Steve Jones
    If you want more automated ways to easily share tests between developers and execute them, take a look at SQL Source Control and SQL Test from Red Gate Software.

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 20.9MB) feed

    MP4 iPod Video ( 24.8MB) feed

    MP3 Audio ( 4.9MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Cyberwar

    There are no shortage of books about cyberattacks and hackers. Some of these fictional stories even postulate that countries will build armies and engage in digital war with other countries. Some of this has come true, with the US and Israel attacking Iranian targets, suspected Chinese hackers targeting the US, and the announcement that Britain is building their own cyber army.

    While there are certainly no shortage of attacks made on corporations every day, how long before countries make determined efforts to disrupt their enemies’ economies with digital war? It’s a scary thought, and given the poor security habits of so many developers, it’s possible that many companies might find themselves struggling to conduct businesses while under attack. It might not be any different than if conventional weapons were being used near our facilities.

    The state of coding by so many “developers” today is somewhat scary. It’s not even old applications that are vulnerable to SQL Injection, but even new systems that have poor security practices being used that are vulnerable.

    I think that secure coding practices like these should be implemented by anyone writing software. I think examples, frameworks, and presentations about coding shouldn’t use simple passwords and bypass checks. Yes, it’s a pain for those that teach, but it also means that shoddy coding practices aren’t proliferated as people borrow your code and alter your examples.

    Security is a problem, but I think a lot of the issues would be minimized if we, as an industry and professionals, learned to write more secure code as a matter of habit, not as an additional feature to be added later.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 17.0MB) feed

    MP4 iPod Video ( 19.9MB) feed

    MP3 Audio ( 4.1MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Effectiveness

    I saw a great quote recently on an internal email at Red Gate. We had deployed a new feature to a website, the application seemed to be working, but someone questioned the architecture of the implementation. The person that was in charge of the project sent this back at the end of an explanation:

    “It’s a little clunky, but we decided it was better to get it done than make it perfect.”

    That’s a great quote. In fact, that’s what I’ve aimed for in most of my career. Move things forward, get them done in an effective manner. That’s what I’ve tried to do as long as I’ve been in technology. Examine a problem, consider various solutions, and then choose one to move forward with. At the end of the day, as has been said by many people, “shipping is a feature“.

    This doesn’t mean giving up on quality or accepting anything, but it does mean that you continue to move forward. You may make compromises on code quality, but small compromises. Your code has to still solve the problem. Your database still has to handle the load. You still need quality work, but a solution you can get done quickly that performs 10% worse may be better than a faster solution that takes twice as long to develop.

    Lots of code lives in systems for years. We want this code to be “good” in that it needs to work, handle the load, and contain few bugs. However lots of code also gets refactored over time. We should minimize bad code as much as possible, but less than perfect code isn’t bad. Sometimes it’s just a little clunky, but it gets the job done.

    Steve Jones

    Video and Audio versions

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.

    Follow Steve Jones on Twitter to find links and database related items and announcements.
    Steve Jones Windows Media Video ( 14.7MB) feed

    MP4 iPod Video ( 17.2MB) feed

    MP3 Audio ( 3.6MB) feed

    Feeds are available at iTunes and Mevio

    To submit an article, rant or editorial,
    log in to the Contribution Center

  • Encrypting T-SQL Code

    This editorial was originally published on April 10, 2009. It is being re-run as Steve is on vacation.

    I recently engaged in a discussion with someone that was building an application on SQL Server. This person had a bunch of SQL code that was being put in stored procedures and then being sent to client sites. The developers were worried about clients modifying their code and wanted to send “secure updates” to the client by encrypting the stored procedures and giving the clients the encrypted text.

    Apart from the hassles of getting this to work, I asked by would they bother. There are decryption routines available and this isn’t meant to be a secure way to hide your code. Heck, even application code can be decompiled, and if they’re likely to mess with the code, they likely have the skills to get the source.

    So for this Friday’s poll, I’m wondering about how you feel about encrypting code in SQL Server. I want to know what you think.

    Is there a point?

    Is there a reason to encrypt stored procedure code? After all, there are many, many vendors that sell applications built on SQL Server, with stored procedures.  Most of that code isn’t encrypted and it’s usually not a problem. Most customers don’t mess with the code and there are usually prohibitions written into support agreements.

    Personally I don’t think there are many great ideas, and likely very, very few in the database space, that are worth securing. Someone doesn’t buy a software package so the can learn how you wrote it. Most of them buy software because it solves a problem and saves them time. If you can deliver a well performing, and good looking application, no one cares about the code.

    But I’m curious what the rest of you think, both end users and software developers. Is there really a good reason to worry about encrypting your code?

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available atsqlservercentral.mevio.com. Comments are definitely appreciated and wanted, and you can get feeds from there.

    You can also follow Steve Jones on Twitter:

    Overall RSS Feed:  or now on iTunes! 

    Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.