Voice of the DBA

Tag: software development

  • 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/)

  • Slow Fixes

    Moving Slow

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

    There’s an interesting piece at the Washington Post on Microsoft’s delays in releasing patches, with some analysis showing that when the flaw is disclosed to the public, a patch comes out much quicker. After some analysis over the last 3 years and researched the dates Microsoft knew about the issue and the dates that the patches were released.

    Surprise, when everyone knows, the patches come out quicker. It seems that the piece is intended to take a shot at Microsoft’s patching process, and maybe it is, but there are some interesting things in there to talk about. First of all is the time lag.

    Is this any different from any software vendor or even internal corporate software? If your boss knows, or the client knows, don’t you work a little harder and a little quicker? Isn’t it more critical and don’t you rush things in addition to working harder when it’s a “public” patch that is needed?

    I’m sure we all do. And it’s human nature to put more effort into something that’s widely perceived as an issue and less effort if you know that you may have more time. We all do that and our work schedules, effort, and productivity change depending on a variety of things, including the importance of the work.

    The piece also leaves open a number of questions and mentions this, noting that the analysis might be flawed. There’s no mention of if the rushed (or delayed) patches had to be repatched later. There’s concern over patches applying to one area, but other similar flaws found in other parts of the software remaining unpatched. That’s something for sure that should be examined in looking for re-patches or whether things are rushed. There’s also the lack of examination on what else was happening inside Microsoft, and whether people working on other projects had to be pulled off them.

    We all know that delays things as well. They take time to get their head back into code, they may be annoyed, a critical person could be out, etc. Not to mention that the statistical methods might not be the best ones, but I’ll leave that to the mathematicians to figure out.

    Patching is hard. As is finding bugs. I think Microsoft has done a much better job over the last 3-4 years and the quality of software, at least SQL Server, has improved. However there is still definitely room for more improvement.

    Steve Jones

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

  • You Should Know

    Are you building your knowledge?

    What skills don’t you get taught about being a good database developer? If you are like most people, there is a whole list of things that are good practices for writing code, but you weren’t aware of. And like most people, you might be confused about what things you ought to start learning because of the huge amount of advice from people that are sure “their” way of building software is the best way.

    I ran across a great article that tackles this subject, and talks about a few fairly critical things that many developers don’t learn. Or maybe they learn them, but don’t believe they provide benefits (like version control). It’s amazing how often I find developers, and DBAs, reinventing some process, or struggling through the same tasks over and over because they haven’t bothered to build a repeatable process.

    The best quote in the article is this one:  Setting up a staging server should be easy.  If it is not easy, you already have a problem in your infrastructure…” It’s absolutely true, and if you don’t think this is an issue for your company,  I have two words for you.

    Disaster recovery.

    A staging server is the equivalent of setting up your system again in a DR scenario. If that’s not easy, then the likelihood of you doing it in a timely, efficient, and acceptable-to-your-boss manner in an emergency is pretty low.

    Do yourself a favor at get a staging/QA/UA server set up in your environment. In today’s multi-code, hypervisor-ridden technology shop, there’s no good excuse not to.

    Steve Jones

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

    The Voice of the DBA Podcasts

  • Operating in Failure

    This editorial was originally published on Sept 25, 2006.

    This quote is great: “Any large system is going to be operating in failure mode most of the time.”

    It’s from Peter Coffee’s essay on learning from paper based systems and what works in their digital equivalents. Peter examines the conversion of a paper based system for keeping track of Boy Scouts’ work on merit badges as the process moves to an online system. He points out a few flaws in the design matching the process.

    More importantly, he points out that the system fails in a few ways, which is to be expected, but it doesn’t fail gracefully. I think this is a good point and one that most developers fail to take into account. Most systems will “fail” in some way and should be able to handle that failure. Whether it’s data entered incorrectly, a mishmash of keys hit, incomplete data, or something else. We seem to expect that our systems will move along perfectly and that our systems will “force” the users to work in the approved method and process, thereby improving efficiency and ensuring things work well.

    I’ve encountered this in many places, but none more apparent then surveys that we used to send out to customers. We’d require answers to many questions to ensure that we could properly fill the parent and child tables in the database and ensure proper reporting. The developers were happy to run along and build this and make it work as expected. My issue, however, was that the surveys were sometimes long and complicated and we should be sure to capture some information in the event the user stops early or has connectivity issues. In other words, assume we will have issues and plan for them.

    You’ve probably encountered this in other places as well. Every system, especially web based ones, should be expected to fail at some point and you should gracefully deal with those issues. We’re all human and we make mistakes and the systems we build will have bugs, problems, or even unintended uses by our clients.

    So plan to fail and you’ll be better off.

    (This editorial is published at: http://www.sqlservercentral.com/articles/Editorial/72149/)