Voice of the DBA

Tag: software development

  • You Don’t Know Enough

    Always be learning

    We always expect developers to test their own code and be sure that it works as expected before they release it for anyone else to use. However we should be aware that developers won’t think of all the edge cases that might break their code, so a good software process includes another group (QA) that tests the software separately, and hopefully also reviews the code as well.

    Why do we do this? It’s because you can’t be sure that just because code passes your own tests that it is well written. You can only be sure that it passes the various tests you have designed, which is likely a subset of all possible tests it ought to pass.

    Bruce Schneier wrote a piece that talks about this from the security perspective. If a system fails initial testing, we know there’s a problem. However if it passes those tests, we still don’t know it’s secure. There still might be other vulnerabilities, perhaps even obvious ones. Only through exhaustive testing and review of the code, can we gain any sense of confidence in the security of a system. Even then we would still want to include some monitoring of the system as vulnerabilities might be discovered at a later time.

    Each of us has some limited amount of knowledge about the technology we work with, but there is one common thing we all share: we can all learn more.  Those limitations of our knowledge carry over to the code we write, and mean that we won’t necessarily completely test our code to cover all possibilities.  We might not even remember to test for some things as our work gets more complicated.

    We need to work with others to ensure enough code coverage and have some level of confidence in the quality of our work. Today’s systems are just too complex for one person to completely understand. Once you accept that and learn to work in a team, critiquing the code of others and accepting criticisms from them on your work, you will find the quality of your software will rise.

    Steve Jones

    The Voice of the DBA Podcasts

  • How to Fix Connect

    Microsoft Connect is the place to submit feedback

    The Connect system is the main way that all of us can feed back information on SQL Server to Microsoft . You can use this system to submit a bug or a suggestion, and your submission will go to the SQL Server development team so that they can respond. There is the ability to comment on other people’s posts, view workarounds that Microsoft or another user have posted, and vote a suggestion up or down. A great example that’s one of the most voted on items is the Create or Replace idea.

    Recently a large number of Connect items were closed, including a few that I had submitted. Based on all the Twitter comments, it seems that most of these items were closed and marked as “Won’t Fix”, which I assume means these will not be fixed for SQL 11.

    That’s good and bad. Having watched the Connect Feed for SQL Server, I’m surprised by some of the suggestions that I see come through. While I can appreciate someone wanting to know when SQL 11 “Denali” will be released, I’m not sure it’s worth a Connect submission. Or this brilliant duplicate indexes note. I feel bad for the people that triage these requests since these not-very-well-thought-out submissions create ill will and waste time. How would you like to get these type of suggestions for your software? My guess is most of these suggestions ought to be closed and this was a good thing.

    But it’s also discouraging for those of us that submit feedback and don’t necessarily get a good response on why our feedback doesn’t make sense, especially when you have dozens of people voting for the idea.

    For a long time I really liked the SQLWish email address where one could send ideas to Microsoft. That was discontinued in favor of Connect, which I think is a good idea. However I think Connect has a scale problem and doesn’t necessarily work as well for “ideas” as it does for bugs.

    I’m not sure how we can fix it, but one thing I’d like to see is a ranking of the top xx items that could be considered for the next version. Feed that back to the community and let us give you opinions on whether or not those items are still important. I know we can’t necessarily drive development, but I do think that SQL Server can evolve into a product that we are more likely to upgrade if our feedback is visibly and obviously considered.

    Steve Jones

    The Voice of the DBA Podcasts

  • Quality Over Timing

    Is quality job one?

    Is quality really the number one job of software developers? I think we’d all like this to be the case, but I suspect that in many companies it’s not. This piece is a few years old, and it talks about how quality has become more important at many large software vendors. Looking back across the five years since the article was written, do you agree?

    Whether you are a commercial software company, or building applications for internal use by a company, there are so many external pressures to finish or ship an application that quality becomes a second, or even third, tier goal. The need to have people begin using the software, with those last minute features added, means that quality gets cut in some areas.

    We build software with the best of intentions, and I understand that there must be a deadline for the software to start being used. However I think that the balance between finding a finishing point for a version of software and quality is leaning a bit too often towards the deadline taking priority.

    In my ideal world, we would pick a stopping point, and then ensure that the development and testing of everything in progress before the stopping point is completed. In other words, we can’t pick a ship date, but we can pick a design end date, and from there work through the proper build and test from that point forward to a well built piece of software.

    I don’t know if we’ll ever get to the point where the overall image of software is that it is mostly well built, but I can hope we do.

    Steve Jones

    The Voice of the DBA Podcasts

  • What’s Your Code Quality?

    The best measure of code quality.

    Today we have an editorial reprinted from Jan 3, 2006 as Steve is on vacation.

    I saw this a piece on code quality recently, specifically mentioning Java development managers and their work on quality. They seem to strive for it and fall short, but I don’t think the results from .NET development managers would be much different.

    The piece talked about most managers not measuring quality or if they do, not starting until the project is over half complete. That’s interesting because in the jobs that I’ve done software development, we were most concerned about timelines, and code was usually graded in one of three ways. Works, doesn’t work, or needs more work. And most things passed through all 3 of these phases during a development project.

    But interestingly enough, I’ve never had quality measured as a DBA. All the T-SQL work either does what it is supposed to do or it doesn’t. And if it doesn’t, we work some more on it 🙂

    There’s never been any measure of code quality for me, and I’m not sure how I’d go about doing it. It seems from the article that they looked at bugs reported v lines of code. I’m not sure that’s the best measurement since I could write some code that works, but is very slow to execute. Or that has hard-coded information that makes maintenance a nightmare.

    I’m not a software expert, especially with regard to quality. To me it either works as I expect it to and well enough or it doesn’t. I kind of use that thumbnail estimation in that a particular item, stored procedure, function, etc. either returns the results it should or it doesn’t, and it works in an acceptable time frame, or it doesn’t. Comparing a method call to calculate interest on a line to a stored procedure that produces a sales by month result is hard, and I’m not sure I could setup concrete ways to do it.

    But I know people are trying. Like the company that sponsored the survey. So I’m wondering, do any of you measure quality? Know of a good way to do it?

    Steve Jones

    (published at http://www.sqlservercentral.com/articles/Editorial/72366/)