Voice of the DBA

Tag: software development

  • Building Better Software

    The Do Not Disturb bug would have seemed to be easy to fix, but perhaps there wasn't time before it fixed itself.
    The Do Not Disturb bug would have seemed to be easy to fix, but perhaps there wasn’t time before it fixed itself.

    Why is programming so hard, especially on seemingly simple problems. Here’s a short piece on the Apple iOS6 Do Not Disturb bug that surprised me. The bug is fixed, as of Jan 7, because it was a date issue. According to the article, the programmers that implemented the Do Not Disturb function used the ISO calendaring dates, which do not work as expected this year. The details are in the article, and it reads like an edge case, but it’s not one I’d expect to have slipped by Apple’s QA department.

    These types of programming errors seem to regularly slip by developers. The situation has gotten better since the days of VB6 when it seemed everyone that could complete a week long course was building buggy applications at a frightening rate. While I still think there are plenty of hack developers out there, it seems that with all the publication and information available, there are better programs being built in many organizations.

    However simple bugs can still slip through. The maintenance plan bug in SQL Server 2005 showed Microsoft that there’s no such thing as a simple fix or patch. In this case, even the Apple documentation for developers (Fixed Format section) notes that the ISO date should not take precedence when there is a conflict. Apparently not all of Apple’s developers are following their own documentation.

    Developing software is easy to do, but hard to get right, especially when you are building software that you expect to last a long time and get used in a variety of ways. Experience, practice, learning from your mistakes, and a deep understanding of the business you are working in help developers write better software over time. It’s a reason why you should ensure you work to retain your talented developers. They are much harder to replace than the lines of code they produce. A new developer may produce the same amount of work in a short period, but I’d wager they produce many more bugs as well.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Message Queues in Software

    Message queues are great ways to scale out your application, among other uses.
    Message queues are great ways to scale out your application, among other uses.

    I had high hopes for Service Broker when it was introduced in SQL Server 2005, but it doesn’t seem that many people have bothered to architect their applications to take advantage of it. I do see some people starting to use it, but it hasn’t been anywhere near the levels of adoption that I would expect.

    I ran across a piece on 10 reasons to use a message queue that points out a number of possible ways that queuing could help you. There are some great ideas, including a few suggestions for scalability and resiliency for your application. One of the more interesting ones to me is the idea of using a queue to buffer the slower processes that may be a bottleneck in your application.

    I still think this is a great way to build applications, especially distributed ones, using queues instead of linked servers, ETL, etc. However until we get more people developing in a service oriented architecture, and getting experience, I think we will struggle to see message queuing gain widespread acceptance. This is a departure from the way most developers are comfortable with building an application, and the way that queues work in SQL Server certainly confuses many DBAs.

    I’d challenge many of you to think about using queuing in any applications where you are moving data from one database to another, or trying to trigger an action on a remote machine. It’s a great way to scale out your systems, and it’s a very solid, reliable architecture for your systems.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • The Shortage of Programmers

    The fellas
    Is there a shortage of talent?

    This editorial was originally published on May 12, 2008. It is being re-run as Steve is on vacation.

    At least at the top. I was reading the Joel on Software latest entry the other day about architecture astronauts and it seemed to make some sense in terms of developers building things they only think people will need, but the tone of the article was quite a rant. It actually sounds very different and a little angry compared to other things he’s written in the past.

    It was at the end of the rant that I saw this: “Why I really care is that Microsoft is vacuuming up way too many programmers.” and “…between Microsoft and Google the starting salary for a smart CS grad is inching dangerously close to six figures and these smart kids, the cream of our universities, are working on hopeless and useless architecture astronomy…”

    That last paragraphs (there’s more ranting I left out), seem to sum up why Joel is angry. Whether he should be or not is another story. I tend to believe that if someone can pay more and someone wants to work for more and accept the environment, they should be allowed to do so. It might not seem fair and seem to give an advantage to a larger company, but I think we should all be allowed to choose for whom we work and why we go there.

    The top graduates in any field are always in demand, really the top people in any field, and they will end up getting bigger salaries, and help to drive up the cost of labor. It happens in movies, in sports, and many other fields, and the top people get the headlines. But for every baseball or basketball player making $10 million a year, there are dozens getting $200k or $300k and that’s not reported quite as widely.

    The same thing happens here. Or at least I think it is happening here with the top graduates getting close to 6 figures. While that might push up the cost of the second tier and other CS grads (and other people changing jobs), I’m not sure it means that all programmers will cost this much. I think the salaries might rise a little over time, but overall it takes time for those averages to filter through to the HR departments and raise salaries. So most of us don’t benefit and it’s not worth getting upset about.

    In smaller companies this might happen quicker as managers or even owners have the flexibility to quickly decide to pay more for a particular person, but I’m not sure how many companies want to match the larger salaries or perks of a Microsoft or Google. Or even can match that environment. If someone wants to go to work at a large company, with a big budget, lots of resources, the prestige of being in the news, etc., why is that a bad thing?

    I guarantee you that for every 10 people that want to work at Microsoft or Google, there are some other very talented people that want to work in a smaller environment, avoid bureaucracy, have a larger impact on the company, or just live in a different place. I’m a good example of this.

    A lot of people have mentioned they think I have some talent in the database area and I think it would be cool to work for Microsoft, especially in the SQL Server group, but unless I can work from Denver, there probably isn’t an offer they can make to get me to move to Redmond. There’s a lot more to my career than money or perks.

    ‘Course I wouldn’t mind them making an offer. Being the “Voice of Microsoft” has a nice ring to it :P.

    Steve Jones

    The Voice of the DBA Podcasts

    Everyday Jones

    The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.

    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 Principle of Least Privilege

    One of the tenets of good security is that no person or process is granted more rights than it needs to accomplish a task. This is the Principle of Least Privilege, and is designed to ensure that your system is as secure, stable, and predictable as possible.

    For a SQL Server instance, this means that unless a person or process needs to perform instance level changes (configuration, patching, etc.), then they should not have instance level privileges. If a process accesses data in a database, there is no need to grant sysadmin privileges, even if they do need db_owner privileges.

    Many software packages require sysadmin access be granted, often without any justification. Developers build software as a sysadmin on their own workstation, or on a development server. They often don’t understand or realize that less privileges will still allow their software to work. As a result we find software running under elevated privileges, which can be a security risk if there are bugs or injection holes in the software.

    It’s hard to make changes later on, and it can be frustrating to argue with vendors that their software doesn’t need elevated privileges. The best way to combat this is to educate yourself and any developers you know about security.

    Adding login or user accounts does not require sa privileges. The securityadmin and db_securityadmin roles can be used. The rights to create objects in a database can be handled with granular permissions in a schema, or with the db_ddladmin role instead of db_owner.

    Work with limited rights when you can, and help other learn how to work with the minimum they need and we’ll all be more secure.