Voice of the DBA

Tag: software development

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

  • Strike Force

    Would you want to be part of an elite strike force inside your company? An IT team that can solve complex problems and save the day when there’s a crisis? Or even a large challenge facing your department?

    It sounds cool, and there’s a neat description of an “A-Team for IT” in this article, talking about the types of people that are needed. Overall I think this is a more a list of the ideal types of people that are important for almost any project, especially one that might involve significant investment from a company.

    This started me thinking about the type of person I have been in the technology world. I haven’t provided air support, or been the Über hacker or Fearless Leader that does something amazing. For the most part, I think I’ve been the infrastructure sherpa. Quietly working along, providing support where it’s needed, and just making sure things get done.

    That’s what I think most of us do on a daily basis. We grind away at work, building and fixing things that many people appreciate, but don’t stand out. We don’t get the spotlight, most people in the company aren’t aware of what we do, and that’s fine. Being part of a crisis or strike team sounds cool and exciting, but I think most of us would rather do a solid day’s work for an honest days pay and then go home and get on with out lives.

    Steve Jones