Voice of the DBA

Tag: software development

  • Practicing Deployments

    Practice makes perfect, especially for deployments.
    Practice makes perfect, especially for deployments.

    It’s said that amateurs practice until they can get something right. Professionals practice until they don’t get something wrong. That’s the idea, and while professionals make mistakes, they make far fewer than those that don’t approach their craft as a professional task.

    Many of us in the data industry develop software in some way. Whether we write queries in T-SQL or build projects in .NET, we produce code to accomplish some task. I’d like to think that many of us improve our skills over time, preferably by practicing new techniques and learning from our mistakes. I know some people stick with the tried and true methods without gaining skill over time, which not only hurts one’s career, but also doesn’t give an employer a reason to value their work.

    However the deployment of software, which encompasses more than the developer(s), doesn’t improve in many cases. Deployment includes operational people’s skills, scheduling dowtime with clients, possible even the briefing of support personel. However the whole process is often performed poorly. Deployments fail, or require more time than expected. People view them as a pain, and software deployment tends to happen less often than it could, resulting in a large software inventory.

    There’s a great quote from James Moore on how we can deploy software better: “…deployments are hard, but rather than long-winded planning, they need constant practice, testing and refining, and we could only do this by deploying early.” Red Gate Software has learned that deploying more often results in the company gaining skill in deploying software, resulting in more successful software changes in applications.

    The improvement you make in your software can bring tremendous value to your clients, but only if they can use those features in the software. Learning to push those changes out in a repeatable, professional manner is a great way to ensure your clients and customers trust you to deliver new features and enhancements that meet their needs.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Serverless Software

    Developers may never see groups of servers like this again in the future.
    Developers may never see groups of servers like this again in the future.

    I love the words “loosely coupled.” At times in my career, I’ve built software and have aimed to ensure that processes, workflows, and components worked well on their own. In the places where I had to work with data or services on different physical machines, I tried to ensure that each item would run separately, and communicate when needed, but wouldn’t fail if another machine was down.

    That’s kind of the idea proposed in the article that says the future of software is serverless? It’s an interesting read, talking about the advances in cloud services that can change the way developers build applications. Developers should think about liking services, and pieces of applications, ignoring the idea their systems are tied to specific servers.

    It’s a future that I think makes sense for most environments. Development shouldn’t be concerned about the size or care of physical machines. Instead they should think about building on a platform of services, and expecting the scale to grow or shrink as needed, without code changes.

    I do think this could be the future in which development proceeds inside companies, as well as for commercial software. However vendors need to sell “private clouds” which function in the same way as the public ones, for those companies that want to control, and invest in, their own hardware.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • 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.