Voice of the DBA

Tag: software development

  • Is Unit Testing Important?

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

    I saw a question on the SQLServerCentral ASK site the other day asking about unit testing for T-SQL stored procedures. There weren’t many responses, but they were interesting to me.

    I wondered how many people bothered to test their stored procedures as a unit. It seems that the idea of test driven development, or even of comprehensive testing of SQL code isn’t very mature. If a query runs and appears to return the data we want, do we bother to test for edge or unusual data conditions?

    Or do we even know how to write those kinds of tests?

    Testing your code as it’s being written is a well known way to reduce your technical debt and ensure better code when it’s released. It’s also a way to lower the cost of maintaining your software over its lifetime. However it slows down development as well.

    That’ s not why most people don’t test their code well. The big reason is that it’s B-O-R-I-N-G.

    But does it matter? Is there really an issue? After all most T-SQL queries are built to scale. If the data is correctly assembled into sets with a small set of data, it will work correctly on large sets of data. Maybe not efficiently, but it tends to work. So is unit testing of T-SQL code important?

    My guess is that it is not all that important. At least not as important as performance tuning. If you have extra time to spend on a query, I think most DBAs would prefer to spend it on making the SQL more efficient, not more tested.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are available at sqlservercentral.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.

    I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.

  • The Worst Code

    This piece was written awhile ago by Jeff Atwood, but I saw a mention about it recently. It’s about software developers hating software. It’s a fun piece, and written a bit tongue-in-cheek, though with a lot of truth in there. Certainly lots of the “bundled software” that come with gadgets is unnecessary and poorly tested. That’s sad, as there is the chance to add value to products if the software is well written, and perhaps, open sourced.

    However the thing that caught my eye was the ending. Mr. Atwood says that if a developer in an interview doesn’t say the worst code they’ve seen lately is their own, then they may not be a competent developer. I hope that part is also a joke, and I suspect it is. Though I also think that it’s a healthy attitude for people to see room for improvement in most of their endeavors.

    No matter what type of task you are performing, and certainly programming is an area many of us focus, complacency is a poor way to approach your work. We know we won’t be perfect, we know we’ll make mistakes, we know there’s room for improvement, and we know we NEED TO GET THE PROJECT DONE. The balance we strike in moving forward should be accomplishing tasks, learning what we did right and wrong, doing more of the former (and less of the latter) in the future, all while taking pride in the work we do well.

    Certainly some people are obsessive and perfectionists. There’s probably another few choice words some of you have for those individuals, but most of us need to balance our desire to build something amazing, with the necessity of completing work. We also need those little wins that come from having our work solve problems, even if we’d build software better the next time. The important thing is that you try to do better the next time.

    Steve Jones

    Listen to the MP3 Audio ( 2.7MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA 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.

  • Developers, developers, developers

    StackOverflow ran a survey for their members in 2013 and released some results recently. The results are on their blog, along with some observations about the data. While most of this audience aren’t in the development space, some may be, and the impacts of the results could certainly affect our careers.
    Most developers and applications aren’t getting much accomplished without data, and whether they use SQL Server, another RDBMS, a NoSQL platform, or a dumb data store, chances are we can help them. Chances are also that if they make a poor decision, we’ll be dealing with the mess in some way.
    The observations note that mobile is still growing, and I believe that. I still think the mobile market will dwarf the PC explosion we’ve seen the last 20 years, and that means we should be preparing and understanding how to deal with data from mobile devices, think about scaling to meet lots of small, quick calls for data from a device.
    I also like the fact that more people are working remotely. If they let developers work remotely, that’s a good step towards DBAs becoming remote as well. As someone that has worked from home for over a decade, I appreciate the challenges, but I still can’t help but thing my productivity is much higher than it ever was in an office.
    It’s also nice that the second most popular language (in use) is SQL. Not necessarily T-SQL, as I’m sure various other platforms are developed on, but it does show that SQL is very important, even to developers. Perhaps the next time a developer is struggling with SQL, you can refer them to this survey and then see if you can help them improve their query skills.
    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA 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.

  • Continuous Delivery

    At Red Gate Software, we have a product called Deployment Manager. Its aim is to smooth and ease the process of deploying changes in your software from environment to environment, database and application code. What I like about the product isn’t that it makes the overall software development process easier, though it does. It’s that the team behind the product is using their own tool and technique to . They’re practicing Continuous Delivery (CD), even as they work to help make it easier for you to practice CD.

    That’s pretty neat. Even if you don’t want to release software that often, you have to admit that’s cool. I once worked at a company that released changes every week for well over a year, and I have to say that the development team was very proud of what we accomplished every week when the deployment was complete.

    However we didn’t release every change every week, and as the Deployment Manager team as learned, some things take longer than a week. There are particular challenges to handling the partial release of software, and while you can overcome lots of them, at times you have to delay a release. However, I’d much rather delay my release a week or two than months. The latter has happened in many places I’ve worked when a large application is being built.

    At Red Gate we do think that continuous delivery is an important skill and valuable technique in software development. This idea gathers a lot of focus at Red Gate as we build tooling to help with the challenges of implementing CD. However the idea of CD doesn’t mean that you constantly update your own software for customers. It’s entirely plausible to practice CD internally, releasing changes to test and staging environments many many times before you release a change to production. The idea in CD is that you know how to, and practice, deploying software regularly. That way you’re assured you can actually perform a release when you need to.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and Mevio . feed

    The Voice of the DBA 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.